maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp

3371 lines
129 KiB
C++
Raw Normal View History

moved Writer.cpp -> BitcodeWriter.cpp to make it more unique in the tree. llvm-svn: 36549
2007-04-29 13:31:57 +08:00
//===--- Bitcode/Writer/BitcodeWriter.cpp - Bitcode Writer ----------------===//
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
//
// The LLVM Compiler Infrastructure
//
Remove attribution from file headers, per discussion on llvmdev. llvm-svn: 45418
2007-12-30 04:36:04 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
//
//===----------------------------------------------------------------------===//
//
// Bitcode writer implementation.
//
//===----------------------------------------------------------------------===//
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "ValueEnumerator.h"
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
#include "llvm/ADT/StringExtras.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "llvm/ADT/Triple.h"
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
#include "llvm/Bitcode/BitstreamWriter.h"
promote LLVMBitCodes to be a public header llvm-svn: 36358
2007-04-23 09:01:37 +08:00
#include "llvm/Bitcode/LLVMBitCodes.h"
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
#include "llvm/Bitcode/ReaderWriter.h"
[Bitcode][Asm] Teach LLVM to read and write operand bundles. Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
2015-09-25 07:34:52 +08:00
#include "llvm/IR/CallSite.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Constants.h"
IR: Split out DebugInfoMetadata.h, NFC Move debug-info-centred `Metadata` subclasses into their own header/source file. A couple of private template functions are needed from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them to `lib/IR/MetadataImpl.h`. llvm-svn: 227835
2015-02-03 02:53:21 +08:00
#include "llvm/IR/DebugInfoMetadata.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/DerivedTypes.h"
#include "llvm/IR/InlineAsm.h"
#include "llvm/IR/Instructions.h"
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
#include "llvm/IR/LLVMContext.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Module.h"
#include "llvm/IR/Operator.h"
IPO: Add use-list-order verifier Add a -verify-use-list-order pass, which shuffles use-list order, writes to bitcode, reads back, and verifies that the (shuffled) order matches. - The utility functions live in lib/IR/UseListOrder.cpp. - Moved (and renamed) the command-line option to enable writing use-lists, so that this pass can return early if the use-list orders aren't being serialized. It's not clear that this pass is the right direction long-term (perhaps a separate tool instead?), but short-term it's a great way to test the use-list order prototype. I've added an XFAIL-ed testcase that I'm hoping to get working pretty quickly. This is part of PR5680. llvm-svn: 213945
2014-07-25 22:49:26 +08:00
#include "llvm/IR/UseListOrder.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/ValueSymbolTable.h"
Begin adding experimental support for preserving use-list ordering of bitcode files. First, add a new block USELIST_BLOCK to the bitcode format. This is where USELIST_CODE_ENTRYs will be stored. The format of the USELIST_CODE_ENTRYs have not yet been defined. Add support in the BitcodeReader for parsing the USELIST_BLOCK. Part of rdar://9860654 and PR5680. llvm-svn: 146078
2011-12-08 05:44:12 +08:00
#include "llvm/Support/CommandLine.h"
assert(0) -> LLVM_UNREACHABLE. Make llvm_unreachable take an optional string, thus moving the cerr<< out of line. LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for NDEBUG builds. llvm-svn: 75379
2009-07-12 04:10:48 +08:00
#include "llvm/Support/ErrorHandling.h"
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
#include "llvm/Support/MathExtras.h"
Merge System into Support. llvm-svn: 120298
2010-11-30 02:16:10 +08:00
#include "llvm/Support/Program.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "llvm/Support/raw_ostream.h"
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
#include "llvm/Support/SHA1.h"
Add missing standard headers. Patch by Joerg Sonnenberger! llvm-svn: 122193
2010-12-20 04:43:38 +08:00
#include <cctype>
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
#include <map>
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
using namespace llvm;
where possible, encode symtab names with 7 bits per char instead of 8. This shaves 110K off kc++ to 3514K. Before: Block ID #14 (VALUE_SYMTAB): Num Instances: 2345 Total Size: 1.50425e+07b/1.88031e+06B/470077W Average Size: 6414.69b/801.837B/200.459W % of file: 51.8057 Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 2345/1 Tot/Avg Records: 120924/51.5667 % Abbrev Recs: 85.1791 after: Block ID #14 (VALUE_SYMTAB): Num Instances: 2345 Total Size: 1.41229e+07b/1.76536e+06B/441341W Average Size: 6022.56b/752.82B/188.205W % of file: 50.2295 Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 4690/2 Tot/Avg Records: 120924/51.5667 % Abbrev Recs: 85.1791 llvm-svn: 36758
2007-05-05 04:52:02 +08:00
/// These are manifest constants used by the bitcode writer. They do not need to
/// be kept in sync with the reader, but need to be consistent within this file.
enum {
// VALUE_SYMTAB_BLOCK abbrev id's.
VST_ENTRY_8_ABBREV = bitc::FIRST_APPLICATION_ABBREV,
shave another 150K off of kc++, by using a 7-bit encoding for BB names where we can. This shrinks kc++'s down to 3368K, with a VST record of: Block ID #14 (VALUE_SYMTAB): Num Instances: 2345 Total Size: 1.29508e+07b/1.61885e+06B/404713W Average Size: 5522.73b/690.342B/172.585W % of file: 48.0645 Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 7035/3 Tot/Avg Records: 120924/51.5667 % Abbrev Recs: 100 Isn't it nice to be able to optimizer bc size without touching the reader? :) llvm-svn: 36759
2007-05-05 04:58:35 +08:00
VST_ENTRY_7_ABBREV,
add a char6 abbrev for bbnames and value names. This represents each character with 6 bits where possible. This shrinks kc++ from 3324164B to 3183584B. The old VST was: Block ID #14 (VALUE_SYMTAB): Total Size: 1.26713e+07b/1.58391e+06B/395978W Average Size: 5403.53b/675.442B/168.86W % of file: 47.6484 The new one is: Block ID #14 (VALUE_SYMTAB): Total Size: 1.15467e+07b/1.44334e+06B/360834W Average Size: 4923.96b/615.495B/153.874W % of file: 45.3368 This is 11% smaller than the VST in the bytecode format. llvm-svn: 36771
2007-05-05 09:26:50 +08:00
VST_ENTRY_6_ABBREV,
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
VST_BBENTRY_6_ABBREV,
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
// CONSTANTS_BLOCK abbrev id's.
CONSTANTS_SETTYPE_ABBREV = bitc::FIRST_APPLICATION_ABBREV,
CONSTANTS_INTEGER_ABBREV,
CONSTANTS_CE_CAST_Abbrev,
add an abbrev for loads. This shrinks the function block about 50K, from: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.8434e+06b/1.10542e+06B/276356W % of file: 35.6726 Average Size: 3772.78b/471.598B/117.899W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 0 to: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.44518e+06b/1.05565e+06B/263912W % of file: 34.6203 Average Size: 3602.89b/450.362B/112.59W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 22.2077 llvm-svn: 36779
2007-05-05 15:44:49 +08:00
CONSTANTS_NULL_Abbrev,
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add an abbrev for loads. This shrinks the function block about 50K, from: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.8434e+06b/1.10542e+06B/276356W % of file: 35.6726 Average Size: 3772.78b/471.598B/117.899W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 0 to: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.44518e+06b/1.05565e+06B/263912W % of file: 34.6203 Average Size: 3602.89b/450.362B/112.59W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 22.2077 llvm-svn: 36779
2007-05-05 15:44:49 +08:00
// FUNCTION_BLOCK abbrev id's.
add some abbrevs for ret and unreachable, shrinking kc++ from 2717360->2705388 llvm-svn: 36823
2007-05-06 09:28:01 +08:00
FUNCTION_INST_LOAD_ABBREV = bitc::FIRST_APPLICATION_ABBREV,
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
FUNCTION_INST_BINOP_ABBREV,
Assembly and Bitcode support for unsigned/signed overflow flags and exact sdiv flags. llvm-svn: 76475
2009-07-21 05:19:07 +08:00
FUNCTION_INST_BINOP_FLAGS_ABBREV,
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
FUNCTION_INST_CAST_ABBREV,
add some abbrevs for ret and unreachable, shrinking kc++ from 2717360->2705388 llvm-svn: 36823
2007-05-06 09:28:01 +08:00
FUNCTION_INST_RET_VOID_ABBREV,
FUNCTION_INST_RET_VAL_ABBREV,
[opaque pointer type] Bitcode support for explicit type parameter on GEP. Like r230414, add bitcode support including backwards compatibility, for an explicit type parameter to GEP. At the suggestion of Duncan I tried coalescing the two older bitcodes into a single new bitcode, though I did hit a wrinkle: I couldn't figure out how to create an explicit abbreviation for a record with a variable number of arguments (the indicies to the gep). This means the discriminator between inbounds and non-inbounds gep is a full variable-length field I believe? Is my understanding correct? Is there a way to create such an abbreviation? Should I just use two bitcodes as before? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7736 llvm-svn: 230415
2015-02-25 09:08:52 +08:00
FUNCTION_INST_UNREACHABLE_ABBREV,
FUNCTION_INST_GEP_ABBREV,
where possible, encode symtab names with 7 bits per char instead of 8. This shaves 110K off kc++ to 3514K. Before: Block ID #14 (VALUE_SYMTAB): Num Instances: 2345 Total Size: 1.50425e+07b/1.88031e+06B/470077W Average Size: 6414.69b/801.837B/200.459W % of file: 51.8057 Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 2345/1 Tot/Avg Records: 120924/51.5667 % Abbrev Recs: 85.1791 after: Block ID #14 (VALUE_SYMTAB): Num Instances: 2345 Total Size: 1.41229e+07b/1.76536e+06B/441341W Average Size: 6022.56b/752.82B/188.205W % of file: 50.2295 Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 4690/2 Tot/Avg Records: 120924/51.5667 % Abbrev Recs: 85.1791 llvm-svn: 36758
2007-05-05 04:52:02 +08:00
};
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
static unsigned GetEncodedCastOpcode(unsigned Opcode) {
switch (Opcode) {
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
default: llvm_unreachable("Unknown cast instruction!");
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
case Instruction::Trunc : return bitc::CAST_TRUNC;
case Instruction::ZExt : return bitc::CAST_ZEXT;
case Instruction::SExt : return bitc::CAST_SEXT;
case Instruction::FPToUI : return bitc::CAST_FPTOUI;
case Instruction::FPToSI : return bitc::CAST_FPTOSI;
case Instruction::UIToFP : return bitc::CAST_UITOFP;
case Instruction::SIToFP : return bitc::CAST_SITOFP;
case Instruction::FPTrunc : return bitc::CAST_FPTRUNC;
case Instruction::FPExt : return bitc::CAST_FPEXT;
case Instruction::PtrToInt: return bitc::CAST_PTRTOINT;
case Instruction::IntToPtr: return bitc::CAST_INTTOPTR;
case Instruction::BitCast : return bitc::CAST_BITCAST;
Fix spacing, forward declare order. llvm-svn: 194985
2013-11-18 10:51:33 +08:00
case Instruction::AddrSpaceCast: return bitc::CAST_ADDRSPACECAST;
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
}
}
static unsigned GetEncodedBinaryOpcode(unsigned Opcode) {
switch (Opcode) {
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
default: llvm_unreachable("Unknown binary instruction!");
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897
2009-06-05 06:49:04 +08:00
case Instruction::Add:
case Instruction::FAdd: return bitc::BINOP_ADD;
case Instruction::Sub:
case Instruction::FSub: return bitc::BINOP_SUB;
case Instruction::Mul:
case Instruction::FMul: return bitc::BINOP_MUL;
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
case Instruction::UDiv: return bitc::BINOP_UDIV;
case Instruction::FDiv:
case Instruction::SDiv: return bitc::BINOP_SDIV;
case Instruction::URem: return bitc::BINOP_UREM;
case Instruction::FRem:
case Instruction::SRem: return bitc::BINOP_SREM;
case Instruction::Shl: return bitc::BINOP_SHL;
case Instruction::LShr: return bitc::BINOP_LSHR;
case Instruction::AShr: return bitc::BINOP_ASHR;
case Instruction::And: return bitc::BINOP_AND;
case Instruction::Or: return bitc::BINOP_OR;
case Instruction::Xor: return bitc::BINOP_XOR;
}
}
LangRef and basic memory-representation/reading/writing for 'cmpxchg' and 'atomicrmw' instructions, which allow representing all the current atomic rmw intrinsics. The allowed operands for these instructions are heavily restricted at the moment; we can probably loosen it a bit, but supporting general first-class types (where it makes sense) might get a bit complicated, given how SelectionDAG works. As an initial cut, these operations do not support specifying an alignment, but it would be possible to add if we think it's useful. Specifying an alignment lower than the natural alignment would be essentially impossible to support on anything other than x86, but specifying a greater alignment would be possible. I can't think of any useful optimizations which would use that information, but maybe someone else has ideas. Optimizer/codegen support coming soon. llvm-svn: 136404
2011-07-29 05:48:00 +08:00
static unsigned GetEncodedRMWOperation(AtomicRMWInst::BinOp Op) {
switch (Op) {
default: llvm_unreachable("Unknown RMW operation!");
case AtomicRMWInst::Xchg: return bitc::RMW_XCHG;
case AtomicRMWInst::Add: return bitc::RMW_ADD;
case AtomicRMWInst::Sub: return bitc::RMW_SUB;
case AtomicRMWInst::And: return bitc::RMW_AND;
case AtomicRMWInst::Nand: return bitc::RMW_NAND;
case AtomicRMWInst::Or: return bitc::RMW_OR;
case AtomicRMWInst::Xor: return bitc::RMW_XOR;
case AtomicRMWInst::Max: return bitc::RMW_MAX;
case AtomicRMWInst::Min: return bitc::RMW_MIN;
case AtomicRMWInst::UMax: return bitc::RMW_UMAX;
case AtomicRMWInst::UMin: return bitc::RMW_UMIN;
}
}
Initial implementation of 'fence' instruction, the new C++0x-style replacement for llvm.memory.barrier. This is just a LangRef entry and reading/writing/memory representation; optimizer+codegen support coming soon. llvm-svn: 136009
2011-07-26 07:16:38 +08:00
static unsigned GetEncodedOrdering(AtomicOrdering Ordering) {
switch (Ordering) {
NFC: make AtomicOrdering an enum class Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
2016-04-07 05:19:33 +08:00
case AtomicOrdering::NotAtomic: return bitc::ORDERING_NOTATOMIC;
case AtomicOrdering::Unordered: return bitc::ORDERING_UNORDERED;
case AtomicOrdering::Monotonic: return bitc::ORDERING_MONOTONIC;
case AtomicOrdering::Acquire: return bitc::ORDERING_ACQUIRE;
case AtomicOrdering::Release: return bitc::ORDERING_RELEASE;
case AtomicOrdering::AcquireRelease: return bitc::ORDERING_ACQREL;
case AtomicOrdering::SequentiallyConsistent: return bitc::ORDERING_SEQCST;
Initial implementation of 'fence' instruction, the new C++0x-style replacement for llvm.memory.barrier. This is just a LangRef entry and reading/writing/memory representation; optimizer+codegen support coming soon. llvm-svn: 136009
2011-07-26 07:16:38 +08:00
}
Add 'llvm_unreachable' to passify GCC's understanding of the constraints of several newly un-defaulted switches. This also helps optimizers (including LLVM's) recognize that every case is covered, and we should assume as much. llvm-svn: 147861
2012-01-11 02:08:01 +08:00
llvm_unreachable("Invalid ordering");
Initial implementation of 'fence' instruction, the new C++0x-style replacement for llvm.memory.barrier. This is just a LangRef entry and reading/writing/memory representation; optimizer+codegen support coming soon. llvm-svn: 136009
2011-07-26 07:16:38 +08:00
}
static unsigned GetEncodedSynchScope(SynchronizationScope SynchScope) {
switch (SynchScope) {
case SingleThread: return bitc::SYNCHSCOPE_SINGLETHREAD;
case CrossThread: return bitc::SYNCHSCOPE_CROSSTHREAD;
}
Add 'llvm_unreachable' to passify GCC's understanding of the constraints of several newly un-defaulted switches. This also helps optimizers (including LLVM's) recognize that every case is covered, and we should assume as much. llvm-svn: 147861
2012-01-11 02:08:01 +08:00
llvm_unreachable("Invalid synch scope");
Initial implementation of 'fence' instruction, the new C++0x-style replacement for llvm.memory.barrier. This is just a LangRef entry and reading/writing/memory representation; optimizer+codegen support coming soon. llvm-svn: 136009
2011-07-26 07:16:38 +08:00
}
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
static void WriteStringRecord(unsigned Code, StringRef Str,
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
unsigned AbbrevToUse, BitstreamWriter &Stream) {
SmallVector<unsigned, 64> Vals;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
eliminate internal length fields from record. Records already know their total length llvm-svn: 36752
2007-05-05 03:11:41 +08:00
// Code: [strchar x N]
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
for (unsigned i = 0, e = Str.size(); i != e; ++i) {
if (AbbrevToUse && !BitCodeAbbrevOp::isChar6(Str[i]))
AbbrevToUse = 0;
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Vals.push_back(Str[i]);
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// Emit the finished record.
Stream.EmitRecord(Code, Vals, AbbrevToUse);
}
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
static uint64_t getAttrKindEncoding(Attribute::AttrKind Kind) {
switch (Kind) {
case Attribute::Alignment:
return bitc::ATTR_KIND_ALIGNMENT;
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
case Attribute::AllocSize:
return bitc::ATTR_KIND_ALLOC_SIZE;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::AlwaysInline:
return bitc::ATTR_KIND_ALWAYS_INLINE;
Add argmemonly attribute. This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis. Differential Revision: http://reviews.llvm.org/D10398 llvm-svn: 241979
2015-07-11 18:30:36 +08:00
case Attribute::ArgMemOnly:
return bitc::ATTR_KIND_ARGMEMONLY;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::Builtin:
return bitc::ATTR_KIND_BUILTIN;
case Attribute::ByVal:
return bitc::ATTR_KIND_BY_VAL;
Add initial support for the convergent attribute. llvm-svn: 238264
2015-05-27 07:48:40 +08:00
case Attribute::Convergent:
return bitc::ATTR_KIND_CONVERGENT;
Begin adding docs and IR-level support for the inalloca attribute The inalloca attribute is designed to support passing C++ objects by value in the Microsoft C++ ABI. It behaves the same as byval, except that it always implies that the argument is in memory and that the bytes are never copied. This attribute allows the caller to take the address of an outgoing argument's memory and execute arbitrary code to store into it. This patch adds basic IR support, docs, and verification. It does not attempt to implement any lowering or fix any possibly broken transforms. When this patch lands, a complete description of this feature should appear at http://llvm.org/docs/InAlloca.html . Differential Revision: http://llvm-reviews.chandlerc.com/D2173 llvm-svn: 197645
2013-12-19 10:14:12 +08:00
case Attribute::InAlloca:
return bitc::ATTR_KIND_IN_ALLOCA;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::Cold:
return bitc::ATTR_KIND_COLD;
Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes Summary: This patch introduces two new function attributes InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone. inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly Test cases have been updated. This revision uses this (https://github.com/llvm-mirror/llvm/commit/d001932f3a8aa1ebd1555162fdce365f011bc292) as reference. Reviewers: jmolloy, hfinkel Subscribers: reames, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15499 llvm-svn: 255778
2015-12-17 00:16:19 +08:00
case Attribute::InaccessibleMemOnly:
return bitc::ATTR_KIND_INACCESSIBLEMEM_ONLY;
case Attribute::InaccessibleMemOrArgMemOnly:
return bitc::ATTR_KIND_INACCESSIBLEMEM_OR_ARGMEMONLY;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::InlineHint:
return bitc::ATTR_KIND_INLINE_HINT;
case Attribute::InReg:
return bitc::ATTR_KIND_IN_REG;
Add a new attribute called 'jumptable' that creates jump-instruction tables for functions marked with this attribute. It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables. This also adds backend support for generating the jump-instruction tables on ARM and X86. Note that since the jumptable attribute creates a second function pointer for a function, any function marked with jumptable must also be marked with unnamed_addr. llvm-svn: 210280
2014-06-06 03:29:43 +08:00
case Attribute::JumpTable:
return bitc::ATTR_KIND_JUMP_TABLE;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::MinSize:
return bitc::ATTR_KIND_MIN_SIZE;
case Attribute::Naked:
return bitc::ATTR_KIND_NAKED;
case Attribute::Nest:
return bitc::ATTR_KIND_NEST;
case Attribute::NoAlias:
return bitc::ATTR_KIND_NO_ALIAS;
case Attribute::NoBuiltin:
return bitc::ATTR_KIND_NO_BUILTIN;
case Attribute::NoCapture:
return bitc::ATTR_KIND_NO_CAPTURE;
case Attribute::NoDuplicate:
return bitc::ATTR_KIND_NO_DUPLICATE;
case Attribute::NoImplicitFloat:
return bitc::ATTR_KIND_NO_IMPLICIT_FLOAT;
case Attribute::NoInline:
return bitc::ATTR_KIND_NO_INLINE;
Add a new attribute: norecurse This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other things to demote global variables to locals. llvm-svn: 252282
2015-11-06 18:32:53 +08:00
case Attribute::NoRecurse:
return bitc::ATTR_KIND_NO_RECURSE;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::NonLazyBind:
return bitc::ATTR_KIND_NON_LAZY_BIND;
Add 'nonnull', a new parameter and return attribute which indicates that the pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden! llvm-svn: 209185
2014-05-20 09:23:40 +08:00
case Attribute::NonNull:
return bitc::ATTR_KIND_NON_NULL;
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
case Attribute::Dereferenceable:
return bitc::ATTR_KIND_DEREFERENCEABLE;
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
case Attribute::DereferenceableOrNull:
return bitc::ATTR_KIND_DEREFERENCEABLE_OR_NULL;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::NoRedZone:
return bitc::ATTR_KIND_NO_RED_ZONE;
case Attribute::NoReturn:
return bitc::ATTR_KIND_NO_RETURN;
case Attribute::NoUnwind:
return bitc::ATTR_KIND_NO_UNWIND;
case Attribute::OptimizeForSize:
return bitc::ATTR_KIND_OPTIMIZE_FOR_SIZE;
Add function attribute 'optnone'. This function attribute indicates that the function is not optimized by any optimization or code generator passes with the exception of interprocedural optimization passes. llvm-svn: 189101
2013-08-23 19:53:55 +08:00
case Attribute::OptimizeNone:
return bitc::ATTR_KIND_OPTIMIZE_NONE;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::ReadNone:
return bitc::ATTR_KIND_READ_NONE;
case Attribute::ReadOnly:
return bitc::ATTR_KIND_READ_ONLY;
case Attribute::Returned:
return bitc::ATTR_KIND_RETURNED;
case Attribute::ReturnsTwice:
return bitc::ATTR_KIND_RETURNS_TWICE;
case Attribute::SExt:
return bitc::ATTR_KIND_S_EXT;
case Attribute::StackAlignment:
return bitc::ATTR_KIND_STACK_ALIGNMENT;
case Attribute::StackProtect:
return bitc::ATTR_KIND_STACK_PROTECT;
case Attribute::StackProtectReq:
return bitc::ATTR_KIND_STACK_PROTECT_REQ;
case Attribute::StackProtectStrong:
return bitc::ATTR_KIND_STACK_PROTECT_STRONG;
Protection against stack-based memory corruption errors using SafeStack This patch adds the safe stack instrumentation pass to LLVM, which separates the program stack into a safe stack, which stores return addresses, register spills, and local variables that are statically verified to be accessed in a safe way, and the unsafe stack, which stores everything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. You can find more information about the safe stack, as well as other parts of or control-flow hijack protection technique in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf) and our project website (http://levee.epfl.ch). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies. In some cases, the safe stack improves performance due to better cache locality. Our current implementation of the safe stack is stable and robust, we used it to recompile multiple projects on Linux including Chromium, and we also recompiled the entire FreeBSD user-space system and more than 100 packages. We ran unit tests on the FreeBSD system and many of the packages and observed no errors caused by the safe stack. The safe stack is also fully binary compatible with non-instrumented code and can be applied to parts of a program selectively. This patch is our implementation of the safe stack on top of LLVM. The patches make the following changes: - Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. - Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed by LLVM as usual. - Invoke the pass as the last stage before code generation (at the same time the existing cookie-based stack protector pass is invoked). - Add unit tests for the safe stack. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6094 llvm-svn: 239761
2015-06-16 05:07:11 +08:00
case Attribute::SafeStack:
return bitc::ATTR_KIND_SAFESTACK;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::StructRet:
return bitc::ATTR_KIND_STRUCT_RET;
case Attribute::SanitizeAddress:
return bitc::ATTR_KIND_SANITIZE_ADDRESS;
case Attribute::SanitizeThread:
return bitc::ATTR_KIND_SANITIZE_THREAD;
case Attribute::SanitizeMemory:
return bitc::ATTR_KIND_SANITIZE_MEMORY;
Swift Calling Convention: add swifterror attribute. A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst. This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch. Differential Revision: http://reviews.llvm.org/D18092 llvm-svn: 265189
2016-04-02 05:41:15 +08:00
case Attribute::SwiftError:
return bitc::ATTR_KIND_SWIFT_ERROR;
Swift Calling Convention: add swiftself attribute. Differential Revision: http://reviews.llvm.org/D17866 llvm-svn: 264754
2016-03-30 01:37:21 +08:00
case Attribute::SwiftSelf:
return bitc::ATTR_KIND_SWIFT_SELF;
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
case Attribute::UWTable:
return bitc::ATTR_KIND_UW_TABLE;
case Attribute::ZExt:
return bitc::ATTR_KIND_Z_EXT;
case Attribute::EndAttrKinds:
llvm_unreachable("Can not encode end-attribute kinds marker.");
case Attribute::None:
llvm_unreachable("Can not encode none-attribute.");
}
llvm_unreachable("Trying to encode unknown attribute");
}
Add code for emitting the attribute groups. This is some initial code for emitting the attribute groups into the bitcode. NOTE: This format *may* change! Do not rely upon the attribute groups' bitcode not changing. llvm-svn: 174845
2013-02-11 07:09:32 +08:00
static void WriteAttributeGroupTable(const ValueEnumerator &VE,
BitstreamWriter &Stream) {
Rename AttributeSets to AttributeGroups so that it's more meaningful. llvm-svn: 174911
2013-02-12 06:33:26 +08:00
const std::vector<AttributeSet> &AttrGrps = VE.getAttributeGroups();
if (AttrGrps.empty()) return;
Add code for emitting the attribute groups. This is some initial code for emitting the attribute groups into the bitcode. NOTE: This format *may* change! Do not rely upon the attribute groups' bitcode not changing. llvm-svn: 174845
2013-02-11 07:09:32 +08:00
Stream.EnterSubblock(bitc::PARAMATTR_GROUP_BLOCK_ID, 3);
SmallVector<uint64_t, 64> Record;
Rename AttributeSets to AttributeGroups so that it's more meaningful. llvm-svn: 174911
2013-02-12 06:33:26 +08:00
for (unsigned i = 0, e = AttrGrps.size(); i != e; ++i) {
AttributeSet AS = AttrGrps[i];
Add code for emitting the attribute groups. This is some initial code for emitting the attribute groups into the bitcode. NOTE: This format *may* change! Do not rely upon the attribute groups' bitcode not changing. llvm-svn: 174845
2013-02-11 07:09:32 +08:00
for (unsigned i = 0, e = AS.getNumSlots(); i != e; ++i) {
AttributeSet A = AS.getSlotAttributes(i);
Rename AttributeSets to AttributeGroups so that it's more meaningful. llvm-svn: 174911
2013-02-12 06:33:26 +08:00
Record.push_back(VE.getAttributeGroupID(A));
Add code for emitting the attribute groups. This is some initial code for emitting the attribute groups into the bitcode. NOTE: This format *may* change! Do not rely upon the attribute groups' bitcode not changing. llvm-svn: 174845
2013-02-11 07:09:32 +08:00
Record.push_back(AS.getSlotIndex(i));
for (AttributeSet::iterator I = AS.begin(0), E = AS.end(0);
I != E; ++I) {
Attribute Attr = *I;
if (Attr.isEnumAttribute()) {
Record.push_back(0);
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
Record.push_back(getAttrKindEncoding(Attr.getKindAsEnum()));
Rename AlignAttribute to IntAttribute Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
2014-07-18 14:51:55 +08:00
} else if (Attr.isIntAttribute()) {
Add code for emitting the attribute groups. This is some initial code for emitting the attribute groups into the bitcode. NOTE: This format *may* change! Do not rely upon the attribute groups' bitcode not changing. llvm-svn: 174845
2013-02-11 07:09:32 +08:00
Record.push_back(1);
Make .bc en/decoding of AttrKind stable The bitcode representation attribute kinds are encoded into / decoded from should be independent of the current set of LLVM attributes and their position in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode values. With this patch applied, LLVM does not silently misread attributes written by LLVM 3.3. We also enhance the decoding slightly such that an error message is printed if an unknown AttrKind encoding was dected. Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds do not need to be kept to support the Bitcode reader. llvm-svn: 187186
2013-07-26 12:16:55 +08:00
Record.push_back(getAttrKindEncoding(Attr.getKindAsEnum()));
Add code for emitting the attribute groups. This is some initial code for emitting the attribute groups into the bitcode. NOTE: This format *may* change! Do not rely upon the attribute groups' bitcode not changing. llvm-svn: 174845
2013-02-11 07:09:32 +08:00
Record.push_back(Attr.getValueAsInt());
} else {
StringRef Kind = Attr.getKindAsString();
StringRef Val = Attr.getValueAsString();
Record.push_back(Val.empty() ? 3 : 4);
Record.append(Kind.begin(), Kind.end());
Record.push_back(0);
if (!Val.empty()) {
Record.append(Val.begin(), Val.end());
Record.push_back(0);
}
}
}
Stream.EmitRecord(bitc::PARAMATTR_GRP_CODE_ENTRY, Record);
Record.clear();
}
}
Stream.ExitBlock();
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
static void WriteAttributeTable(const ValueEnumerator &VE,
trivial scaffolding for param attrs llvm-svn: 36720
2007-05-04 08:44:52 +08:00
BitstreamWriter &Stream) {
s/AttrListPtr/AttributeSet/g to better label what this class is going to be in the near future. llvm-svn: 169651
2012-12-08 07:16:57 +08:00
const std::vector<AttributeSet> &Attrs = VE.getAttributes();
trivial scaffolding for param attrs llvm-svn: 36720
2007-05-04 08:44:52 +08:00
if (Attrs.empty()) return;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add writer support for param attrs llvm-svn: 36724
2007-05-04 10:59:04 +08:00
Stream.EnterSubblock(bitc::PARAMATTR_BLOCK_ID, 3);
SmallVector<uint64_t, 64> Record;
for (unsigned i = 0, e = Attrs.size(); i != e; ++i) {
s/AttrListPtr/AttributeSet/g to better label what this class is going to be in the near future. llvm-svn: 169651
2012-12-08 07:16:57 +08:00
const AttributeSet &A = Attrs[i];
Have the bitcode writer and reader handle the new attribute references. The bitcode writer emits a reference to the attribute group that the object at the given index refers to. The bitcode reader is modified to read this in and map it back to the attribute group. llvm-svn: 174952
2013-02-12 16:13:50 +08:00
for (unsigned i = 0, e = A.getNumSlots(); i != e; ++i)
Record.push_back(VE.getAttributeGroupID(A.getSlotAttributes(i)));
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Have the bitcode writer and reader handle the new attribute references. The bitcode writer emits a reference to the attribute group that the object at the given index refers to. The bitcode reader is modified to read this in and map it back to the attribute group. llvm-svn: 174952
2013-02-12 16:13:50 +08:00
Stream.EmitRecord(bitc::PARAMATTR_CODE_ENTRY, Record);
add writer support for param attrs llvm-svn: 36724
2007-05-04 10:59:04 +08:00
Record.clear();
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add writer support for param attrs llvm-svn: 36724
2007-05-04 10:59:04 +08:00
Stream.ExitBlock();
trivial scaffolding for param attrs llvm-svn: 36720
2007-05-04 08:44:52 +08:00
}
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
/// WriteTypeTable - Write out the type table for a module.
static void WriteTypeTable(const ValueEnumerator &VE, BitstreamWriter &Stream) {
const ValueEnumerator::TypeList &TypeList = VE.getTypes();
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
Stream.EnterSubblock(bitc::TYPE_BLOCK_ID_NEW, 4 /*count from # abbrevs */);
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
SmallVector<uint64_t, 64> TypeVals;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
BitcodeWriter: Refactor common computation of bits required for a type index. Suggested by Duncan. Happy to bikeshed the name, cache the result, etc. llvm-svn: 230410
2015-02-25 08:51:52 +08:00
uint64_t NumBits = VE.computeBitsRequiredForTypeIndicies();
Fix 80-column. Simplify code. llvm-svn: 146112
2011-12-08 08:38:45 +08:00
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
// Abbrev for TYPE_CODE_POINTER.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::TYPE_CODE_POINTER));
Fix 80-column. Simplify code. llvm-svn: 146112
2011-12-08 08:38:45 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, NumBits));
Implement part of review feedback for address spaces. llvm-svn: 44933
2007-12-12 16:44:39 +08:00
Abbv->Add(BitCodeAbbrevOp(0)); // Addrspace = 0
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
unsigned PtrAbbrev = Stream.EmitAbbrev(Abbv);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
// Abbrev for TYPE_CODE_FUNCTION.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::TYPE_CODE_FUNCTION));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // isvararg
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Fix 80-column. Simplify code. llvm-svn: 146112
2011-12-08 08:38:45 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, NumBits));
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
unsigned FunctionAbbrev = Stream.EmitAbbrev(Abbv);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
// Abbrev for TYPE_CODE_STRUCT_ANON.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::TYPE_CODE_STRUCT_ANON));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ispacked
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Fix 80-column. Simplify code. llvm-svn: 146112
2011-12-08 08:38:45 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, NumBits));
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
unsigned StructAnonAbbrev = Stream.EmitAbbrev(Abbv);
// Abbrev for TYPE_CODE_STRUCT_NAME.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::TYPE_CODE_STRUCT_NAME));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Char6));
unsigned StructNameAbbrev = Stream.EmitAbbrev(Abbv);
// Abbrev for TYPE_CODE_STRUCT_NAMED.
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
Abbv = new BitCodeAbbrev();
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
Abbv->Add(BitCodeAbbrevOp(bitc::TYPE_CODE_STRUCT_NAMED));
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ispacked
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Fix 80-column. Simplify code. llvm-svn: 146112
2011-12-08 08:38:45 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, NumBits));
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
unsigned StructNamedAbbrev = Stream.EmitAbbrev(Abbv);
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
// Abbrev for TYPE_CODE_ARRAY.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::TYPE_CODE_ARRAY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // size
Fix 80-column. Simplify code. llvm-svn: 146112
2011-12-08 08:38:45 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, NumBits));
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
unsigned ArrayAbbrev = Stream.EmitAbbrev(Abbv);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// Emit an entry count so the reader can reserve space.
TypeVals.push_back(TypeList.size());
Stream.EmitRecord(bitc::TYPE_CODE_NUMENTRY, TypeVals);
TypeVals.clear();
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// Loop over all of the types, emitting each in turn.
for (unsigned i = 0, e = TypeList.size(); i != e; ++i) {
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
Type *T = TypeList[i];
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
int AbbrevToUse = 0;
unsigned Code = 0;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
switch (T->getTypeID()) {
Code Custodian: - Widespread trailing space removal - A dash of OCD spacing to block align enums - joined a line that probably needed 80 cols a while back llvm-svn: 168566
2012-11-25 23:23:39 +08:00
case Type::VoidTyID: Code = bitc::TYPE_CODE_VOID; break;
case Type::HalfTyID: Code = bitc::TYPE_CODE_HALF; break;
case Type::FloatTyID: Code = bitc::TYPE_CODE_FLOAT; break;
case Type::DoubleTyID: Code = bitc::TYPE_CODE_DOUBLE; break;
case Type::X86_FP80TyID: Code = bitc::TYPE_CODE_X86_FP80; break;
case Type::FP128TyID: Code = bitc::TYPE_CODE_FP128; break;
Long double, part 1 of N. Support in IR. llvm-svn: 40774
2007-08-03 09:03:46 +08:00
case Type::PPC_FP128TyID: Code = bitc::TYPE_CODE_PPC_FP128; break;
Code Custodian: - Widespread trailing space removal - A dash of OCD spacing to block align enums - joined a line that probably needed 80 cols a while back llvm-svn: 168566
2012-11-25 23:23:39 +08:00
case Type::LabelTyID: Code = bitc::TYPE_CODE_LABEL; break;
case Type::MetadataTyID: Code = bitc::TYPE_CODE_METADATA; break;
case Type::X86_MMXTyID: Code = bitc::TYPE_CODE_X86_MMX; break;
[IR] Add token types This introduces the basic functionality to support "token types". The motivation stems from the need to perform operations on a Value whose provenance cannot be obscured. There are several applications for such a type but my immediate motivation stems from WinEH. Our personality routine enforces a single-entry - single-exit regime for cleanups. After several rounds of optimizations, we may be left with a terminator whose "cleanup-entry block" is not entirely clear because control flow has merged two cleanups together. We have experimented with using labels as operands inside of instructions which are not terminators to indicate where we came from but found that LLVM does not expect such exotic uses of BasicBlocks. Instead, we can use this new type to clearly associate the "entry point" and "exit point" of our cleanup. This is done by having the cleanuppad yield a Token and consuming it at the cleanupret. The token type makes it impossible to obscure or otherwise hide the Value, making it trivial to track the relationship between the two points. What is the burden to the optimizer? Well, it turns out we have already paid down this cost by accepting that there are certain calls that we are not permitted to duplicate, optimizations have to watch out for such instructions anyway. There are additional places in the optimizer that we will probably have to update but early examination has given me the impression that this will not be heroic. Differential Revision: http://reviews.llvm.org/D11861 llvm-svn: 245029
2015-08-14 13:09:07 +08:00
case Type::TokenTyID: Code = bitc::TYPE_CODE_TOKEN; break;
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
case Type::IntegerTyID:
// INTEGER: [width]
Code = bitc::TYPE_CODE_INTEGER;
TypeVals.push_back(cast<IntegerType>(T)->getBitWidth());
break;
Fix compilation. llvm-svn: 44864
2007-12-11 20:20:47 +08:00
case Type::PointerTyID: {
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
PointerType *PTy = cast<PointerType>(T);
Implement part of review feedback for address spaces. llvm-svn: 44933
2007-12-12 16:44:39 +08:00
// POINTER: [pointee type, address space]
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Code = bitc::TYPE_CODE_POINTER;
Implement address space attribute for LLVM pointer types. Address spaces are regions of memory that have a target specific relationship, as described in the Embedded C Technical Report. This also implements the 2007-12-11-AddressSpaces test, which demonstrates how address space attributes can be used in LLVM IR. In addition, this patch changes the bitcode signature for stores (in a backwards compatible manner), such that the pointer type, rather than the pointee type, is encoded. This permits type information in the pointer (e.g. address space) to be preserved for stores. LangRef updates are forthcoming. llvm-svn: 44858
2007-12-11 16:59:05 +08:00
TypeVals.push_back(VE.getTypeID(PTy->getElementType()));
Implement part of review feedback for address spaces. llvm-svn: 44933
2007-12-12 16:44:39 +08:00
unsigned AddressSpace = PTy->getAddressSpace();
TypeVals.push_back(AddressSpace);
if (AddressSpace == 0) AbbrevToUse = PtrAbbrev;
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
break;
Fix compilation. llvm-svn: 44864
2007-12-11 20:20:47 +08:00
}
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
case Type::FunctionTyID: {
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
FunctionType *FT = cast<FunctionType>(T);
Remove some cruft from the BitcodeWriter, while still maintaining backward compatibility in the BitcodeReader. llvm-svn: 143598
2011-11-03 08:14:01 +08:00
// FUNCTION: [isvararg, retty, paramty x N]
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Code = bitc::TYPE_CODE_FUNCTION;
TypeVals.push_back(FT->isVarArg());
TypeVals.push_back(VE.getTypeID(FT->getReturnType()));
for (unsigned i = 0, e = FT->getNumParams(); i != e; ++i)
TypeVals.push_back(VE.getTypeID(FT->getParamType(i)));
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
AbbrevToUse = FunctionAbbrev;
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
break;
}
case Type::StructTyID: {
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
StructType *ST = cast<StructType>(T);
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
// STRUCT: [ispacked, eltty x N]
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
TypeVals.push_back(ST->isPacked());
eliminate internal length fields from record. Records already know their total length llvm-svn: 36752
2007-05-05 03:11:41 +08:00
// Output all of the element types.
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
for (StructType::element_iterator I = ST->element_begin(),
E = ST->element_end(); I != E; ++I)
TypeVals.push_back(VE.getTypeID(*I));
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
switch to use the new api for structtypes. llvm-svn: 137480
2011-08-13 02:06:37 +08:00
if (ST->isLiteral()) {
Land the long talked about "type system rewrite" patch. This patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
2011-07-10 01:41:24 +08:00
Code = bitc::TYPE_CODE_STRUCT_ANON;
AbbrevToUse = StructAnonAbbrev;
} else {
if (ST->isOpaque()) {
Code = bitc::TYPE_CODE_OPAQUE;
} else {
Code = bitc::TYPE_CODE_STRUCT_NAMED;
AbbrevToUse = StructNamedAbbrev;
}
// Emit the name if it is present.
if (!ST->getName().empty())
WriteStringRecord(bitc::TYPE_CODE_STRUCT_NAME, ST->getName(),
StructNameAbbrev, Stream);
}
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
break;
}
case Type::ArrayTyID: {
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
ArrayType *AT = cast<ArrayType>(T);
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// ARRAY: [numelts, eltty]
Code = bitc::TYPE_CODE_ARRAY;
TypeVals.push_back(AT->getNumElements());
TypeVals.push_back(VE.getTypeID(AT->getElementType()));
Add abbreviations to the TYPE_BLOCK for pointers, functions, structs and arrays. This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39% of the file), a 40% reduction. This shrink the record from: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 139901b/17487.6B/4371.91W % of file: 0.549306 Num Abbrevs: 0 Num Records: 3203 % Abbrev Recs: 0 to: Block ID #10 (TYPE_BLOCK): Num Instances: 1 Total Size: 99389b/12423.6B/3105.91W % of file: 0.390862 Num Abbrevs: 4 Num Records: 3203 % Abbrev Recs: 99.6566 With a common histogram of: Code Histogram: 1613 POINTER 1100 FUNCTION 255 STRUCT 224 ARRAY 5 INTEGER 2 OPAQUE 1 LABEL 1 DOUBLE 1 VOID 1 NUMENTRY llvm-svn: 36776
2007-05-05 14:30:12 +08:00
AbbrevToUse = ArrayAbbrev;
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
break;
}
case Type::VectorTyID: {
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
VectorType *VT = cast<VectorType>(T);
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// VECTOR [numelts, eltty]
Code = bitc::TYPE_CODE_VECTOR;
TypeVals.push_back(VT->getNumElements());
TypeVals.push_back(VE.getTypeID(VT->getElementType()));
break;
}
}
// Emit the finished record.
Stream.EmitRecord(Code, TypeVals, AbbrevToUse);
TypeVals.clear();
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Stream.ExitBlock();
}
[ThinLTO] Include linkage type in function summary Summary: Adds the linkage type to both the per-module and combined function summaries, which subsumes the current islocal bit. This will eventually be used to optimized linkage types based on global summary-based analysis. Reviewers: joker.eph Subscribers: joker.eph, davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D16943 llvm-svn: 259993
2016-02-07 00:07:35 +08:00
static unsigned getEncodedLinkage(const GlobalValue::LinkageTypes Linkage) {
switch (Linkage) {
clang-format. NFC. llvm-svn: 225454
2015-01-09 00:25:01 +08:00
case GlobalValue::ExternalLinkage:
return 0;
case GlobalValue::WeakAnyLinkage:
Bring r226038 back. No change in this commit, but clang was changed to also produce trivial comdats when needed. Original message: Don't create new comdats in CodeGen. This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226467
2015-01-19 23:16:06 +08:00
return 16;
clang-format. NFC. llvm-svn: 225454
2015-01-09 00:25:01 +08:00
case GlobalValue::AppendingLinkage:
return 2;
case GlobalValue::InternalLinkage:
return 3;
case GlobalValue::LinkOnceAnyLinkage:
Bring r226038 back. No change in this commit, but clang was changed to also produce trivial comdats when needed. Original message: Don't create new comdats in CodeGen. This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226467
2015-01-19 23:16:06 +08:00
return 18;
clang-format. NFC. llvm-svn: 225454
2015-01-09 00:25:01 +08:00
case GlobalValue::ExternalWeakLinkage:
return 7;
case GlobalValue::CommonLinkage:
return 8;
case GlobalValue::PrivateLinkage:
return 9;
case GlobalValue::WeakODRLinkage:
Bring r226038 back. No change in this commit, but clang was changed to also produce trivial comdats when needed. Original message: Don't create new comdats in CodeGen. This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226467
2015-01-19 23:16:06 +08:00
return 17;
clang-format. NFC. llvm-svn: 225454
2015-01-09 00:25:01 +08:00
case GlobalValue::LinkOnceODRLinkage:
Bring r226038 back. No change in this commit, but clang was changed to also produce trivial comdats when needed. Original message: Don't create new comdats in CodeGen. This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226467
2015-01-19 23:16:06 +08:00
return 19;
clang-format. NFC. llvm-svn: 225454
2015-01-09 00:25:01 +08:00
case GlobalValue::AvailableExternallyLinkage:
return 12;
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
}
Add 'llvm_unreachable' to passify GCC's understanding of the constraints of several newly un-defaulted switches. This also helps optimizers (including LLVM's) recognize that every case is covered, and we should assume as much. llvm-svn: 147861
2012-01-11 02:08:01 +08:00
llvm_unreachable("Invalid linkage");
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
}
[ThinLTO] Include linkage type in function summary Summary: Adds the linkage type to both the per-module and combined function summaries, which subsumes the current islocal bit. This will eventually be used to optimized linkage types based on global summary-based analysis. Reviewers: joker.eph Subscribers: joker.eph, davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D16943 llvm-svn: 259993
2016-02-07 00:07:35 +08:00
static unsigned getEncodedLinkage(const GlobalValue &GV) {
return getEncodedLinkage(GV.getLinkage());
}
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
static unsigned getEncodedVisibility(const GlobalValue &GV) {
switch (GV.getVisibility()) {
Implement visibility checking during linking. Also implement protected visibility support for bitcode. llvm-svn: 36577
2007-04-30 04:56:48 +08:00
case GlobalValue::DefaultVisibility: return 0;
case GlobalValue::HiddenVisibility: return 1;
case GlobalValue::ProtectedVisibility: return 2;
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
}
Add 'llvm_unreachable' to passify GCC's understanding of the constraints of several newly un-defaulted switches. This also helps optimizers (including LLVM's) recognize that every case is covered, and we should assume as much. llvm-svn: 147861
2012-01-11 02:08:01 +08:00
llvm_unreachable("Invalid visibility");
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
}
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
static unsigned getEncodedDLLStorageClass(const GlobalValue &GV) {
switch (GV.getDLLStorageClass()) {
Decouple dllexport/dllimport from linkage Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199218
2014-01-14 23:22:47 +08:00
case GlobalValue::DefaultStorageClass: return 0;
case GlobalValue::DLLImportStorageClass: return 1;
case GlobalValue::DLLExportStorageClass: return 2;
}
llvm_unreachable("Invalid DLL storage class");
}
[pr19844] Add thread local mode to aliases. This matches gcc's behavior. It also seems natural given that aliases contain other properties that govern how it is accessed (linkage, visibility, dll storage). Clang still has to be updated to expose this feature to C. llvm-svn: 209759
2014-05-29 02:15:43 +08:00
static unsigned getEncodedThreadLocalMode(const GlobalValue &GV) {
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
switch (GV.getThreadLocalMode()) {
Extend the IL for selecting TLS models (PR9788) This allows the user/front-end to specify a model that is better than what LLVM would choose by default. For example, a variable might be declared as @x = thread_local(initialexec) global i32 42 if it will not be used in a shared library that is dlopen'ed. If the specified model isn't supported by the target, or if LLVM can make a better choice, a different model may be used. llvm-svn: 159077
2012-06-23 19:37:03 +08:00
case GlobalVariable::NotThreadLocal: return 0;
case GlobalVariable::GeneralDynamicTLSModel: return 1;
case GlobalVariable::LocalDynamicTLSModel: return 2;
case GlobalVariable::InitialExecTLSModel: return 3;
case GlobalVariable::LocalExecTLSModel: return 4;
}
llvm_unreachable("Invalid TLS model");
}
IR: Add COMDATs to the IR This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
2014-06-28 02:19:56 +08:00
static unsigned getEncodedComdatSelectionKind(const Comdat &C) {
switch (C.getSelectionKind()) {
case Comdat::Any:
return bitc::COMDAT_SELECTION_KIND_ANY;
case Comdat::ExactMatch:
return bitc::COMDAT_SELECTION_KIND_EXACT_MATCH;
case Comdat::Largest:
return bitc::COMDAT_SELECTION_KIND_LARGEST;
case Comdat::NoDuplicates:
return bitc::COMDAT_SELECTION_KIND_NO_DUPLICATES;
case Comdat::SameSize:
return bitc::COMDAT_SELECTION_KIND_SAME_SIZE;
}
llvm_unreachable("Invalid selection kind");
}
static void writeComdats(const ValueEnumerator &VE, BitstreamWriter &Stream) {
[Bitcode] Make writeComdats less strange It had a weird artificial limitation on the write side: the comdat name couldn't be bigger than 2**16. However, the reader had no such limitation. Make the reader and the writer agree. llvm-svn: 263377
2016-03-13 16:01:03 +08:00
SmallVector<unsigned, 64> Vals;
IR: Add COMDATs to the IR This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
2014-06-28 02:19:56 +08:00
for (const Comdat *C : VE.getComdats()) {
// COMDAT: [selection_kind, name]
Vals.push_back(getEncodedComdatSelectionKind(*C));
Add support for comdats with names larger than 256 characters. llvm-svn: 226012
2015-01-15 02:25:45 +08:00
size_t Size = C->getName().size();
[Bitcode] Make writeComdats less strange It had a weird artificial limitation on the write side: the comdat name couldn't be bigger than 2**16. However, the reader had no such limitation. Make the reader and the writer agree. llvm-svn: 263377
2016-03-13 16:01:03 +08:00
assert(isUInt<32>(Size));
Add support for comdats with names larger than 256 characters. llvm-svn: 226012
2015-01-15 02:25:45 +08:00
Vals.push_back(Size);
IR: Add COMDATs to the IR This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
2014-06-28 02:19:56 +08:00
for (char Chr : C->getName())
Vals.push_back((unsigned char)Chr);
Stream.EmitRecord(bitc::MODULE_CODE_COMDAT, Vals, /*AbbrevToUse=*/0);
Vals.clear();
}
}
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
/// Write a record that will eventually hold the word offset of the
/// module-level VST. For now the offset is 0, which will be backpatched
/// after the real VST is written. Returns the bit offset to backpatch.
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
static uint64_t WriteValueSymbolTableForwardDecl(BitstreamWriter &Stream) {
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
// Write a placeholder value in for the offset of the real VST,
// which is written after the function blocks so that it can include
// the offset of each function. The placeholder offset will be
// updated when the real VST is written.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::MODULE_CODE_VSTOFFSET));
// Blocks are 32-bit aligned, so we can use a 32-bit word offset to
// hold the real VST offset. Must use fixed instead of VBR as we don't
// know how many VBR chunks to reserve ahead of time.
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 32));
unsigned VSTOffsetAbbrev = Stream.EmitAbbrev(Abbv);
// Emit the placeholder
uint64_t Vals[] = {bitc::MODULE_CODE_VSTOFFSET, 0};
Stream.EmitRecordWithAbbrev(VSTOffsetAbbrev, Vals);
// Compute and return the bit offset to the placeholder, which will be
// patched when the real VST is written. We can simply subtract the 32-bit
// fixed size from the current bit number to get the location to backpatch.
return Stream.GetCurrentBitNo() - 32;
}
Restore "[ThinLTO] Use MD5 hash in function index." with fix This restores commit r260408, along with a fix for a bot failure. The bot failure was caused by dereferencing a unique_ptr in the same call instruction parameter list where it was passed via std::move. Apparently due to luck this was not exposed when I built the compiler with clang, only with gcc. llvm-svn: 260442
2016-02-11 05:55:02 +08:00
enum StringEncoding { SE_Char6, SE_Fixed7, SE_Fixed8 };
/// Determine the encoding to use for the given string name and length.
static StringEncoding getStringEncoding(const char *Str, unsigned StrLen) {
bool isChar6 = true;
for (const char *C = Str, *E = C + StrLen; C != E; ++C) {
if (isChar6)
isChar6 = BitCodeAbbrevOp::isChar6(*C);
if ((unsigned char)*C & 128)
// don't bother scanning the rest.
return SE_Fixed8;
}
if (isChar6)
return SE_Char6;
else
return SE_Fixed7;
}
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
/// Emit top-level description of module, including target triple, inline asm,
/// descriptors for global variables, and function prototype info.
/// Returns the bit offset to backpatch with the location of the real VST.
static uint64_t WriteModuleInfo(const Module *M, const ValueEnumerator &VE,
BitstreamWriter &Stream) {
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// Emit various pieces of data attached to a module.
if (!M->getTargetTriple().empty())
WriteStringRecord(bitc::MODULE_CODE_TRIPLE, M->getTargetTriple(),
0/*TODO*/, Stream);
Store a DataLayout in Module. Now that DataLayout is not a pass, store one in Module. Since the C API expects to be able to get a char* to the datalayout description, we have to keep a std::string somewhere. This patch keeps it in Module and also uses it to represent modules without a DataLayout. Once DataLayout is mandatory, we should probably move the string to DataLayout itself since it won't be necessary anymore to represent the special case of a module without a DataLayout. llvm-svn: 202190
2014-02-26 04:01:08 +08:00
const std::string &DL = M->getDataLayoutStr();
if (!DL.empty())
WriteStringRecord(bitc::MODULE_CODE_DATALAYOUT, DL, 0 /*TODO*/, Stream);
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
if (!M->getModuleInlineAsm().empty())
WriteStringRecord(bitc::MODULE_CODE_ASM, M->getModuleInlineAsm(),
0/*TODO*/, Stream);
Rename some GC classes so that their roll will hopefully be clearer. In particular, Collector was confusing to implementors. Several thought that this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC (setGC, hasGC, clearGC) Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. llvm-svn: 54899
2008-08-18 02:44:35 +08:00
// Emit information about sections and GC, computing how many there are. Also
// compute the maximum alignment value.
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
std::map<std::string, unsigned> SectionMap;
Rename some GC classes so that their roll will hopefully be clearer. In particular, Collector was confusing to implementors. Several thought that this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC (setGC, hasGC, clearGC) Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. llvm-svn: 54899
2008-08-18 02:44:35 +08:00
std::map<std::string, unsigned> GCMap;
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
unsigned MaxAlignment = 0;
implement reading of abbrevs, and writing of abbreviated global varrs. llvm-svn: 36367
2007-04-24 02:58:34 +08:00
unsigned MaxGlobalType = 0;
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
for (const GlobalValue &GV : M->globals()) {
MaxAlignment = std::max(MaxAlignment, GV.getAlignment());
[opaque pointer type] encode the pointee type of global variables Use a few extra bits in the const field (after widening it from a fixed single bit) to stash the address space which is no longer provided by the type (and an extra bit in there to specify that we're using that new encoding). llvm-svn: 235911
2015-04-28 03:58:56 +08:00
MaxGlobalType = std::max(MaxGlobalType, VE.getTypeID(GV.getValueType()));
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
if (GV.hasSection()) {
Whitespace and formatting. No functional change intended. llvm-svn: 137463
2011-08-13 00:45:18 +08:00
// Give section names unique ID's.
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
unsigned &Entry = SectionMap[GV.getSection()];
Whitespace and formatting. No functional change intended. llvm-svn: 137463
2011-08-13 00:45:18 +08:00
if (!Entry) {
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
WriteStringRecord(bitc::MODULE_CODE_SECTIONNAME, GV.getSection(),
Whitespace and formatting. No functional change intended. llvm-svn: 137463
2011-08-13 00:45:18 +08:00
0/*TODO*/, Stream);
Entry = SectionMap.size();
}
}
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
}
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
for (const Function &F : *M) {
MaxAlignment = std::max(MaxAlignment, F.getAlignment());
if (F.hasSection()) {
Adding a collector name attribute to Function in the IR. These methods are new to Function: bool hasCollector() const; const std::string &getCollector() const; void setCollector(const std::string &); void clearCollector(); The assembly representation is as such: define void @f() gc "shadow-stack" { ... The implementation uses an on-the-side table to map Functions to collector names, such that there is no overhead. A StringPool is further used to unique collector names, which are extremely likely to be unique per process. llvm-svn: 44769
2007-12-10 11:18:06 +08:00
// Give section names unique ID's.
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
unsigned &Entry = SectionMap[F.getSection()];
Adding a collector name attribute to Function in the IR. These methods are new to Function: bool hasCollector() const; const std::string &getCollector() const; void setCollector(const std::string &); void clearCollector(); The assembly representation is as such: define void @f() gc "shadow-stack" { ... The implementation uses an on-the-side table to map Functions to collector names, such that there is no overhead. A StringPool is further used to unique collector names, which are extremely likely to be unique per process. llvm-svn: 44769
2007-12-10 11:18:06 +08:00
if (!Entry) {
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
WriteStringRecord(bitc::MODULE_CODE_SECTIONNAME, F.getSection(),
Adding a collector name attribute to Function in the IR. These methods are new to Function: bool hasCollector() const; const std::string &getCollector() const; void setCollector(const std::string &); void clearCollector(); The assembly representation is as such: define void @f() gc "shadow-stack" { ... The implementation uses an on-the-side table to map Functions to collector names, such that there is no overhead. A StringPool is further used to unique collector names, which are extremely likely to be unique per process. llvm-svn: 44769
2007-12-10 11:18:06 +08:00
0/*TODO*/, Stream);
Entry = SectionMap.size();
}
}
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
if (F.hasGC()) {
Rename some GC classes so that their roll will hopefully be clearer. In particular, Collector was confusing to implementors. Several thought that this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC (setGC, hasGC, clearGC) Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. llvm-svn: 54899
2008-08-18 02:44:35 +08:00
// Same for GC names.
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
unsigned &Entry = GCMap[F.getGC()];
Adding a collector name attribute to Function in the IR. These methods are new to Function: bool hasCollector() const; const std::string &getCollector() const; void setCollector(const std::string &); void clearCollector(); The assembly representation is as such: define void @f() gc "shadow-stack" { ... The implementation uses an on-the-side table to map Functions to collector names, such that there is no overhead. A StringPool is further used to unique collector names, which are extremely likely to be unique per process. llvm-svn: 44769
2007-12-10 11:18:06 +08:00
if (!Entry) {
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
WriteStringRecord(bitc::MODULE_CODE_GCNAME, F.getGC(),
Adding a collector name attribute to Function in the IR. These methods are new to Function: bool hasCollector() const; const std::string &getCollector() const; void setCollector(const std::string &); void clearCollector(); The assembly representation is as such: define void @f() gc "shadow-stack" { ... The implementation uses an on-the-side table to map Functions to collector names, such that there is no overhead. A StringPool is further used to unique collector names, which are extremely likely to be unique per process. llvm-svn: 44769
2007-12-10 11:18:06 +08:00
0/*TODO*/, Stream);
Rename some GC classes so that their roll will hopefully be clearer. In particular, Collector was confusing to implementors. Several thought that this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC (setGC, hasGC, clearGC) Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. llvm-svn: 54899
2008-08-18 02:44:35 +08:00
Entry = GCMap.size();
Adding a collector name attribute to Function in the IR. These methods are new to Function: bool hasCollector() const; const std::string &getCollector() const; void setCollector(const std::string &); void clearCollector(); The assembly representation is as such: define void @f() gc "shadow-stack" { ... The implementation uses an on-the-side table to map Functions to collector names, such that there is no overhead. A StringPool is further used to unique collector names, which are extremely likely to be unique per process. llvm-svn: 44769
2007-12-10 11:18:06 +08:00
}
}
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
// Emit abbrev for globals, now that we know # sections and max alignment.
unsigned SimpleGVarAbbrev = 0;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
if (!M->global_empty()) {
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
// Add an abbrev for common globals with no visibility or thread localness.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::MODULE_CODE_GLOBALVAR));
Encode all value symtab strings as arrays of 8-bit fixed width integers, instead of the default inefficient encoding. This shrinks kc++ from 4134K to 3629K llvm-svn: 36755
2007-05-05 04:34:50 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed,
implement reading of abbrevs, and writing of abbreviated global varrs. llvm-svn: 36367
2007-04-24 02:58:34 +08:00
Log2_32_Ceil(MaxGlobalType+1)));
[opaque pointer type] encode the pointee type of global variables Use a few extra bits in the const field (after widening it from a fixed single bit) to stash the address space which is no longer provided by the type (and an extra bit in there to specify that we're using that new encoding). llvm-svn: 235911
2015-04-28 03:58:56 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // AddrSpace << 2
//| explicitType << 1
//| constant
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Initializer.
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // Linkage.
if (MaxAlignment == 0) // Alignment.
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
Abbv->Add(BitCodeAbbrevOp(0));
else {
unsigned MaxEncAlignment = Log2_32(MaxAlignment)+1;
Encode all value symtab strings as arrays of 8-bit fixed width integers, instead of the default inefficient encoding. This shrinks kc++ from 4134K to 3629K llvm-svn: 36755
2007-05-05 04:34:50 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed,
implement reading of abbrevs, and writing of abbreviated global varrs. llvm-svn: 36367
2007-04-24 02:58:34 +08:00
Log2_32_Ceil(MaxEncAlignment+1)));
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
}
if (SectionMap.empty()) // Section.
Abbv->Add(BitCodeAbbrevOp(0));
else
Encode all value symtab strings as arrays of 8-bit fixed width integers, instead of the default inefficient encoding. This shrinks kc++ from 4134K to 3629K llvm-svn: 36755
2007-05-05 04:34:50 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed,
fix off-by-one computing size for section abbrevs llvm-svn: 36388
2007-04-24 11:29:47 +08:00
Log2_32_Ceil(SectionMap.size()+1)));
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
// Don't bother emitting vis + thread local.
SimpleGVarAbbrev = Stream.EmitAbbrev(Abbv);
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// Emit the global variable information.
SmallVector<unsigned, 64> Vals;
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
for (const GlobalVariable &GV : M->globals()) {
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
unsigned AbbrevToUse = 0;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
// GLOBALVAR: [type, isconst, initid,
First step in fixing PR8927: Add a unnamed_addr bit to global variables and functions. This will be used to indicate that the address is not significant and therefore the constant or function can be merged with others. If an optimization pass can show that an address is not used, it can set this. Examples of things that can have this set by the FE are globals created to hold string literals and C++ constructors. Adding unnamed_addr to a non-const global should have no effect unless an optimization can transform that global into a constant. Aliases are not allowed to have unnamed_addr since I couldn't figure out any use for it. llvm-svn: 123063
2011-01-09 00:42:36 +08:00
// linkage, alignment, section, visibility, threadlocal,
Misc documentation/comment fixes. llvm-svn: 228093
2015-02-04 08:42:45 +08:00
// unnamed_addr, externally_initialized, dllstorageclass,
// comdat]
[opaque pointer type] encode the pointee type of global variables Use a few extra bits in the const field (after widening it from a fixed single bit) to stash the address space which is no longer provided by the type (and an extra bit in there to specify that we're using that new encoding). llvm-svn: 235911
2015-04-28 03:58:56 +08:00
Vals.push_back(VE.getTypeID(GV.getValueType()));
Vals.push_back(GV.getType()->getAddressSpace() << 2 | 2 | GV.isConstant());
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
Vals.push_back(GV.isDeclaration() ? 0 :
(VE.getValueID(GV.getInitializer()) + 1));
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Vals.push_back(getEncodedLinkage(GV));
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
Vals.push_back(Log2_32(GV.getAlignment())+1);
Vals.push_back(GV.hasSection() ? SectionMap[GV.getSection()] : 0);
if (GV.isThreadLocal() ||
GV.getVisibility() != GlobalValue::DefaultVisibility ||
GV.hasUnnamedAddr() || GV.isExternallyInitialized() ||
IR: Add COMDATs to the IR This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
2014-06-28 02:19:56 +08:00
GV.getDLLStorageClass() != GlobalValue::DefaultStorageClass ||
GV.hasComdat()) {
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
Vals.push_back(getEncodedVisibility(GV));
Extend the IL for selecting TLS models (PR9788) This allows the user/front-end to specify a model that is better than what LLVM would choose by default. For example, a variable might be declared as @x = thread_local(initialexec) global i32 42 if it will not be used in a shared library that is dlopen'ed. If the specified model isn't supported by the target, or if LLVM can make a better choice, a different model may be used. llvm-svn: 159077
2012-06-23 19:37:03 +08:00
Vals.push_back(getEncodedThreadLocalMode(GV));
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
Vals.push_back(GV.hasUnnamedAddr());
Vals.push_back(GV.isExternallyInitialized());
Decouple dllexport/dllimport from linkage Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199218
2014-01-14 23:22:47 +08:00
Vals.push_back(getEncodedDLLStorageClass(GV));
IR: Add COMDATs to the IR This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
2014-06-28 02:19:56 +08:00
Vals.push_back(GV.hasComdat() ? VE.getComdatID(GV.getComdat()) : 0);
first part of implementation of abbrevs. The writer isn't fully there yet and the reader doesn't handle them at all yet. llvm-svn: 36363
2007-04-24 00:04:05 +08:00
} else {
AbbrevToUse = SimpleGVarAbbrev;
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Stream.EmitRecord(bitc::MODULE_CODE_GLOBALVAR, Vals, AbbrevToUse);
Vals.clear();
}
// Emit the function proto information.
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
for (const Function &F : *M) {
Fix comments. llvm-svn: 146107
2011-12-08 07:57:55 +08:00
// FUNCTION: [type, callingconv, isproto, linkage, paramattrs, alignment,
Prologue support Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
2014-12-03 10:08:38 +08:00
// section, visibility, gc, unnamed_addr, prologuedata,
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
// dllstorageclass, comdat, prefixdata, personalityfn]
[opaque pointer type] Serialize the type of an llvm::Function as a function type rather than a function pointer type llvm-svn: 235200
2015-04-18 00:28:26 +08:00
Vals.push_back(VE.getTypeID(F.getFunctionType()));
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
Vals.push_back(F.getCallingConv());
Vals.push_back(F.isDeclaration());
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Vals.push_back(getEncodedLinkage(F));
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
Vals.push_back(VE.getAttributeID(F.getAttributes()));
Vals.push_back(Log2_32(F.getAlignment())+1);
Vals.push_back(F.hasSection() ? SectionMap[F.getSection()] : 0);
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Vals.push_back(getEncodedVisibility(F));
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
Vals.push_back(F.hasGC() ? GCMap[F.getGC()] : 0);
Vals.push_back(F.hasUnnamedAddr());
Prologue support Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
2014-12-03 10:08:38 +08:00
Vals.push_back(F.hasPrologueData() ? (VE.getValueID(F.getPrologueData()) + 1)
: 0);
Decouple dllexport/dllimport from linkage Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199218
2014-01-14 23:22:47 +08:00
Vals.push_back(getEncodedDLLStorageClass(F));
IR: Add COMDATs to the IR This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
2014-06-28 02:19:56 +08:00
Vals.push_back(F.hasComdat() ? VE.getComdatID(F.getComdat()) : 0);
Prologue support Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
2014-12-03 10:08:38 +08:00
Vals.push_back(F.hasPrefixData() ? (VE.getValueID(F.getPrefixData()) + 1)
: 0);
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
Vals.push_back(
F.hasPersonalityFn() ? (VE.getValueID(F.getPersonalityFn()) + 1) : 0);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
unsigned AbbrevToUse = 0;
Stream.EmitRecord(bitc::MODULE_CODE_FUNCTION, Vals, AbbrevToUse);
Vals.clear();
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add bitcode alias support llvm-svn: 36461
2007-04-26 10:46:40 +08:00
// Emit the alias information.
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
for (const GlobalAlias &A : M->aliases()) {
Fix comments. llvm-svn: 146109
2011-12-08 08:11:31 +08:00
// ALIAS: [alias type, aliasee val#, linkage, visibility]
[opaque pointer types] Add an explicit pointee type to alias records in the IR Since aliases actually use and verify their explicit type already, no further invalid testing is required here. The invalid.test:ALIAS-TYPE-MISMATCH case catches errors due to emitting a non-pointee type in the new format or a non-pointer type in the old format. llvm-svn: 247952
2015-09-18 06:18:59 +08:00
Vals.push_back(VE.getTypeID(A.getValueType()));
Vals.push_back(A.getType()->getAddressSpace());
Convert a few loops to use ranges. llvm-svn: 209628
2014-05-26 21:38:51 +08:00
Vals.push_back(VE.getValueID(A.getAliasee()));
Vals.push_back(getEncodedLinkage(A));
Vals.push_back(getEncodedVisibility(A));
Vals.push_back(getEncodedDLLStorageClass(A));
Allow aliases to be unnamed_addr. Alias with unnamed_addr were in a strange state. It is stored in GlobalValue, the language reference talks about "unnamed_addr aliases" but the verifier was rejecting them. It seems natural to allow unnamed_addr in aliases: * It is a property of how it is accessed, not of the data itself. * It is perfectly possible to write code that depends on the address of an alias. This patch then makes unname_addr legal for aliases. One side effect is that the syntax changes for a corner case: In globals, unnamed_addr is now printed before the address space. llvm-svn: 210302
2014-06-06 09:20:28 +08:00
Vals.push_back(getEncodedThreadLocalMode(A));
Vals.push_back(A.hasUnnamedAddr());
add bitcode alias support llvm-svn: 36461
2007-04-26 10:46:40 +08:00
unsigned AbbrevToUse = 0;
Stream.EmitRecord(bitc::MODULE_CODE_ALIAS, Vals, AbbrevToUse);
Vals.clear();
}
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
[GCC] Attribute ifunc support in llvm This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
2016-04-07 20:32:19 +08:00
// Emit the ifunc information.
for (const GlobalIFunc &I : M->ifuncs()) {
// IFUNC: [ifunc type, address space, resolver val#, linkage, visibility]
Vals.push_back(VE.getTypeID(I.getValueType()));
Vals.push_back(I.getType()->getAddressSpace());
Vals.push_back(VE.getValueID(I.getResolver()));
Vals.push_back(getEncodedLinkage(I));
Vals.push_back(getEncodedVisibility(I));
Stream.EmitRecord(bitc::MODULE_CODE_IFUNC, Vals);
Vals.clear();
}
Restore "[ThinLTO] Use MD5 hash in function index." with fix This restores commit r260408, along with a fix for a bot failure. The bot failure was caused by dereferencing a unique_ptr in the same call instruction parameter list where it was passed via std::move. Apparently due to luck this was not exposed when I built the compiler with clang, only with gcc. llvm-svn: 260442
2016-02-11 05:55:02 +08:00
// Emit the module's source file name.
{
Bitcode writer: fix a typo, using getName() instead of getSourceFileName() When emitting the source filename, the encoding of the string was checked against the name instead of the filename. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 261019
2016-02-17 06:07:03 +08:00
StringEncoding Bits = getStringEncoding(M->getSourceFileName().data(),
M->getSourceFileName().size());
Restore "[ThinLTO] Use MD5 hash in function index." with fix This restores commit r260408, along with a fix for a bot failure. The bot failure was caused by dereferencing a unique_ptr in the same call instruction parameter list where it was passed via std::move. Apparently due to luck this was not exposed when I built the compiler with clang, only with gcc. llvm-svn: 260442
2016-02-11 05:55:02 +08:00
BitCodeAbbrevOp AbbrevOpToUse = BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 8);
if (Bits == SE_Char6)
AbbrevOpToUse = BitCodeAbbrevOp(BitCodeAbbrevOp::Char6);
else if (Bits == SE_Fixed7)
AbbrevOpToUse = BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 7);
// MODULE_CODE_SOURCE_FILENAME: [namechar x N]
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::MODULE_CODE_SOURCE_FILENAME));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(AbbrevOpToUse);
unsigned FilenameAbbrev = Stream.EmitAbbrev(Abbv);
for (const auto P : M->getSourceFileName())
Vals.push_back((unsigned char)P);
// Emit the finished record.
Stream.EmitRecord(bitc::MODULE_CODE_SOURCE_FILENAME, Vals, FilenameAbbrev);
Vals.clear();
}
[ThinLTO] Add MODULE_CODE_METADATA_VALUES record Summary: This is split out from the ThinLTO metadata mapping patch http://reviews.llvm.org/D14752. To avoid needing to parse the module level metadata during function importing, a new module-level record is added which holds the number of module-level metadata values. This is required because metadata value ids are assigned implicitly during parsing, and the function-level metadata ids start after the module-level metadata ids. I made a change to this version of the code compared to D14752 in order to add more consistent and thorough assertion checking of the new record value. We now unconditionally use the record value to initialize the MDValueList size, and handle it the same in parseMetadata for all module level metadata cases (lazy loading or not). Reviewers: dexonsmith, joker.eph Subscribers: davidxl, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14825 llvm-svn: 253668
2015-11-20 22:51:27 +08:00
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// If we have a VST, write the VSTOFFSET record placeholder and return
// its offset.
if (M->getValueSymbolTable().empty())
return 0;
return WriteValueSymbolTableForwardDecl(Stream);
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
}
Assembly and Bitcode support for unsigned/signed overflow flags and exact sdiv flags. llvm-svn: 76475
2009-07-21 05:19:07 +08:00
static uint64_t GetOptimizationFlags(const Value *V) {
uint64_t Flags = 0;
correct const-ness with auto and dyn_cast 1. Use const with autos. 2. Don't bother with explicit const in cast ops because they do it automagically. Thanks, David B. / Aaron B. / Reid K. llvm-svn: 219817
2014-10-16 01:45:13 +08:00
if (const auto *OBO = dyn_cast<OverflowingBinaryOperator>(V)) {
Rename hasNoUnsignedOverflow and hasNoSignedOverflow to hasNoUnsignedWrap and hasNoSignedWrap, for consistency with the nuw and nsw properties. llvm-svn: 79539
2009-08-21 01:11:38 +08:00
if (OBO->hasNoSignedWrap())
Flags |= 1 << bitc::OBO_NO_SIGNED_WRAP;
if (OBO->hasNoUnsignedWrap())
Flags |= 1 << bitc::OBO_NO_UNSIGNED_WRAP;
correct const-ness with auto and dyn_cast 1. Use const with autos. 2. Don't bother with explicit const in cast ops because they do it automagically. Thanks, David B. / Aaron B. / Reid K. llvm-svn: 219817
2014-10-16 01:45:13 +08:00
} else if (const auto *PEO = dyn_cast<PossiblyExactOperator>(V)) {
enhance vmcore to know that udiv's can be exact, and add a trivial instcombine xform to exercise this. Nothing forms exact udivs yet though. This is progress on PR8862 llvm-svn: 124992
2011-02-07 05:44:57 +08:00
if (PEO->isExact())
Flags |= 1 << bitc::PEO_EXACT;
correct const-ness with auto and dyn_cast 1. Use const with autos. 2. Don't bother with explicit const in cast ops because they do it automagically. Thanks, David B. / Aaron B. / Reid K. llvm-svn: 219817
2014-10-16 01:45:13 +08:00
} else if (const auto *FPMO = dyn_cast<FPMathOperator>(V)) {
Fast-math flags for the bitcode Added in bitcode enum for the serializing of fast-math flags. Added in the reading/writing of fast-math flags from the OptimizationFlags record for BinaryOps. llvm-svn: 168646
2012-11-27 08:43:38 +08:00
if (FPMO->hasUnsafeAlgebra())
Reorganize FastMathFlags to be a wrapper around unsigned, and streamline some interfaces. llvm-svn: 169712
2012-12-10 05:12:04 +08:00
Flags |= FastMathFlags::UnsafeAlgebra;
Fast-math flags for the bitcode Added in bitcode enum for the serializing of fast-math flags. Added in the reading/writing of fast-math flags from the OptimizationFlags record for BinaryOps. llvm-svn: 168646
2012-11-27 08:43:38 +08:00
if (FPMO->hasNoNaNs())
Reorganize FastMathFlags to be a wrapper around unsigned, and streamline some interfaces. llvm-svn: 169712
2012-12-10 05:12:04 +08:00
Flags |= FastMathFlags::NoNaNs;
Fast-math flags for the bitcode Added in bitcode enum for the serializing of fast-math flags. Added in the reading/writing of fast-math flags from the OptimizationFlags record for BinaryOps. llvm-svn: 168646
2012-11-27 08:43:38 +08:00
if (FPMO->hasNoInfs())
Reorganize FastMathFlags to be a wrapper around unsigned, and streamline some interfaces. llvm-svn: 169712
2012-12-10 05:12:04 +08:00
Flags |= FastMathFlags::NoInfs;
Fast-math flags for the bitcode Added in bitcode enum for the serializing of fast-math flags. Added in the reading/writing of fast-math flags from the OptimizationFlags record for BinaryOps. llvm-svn: 168646
2012-11-27 08:43:38 +08:00
if (FPMO->hasNoSignedZeros())
Reorganize FastMathFlags to be a wrapper around unsigned, and streamline some interfaces. llvm-svn: 169712
2012-12-10 05:12:04 +08:00
Flags |= FastMathFlags::NoSignedZeros;
Fast-math flags for the bitcode Added in bitcode enum for the serializing of fast-math flags. Added in the reading/writing of fast-math flags from the OptimizationFlags record for BinaryOps. llvm-svn: 168646
2012-11-27 08:43:38 +08:00
if (FPMO->hasAllowReciprocal())
Reorganize FastMathFlags to be a wrapper around unsigned, and streamline some interfaces. llvm-svn: 169712
2012-12-10 05:12:04 +08:00
Flags |= FastMathFlags::AllowReciprocal;
Assembly and Bitcode support for unsigned/signed overflow flags and exact sdiv flags. llvm-svn: 76475
2009-07-21 05:19:07 +08:00
}
return Flags;
}
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeValueAsMetadata(const ValueAsMetadata *MD,
Bitcode: Add METADATA_NODE and METADATA_VALUE This reflects the typelessness of `Metadata` in the bitcode format, removing types from all metadata operands. `METADATA_VALUE` represents a `ValueAsMetadata`, and always has two fields: the type and the value. `METADATA_NODE` represents an `MDNode`, and unlike `METADATA_OLD_NODE`, doesn't store types. It stores operands at their ID+1 so that `0` can reference `nullptr` operands. Part of PR21532. llvm-svn: 224073
2014-12-12 07:02:24 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record) {
IR: Split Metadata from Value Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
2014-12-10 02:38:53 +08:00
// Mimic an MDNode with a value as one operand.
Value *V = MD->getValue();
Record.push_back(VE.getTypeID(V->getType()));
Record.push_back(VE.getValueID(V));
Bitcode: Add METADATA_NODE and METADATA_VALUE This reflects the typelessness of `Metadata` in the bitcode format, removing types from all metadata operands. `METADATA_VALUE` represents a `ValueAsMetadata`, and always has two fields: the type and the value. `METADATA_NODE` represents an `MDNode`, and unlike `METADATA_OLD_NODE`, doesn't store types. It stores operands at their ID+1 so that `0` can reference `nullptr` operands. Part of PR21532. llvm-svn: 224073
2014-12-12 07:02:24 +08:00
Stream.EmitRecord(bitc::METADATA_VALUE, Record, 0);
IR: Split Metadata from Value Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
2014-12-10 02:38:53 +08:00
Record.clear();
}
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeMDTuple(const MDTuple *N, const ValueEnumerator &VE,
Bitcode: WriteMDNode() => WriteMDTuple(), NFC llvm-svn: 226534
2015-01-20 09:01:53 +08:00
BitstreamWriter &Stream,
Bitcode: Simplify MDNode subclass dispatch, NFC llvm-svn: 226535
2015-01-20 09:03:09 +08:00
SmallVectorImpl<uint64_t> &Record, unsigned Abbrev) {
rename "elements" of metadata to "operands". "Elements" are things that occur in types. "operands" are things that occur in values. llvm-svn: 92322
2009-12-31 09:22:29 +08:00
for (unsigned i = 0, e = N->getNumOperands(); i != e; ++i) {
IR: Split Metadata from Value Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
2014-12-10 02:38:53 +08:00
Metadata *MD = N->getOperand(i);
Bitcode: Add ValueEnumerator::getMetadataOrNullID(), NFC llvm-svn: 226533
2015-01-20 09:00:23 +08:00
assert(!(MD && isa<LocalAsMetadata>(MD)) &&
"Unexpected function-local metadata");
Record.push_back(VE.getMetadataOrNullID(MD));
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
}
IR: Add 'distinct' MDNodes to bitcode and assembly Propagate whether `MDNode`s are 'distinct' through the other types of IR (assembly and bitcode). This adds the `distinct` keyword to assembly. Currently, no one actually calls `MDNode::getDistinct()`, so these nodes only get created for: - self-references, which are never uniqued, and - nodes whose operands are replaced that hit a uniquing collision. The concept of distinct nodes is still not quite first-class, since distinct-ness doesn't yet survive across `MapMetadata()`. Part of PR22111. llvm-svn: 225474
2015-01-09 06:38:29 +08:00
Stream.EmitRecord(N->isDistinct() ? bitc::METADATA_DISTINCT_NODE
: bitc::METADATA_NODE,
Bitcode: Simplify MDNode subclass dispatch, NFC llvm-svn: 226535
2015-01-20 09:03:09 +08:00
Record, Abbrev);
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
Record.clear();
}
Constants and Metadata share ValueList. This means they must be emitted interleaved (using appropriate BLOCK_IDs) otherwise ValuePtrs index gets out of sync. llvm-svn: 78033
2009-08-04 10:26:56 +08:00
BitcodeWriter: Move abbreviation for DILocation; almost NFC Simplify ValueEnumerator and WriteModuleMetadata by shifting the logic for the METADATA_LOCATION abbreviation into WriteDILocation. The only change is that the abbreviation is emitted later in the bitcode, just before the first `DILocation` record. This shouldn't be observable though. llvm-svn: 264302
2016-03-25 00:25:51 +08:00
static unsigned createDILocationAbbrev(BitstreamWriter &Stream) {
// Assume the column is usually under 128, and always output the inlined-at
// location (it's never more expensive than building an array size 1).
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::METADATA_LOCATION));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));
return Stream.EmitAbbrev(Abbv);
}
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDILocation(const DILocation *N, const ValueEnumerator &VE,
AsmParser/Bitcode: Add support for MDLocation This adds assembly and bitcode support for `MDLocation`. The assembly side is rather big, since this is the first `MDNode` subclass (that isn't `MDTuple`). Part of PR21433. (If you're wondering where the mountains of testcase updates are, we don't need them until I update `DILocation` and `DebugLoc` to actually use this class.) llvm-svn: 225830
2015-01-14 05:10:44 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
BitcodeWriter: Move abbreviation for DILocation; almost NFC Simplify ValueEnumerator and WriteModuleMetadata by shifting the logic for the METADATA_LOCATION abbreviation into WriteDILocation. The only change is that the abbreviation is emitted later in the bitcode, just before the first `DILocation` record. This shouldn't be observable though. llvm-svn: 264302
2016-03-25 00:25:51 +08:00
unsigned &Abbrev) {
if (!Abbrev)
Abbrev = createDILocationAbbrev(Stream);
AsmParser/Bitcode: Add support for MDLocation This adds assembly and bitcode support for `MDLocation`. The assembly side is rather big, since this is the first `MDNode` subclass (that isn't `MDTuple`). Part of PR21433. (If you're wondering where the mountains of testcase updates are, we don't need them until I update `DILocation` and `DebugLoc` to actually use this class.) llvm-svn: 225830
2015-01-14 05:10:44 +08:00
Record.push_back(N->isDistinct());
Record.push_back(N->getLine());
Record.push_back(N->getColumn());
Record.push_back(VE.getMetadataID(N->getScope()));
Bitcode: Add ValueEnumerator::getMetadataOrNullID(), NFC llvm-svn: 226533
2015-01-20 09:00:23 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getInlinedAt()));
AsmParser/Bitcode: Add support for MDLocation This adds assembly and bitcode support for `MDLocation`. The assembly side is rather big, since this is the first `MDNode` subclass (that isn't `MDTuple`). Part of PR21433. (If you're wondering where the mountains of testcase updates are, we don't need them until I update `DILocation` and `DebugLoc` to actually use this class.) llvm-svn: 225830
2015-01-14 05:10:44 +08:00
Stream.EmitRecord(bitc::METADATA_LOCATION, Record, Abbrev);
Record.clear();
}
BitcodeWriter: Move abbreviation for GenericDINode; almost NFC Simplify ValueEnumerator and WriteModuleMetadata by shifting the logic for the METADATA_GENERIC_DEBUG abbreviation into WriteGenericDINode. (This is just like r264302, but for GenericDINode.) The only change is that the abbreviation is emitted later in the bitcode, just before the first `GenericDINode` record. This shouldn't be observable though. llvm-svn: 264303
2016-03-25 00:30:18 +08:00
static unsigned createGenericDINodeAbbrev(BitstreamWriter &Stream) {
// Assume the column is usually under 128, and always output the inlined-at
// location (it's never more expensive than building an array size 1).
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::METADATA_GENERIC_DEBUG));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));
return Stream.EmitAbbrev(Abbv);
}
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeGenericDINode(const GenericDINode *N,
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-30 00:38:44 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
BitcodeWriter: Move abbreviation for GenericDINode; almost NFC Simplify ValueEnumerator and WriteModuleMetadata by shifting the logic for the METADATA_GENERIC_DEBUG abbreviation into WriteGenericDINode. (This is just like r264302, but for GenericDINode.) The only change is that the abbreviation is emitted later in the bitcode, just before the first `GenericDINode` record. This shouldn't be observable though. llvm-svn: 264303
2016-03-25 00:30:18 +08:00
unsigned &Abbrev) {
if (!Abbrev)
Abbrev = createGenericDINodeAbbrev(Stream);
IR: Assembly and bitcode for GenericDebugNode llvm-svn: 228041
2015-02-04 05:54:14 +08:00
Record.push_back(N->isDistinct());
Record.push_back(N->getTag());
Record.push_back(0); // Per-tag version field; unused for now.
for (auto &I : N->operands())
Record.push_back(VE.getMetadataOrNullID(I));
Stream.EmitRecord(bitc::METADATA_GENERIC_DEBUG, Record, Abbrev);
Record.clear();
Bitcode: Simplify MDNode subclass dispatch, NFC llvm-svn: 226535
2015-01-20 09:03:09 +08:00
}
AsmWriter/Bitcode: MDSubrange llvm-svn: 229003
2015-02-13 09:10:38 +08:00
static uint64_t rotateSign(int64_t I) {
uint64_t U = I;
return I < 0 ? ~(U << 1) : U << 1;
}
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDISubrange(const DISubrange *N, const ValueEnumerator &,
AsmWriter/Bitcode: MDSubrange llvm-svn: 229003
2015-02-13 09:10:38 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getCount());
IR: Rename MDSubrange::getLo() to getLowerBound() During initial review, the `lo:` field was renamed to `lowerBound:`. Make the same change to the C++ API. llvm-svn: 234267
2015-04-07 08:39:59 +08:00
Record.push_back(rotateSign(N->getLowerBound()));
AsmWriter/Bitcode: MDSubrange llvm-svn: 229003
2015-02-13 09:10:38 +08:00
Stream.EmitRecord(bitc::METADATA_SUBRANGE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDSubrange llvm-svn: 229003
2015-02-13 09:10:38 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIEnumerator(const DIEnumerator *N, const ValueEnumerator &VE,
AsmWriter/Bitcode: MDEnumerator llvm-svn: 229004
2015-02-13 09:14:11 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(rotateSign(N->getValue()));
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Stream.EmitRecord(bitc::METADATA_ENUMERATOR, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDEnumerator llvm-svn: 229004
2015-02-13 09:14:11 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIBasicType(const DIBasicType *N, const ValueEnumerator &VE,
AsmWriter/Bitcode: MDBasicType llvm-svn: 229005
2015-02-13 09:14:58 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getTag());
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(N->getSizeInBits());
Record.push_back(N->getAlignInBits());
Record.push_back(N->getEncoding());
Stream.EmitRecord(bitc::METADATA_BASIC_TYPE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDBasicType llvm-svn: 229005
2015-02-13 09:14:58 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIDerivedType(const DIDerivedType *N,
AsmWriter/Bitcode: MDDerivedType and MDCompositeType llvm-svn: 229009
2015-02-13 09:20:38 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getTag());
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Bitcode: Stop assuming non-null fields When writing the bitcode serialization for the new debug info hierarchy, I assumed two fields would never be null. Drop that assumption, since it's brittle (and crashes the `BitcodeWriter` if wrong), and is a check better left for the verifier anyway. (No need for a bitcode upgrade here, since the new hierarchy is still not in place.) The fields in question are `MDCompileUnit::getFile()` and `MDDerivedType::getBaseType()`, the latter of which isn't null in test/Transforms/Mem2Reg/ConvertDebugInfo2.ll (see !14, a pointer to nothing). While the testcase might have bitrotted, there's no reason for the bitcode format to rely on non-null for metadata operands. This also fixes a bug in `AsmWriter` where if the `file:` is null it isn't emitted (caught by the double-round trip in the testcase I'm adding) -- this is a required field in `LLParser`. I'll circle back to ConvertDebugInfo2. Once the specialized nodes are in place, I'll be trying to turn the debug info verifier back on by default (in the newer module pass form committed r206300) and throwing more logic in there. If the testcase has bitrotted (as opposed to me not understanding the schema correctly) I'll fix it then. llvm-svn: 229960
2015-02-20 11:17:58 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getBaseType()));
AsmWriter/Bitcode: MDDerivedType and MDCompositeType llvm-svn: 229009
2015-02-13 09:20:38 +08:00
Record.push_back(N->getSizeInBits());
Record.push_back(N->getAlignInBits());
Record.push_back(N->getOffsetInBits());
Record.push_back(N->getFlags());
Record.push_back(VE.getMetadataOrNullID(N->getExtraData()));
Stream.EmitRecord(bitc::METADATA_DERIVED_TYPE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDDerivedType and MDCompositeType llvm-svn: 229009
2015-02-13 09:20:38 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDICompositeType(const DICompositeType *N,
AsmWriter/Bitcode: MDDerivedType and MDCompositeType llvm-svn: 229009
2015-02-13 09:20:38 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getTag());
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Record.push_back(VE.getMetadataOrNullID(N->getBaseType()));
Record.push_back(N->getSizeInBits());
Record.push_back(N->getAlignInBits());
Record.push_back(N->getOffsetInBits());
Record.push_back(N->getFlags());
IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*() Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes ambiguity (at least in some [1] compilers [2]) when using indexes to `MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to (but not the same as) `unsigned`. [1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308 [2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442 llvm-svn: 234326
2015-04-08 00:50:39 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getElements().get()));
AsmWriter/Bitcode: MDDerivedType and MDCompositeType llvm-svn: 229009
2015-02-13 09:20:38 +08:00
Record.push_back(N->getRuntimeLang());
Record.push_back(VE.getMetadataOrNullID(N->getVTableHolder()));
IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*() Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes ambiguity (at least in some [1] compilers [2]) when using indexes to `MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to (but not the same as) `unsigned`. [1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308 [2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442 llvm-svn: 234326
2015-04-08 00:50:39 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getTemplateParams().get()));
AsmWriter/Bitcode: MDDerivedType and MDCompositeType llvm-svn: 229009
2015-02-13 09:20:38 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getRawIdentifier()));
Stream.EmitRecord(bitc::METADATA_COMPOSITE_TYPE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDDerivedType and MDCompositeType llvm-svn: 229009
2015-02-13 09:20:38 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDISubroutineType(const DISubroutineType *N,
AsmWriter/Bitcode: MDSubroutineType llvm-svn: 229011
2015-02-13 09:22:59 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getFlags());
IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*() Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes ambiguity (at least in some [1] compilers [2]) when using indexes to `MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to (but not the same as) `unsigned`. [1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308 [2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442 llvm-svn: 234326
2015-04-08 00:50:39 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getTypeArray().get()));
AsmWriter/Bitcode: MDSubroutineType llvm-svn: 229011
2015-02-13 09:22:59 +08:00
Stream.EmitRecord(bitc::METADATA_SUBROUTINE_TYPE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDFile llvm-svn: 229007
2015-02-13 09:19:14 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIFile(const DIFile *N, const ValueEnumerator &VE,
AsmWriter/Bitcode: MDFile llvm-svn: 229007
2015-02-13 09:19:14 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record, unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getRawFilename()));
Record.push_back(VE.getMetadataOrNullID(N->getRawDirectory()));
Stream.EmitRecord(bitc::METADATA_FILE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDFile llvm-svn: 229007
2015-02-13 09:19:14 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDICompileUnit(const DICompileUnit *N,
AsmWriter/Bitcode: MDCompileUnit llvm-svn: 229013
2015-02-13 09:25:10 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
DI: Disallow uniquable DICompileUnits Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s. The backend is liable to start relying on that (if it hasn't already), so make uniquable `DICompileUnit`s illegal and automatically upgrade old bitcode. This is a nice cleanup, since we can remove an unnecessary `DenseSet` (and the associated uniquing info) from `LLVMContextImpl`. Almost all the testcases were updated with this script: git grep -e '= !DICompileUnit' -l -- test | grep -v test/Bitcode | xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,' I imagine something similar should work for out-of-tree testcases. llvm-svn: 243885
2015-08-04 01:26:41 +08:00
assert(N->isDistinct() && "Expected distinct compile units");
Record.push_back(/* IsDistinct */ true);
AsmWriter/Bitcode: MDCompileUnit llvm-svn: 229013
2015-02-13 09:25:10 +08:00
Record.push_back(N->getSourceLanguage());
Bitcode: Stop assuming non-null fields When writing the bitcode serialization for the new debug info hierarchy, I assumed two fields would never be null. Drop that assumption, since it's brittle (and crashes the `BitcodeWriter` if wrong), and is a check better left for the verifier anyway. (No need for a bitcode upgrade here, since the new hierarchy is still not in place.) The fields in question are `MDCompileUnit::getFile()` and `MDDerivedType::getBaseType()`, the latter of which isn't null in test/Transforms/Mem2Reg/ConvertDebugInfo2.ll (see !14, a pointer to nothing). While the testcase might have bitrotted, there's no reason for the bitcode format to rely on non-null for metadata operands. This also fixes a bug in `AsmWriter` where if the `file:` is null it isn't emitted (caught by the double-round trip in the testcase I'm adding) -- this is a required field in `LLParser`. I'll circle back to ConvertDebugInfo2. Once the specialized nodes are in place, I'll be trying to turn the debug info verifier back on by default (in the newer module pass form committed r206300) and throwing more logic in there. If the testcase has bitrotted (as opposed to me not understanding the schema correctly) I'll fix it then. llvm-svn: 229960
2015-02-20 11:17:58 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
AsmWriter/Bitcode: MDCompileUnit llvm-svn: 229013
2015-02-13 09:25:10 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getRawProducer()));
Record.push_back(N->isOptimized());
Record.push_back(VE.getMetadataOrNullID(N->getRawFlags()));
Record.push_back(N->getRuntimeVersion());
Record.push_back(VE.getMetadataOrNullID(N->getRawSplitDebugFilename()));
Record.push_back(N->getEmissionKind());
IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*() Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes ambiguity (at least in some [1] compilers [2]) when using indexes to `MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to (but not the same as) `unsigned`. [1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308 [2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442 llvm-svn: 234326
2015-04-08 00:50:39 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getEnumTypes().get()));
Record.push_back(VE.getMetadataOrNullID(N->getRetainedTypes().get()));
Record.push_back(VE.getMetadataOrNullID(N->getSubprograms().get()));
Record.push_back(VE.getMetadataOrNullID(N->getGlobalVariables().get()));
Record.push_back(VE.getMetadataOrNullID(N->getImportedEntities().get()));
IR / debug info: Add a DWOId field to DICompileUnit, so DWARF skeleton CUs can be expression in IR. A skeleton CU is a (typically empty) DW_TAG_compile_unit that has a DW_AT_(GNU)_dwo_name and a DW_AT_(GNU)_dwo_id attribute. It is used to refer to external debug info. This is a prerequisite for clang module debugging as discussed in http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html. In order to refer to external types stored in split DWARF (dwo) objects, such as clang modules, we need to emit skeleton CUs, which identify the dwarf object (i.e., the clang module) by filename (the SplitDebugFilename) and a hash value, the dwo_id. This patch only contains the IR changes. The idea is that a CUs with a non-zero dwo_id field will be emitted together with a DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id attribute. http://reviews.llvm.org/D9488 rdar://problem/20091852 llvm-svn: 237949
2015-05-22 04:37:30 +08:00
Record.push_back(N->getDWOId());
Macro debug info support in LLVM IR Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
2015-12-10 20:56:35 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getMacros().get()));
AsmWriter/Bitcode: MDCompileUnit llvm-svn: 229013
2015-02-13 09:25:10 +08:00
Stream.EmitRecord(bitc::METADATA_COMPILE_UNIT, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDCompileUnit llvm-svn: 229013
2015-02-13 09:25:10 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDISubprogram(const DISubprogram *N, const ValueEnumerator &VE,
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-30 00:38:44 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
AsmWriter/Bitcode: MDSubprogram llvm-svn: 229014
2015-02-13 09:26:47 +08:00
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getRawLinkageName()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getType()));
Record.push_back(N->isLocalToUnit());
Record.push_back(N->isDefinition());
Record.push_back(N->getScopeLine());
Record.push_back(VE.getMetadataOrNullID(N->getContainingType()));
Record.push_back(N->getVirtuality());
Record.push_back(N->getVirtualIndex());
Record.push_back(N->getFlags());
Record.push_back(N->isOptimized());
IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*() Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes ambiguity (at least in some [1] compilers [2]) when using indexes to `MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to (but not the same as) `unsigned`. [1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308 [2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442 llvm-svn: 234326
2015-04-08 00:50:39 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getTemplateParams().get()));
AsmWriter/Bitcode: MDSubprogram llvm-svn: 229014
2015-02-13 09:26:47 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getDeclaration()));
IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*() Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes ambiguity (at least in some [1] compilers [2]) when using indexes to `MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to (but not the same as) `unsigned`. [1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308 [2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442 llvm-svn: 234326
2015-04-08 00:50:39 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getVariables().get()));
AsmWriter/Bitcode: MDSubprogram llvm-svn: 229014
2015-02-13 09:26:47 +08:00
Stream.EmitRecord(bitc::METADATA_SUBPROGRAM, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDSubprogram llvm-svn: 229014
2015-02-13 09:26:47 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDILexicalBlock(const DILexicalBlock *N,
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-30 00:38:44 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
AsmWriter/Bitcode: MDLexicalBlock llvm-svn: 229016
2015-02-13 09:29:28 +08:00
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(N->getLine());
Record.push_back(N->getColumn());
Stream.EmitRecord(bitc::METADATA_LEXICAL_BLOCK, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDLexicalBlock llvm-svn: 229016
2015-02-13 09:29:28 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDILexicalBlockFile(const DILexicalBlockFile *N,
AsmWriter/Bitcode: MDLexicalBlockFile llvm-svn: 229017
2015-02-13 09:30:42 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(N->getDiscriminator());
Stream.EmitRecord(bitc::METADATA_LEXICAL_BLOCK_FILE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDLexicalBlockFile llvm-svn: 229017
2015-02-13 09:30:42 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDINamespace(const DINamespace *N, const ValueEnumerator &VE,
AsmWriter/Bitcode: MDNamespace llvm-svn: 229018
2015-02-13 09:32:09 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(N->getLine());
Stream.EmitRecord(bitc::METADATA_NAMESPACE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDNamespace llvm-svn: 229018
2015-02-13 09:32:09 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIMacro(const DIMacro *N, const ValueEnumerator &VE,
Macro debug info support in LLVM IR Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
2015-12-10 20:56:35 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record, unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getMacinfoType());
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getRawValue()));
Stream.EmitRecord(bitc::METADATA_MACRO, Record, Abbrev);
Record.clear();
}
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIMacroFile(const DIMacroFile *N, const ValueEnumerator &VE,
Macro debug info support in LLVM IR Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
2015-12-10 20:56:35 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getMacinfoType());
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(VE.getMetadataOrNullID(N->getElements().get()));
Stream.EmitRecord(bitc::METADATA_MACRO_FILE, Record, Abbrev);
Record.clear();
}
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIModule(const DIModule *N, const ValueEnumerator &VE,
Add a DIModule metadata node to the IR. It is meant to be used to record modules @imported by the current compile unit, so a debugger an import the same modules to replicate this environment before dropping into the expression evaluator. DIModule is a sibling to DINamespace and behaves quite similarly. In addition to the name of the module it also records the module configuration details that are necessary to uniquely identify the module. This includes the configuration macros (e.g., -DNDEBUG), the include path where the module.map file is to be found, and the isysroot. The idea is that the backend will turn this into a DW_TAG_module. http://reviews.llvm.org/D9614 rdar://problem/20965932 llvm-svn: 241017
2015-06-30 07:03:47 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record, unsigned Abbrev) {
Record.push_back(N->isDistinct());
for (auto &I : N->operands())
Record.push_back(VE.getMetadataOrNullID(I));
Stream.EmitRecord(bitc::METADATA_MODULE, Record, Abbrev);
Record.clear();
}
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDITemplateTypeParameter(const DITemplateTypeParameter *N,
AsmWriter/Bitcode: MDTemplate{Type,Value}Parameter llvm-svn: 229019
2015-02-13 09:34:32 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getType()));
Stream.EmitRecord(bitc::METADATA_TEMPLATE_TYPE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDTemplate{Type,Value}Parameter llvm-svn: 229019
2015-02-13 09:34:32 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDITemplateValueParameter(const DITemplateValueParameter *N,
AsmWriter/Bitcode: MDTemplate{Type,Value}Parameter llvm-svn: 229019
2015-02-13 09:34:32 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getTag());
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getType()));
Record.push_back(VE.getMetadataOrNullID(N->getValue()));
Stream.EmitRecord(bitc::METADATA_TEMPLATE_VALUE, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDTemplate{Type,Value}Parameter llvm-svn: 229019
2015-02-13 09:34:32 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIGlobalVariable(const DIGlobalVariable *N,
AsmWriter/Bitcode: MDGlobalVariable llvm-svn: 229020
2015-02-13 09:35:40 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getRawLinkageName()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getType()));
Record.push_back(N->isLocalToUnit());
Record.push_back(N->isDefinition());
DebugInfo: Make MDSubprogram::getFunction() return Constant Change `MDSubprogram::getFunction()` and `MDGlobalVariable::getConstant()` to return a `Constant`. Previously, both returned `ConstantAsMetadata`. llvm-svn: 234699
2015-04-12 04:27:40 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getRawVariable()));
AsmWriter/Bitcode: MDGlobalVariable llvm-svn: 229020
2015-02-13 09:35:40 +08:00
Record.push_back(VE.getMetadataOrNullID(N->getStaticDataMemberDeclaration()));
Stream.EmitRecord(bitc::METADATA_GLOBAL_VAR, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDGlobalVariable llvm-svn: 229020
2015-02-13 09:35:40 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDILocalVariable(const DILocalVariable *N,
AsmWriter/Bitcode: MDLocalVariable llvm-svn: 229022
2015-02-13 09:39:44 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getType()));
Record.push_back(N->getArg());
Record.push_back(N->getFlags());
Stream.EmitRecord(bitc::METADATA_LOCAL_VAR, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDLocalVariable llvm-svn: 229022
2015-02-13 09:39:44 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIExpression(const DIExpression *N, const ValueEnumerator &,
AsmWriter/Bitcode: MDExpression llvm-svn: 229023
2015-02-13 09:42:09 +08:00
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.reserve(N->getElements().size() + 1);
Record.push_back(N->isDistinct());
Prefer SmallVector::append/insert over push_back loops. Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
2015-02-17 23:29:18 +08:00
Record.append(N->elements_begin(), N->elements_end());
AsmWriter/Bitcode: MDExpression llvm-svn: 229023
2015-02-13 09:42:09 +08:00
Stream.EmitRecord(bitc::METADATA_EXPRESSION, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDExpression llvm-svn: 229023
2015-02-13 09:42:09 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIObjCProperty(const DIObjCProperty *N,
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-30 00:38:44 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
AsmWriter/Bitcode: MDObjCProperty llvm-svn: 229024
2015-02-13 09:43:22 +08:00
Record.push_back(N->isDistinct());
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Record.push_back(VE.getMetadataOrNullID(N->getFile()));
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getRawSetterName()));
Record.push_back(VE.getMetadataOrNullID(N->getRawGetterName()));
Record.push_back(N->getAttributes());
Record.push_back(VE.getMetadataOrNullID(N->getType()));
Stream.EmitRecord(bitc::METADATA_OBJC_PROPERTY, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
AsmWriter/Bitcode: MDObjCProperty llvm-svn: 229024
2015-02-13 09:43:22 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeDIImportedEntity(const DIImportedEntity *N,
AsmWriter/Bitcode: MDImportedEntity llvm-svn: 229025
2015-02-13 09:46:02 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record,
unsigned Abbrev) {
Record.push_back(N->isDistinct());
Record.push_back(N->getTag());
Record.push_back(VE.getMetadataOrNullID(N->getScope()));
Record.push_back(VE.getMetadataOrNullID(N->getEntity()));
Record.push_back(N->getLine());
Record.push_back(VE.getMetadataOrNullID(N->getRawName()));
Stream.EmitRecord(bitc::METADATA_IMPORTED_ENTITY, Record, Abbrev);
Record.clear();
IR: Add specialized debug info metadata nodes Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
2015-02-10 08:52:32 +08:00
}
BitcodeWriter: Split out named metadata; almost NFC Split writeNamedMetadata out of WriteModuleMetadata to write named metadata, and createNamedMetadataAbbrev for the abbreviation. There should be no effective functionality change, although the layout of the bitcode will change. Previously, the abbreviation was emitted at the top of the block, but now it is delayed until immediately before the named metadata records are emitted. llvm-svn: 264301
2016-03-25 00:16:08 +08:00
static unsigned createNamedMetadataAbbrev(BitstreamWriter &Stream) {
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::METADATA_NAME));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 8));
return Stream.EmitAbbrev(Abbv);
}
static void writeNamedMetadata(const Module &M, const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record) {
if (M.named_metadata_empty())
return;
unsigned Abbrev = createNamedMetadataAbbrev(Stream);
for (const NamedMDNode &NMD : M.named_metadata()) {
// Write name.
StringRef Str = NMD.getName();
Record.append(Str.bytes_begin(), Str.bytes_end());
Stream.EmitRecord(bitc::METADATA_NAME, Record, Abbrev);
Record.clear();
// Write named metadata operands.
for (const MDNode *N : NMD.operands())
Record.push_back(VE.getMetadataID(N));
Stream.EmitRecord(bitc::METADATA_NAMED_NODE, Record, 0);
Record.clear();
}
}
Reapply ~"Bitcode: Collect all MDString records into a single blob" Spiritually reapply commit r264409 (reverted in r264410), albeit with a bit of a redesign. Firstly, avoid splitting the big blob into multiple chunks of strings. r264409 imposed an arbitrary limit to avoid a massive allocation on the shared 'Record' SmallVector. The bug with that commit only reproduced when there were more than "chunk-size" strings. A test for this would have been useless long-term, since we're liable to adjust the chunk-size in the future. Thus, eliminate the motivation for chunk-ing by storing the string sizes in the blob. Here's the layout: vbr6: # of strings vbr6: offset-to-blob blob: [vbr6]: string lengths [char]: concatenated strings Secondly, make the output of llvm-bcanalyzer readable. I noticed when debugging r264409 that llvm-bcanalyzer was outputting a massive blob all in one line. Past a small number, the strings were impossible to split in my head, and the lines were way too long. This version adds support in llvm-bcanalyzer for pretty-printing. <STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 { 'abc' 'def' 'ghi' } From the original commit: Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this should (a) slightly reduce bitcode size, since there is less record overhead, and (b) greatly improve reading speed, since blobs are super cheap to deserialize. llvm-svn: 264551
2016-03-28 07:17:54 +08:00
static unsigned createMetadataStringsAbbrev(BitstreamWriter &Stream) {
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::METADATA_STRINGS));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // # of strings
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // offset to chars
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Blob));
return Stream.EmitAbbrev(Abbv);
}
/// Write out a record for MDString.
///
/// All the metadata strings in a metadata block are emitted in a single
/// record. The sizes and strings themselves are shoved into a blob.
static void writeMetadataStrings(ArrayRef<const Metadata *> Strings,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record) {
if (Strings.empty())
return;
// Start the record with the number of strings.
Record.push_back(bitc::METADATA_STRINGS);
Record.push_back(Strings.size());
// Emit the sizes of the strings in the blob.
SmallString<256> Blob;
{
BitstreamWriter W(Blob);
for (const Metadata *MD : Strings)
W.EmitVBR(cast<MDString>(MD)->getLength(), 6);
W.FlushToWord();
}
// Add the offset to the strings to the record.
Record.push_back(Blob.size());
// Add the strings to the blob.
for (const Metadata *MD : Strings)
Blob.append(cast<MDString>(MD)->getString());
// Emit the final record.
Stream.EmitRecordWithBlob(createMetadataStringsAbbrev(Stream), Record, Blob);
Record.clear();
}
BitcodeWriter: Split out writeMetadataRecords, NFC Besides being a nice cleanup, this is preparation for reusing the code in function metadata blocks. llvm-svn: 264555
2016-03-28 07:53:30 +08:00
static void writeMetadataRecords(ArrayRef<const Metadata *> MDs,
const ValueEnumerator &VE,
BitstreamWriter &Stream,
SmallVectorImpl<uint64_t> &Record) {
if (MDs.empty())
Bitcode: Simplify emission of METADATA_BLOCK Refactor logic so that we know up-front whether to open a block and whether we need an MDString abbreviation. This is almost NFC, but will start emitting `MDString` abbreviations when the first record is not an `MDString`. llvm-svn: 225712
2015-01-13 06:30:34 +08:00
return;
IR: Initialize MDNode abbreviations en masse, NFC llvm-svn: 228203
2015-02-05 05:54:12 +08:00
// Initialize MDNode abbreviations.
#define HANDLE_MDNODE_LEAF(CLASS) unsigned CLASS##Abbrev = 0;
#include "llvm/IR/Metadata.def"
BitcodeWriter: Split out writeMetadataRecords, NFC Besides being a nice cleanup, this is preparation for reusing the code in function metadata blocks. llvm-svn: 264555
2016-03-28 07:53:30 +08:00
for (const Metadata *MD : MDs) {
Bitcode: Range-based for, NFC llvm-svn: 225713
2015-01-13 06:31:35 +08:00
if (const MDNode *N = dyn_cast<MDNode>(MD)) {
AsmWriter: Assert on unresolved metadata nodes Assert that `MDNode::isResolved()`. While in theory the `Verifier` should catch this, it doesn't descend into all debug info, and the `DebugInfoVerifier` doesn't call into the `Verifier`. Besides, this helps to catch bugs when `-disable-verify=true`. Note that I haven't come across a place where this fails with clang today, so no testcase. llvm-svn: 232442
2015-03-17 08:16:35 +08:00
assert(N->isResolved() && "Expected forward references to be resolved");
Bitcode: Simplify MDNode subclass dispatch, NFC llvm-svn: 226535
2015-01-20 09:03:09 +08:00
switch (N->getMetadataID()) {
default:
llvm_unreachable("Invalid MDNode subclass");
#define HANDLE_MDNODE_LEAF(CLASS) \
case Metadata::CLASS##Kind: \
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
write##CLASS(cast<CLASS>(N), VE, Stream, Record, CLASS##Abbrev); \
Bitcode: Simplify MDNode subclass dispatch, NFC llvm-svn: 226535
2015-01-20 09:03:09 +08:00
continue;
#include "llvm/IR/Metadata.def"
}
Bitcode: Simplify emission of METADATA_BLOCK Refactor logic so that we know up-front whether to open a block and whether we need an MDString abbreviation. This is almost NFC, but will start emitting `MDString` abbreviations when the first record is not an `MDString`. llvm-svn: 225712
2015-01-13 06:30:34 +08:00
}
BitcodeWriter: Reuse writeMetadataRecords, NFC Change writeFunctionMetadata to call writeMetadataRecords. For now there's no functionality change, but makes it easy to serialize other types of metadata in the function block in the future. llvm-svn: 264557
2016-03-28 07:59:32 +08:00
writeValueAsMetadata(cast<ValueAsMetadata>(MD), VE, Stream, Record);
Make NamedMDNode not be a subclass of Value, and simplify the interface for creating and populating NamedMDNodes. llvm-svn: 109061
2010-07-22 07:38:33 +08:00
}
BitcodeWriter: Split out writeMetadataRecords, NFC Besides being a nice cleanup, this is preparation for reusing the code in function metadata blocks. llvm-svn: 264555
2016-03-28 07:53:30 +08:00
}
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeModuleMetadata(const Module &M,
BitcodeWriter: Split out writeMetadataRecords, NFC Besides being a nice cleanup, this is preparation for reusing the code in function metadata blocks. llvm-svn: 264555
2016-03-28 07:53:30 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream) {
BitcodeWriter: Further unify function metadata, NFC Further unify the handling of function-local metadata with global metadata, by exposing the same interface in ValueEnumerator. Both contexts use the same accessors: - getMDStrings(): get the strings for this block. - getNonMDStrings(): get the non-strings for this block. A future commit will start adding strings to the function-block. llvm-svn: 265224
2016-04-02 23:09:42 +08:00
if (!VE.hasMDs() && M.named_metadata_empty())
BitcodeWriter: Split out writeMetadataRecords, NFC Besides being a nice cleanup, this is preparation for reusing the code in function metadata blocks. llvm-svn: 264555
2016-03-28 07:53:30 +08:00
return;
Stream.EnterSubblock(bitc::METADATA_BLOCK_ID, 3);
SmallVector<uint64_t, 64> Record;
writeMetadataStrings(VE.getMDStrings(), Stream, Record);
writeMetadataRecords(VE.getNonMDStrings(), VE, Stream, Record);
BitcodeWriter: Split out named metadata; almost NFC Split writeNamedMetadata out of WriteModuleMetadata to write named metadata, and createNamedMetadataAbbrev for the abbreviation. There should be no effective functionality change, although the layout of the bitcode will change. Previously, the abbreviation was emitted at the top of the block, but now it is delayed until immediately before the named metadata records are emitted. llvm-svn: 264301
2016-03-25 00:16:08 +08:00
writeNamedMetadata(M, VE, Stream, Record);
Bitcode: Simplify emission of METADATA_BLOCK Refactor logic so that we know up-front whether to open a block and whether we need an MDString abbreviation. This is almost NFC, but will start emitting `MDString` abbreviations when the first record is not an `MDString`. llvm-svn: 225712
2015-01-13 06:30:34 +08:00
Stream.ExitBlock();
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
}
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
static void writeFunctionMetadata(const Function &F, const ValueEnumerator &VE,
BitstreamWriter &Stream) {
BitcodeWriter: Further unify function metadata, NFC Further unify the handling of function-local metadata with global metadata, by exposing the same interface in ValueEnumerator. Both contexts use the same accessors: - getMDStrings(): get the strings for this block. - getNonMDStrings(): get the non-strings for this block. A future commit will start adding strings to the function-block. llvm-svn: 265224
2016-04-02 23:09:42 +08:00
if (!VE.hasMDs())
BitcodeWriter: Restructure WriteFunctionLocalMetadata, NFC Use an early return to simplify logic. llvm-svn: 264554
2016-03-28 07:38:36 +08:00
return;
Stream.EnterSubblock(bitc::METADATA_BLOCK_ID, 3);
Write function-local metadata as a metadata subblock of a funciton block llvm-svn: 93339
2010-01-14 03:37:33 +08:00
SmallVector<uint64_t, 64> Record;
Bitcode: Try to emit metadata in function blocks Whenever metadata is only referenced by a single function, emit the metadata just in that function block. This should improve lazy-loading by reducing the amount of metadata in the global block. For now, this should catch all DILocations, and anything else that happens to be referenced only by a single function. It's also a first step toward a couple of possible future directions (which this commit does *not* implement): 1. Some debug info metadata is only referenced from compile units and individual functions. If we can drop the link from the compile unit, this optimization will get more powerful. 2. Any uniqued metadata that isn't referenced globally can in theory be emitted in every function block that references it (trading off bitcode size and full-parse time vs. lazy-load time). Note: this assumes the new BitcodeReader error checking from r265223. The metadata stored in function blocks gets purged after parsing each function, which means unresolved forward references will get lost. Since all the global metadata should have already been resolved by the time we get to the function metadata blocks we just need to check for that case. (If for some reason we need to handle bitcode that fails the checks in r265223, the fix is to store about-to-be-dropped unresolved nodes in MetadataList::shrinkTo until they can be handled succesfully by a future call to MetadataList::tryToResolveCycles.) llvm-svn: 265226
2016-04-02 23:22:57 +08:00
writeMetadataStrings(VE.getMDStrings(), Stream, Record);
BitcodeWriter: Further unify function metadata, NFC Further unify the handling of function-local metadata with global metadata, by exposing the same interface in ValueEnumerator. Both contexts use the same accessors: - getMDStrings(): get the strings for this block. - getNonMDStrings(): get the non-strings for this block. A future commit will start adding strings to the function-block. llvm-svn: 265224
2016-04-02 23:09:42 +08:00
writeMetadataRecords(VE.getNonMDStrings(), VE, Stream, Record);
BitcodeWriter: Restructure WriteFunctionLocalMetadata, NFC Use an early return to simplify logic. llvm-svn: 264554
2016-03-28 07:38:36 +08:00
Stream.ExitBlock();
Write function-local metadata as a metadata subblock of a funciton block llvm-svn: 93339
2010-01-14 03:37:33 +08:00
}
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
static void WriteMetadataAttachment(const Function &F,
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
const ValueEnumerator &VE,
BitstreamWriter &Stream) {
Add special case bitcode support for DebugLoc. This avoids having the bitcode writer materialize mdnodes for all the debug location tuples when writing out the bc file and stores the information in a more compact form. For example, the -O0 -g bc file for combine.c in 176.gcc shrinks from 739392 to 512096 bytes. This concludes my planned short-term debug info work. llvm-svn: 100261
2010-04-03 10:17:50 +08:00
Stream.EnterSubblock(bitc::METADATA_ATTACHMENT_ID, 3);
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
SmallVector<uint64_t, 64> Record;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
// Write metadata attachments
missed a file. llvm-svn: 133270
2011-06-18 01:56:00 +08:00
// METADATA_ATTACHMENT - [m x [value, [n x [id, mdnode]]]
Revert "IR: MDNode => Value" Instead, we're going to separate metadata from the Value hierarchy. See PR21532. This reverts commit r221375. This reverts commit r221373. This reverts commit r221359. This reverts commit r221167. This reverts commit r221027. This reverts commit r221024. This reverts commit r221023. This reverts commit r220995. This reverts commit r220994. llvm-svn: 221711
2014-11-12 05:30:22 +08:00
SmallVector<std::pair<unsigned, MDNode *>, 4> MDs;
IR: Add assembly/bitcode support for function metadata attachments Add serialization support for function metadata attachments (added in r235783). The syntax is: define @foo() !attach !0 { Metadata attachments are only allowed on functions with bodies. Since they come before the `{`, they're not really part of the body; since they require a body, they're not really part of the header. In `LLParser` I gave them a separate function called from `ParseDefine()`, `ParseOptionalFunctionMetadata()`. In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by instructions. Instruction metadata attachments are included in a special "attachment" block at the end of a `Function`. The attachment records are laid out like this: InstID (KindID MetadataID)+ Note that these records always have an odd number of fields. The new code takes advantage of this to recognize function attachments (which don't need an instruction ID): (KindID MetadataID)+ This means we can use the same attachment block already used for instructions. This is part of PR23340. llvm-svn: 235785
2015-04-25 06:04:41 +08:00
F.getAllMetadata(MDs);
if (!MDs.empty()) {
for (const auto &I : MDs) {
Record.push_back(I.first);
Record.push_back(VE.getMetadataID(I.second));
}
Stream.EmitRecord(bitc::METADATA_ATTACHMENT, Record, 0);
Record.clear();
}
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
BitcodeWriter: Stop using implicit ilist iterator conversion, NFC Now LLVMBitWriter compiles without implicit ilist iterator conversions. In these cases, the cleanest thing was to switch to range-based for loops. Since there wasn't much noise I converted sub-loops and parent loops as a drive-by. llvm-svn: 250144
2015-10-13 11:26:19 +08:00
for (const BasicBlock &BB : F)
for (const Instruction &I : BB) {
Fix getMDs() interface such that it does not expose implementation details. llvm-svn: 84885
2009-10-23 02:55:16 +08:00
MDs.clear();
BitcodeWriter: Stop using implicit ilist iterator conversion, NFC Now LLVMBitWriter compiles without implicit ilist iterator conversions. In these cases, the cleanest thing was to switch to range-based for loops. Since there wasn't much noise I converted sub-loops and parent loops as a drive-by. llvm-svn: 250144
2015-10-13 11:26:19 +08:00
I.getAllMetadataOtherThanDebugLoc(MDs);
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
This is a major cleanup of the instruction metadata interfaces that I asked Devang to do back on Sep 27. Instead of going through the MetadataContext class with methods like getMD() and getMDs(), just ask the instruction directly for its metadata with getMetadata() and getAllMetadata(). This includes a variety of other fixes and improvements: previously all Value*'s were bloated because the HasMetadata bit was thrown into value, adding a 9th bit to a byte. Now this is properly sunk down to the Instruction class (the only place where it makes sense) and it will be folded away somewhere soon. This also fixes some confusion in getMDs and its clients about whether the returned list is indexed by the MDID or densely packed. This is now returned sorted and densely packed and the comments make this clear. This introduces a number of fixme's which I'll follow up on. llvm-svn: 92235
2009-12-29 07:41:32 +08:00
// If no metadata, ignore instruction.
if (MDs.empty()) continue;
BitcodeWriter: Stop using implicit ilist iterator conversion, NFC Now LLVMBitWriter compiles without implicit ilist iterator conversions. In these cases, the cleanest thing was to switch to range-based for loops. Since there wasn't much noise I converted sub-loops and parent loops as a drive-by. llvm-svn: 250144
2015-10-13 11:26:19 +08:00
Record.push_back(VE.getInstructionID(&I));
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
This is a major cleanup of the instruction metadata interfaces that I asked Devang to do back on Sep 27. Instead of going through the MetadataContext class with methods like getMD() and getMDs(), just ask the instruction directly for its metadata with getMetadata() and getAllMetadata(). This includes a variety of other fixes and improvements: previously all Value*'s were bloated because the HasMetadata bit was thrown into value, adding a 9th bit to a byte. Now this is properly sunk down to the Instruction class (the only place where it makes sense) and it will be folded away somewhere soon. This also fixes some confusion in getMDs and its clients about whether the returned list is indexed by the MDID or densely packed. This is now returned sorted and densely packed and the comments make this clear. This introduces a number of fixme's which I'll follow up on. llvm-svn: 92235
2009-12-29 07:41:32 +08:00
for (unsigned i = 0, e = MDs.size(); i != e; ++i) {
Record.push_back(MDs[i].first);
IR: Split Metadata from Value Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
2014-12-10 02:38:53 +08:00
Record.push_back(VE.getMetadataID(MDs[i].second));
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
}
missed a file. llvm-svn: 133270
2011-06-18 01:56:00 +08:00
Stream.EmitRecord(bitc::METADATA_ATTACHMENT, Record, 0);
This is a major cleanup of the instruction metadata interfaces that I asked Devang to do back on Sep 27. Instead of going through the MetadataContext class with methods like getMD() and getMDs(), just ask the instruction directly for its metadata with getMetadata() and getAllMetadata(). This includes a variety of other fixes and improvements: previously all Value*'s were bloated because the HasMetadata bit was thrown into value, adding a 9th bit to a byte. Now this is properly sunk down to the Instruction class (the only place where it makes sense) and it will be folded away somewhere soon. This also fixes some confusion in getMDs and its clients about whether the returned list is indexed by the MDID or densely packed. This is now returned sorted and densely packed and the comments make this clear. This introduces a number of fixme's which I'll follow up on. llvm-svn: 92235
2009-12-29 07:41:32 +08:00
Record.clear();
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
}
Add special case bitcode support for DebugLoc. This avoids having the bitcode writer materialize mdnodes for all the debug location tuples when writing out the bc file and stores the information in a more compact form. For example, the -O0 -g bc file for combine.c in 176.gcc shrinks from 739392 to 512096 bytes. This concludes my planned short-term debug info work. llvm-svn: 100261
2010-04-03 10:17:50 +08:00
Stream.ExitBlock();
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
}
rename getHandlerNames to getMDKindNames, simplify its interface and simplify all the clients that use it. llvm-svn: 92224
2009-12-29 04:10:43 +08:00
static void WriteModuleMetadataStore(const Module *M, BitstreamWriter &Stream) {
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
SmallVector<uint64_t, 64> Record;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
// Write metadata kinds
// METADATA_KIND - [n x [id, name]]
Minor tweaking to SmallVector static size. llvm-svn: 169176
2012-12-04 06:57:47 +08:00
SmallVector<StringRef, 8> Names;
Final step in the metadata API restructuring: move the getMDKindID/getMDKindNames methods to LLVMContext (and add convenience methods to Module), eliminating MetadataContext. Move the state that it maintains out to LLVMContext. llvm-svn: 92259
2009-12-29 17:01:33 +08:00
M->getMDKindNames(Names);
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
Add support for remapping metadata kind IDs when reading in a bitcode file, so that two bitcode files where the same metadata kind name happens to have been assigned a different ID can still be linked together. Eliminate the restriction that metadata kind IDs can't be 0. Change MD_dbg from 1 to 0, because we can now, and because it's less mysterious that way. llvm-svn: 108939
2010-07-21 05:42:28 +08:00
if (Names.empty()) return;
rename getHandlerNames to getMDKindNames, simplify its interface and simplify all the clients that use it. llvm-svn: 92224
2009-12-29 04:10:43 +08:00
Use a different block id for block of metadata kind records Summary: There are currently two blocks with the METADATA_BLOCK id at module scope. The first has the module-level metadata values (consisting of some combination of METADATA_* record codes except for METADATA_KIND). The second consists only of METADATA_KIND records. The latter is used only in the METADATA_ATTACHMENT block within function blocks (for metadata attached to instructions). For ThinLTO we want to delay the parsing of module level metadata until all functions have been imported from that module (there is some bookkeeping used to suture it up when we read it during a post-pass). However, we do need the METADATA_KIND records when parsing the function body during importing, since those kinds are used as described above. To simplify identification and parsing of just the block containing the metadata kinds, use a different block id (METADATA_KIND_BLOCK_ID). Support older bitcode without the new block id as well. Reviewers: dexonsmith, joker.eph Subscribers: davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D14654 llvm-svn: 253154
2015-11-15 10:00:09 +08:00
Stream.EnterSubblock(bitc::METADATA_KIND_BLOCK_ID, 3);
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
Add support for remapping metadata kind IDs when reading in a bitcode file, so that two bitcode files where the same metadata kind name happens to have been assigned a different ID can still be linked together. Eliminate the restriction that metadata kind IDs can't be 0. Change MD_dbg from 1 to 0, because we can now, and because it's less mysterious that way. llvm-svn: 108939
2010-07-21 05:42:28 +08:00
for (unsigned MDKindID = 0, e = Names.size(); MDKindID != e; ++MDKindID) {
rename getHandlerNames to getMDKindNames, simplify its interface and simplify all the clients that use it. llvm-svn: 92224
2009-12-29 04:10:43 +08:00
Record.push_back(MDKindID);
StringRef KName = Names[MDKindID];
Record.append(KName.begin(), KName.end());
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
Stream.EmitRecord(bitc::METADATA_KIND, Record, 0);
Record.clear();
}
rename getHandlerNames to getMDKindNames, simplify its interface and simplify all the clients that use it. llvm-svn: 92224
2009-12-29 04:10:43 +08:00
Stream.ExitBlock();
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
}
Introduce MetadataBase, a base class for MDString and MDNode. Derive MDString directly from MetadataBase. Introduce new bitcode block to hold metadata. llvm-svn: 76759
2009-07-23 01:43:22 +08:00
[Bitcode][Asm] Teach LLVM to read and write operand bundles. Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
2015-09-25 07:34:52 +08:00
static void WriteOperandBundleTags(const Module *M, BitstreamWriter &Stream) {
// Write metadata kinds
//
// OPERAND_BUNDLE_TAGS_BLOCK_ID : N x OPERAND_BUNDLE_TAG
//
// OPERAND_BUNDLE_TAG - [strchr x N]
SmallVector<StringRef, 8> Tags;
M->getOperandBundleTags(Tags);
if (Tags.empty())
return;
Stream.EnterSubblock(bitc::OPERAND_BUNDLE_TAGS_BLOCK_ID, 3);
SmallVector<uint64_t, 64> Record;
for (auto Tag : Tags) {
Record.append(Tag.begin(), Tag.end());
Stream.EmitRecord(bitc::OPERAND_BUNDLE_TAG, Record, 0);
Record.clear();
}
Stream.ExitBlock();
}
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
static void emitSignedInt64(SmallVectorImpl<uint64_t> &Vals, uint64_t V) {
if ((int64_t)V >= 0)
Vals.push_back(V << 1);
else
Vals.push_back((-V << 1) | 1);
}
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
static void WriteConstants(unsigned FirstVal, unsigned LastVal,
const ValueEnumerator &VE,
BitstreamWriter &Stream, bool isGlobal) {
if (FirstVal == LastVal) return;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
Stream.EnterSubblock(bitc::CONSTANTS_BLOCK_ID, 4);
add an abbreviation for the string constants opzn, shrinking the constnats block from: Block ID #11 (CONSTANTS_BLOCK): Num Instances: 1722 Total Size: 3.85976e+06b/482470B/120617W % of file: 16.7609 Average Size: 2241.44b/280.18B/70.045W Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 1/0.00058072 Tot/Avg Records: 26423/15.3444 % Abbrev Recs: 69.1746 to: Block ID #11 (CONSTANTS_BLOCK): Num Instances: 1724 Total Size: 2.62406e+06b/328008B/82001.9W % of file: 12.041 Average Size: 1522.08b/190.26B/47.5649W Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 2/0.00116009 Tot/Avg Records: 26280/15.2436 % Abbrev Recs: 68.9992 This shrinks kc++ from 2815788 to 2724088 bytes, which means the bitcode file is now smaller than the bytecode file. llvm-svn: 36820
2007-05-06 08:42:18 +08:00
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
unsigned AggregateAbbrev = 0;
unsigned String8Abbrev = 0;
unsigned CString7Abbrev = 0;
unsigned CString6Abbrev = 0;
// If this is a constant pool for the module, emit module-specific abbrevs.
if (isGlobal) {
// Abbrev for CST_CODE_AGGREGATE.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::CST_CODE_AGGREGATE));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, Log2_32_Ceil(LastVal+1)));
AggregateAbbrev = Stream.EmitAbbrev(Abbv);
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
// Abbrev for CST_CODE_STRING.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::CST_CODE_STRING));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 8));
String8Abbrev = Stream.EmitAbbrev(Abbv);
// Abbrev for CST_CODE_CSTRING.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::CST_CODE_CSTRING));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 7));
CString7Abbrev = Stream.EmitAbbrev(Abbv);
// Abbrev for CST_CODE_CSTRING.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::CST_CODE_CSTRING));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Char6));
CString6Abbrev = Stream.EmitAbbrev(Abbv);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
}
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
SmallVector<uint64_t, 64> Record;
Constants and Metadata share ValueList. This means they must be emitted interleaved (using appropriate BLOCK_IDs) otherwise ValuePtrs index gets out of sync. llvm-svn: 78033
2009-08-04 10:26:56 +08:00
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
const ValueEnumerator::ValueList &Vals = VE.getValues();
[C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 206252
2014-04-15 14:32:26 +08:00
Type *LastTy = nullptr;
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
for (unsigned i = FirstVal; i != LastVal; ++i) {
const Value *V = Vals[i].first;
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
// If we need to switch types, do so now.
if (V->getType() != LastTy) {
LastTy = V->getType();
Record.push_back(VE.getTypeID(LastTy));
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
Stream.EmitRecord(bitc::CST_CODE_SETTYPE, Record,
CONSTANTS_SETTYPE_ABBREV);
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
Record.clear();
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
if (const InlineAsm *IA = dyn_cast<InlineAsm>(V)) {
Add an "msasm" flag to inline asm as suggested in PR 5125. A little ugliness is accepted to keep the binary file format compatible. No functional change yet. llvm-svn: 84020
2009-10-14 04:46:56 +08:00
Record.push_back(unsigned(IA->hasSideEffects()) |
[ms-inline asm] Add support for the nsdialect keyword in the Bitcode Reader/Writer. llvm-svn: 163185
2012-09-05 08:56:20 +08:00
unsigned(IA->isAlignStack()) << 1 |
unsigned(IA->getDialect()&1) << 2);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
implement reading/writing of inlineasm objects llvm-svn: 36827
2007-05-06 09:58:20 +08:00
// Add the asm string.
const std::string &AsmStr = IA->getAsmString();
Record.push_back(AsmStr.size());
Prefer SmallVector::append/insert over push_back loops. Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
2015-02-17 23:29:18 +08:00
Record.append(AsmStr.begin(), AsmStr.end());
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
implement reading/writing of inlineasm objects llvm-svn: 36827
2007-05-06 09:58:20 +08:00
// Add the constraint string.
const std::string &ConstraintStr = IA->getConstraintString();
Record.push_back(ConstraintStr.size());
Prefer SmallVector::append/insert over push_back loops. Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
2015-02-17 23:29:18 +08:00
Record.append(ConstraintStr.begin(), ConstraintStr.end());
implement reading/writing of inlineasm objects llvm-svn: 36827
2007-05-06 09:58:20 +08:00
Stream.EmitRecord(bitc::CST_CODE_INLINEASM, Record);
Record.clear();
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
continue;
}
const Constant *C = cast<Constant>(V);
unsigned Code = -1U;
unsigned AbbrevToUse = 0;
if (C->isNullValue()) {
Code = bitc::CST_CODE_NULL;
} else if (isa<UndefValue>(C)) {
Code = bitc::CST_CODE_UNDEF;
} else if (const ConstantInt *IV = dyn_cast<ConstantInt>(C)) {
Revert patches to add case-range support for PR1255. The work on this project was left in an unfinished and inconsistent state. Hopefully someone will eventually get a chance to implement this feature, but in the meantime, it is better to put things back the way the were. I have left support in the bitcode reader to handle the case-range bitcode format, so that we do not lose bitcode compatibility with the llvm 3.3 release. This reverts the following commits: 155464, 156374, 156377, 156613, 156704, 156757, 156804 156808, 156985, 157046, 157112, 157183, 157315, 157384, 157575, 157576, 157586, 157612, 157810, 157814, 157815, 157880, 157881, 157882, 157884, 157887, 157901, 158979, 157987, 157989, 158986, 158997, 159076, 159101, 159100, 159200, 159201, 159207, 159527, 159532, 159540, 159583, 159618, 159658, 159659, 159660, 159661, 159703, 159704, 160076, 167356, 172025, 186736 llvm-svn: 190328
2013-09-10 03:14:35 +08:00
if (IV->getBitWidth() <= 64) {
uint64_t V = IV->getSExtValue();
emitSignedInt64(Record, V);
Code = bitc::CST_CODE_INTEGER;
AbbrevToUse = CONSTANTS_INTEGER_ABBREV;
} else { // Wide integers, > 64 bits in size.
// We have an arbitrary precision integer value to write whose
// bit width is > 64. However, in canonical unsigned integer
// format it is likely that the high bits are going to be zero.
// So, we only write the number of active words.
unsigned NWords = IV->getValue().getActiveWords();
const uint64_t *RawWords = IV->getValue().getRawData();
for (unsigned i = 0; i != NWords; ++i) {
emitSignedInt64(Record, RawWords[i]);
}
Code = bitc::CST_CODE_WIDE_INTEGER;
}
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
} else if (const ConstantFP *CFP = dyn_cast<ConstantFP>(C)) {
Code = bitc::CST_CODE_FLOAT;
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
Type *Ty = CFP->getType();
The powers that be have decided that LLVM IR should now support 16-bit "half precision" floating-point with a first-class type. This patch adds basic IR support (but not codegen support). llvm-svn: 146786
2011-12-17 08:04:22 +08:00
if (Ty->isHalfTy() || Ty->isFloatTy() || Ty->isDoubleTy()) {
Rename APFloat::convertToAPInt to bitcastToAPInt to make it clearer what the function does. No functional change. llvm-svn: 57325
2008-10-10 02:53:47 +08:00
Record.push_back(CFP->getValueAPF().bitcastToAPInt().getZExtValue());
strength reduce a ton of type equality tests to check the typeid (Through the new predicates I added) instead of going through a context and doing a pointer comparison. Besides being cheaper, this allows a smart compiler to turn the if sequence into a switch. llvm-svn: 83297
2009-10-05 13:54:46 +08:00
} else if (Ty->isX86_FP80Ty()) {
Make temporaries explicit to avoid premature destruction of compiler-created ones. llvm-svn: 42383
2007-09-27 07:20:33 +08:00
// api needed to prevent premature destruction
Fix internal representation of fp80 to be the same as a normal i80 {low64, high16} rather than its own {high64, low16}. A depressing number of places know about this; I think I got them all. Bitcode readers and writers convert back to the old form to avoid breaking compatibility. llvm-svn: 67562
2009-03-24 05:16:53 +08:00
// bits are not in the same order as a normal i80 APInt, compensate.
Rename APFloat::convertToAPInt to bitcastToAPInt to make it clearer what the function does. No functional change. llvm-svn: 57325
2008-10-10 02:53:47 +08:00
APInt api = CFP->getValueAPF().bitcastToAPInt();
Make temporaries explicit to avoid premature destruction of compiler-created ones. llvm-svn: 42383
2007-09-27 07:20:33 +08:00
const uint64_t *p = api.getRawData();
Fix internal representation of fp80 to be the same as a normal i80 {low64, high16} rather than its own {high64, low16}. A depressing number of places know about this; I think I got them all. Bitcode readers and writers convert back to the old form to avoid breaking compatibility. llvm-svn: 67562
2009-03-24 05:16:53 +08:00
Record.push_back((p[1] << 48) | (p[0] >> 16));
Record.push_back(p[0] & 0xffffLL);
strength reduce a ton of type equality tests to check the typeid (Through the new predicates I added) instead of going through a context and doing a pointer comparison. Besides being cheaper, this allows a smart compiler to turn the if sequence into a switch. llvm-svn: 83297
2009-10-05 13:54:46 +08:00
} else if (Ty->isFP128Ty() || Ty->isPPC_FP128Ty()) {
Rename APFloat::convertToAPInt to bitcastToAPInt to make it clearer what the function does. No functional change. llvm-svn: 57325
2008-10-10 02:53:47 +08:00
APInt api = CFP->getValueAPF().bitcastToAPInt();
Make temporaries explicit to avoid premature destruction of compiler-created ones. llvm-svn: 42383
2007-09-27 07:20:33 +08:00
const uint64_t *p = api.getRawData();
Add APInt interfaces to APFloat (allows directly access to bits). Use them in place of float and double interfaces where appropriate. First bits of x86 long double constants handling (untested, probably does not work). llvm-svn: 41858
2007-09-12 02:32:33 +08:00
Record.push_back(p[0]);
Record.push_back(p[1]);
Patch 10 for long double. Doing constants right needs expanding ConstantFP to handle values bigger than double. If we assume host==target and host long double works correctly, this is not too bad, but we don't want to have that limitation longterm. I could implement accepting double constants as long double or something like that, which would lead to incorrect codegen with no errors; the more I think about that the worse it seems. Rather than do such a hack that would be backed out later, I'm settling for giving reasonable error messages, for now. llvm-svn: 40974
2007-08-10 06:51:36 +08:00
} else {
assert (0 && "Unknown FP type!");
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
}
Add bitcode reader and writer support for ConstantDataAggregate, which should be feature complete now. Lets see if it works. llvm-svn: 149215
2012-01-30 08:51:16 +08:00
} else if (isa<ConstantDataSequential>(C) &&
cast<ConstantDataSequential>(C)->isString()) {
const ConstantDataSequential *Str = cast<ConstantDataSequential>(C);
// Emit constant strings specially.
unsigned NumElts = Str->getNumElements();
// If this is a null-terminated string, use the denser CSTRING encoding.
if (Str->isCString()) {
Code = bitc::CST_CODE_CSTRING;
--NumElts; // Don't encode the null, which isn't allowed by char6.
} else {
Code = bitc::CST_CODE_STRING;
AbbrevToUse = String8Abbrev;
}
bool isCStr7 = Code == bitc::CST_CODE_CSTRING;
bool isCStrChar6 = Code == bitc::CST_CODE_CSTRING;
for (unsigned i = 0; i != NumElts; ++i) {
unsigned char V = Str->getElementAsInteger(i);
Record.push_back(V);
isCStr7 &= (V & 128) == 0;
if (isCStrChar6)
isCStrChar6 = BitCodeAbbrevOp::isChar6(V);
}
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
Add bitcode reader and writer support for ConstantDataAggregate, which should be feature complete now. Lets see if it works. llvm-svn: 149215
2012-01-30 08:51:16 +08:00
if (isCStrChar6)
AbbrevToUse = CString6Abbrev;
else if (isCStr7)
AbbrevToUse = CString7Abbrev;
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
} else if (const ConstantDataSequential *CDS =
Add bitcode reader and writer support for ConstantDataAggregate, which should be feature complete now. Lets see if it works. llvm-svn: 149215
2012-01-30 08:51:16 +08:00
dyn_cast<ConstantDataSequential>(C)) {
fix a major oversight that is breaking some llvm-test tests. llvm-svn: 149230
2012-01-30 15:36:01 +08:00
Code = bitc::CST_CODE_DATA;
Add bitcode reader and writer support for ConstantDataAggregate, which should be feature complete now. Lets see if it works. llvm-svn: 149215
2012-01-30 08:51:16 +08:00
Type *EltTy = CDS->getType()->getElementType();
if (isa<IntegerType>(EltTy)) {
for (unsigned i = 0, e = CDS->getNumElements(); i != e; ++i)
Record.push_back(CDS->getElementAsInteger(i));
} else {
Bitcode: Fix reading and writing of ConstantDataVectors of halfs In r254991 I allowed ConstantDataVectors to contain elements of HalfTy, but I missed updating the bitcode reader and writer to handle this, so now we crash if we try to emit bitcode on programs that have constant vectors of half. This fixes the issue and adds test coverage for reading and writing constant sequences in bitcode. llvm-svn: 256982
2016-01-07 06:31:32 +08:00
for (unsigned i = 0, e = CDS->getNumElements(); i != e; ++i)
Record.push_back(
CDS->getElementAsAPFloat(i).bitcastToAPInt().getLimitedValue());
Add bitcode reader and writer support for ConstantDataAggregate, which should be feature complete now. Lets see if it works. llvm-svn: 149215
2012-01-30 08:51:16 +08:00
}
IR: Introduce ConstantAggregate, NFC Add a common parent class for ConstantArray, ConstantVector, and ConstantStruct called ConstantAggregate. These are the aggregate subclasses of Constant that take operands. This is mainly a cleanup, adding common `isa` target and removing duplicated code. However, it also simplifies caching which constants point transitively at `GlobalValue` (a possible future direction). llvm-svn: 265466
2016-04-06 05:10:45 +08:00
} else if (isa<ConstantAggregate>(C)) {
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
Code = bitc::CST_CODE_AGGREGATE;
Use foreach loop over constant operands. NFC. A number of places had explicit loops over Constant::operands(). Just use foreach loops where possible. llvm-svn: 240694
2015-06-26 04:51:38 +08:00
for (const Value *Op : C->operands())
Record.push_back(VE.getValueID(Op));
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
AbbrevToUse = AggregateAbbrev;
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
} else if (const ConstantExpr *CE = dyn_cast<ConstantExpr>(C)) {
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
switch (CE->getOpcode()) {
default:
if (Instruction::isCast(CE->getOpcode())) {
Code = bitc::CST_CODE_CE_CAST;
Record.push_back(GetEncodedCastOpcode(CE->getOpcode()));
Record.push_back(VE.getTypeID(C->getOperand(0)->getType()));
Record.push_back(VE.getValueID(C->getOperand(0)));
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
AbbrevToUse = CONSTANTS_CE_CAST_Abbrev;
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
} else {
assert(CE->getNumOperands() == 2 && "Unknown constant expr!");
Code = bitc::CST_CODE_CE_BINOP;
Record.push_back(GetEncodedBinaryOpcode(CE->getOpcode()));
Record.push_back(VE.getValueID(C->getOperand(0)));
Record.push_back(VE.getValueID(C->getOperand(1)));
Assembly and Bitcode support for unsigned/signed overflow flags and exact sdiv flags. llvm-svn: 76475
2009-07-21 05:19:07 +08:00
uint64_t Flags = GetOptimizationFlags(CE);
if (Flags != 0)
Record.push_back(Flags);
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
}
break;
[opaque pointer type] Bitcode support for explicit type parameter on the gep operator This happened to be fairly easy to support backwards compatibility based on the number of operands (old format had an even number, new format has one more operand so an odd number). test/Bitcode/old-aliases.ll already appears to test old gep operators (if I remove the backwards compatibility in the BitcodeReader, this and another test fail) so I'm not adding extra test coverage here. llvm-svn: 232216
2015-03-14 05:03:36 +08:00
case Instruction::GetElementPtr: {
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
Code = bitc::CST_CODE_CE_GEP;
[opaque pointer type] Bitcode support for explicit type parameter on the gep operator This happened to be fairly easy to support backwards compatibility based on the number of operands (old format had an even number, new format has one more operand so an odd number). test/Bitcode/old-aliases.ll already appears to test old gep operators (if I remove the backwards compatibility in the BitcodeReader, this and another test fail) so I'm not adding extra test coverage here. llvm-svn: 232216
2015-03-14 05:03:36 +08:00
const auto *GO = cast<GEPOperator>(C);
if (GO->isInBounds())
Add a new keyword 'inbounds' for use with getelementptr. See the LangRef.html changes for details. llvm-svn: 77259
2009-07-28 05:53:46 +08:00
Code = bitc::CST_CODE_CE_INBOUNDS_GEP;
[opaque pointer type] Bitcode support for explicit type parameter on the gep operator This happened to be fairly easy to support backwards compatibility based on the number of operands (old format had an even number, new format has one more operand so an odd number). test/Bitcode/old-aliases.ll already appears to test old gep operators (if I remove the backwards compatibility in the BitcodeReader, this and another test fail) so I'm not adding extra test coverage here. llvm-svn: 232216
2015-03-14 05:03:36 +08:00
Record.push_back(VE.getTypeID(GO->getSourceElementType()));
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
for (unsigned i = 0, e = CE->getNumOperands(); i != e; ++i) {
Record.push_back(VE.getTypeID(C->getOperand(i)->getType()));
Record.push_back(VE.getValueID(C->getOperand(i)));
}
break;
[opaque pointer type] Bitcode support for explicit type parameter on the gep operator This happened to be fairly easy to support backwards compatibility based on the number of operands (old format had an even number, new format has one more operand so an odd number). test/Bitcode/old-aliases.ll already appears to test old gep operators (if I remove the backwards compatibility in the BitcodeReader, this and another test fail) so I'm not adding extra test coverage here. llvm-svn: 232216
2015-03-14 05:03:36 +08:00
}
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
case Instruction::Select:
Code = bitc::CST_CODE_CE_SELECT;
Record.push_back(VE.getValueID(C->getOperand(0)));
Record.push_back(VE.getValueID(C->getOperand(1)));
Record.push_back(VE.getValueID(C->getOperand(2)));
break;
case Instruction::ExtractElement:
Code = bitc::CST_CODE_CE_EXTRACTELT;
Record.push_back(VE.getTypeID(C->getOperand(0)->getType()));
Record.push_back(VE.getValueID(C->getOperand(0)));
[IR] Make {extract,insert}element accept an index of any integer type. Given the following C code llvm currently generates suboptimal code for x86-64: __m128 bss4( const __m128 *ptr, size_t i, size_t j ) { float f = ptr[i][j]; return (__m128) { f, f, f, f }; } ================================================= define <4 x float> @_Z4bss4PKDv4_fmm(<4 x float>* nocapture readonly %ptr, i64 %i, i64 %j) #0 { %a1 = getelementptr inbounds <4 x float>* %ptr, i64 %i %a2 = load <4 x float>* %a1, align 16, !tbaa !1 %a3 = trunc i64 %j to i32 %a4 = extractelement <4 x float> %a2, i32 %a3 %a5 = insertelement <4 x float> undef, float %a4, i32 0 %a6 = insertelement <4 x float> %a5, float %a4, i32 1 %a7 = insertelement <4 x float> %a6, float %a4, i32 2 %a8 = insertelement <4 x float> %a7, float %a4, i32 3 ret <4 x float> %a8 } ================================================= shlq $4, %rsi addq %rdi, %rsi movslq %edx, %rax vbroadcastss (%rsi,%rax,4), %xmm0 retq ================================================= The movslq is uneeded, but is present because of the trunc to i32 and then sext back to i64 that the backend adds for vbroadcastss. We can't remove it because it changes the meaning. The IR that clang generates is already suboptimal. What clang really should emit is: %a4 = extractelement <4 x float> %a2, i64 %j This patch makes that legal. A separate patch will teach clang to do it. Differential Revision: http://reviews.llvm.org/D3519 llvm-svn: 207801
2014-05-02 06:12:39 +08:00
Record.push_back(VE.getTypeID(C->getOperand(1)->getType()));
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
Record.push_back(VE.getValueID(C->getOperand(1)));
break;
case Instruction::InsertElement:
Code = bitc::CST_CODE_CE_INSERTELT;
Record.push_back(VE.getValueID(C->getOperand(0)));
Record.push_back(VE.getValueID(C->getOperand(1)));
[IR] Make {extract,insert}element accept an index of any integer type. Given the following C code llvm currently generates suboptimal code for x86-64: __m128 bss4( const __m128 *ptr, size_t i, size_t j ) { float f = ptr[i][j]; return (__m128) { f, f, f, f }; } ================================================= define <4 x float> @_Z4bss4PKDv4_fmm(<4 x float>* nocapture readonly %ptr, i64 %i, i64 %j) #0 { %a1 = getelementptr inbounds <4 x float>* %ptr, i64 %i %a2 = load <4 x float>* %a1, align 16, !tbaa !1 %a3 = trunc i64 %j to i32 %a4 = extractelement <4 x float> %a2, i32 %a3 %a5 = insertelement <4 x float> undef, float %a4, i32 0 %a6 = insertelement <4 x float> %a5, float %a4, i32 1 %a7 = insertelement <4 x float> %a6, float %a4, i32 2 %a8 = insertelement <4 x float> %a7, float %a4, i32 3 ret <4 x float> %a8 } ================================================= shlq $4, %rsi addq %rdi, %rsi movslq %edx, %rax vbroadcastss (%rsi,%rax,4), %xmm0 retq ================================================= The movslq is uneeded, but is present because of the trunc to i32 and then sext back to i64 that the backend adds for vbroadcastss. We can't remove it because it changes the meaning. The IR that clang generates is already suboptimal. What clang really should emit is: %a4 = extractelement <4 x float> %a2, i64 %j This patch makes that legal. A separate patch will teach clang to do it. Differential Revision: http://reviews.llvm.org/D3519 llvm-svn: 207801
2014-05-02 06:12:39 +08:00
Record.push_back(VE.getTypeID(C->getOperand(2)->getType()));
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
Record.push_back(VE.getValueID(C->getOperand(2)));
break;
case Instruction::ShuffleVector:
Add suppport for ConstantExprs of shufflevectors whose result type is not equal to the type of the vectors being shuffled. llvm-svn: 64401
2009-02-13 05:28:33 +08:00
// If the return type and argument types are the same, this is a
// standard shufflevector instruction. If the types are different,
// then the shuffle is widening or truncating the input vectors, and
// the argument type must also be encoded.
if (C->getType() == C->getOperand(0)->getType()) {
Code = bitc::CST_CODE_CE_SHUFFLEVEC;
} else {
Code = bitc::CST_CODE_CE_SHUFVEC_EX;
Record.push_back(VE.getTypeID(C->getOperand(0)->getType()));
}
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
Record.push_back(VE.getValueID(C->getOperand(0)));
Record.push_back(VE.getValueID(C->getOperand(1)));
Record.push_back(VE.getValueID(C->getOperand(2)));
break;
case Instruction::ICmp:
case Instruction::FCmp:
Remove the vicmp and vfcmp instructions. Because we never had a release with these instructions, no autoupgrade or backwards compatibility support is provided. llvm-svn: 74991
2009-07-08 11:04:38 +08:00
Code = bitc::CST_CODE_CE_CMP;
implement reading and writing of constant exprs. llvm-svn: 36394
2007-04-24 15:07:11 +08:00
Record.push_back(VE.getTypeID(C->getOperand(0)->getType()));
Record.push_back(VE.getValueID(C->getOperand(0)));
Record.push_back(VE.getValueID(C->getOperand(1)));
Record.push_back(CE->getPredicate());
break;
}
bitcode writer support for blockaddress. llvm-svn: 85376
2009-10-28 13:24:40 +08:00
} else if (const BlockAddress *BA = dyn_cast<BlockAddress>(C)) {
Code = bitc::CST_CODE_BLOCKADDRESS;
Record.push_back(VE.getTypeID(BA->getFunction()->getType()));
Record.push_back(VE.getValueID(BA->getFunction()));
Record.push_back(VE.getGlobalBasicBlockID(BA->getBasicBlock()));
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
} else {
Add some debug output to help diagnose PR7689. llvm-svn: 109036
2010-07-22 05:18:37 +08:00
#ifndef NDEBUG
C->dump();
#endif
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unknown constant!");
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
}
Stream.EmitRecord(Code, Record, AbbrevToUse);
Record.clear();
}
Stream.ExitBlock();
}
static void WriteModuleConstants(const ValueEnumerator &VE,
BitstreamWriter &Stream) {
const ValueEnumerator::ValueList &Vals = VE.getValues();
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
// Find the first constant to emit, which is the first non-globalvalue value.
// We know globalvalues have been emitted by WriteModuleInfo.
for (unsigned i = 0, e = Vals.size(); i != e; ++i) {
if (!isa<GlobalValue>(Vals[i].first)) {
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
WriteConstants(i, Vals.size(), VE, Stream, true);
Emit module-level constants. llvm-svn: 36384
2007-04-24 08:16:04 +08:00
return;
}
}
}
write out the symtab for globals. llvm-svn: 36374
2007-04-24 04:35:01 +08:00
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
/// PushValueAndType - The file has to encode both the value and type id for
/// many values, because we need to know what type to create for forward
/// references. However, most operands are not forward references, so this type
/// field is not needed.
///
/// This function adds V's value ID to Vals. If the value ID is higher than the
/// instruction ID, then it is a forward reference, and it also includes the
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
/// type ID. The value ID that is written is encoded relative to the InstID.
use specialized accessor instead of plain getOperand(0) llvm-svn: 62330
2009-01-17 02:40:27 +08:00
static bool PushValueAndType(const Value *V, unsigned InstID,
Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector size. llvm-svn: 186098
2013-07-12 00:22:38 +08:00
SmallVectorImpl<unsigned> &Vals,
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
ValueEnumerator &VE) {
unsigned ValID = VE.getValueID(V);
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
// Make encoding relative to the InstID.
Vals.push_back(InstID - ValID);
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
if (ValID >= InstID) {
Vals.push_back(VE.getTypeID(V->getType()));
return true;
}
return false;
}
[Bitcode][Asm] Teach LLVM to read and write operand bundles. Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
2015-09-25 07:34:52 +08:00
static void WriteOperandBundles(BitstreamWriter &Stream, ImmutableCallSite CS,
unsigned InstID, ValueEnumerator &VE) {
SmallVector<unsigned, 64> Record;
LLVMContext &C = CS.getInstruction()->getContext();
for (unsigned i = 0, e = CS.getNumOperandBundles(); i != e; ++i) {
[OperandBundles] Rename accessor, NFC Rename getOperandBundle to getOperandBundleAt since that's more obvious. llvm-svn: 252388
2015-11-07 09:56:04 +08:00
const auto &Bundle = CS.getOperandBundleAt(i);
[OperandBundles] Identify operand bundles with both their names and IDs No code uses this functionality yet. This change just exposes information / structure that was already present. llvm-svn: 252644
2015-11-11 04:13:15 +08:00
Record.push_back(C.getOperandBundleTagID(Bundle.getTagName()));
[Bitcode][Asm] Teach LLVM to read and write operand bundles. Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
2015-09-25 07:34:52 +08:00
for (auto &Input : Bundle.Inputs)
PushValueAndType(Input, InstID, Record, VE);
Stream.EmitRecord(bitc::FUNC_CODE_OPERAND_BUNDLE, Record);
Record.clear();
}
}
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
/// pushValue - Like PushValueAndType, but where the type of the value is
/// omitted (perhaps it was already encoded in an earlier operand).
static void pushValue(const Value *V, unsigned InstID,
Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector size. llvm-svn: 186098
2013-07-12 00:22:38 +08:00
SmallVectorImpl<unsigned> &Vals,
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
ValueEnumerator &VE) {
unsigned ValID = VE.getValueID(V);
Vals.push_back(InstID - ValID);
}
static void pushValueSigned(const Value *V, unsigned InstID,
Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector size. llvm-svn: 186098
2013-07-12 00:22:38 +08:00
SmallVectorImpl<uint64_t> &Vals,
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
ValueEnumerator &VE) {
unsigned ValID = VE.getValueID(V);
int64_t diff = ((int32_t)InstID - (int32_t)ValID);
emitSignedInt64(Vals, diff);
}
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
/// WriteInstruction - Emit an instruction to the specified stream.
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
static void WriteInstruction(const Instruction &I, unsigned InstID,
ValueEnumerator &VE, BitstreamWriter &Stream,
Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector size. llvm-svn: 186098
2013-07-12 00:22:38 +08:00
SmallVectorImpl<unsigned> &Vals) {
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
unsigned Code = 0;
unsigned AbbrevToUse = 0;
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
VE.setInstructionID(&I);
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
switch (I.getOpcode()) {
default:
if (Instruction::isCast(I.getOpcode())) {
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Code = bitc::FUNC_CODE_INST_CAST;
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
if (!PushValueAndType(I.getOperand(0), InstID, Vals, VE))
AbbrevToUse = FUNCTION_INST_CAST_ABBREV;
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
Vals.push_back(VE.getTypeID(I.getType()));
further reduce the redundancy of types in the instruction encoding. This shrinks function bodies in kc++ from 891913B to 884073B llvm-svn: 36817
2007-05-06 08:21:25 +08:00
Vals.push_back(GetEncodedCastOpcode(I.getOpcode()));
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
} else {
assert(isa<BinaryOperator>(I) && "Unknown instruction!");
use the correct code for binop instrs llvm-svn: 36639
2007-05-02 12:26:36 +08:00
Code = bitc::FUNC_CODE_INST_BINOP;
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
if (!PushValueAndType(I.getOperand(0), InstID, Vals, VE))
AbbrevToUse = FUNCTION_INST_BINOP_ABBREV;
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(1), InstID, Vals, VE);
further reduce the redundancy of types in the instruction encoding. This shrinks function bodies in kc++ from 891913B to 884073B llvm-svn: 36817
2007-05-06 08:21:25 +08:00
Vals.push_back(GetEncodedBinaryOpcode(I.getOpcode()));
Assembly and Bitcode support for unsigned/signed overflow flags and exact sdiv flags. llvm-svn: 76475
2009-07-21 05:19:07 +08:00
uint64_t Flags = GetOptimizationFlags(&I);
if (Flags != 0) {
if (AbbrevToUse == FUNCTION_INST_BINOP_ABBREV)
AbbrevToUse = FUNCTION_INST_BINOP_FLAGS_ABBREV;
Vals.push_back(Flags);
}
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
}
break;
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
[opaque pointer type] Bitcode support for explicit type parameter on GEP. Like r230414, add bitcode support including backwards compatibility, for an explicit type parameter to GEP. At the suggestion of Duncan I tried coalescing the two older bitcodes into a single new bitcode, though I did hit a wrinkle: I couldn't figure out how to create an explicit abbreviation for a record with a variable number of arguments (the indicies to the gep). This means the discriminator between inbounds and non-inbounds gep is a full variable-length field I believe? Is my understanding correct? Is there a way to create such an abbreviation? Should I just use two bitcodes as before? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7736 llvm-svn: 230415
2015-02-25 09:08:52 +08:00
case Instruction::GetElementPtr: {
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Code = bitc::FUNC_CODE_INST_GEP;
[opaque pointer type] Bitcode support for explicit type parameter on GEP. Like r230414, add bitcode support including backwards compatibility, for an explicit type parameter to GEP. At the suggestion of Duncan I tried coalescing the two older bitcodes into a single new bitcode, though I did hit a wrinkle: I couldn't figure out how to create an explicit abbreviation for a record with a variable number of arguments (the indicies to the gep). This means the discriminator between inbounds and non-inbounds gep is a full variable-length field I believe? Is my understanding correct? Is there a way to create such an abbreviation? Should I just use two bitcodes as before? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7736 llvm-svn: 230415
2015-02-25 09:08:52 +08:00
AbbrevToUse = FUNCTION_INST_GEP_ABBREV;
auto &GEPInst = cast<GetElementPtrInst>(I);
Vals.push_back(GEPInst.isInBounds());
Vals.push_back(VE.getTypeID(GEPInst.getSourceElementType()));
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
for (unsigned i = 0, e = I.getNumOperands(); i != e; ++i)
PushValueAndType(I.getOperand(i), InstID, Vals, VE);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
[opaque pointer type] Bitcode support for explicit type parameter on GEP. Like r230414, add bitcode support including backwards compatibility, for an explicit type parameter to GEP. At the suggestion of Duncan I tried coalescing the two older bitcodes into a single new bitcode, though I did hit a wrinkle: I couldn't figure out how to create an explicit abbreviation for a record with a variable number of arguments (the indicies to the gep). This means the discriminator between inbounds and non-inbounds gep is a full variable-length field I believe? Is my understanding correct? Is there a way to create such an abbreviation? Should I just use two bitcodes as before? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7736 llvm-svn: 230415
2015-02-25 09:08:52 +08:00
}
Improved bitcode support for insertvalue/extractvalue. llvm-svn: 51822
2008-06-01 03:11:15 +08:00
case Instruction::ExtractValue: {
Make structs and arrays first-class types, and add assembly and bitcode support for the extractvalue and insertvalue instructions and constant expressions. Note that this does not yet include CodeGen support. llvm-svn: 51468
2008-05-23 09:55:30 +08:00
Code = bitc::FUNC_CODE_INST_EXTRACTVAL;
Improved bitcode support for insertvalue/extractvalue. llvm-svn: 51822
2008-06-01 03:11:15 +08:00
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
const ExtractValueInst *EVI = cast<ExtractValueInst>(&I);
Prefer SmallVector::append/insert over push_back loops. Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
2015-02-17 23:29:18 +08:00
Vals.append(EVI->idx_begin(), EVI->idx_end());
Make structs and arrays first-class types, and add assembly and bitcode support for the extractvalue and insertvalue instructions and constant expressions. Note that this does not yet include CodeGen support. llvm-svn: 51468
2008-05-23 09:55:30 +08:00
break;
Improved bitcode support for insertvalue/extractvalue. llvm-svn: 51822
2008-06-01 03:11:15 +08:00
}
case Instruction::InsertValue: {
Make structs and arrays first-class types, and add assembly and bitcode support for the extractvalue and insertvalue instructions and constant expressions. Note that this does not yet include CodeGen support. llvm-svn: 51468
2008-05-23 09:55:30 +08:00
Code = bitc::FUNC_CODE_INST_INSERTVAL;
Improved bitcode support for insertvalue/extractvalue. llvm-svn: 51822
2008-06-01 03:11:15 +08:00
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
PushValueAndType(I.getOperand(1), InstID, Vals, VE);
const InsertValueInst *IVI = cast<InsertValueInst>(&I);
Prefer SmallVector::append/insert over push_back loops. Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
2015-02-17 23:29:18 +08:00
Vals.append(IVI->idx_begin(), IVI->idx_end());
Make structs and arrays first-class types, and add assembly and bitcode support for the extractvalue and insertvalue instructions and constant expressions. Note that this does not yet include CodeGen support. llvm-svn: 51468
2008-05-23 09:55:30 +08:00
break;
Improved bitcode support for insertvalue/extractvalue. llvm-svn: 51822
2008-06-01 03:11:15 +08:00
}
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
case Instruction::Select:
Re-enables the new vector select in the bitcode reader, by modifying the bitcode reader/writer as follows: - add and use new bitcode FUNC_CODE_INST_VSELECT to handle the llvm select opcode using either i1 or [N x i1] as the selector. - retain old BITCODE FUNC_CODE_INST_SELECT in the bitcode reader to handle select on i1 for backwards compatibility with existing bitcode files. - re-enable the vector-select.ll test program. Also, rename the recently added bitcode opcode FUNC_CODE_INST_VCMP to FUNC_CODE_INST_CMP2 and make the bitcode writer use it to handle fcmp/icmp on scalars or vectors. In the bitcode writer, use FUNC_CODE_INST_CMP for vfcmp/vicmp only. In the bitcode reader, have FUNC_CODE_INST_CMP handle icmp/fcmp returning bool, for backwards compatibility with existing bitcode files. Patch by Preston Gurd! llvm-svn: 56233
2008-09-16 09:01:33 +08:00
Code = bitc::FUNC_CODE_INST_VSELECT;
further reduce the redundancy of types in the instruction encoding. This shrinks function bodies in kc++ from 891913B to 884073B llvm-svn: 36817
2007-05-06 08:21:25 +08:00
PushValueAndType(I.getOperand(1), InstID, Vals, VE);
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(2), InstID, Vals, VE);
Re-enables the new vector select in the bitcode reader, by modifying the bitcode reader/writer as follows: - add and use new bitcode FUNC_CODE_INST_VSELECT to handle the llvm select opcode using either i1 or [N x i1] as the selector. - retain old BITCODE FUNC_CODE_INST_SELECT in the bitcode reader to handle select on i1 for backwards compatibility with existing bitcode files. - re-enable the vector-select.ll test program. Also, rename the recently added bitcode opcode FUNC_CODE_INST_VCMP to FUNC_CODE_INST_CMP2 and make the bitcode writer use it to handle fcmp/icmp on scalars or vectors. In the bitcode writer, use FUNC_CODE_INST_CMP for vfcmp/vicmp only. In the bitcode reader, have FUNC_CODE_INST_CMP handle icmp/fcmp returning bool, for backwards compatibility with existing bitcode files. Patch by Preston Gurd! llvm-svn: 56233
2008-09-16 09:01:33 +08:00
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
case Instruction::ExtractElement:
Code = bitc::FUNC_CODE_INST_EXTRACTELT;
further reduce the redundancy of types in the instruction encoding. This shrinks function bodies in kc++ from 891913B to 884073B llvm-svn: 36817
2007-05-06 08:21:25 +08:00
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
[IR] Make {extract,insert}element accept an index of any integer type. Given the following C code llvm currently generates suboptimal code for x86-64: __m128 bss4( const __m128 *ptr, size_t i, size_t j ) { float f = ptr[i][j]; return (__m128) { f, f, f, f }; } ================================================= define <4 x float> @_Z4bss4PKDv4_fmm(<4 x float>* nocapture readonly %ptr, i64 %i, i64 %j) #0 { %a1 = getelementptr inbounds <4 x float>* %ptr, i64 %i %a2 = load <4 x float>* %a1, align 16, !tbaa !1 %a3 = trunc i64 %j to i32 %a4 = extractelement <4 x float> %a2, i32 %a3 %a5 = insertelement <4 x float> undef, float %a4, i32 0 %a6 = insertelement <4 x float> %a5, float %a4, i32 1 %a7 = insertelement <4 x float> %a6, float %a4, i32 2 %a8 = insertelement <4 x float> %a7, float %a4, i32 3 ret <4 x float> %a8 } ================================================= shlq $4, %rsi addq %rdi, %rsi movslq %edx, %rax vbroadcastss (%rsi,%rax,4), %xmm0 retq ================================================= The movslq is uneeded, but is present because of the trunc to i32 and then sext back to i64 that the backend adds for vbroadcastss. We can't remove it because it changes the meaning. The IR that clang generates is already suboptimal. What clang really should emit is: %a4 = extractelement <4 x float> %a2, i64 %j This patch makes that legal. A separate patch will teach clang to do it. Differential Revision: http://reviews.llvm.org/D3519 llvm-svn: 207801
2014-05-02 06:12:39 +08:00
PushValueAndType(I.getOperand(1), InstID, Vals, VE);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
case Instruction::InsertElement:
Code = bitc::FUNC_CODE_INST_INSERTELT;
further reduce the redundancy of types in the instruction encoding. This shrinks function bodies in kc++ from 891913B to 884073B llvm-svn: 36817
2007-05-06 08:21:25 +08:00
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(1), InstID, Vals, VE);
[IR] Make {extract,insert}element accept an index of any integer type. Given the following C code llvm currently generates suboptimal code for x86-64: __m128 bss4( const __m128 *ptr, size_t i, size_t j ) { float f = ptr[i][j]; return (__m128) { f, f, f, f }; } ================================================= define <4 x float> @_Z4bss4PKDv4_fmm(<4 x float>* nocapture readonly %ptr, i64 %i, i64 %j) #0 { %a1 = getelementptr inbounds <4 x float>* %ptr, i64 %i %a2 = load <4 x float>* %a1, align 16, !tbaa !1 %a3 = trunc i64 %j to i32 %a4 = extractelement <4 x float> %a2, i32 %a3 %a5 = insertelement <4 x float> undef, float %a4, i32 0 %a6 = insertelement <4 x float> %a5, float %a4, i32 1 %a7 = insertelement <4 x float> %a6, float %a4, i32 2 %a8 = insertelement <4 x float> %a7, float %a4, i32 3 ret <4 x float> %a8 } ================================================= shlq $4, %rsi addq %rdi, %rsi movslq %edx, %rax vbroadcastss (%rsi,%rax,4), %xmm0 retq ================================================= The movslq is uneeded, but is present because of the trunc to i32 and then sext back to i64 that the backend adds for vbroadcastss. We can't remove it because it changes the meaning. The IR that clang generates is already suboptimal. What clang really should emit is: %a4 = extractelement <4 x float> %a2, i64 %j This patch makes that legal. A separate patch will teach clang to do it. Differential Revision: http://reviews.llvm.org/D3519 llvm-svn: 207801
2014-05-02 06:12:39 +08:00
PushValueAndType(I.getOperand(2), InstID, Vals, VE);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
case Instruction::ShuffleVector:
Code = bitc::FUNC_CODE_INST_SHUFFLEVEC;
further reduce the redundancy of types in the instruction encoding. This shrinks function bodies in kc++ from 891913B to 884073B llvm-svn: 36817
2007-05-06 08:21:25 +08:00
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(1), InstID, Vals, VE);
pushValue(I.getOperand(2), InstID, Vals, VE);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
case Instruction::ICmp:
Add support for fast-math flags to the FCmp instruction. FCmp behaves a lot like a floating-point binary operator in many ways, and can benefit from fast-math information. Flags such as nsz and nnan can affect if this fcmp (in combination with a select) can be treated as a fminnum/fmaxnum operation. This adds backwards-compatible bitcode support, IR parsing and writing, LangRef changes and IRBuilder changes. I'll need to audit InstSimplify and InstCombine in a followup to find places where flags should be copied. llvm-svn: 241901
2015-07-10 20:52:00 +08:00
case Instruction::FCmp: {
Remove the vicmp and vfcmp instructions. Because we never had a release with these instructions, no autoupgrade or backwards compatibility support is provided. llvm-svn: 74991
2009-07-08 11:04:38 +08:00
// compare returning Int1Ty or vector of Int1Ty
Code = bitc::FUNC_CODE_INST_CMP2;
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(1), InstID, Vals, VE);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Vals.push_back(cast<CmpInst>(I).getPredicate());
Add support for fast-math flags to the FCmp instruction. FCmp behaves a lot like a floating-point binary operator in many ways, and can benefit from fast-math information. Flags such as nsz and nnan can affect if this fcmp (in combination with a select) can be treated as a fminnum/fmaxnum operation. This adds backwards-compatible bitcode support, IR parsing and writing, LangRef changes and IRBuilder changes. I'll need to audit InstSimplify and InstCombine in a followup to find places where flags should be copied. llvm-svn: 241901
2015-07-10 20:52:00 +08:00
uint64_t Flags = GetOptimizationFlags(&I);
if (Flags != 0)
Vals.push_back(Flags);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
Add support for fast-math flags to the FCmp instruction. FCmp behaves a lot like a floating-point binary operator in many ways, and can benefit from fast-math information. Flags such as nsz and nnan can affect if this fcmp (in combination with a select) can be treated as a fminnum/fmaxnum operation. This adds backwards-compatible bitcode support, IR parsing and writing, LangRef changes and IRBuilder changes. I'll need to audit InstSimplify and InstCombine in a followup to find places where flags should be copied. llvm-svn: 241901
2015-07-10 20:52:00 +08:00
}
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
case Instruction::Ret:
Update bitcode reader and writer to handle multiple return values. Take 2. llvm-svn: 47583
2008-02-26 09:29:32 +08:00
{
Code = bitc::FUNC_CODE_INST_RET;
unsigned NumOperands = I.getNumOperands();
if (NumOperands == 0)
AbbrevToUse = FUNCTION_INST_RET_VOID_ABBREV;
else if (NumOperands == 1) {
if (!PushValueAndType(I.getOperand(0), InstID, Vals, VE))
AbbrevToUse = FUNCTION_INST_RET_VAL_ABBREV;
} else {
for (unsigned i = 0, e = NumOperands; i != e; ++i)
PushValueAndType(I.getOperand(i), InstID, Vals, VE);
}
}
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
case Instruction::Br:
use precise getters llvm-svn: 63403
2009-01-31 02:27:21 +08:00
{
Code = bitc::FUNC_CODE_INST_BR;
Fix unnecessary removal of const through cast machinery I have some uncommitted changes to the cast code that catch this sort of thing at compile-time but I still need to do some other cleanup before I can enable it. llvm-svn: 174853
2013-02-11 09:16:51 +08:00
const BranchInst &II = cast<BranchInst>(I);
use precise getters llvm-svn: 63403
2009-01-31 02:27:21 +08:00
Vals.push_back(VE.getValueID(II.getSuccessor(0)));
if (II.isConditional()) {
Vals.push_back(VE.getValueID(II.getSuccessor(1)));
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(II.getCondition(), InstID, Vals, VE);
use precise getters llvm-svn: 63403
2009-01-31 02:27:21 +08:00
}
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
}
break;
case Instruction::Switch:
SwitchInst refactoring. The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want. What was done: 1. Changed semantics of index inside the getCaseValue method: getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous. 2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned. 3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment. 4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst. 4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor. 4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor. Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang. llvm-svn: 149481
2012-02-01 15:49:51 +08:00
{
Code = bitc::FUNC_CODE_INST_SWITCH;
Fix unnecessary removal of const through cast machinery I have some uncommitted changes to the cast code that catch this sort of thing at compile-time but I still need to do some other cleanup before I can enable it. llvm-svn: 174853
2013-02-11 09:16:51 +08:00
const SwitchInst &SI = cast<SwitchInst>(I);
Revert patches to add case-range support for PR1255. The work on this project was left in an unfinished and inconsistent state. Hopefully someone will eventually get a chance to implement this feature, but in the meantime, it is better to put things back the way the were. I have left support in the bitcode reader to handle the case-range bitcode format, so that we do not lose bitcode compatibility with the llvm 3.3 release. This reverts the following commits: 155464, 156374, 156377, 156613, 156704, 156757, 156804 156808, 156985, 157046, 157112, 157183, 157315, 157384, 157575, 157576, 157586, 157612, 157810, 157814, 157815, 157880, 157881, 157882, 157884, 157887, 157901, 158979, 157987, 157989, 158986, 158997, 159076, 159101, 159100, 159200, 159201, 159207, 159527, 159532, 159540, 159583, 159618, 159658, 159659, 159660, 159661, 159703, 159704, 160076, 167356, 172025, 186736 llvm-svn: 190328
2013-09-10 03:14:35 +08:00
Vals.push_back(VE.getTypeID(SI.getCondition()->getType()));
pushValue(SI.getCondition(), InstID, Vals, VE);
Vals.push_back(VE.getValueID(SI.getDefaultDest()));
use range-based for loop; NFCI llvm-svn: 253048
2015-11-14 00:21:23 +08:00
for (SwitchInst::ConstCaseIt Case : SI.cases()) {
Vals.push_back(VE.getValueID(Case.getCaseValue()));
Vals.push_back(VE.getValueID(Case.getCaseSuccessor()));
SwitchInst refactoring. The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want. What was done: 1. Changed semantics of index inside the getCaseValue method: getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous. 2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned. 3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment. 4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst. 4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor. 4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor. Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang. llvm-svn: 149481
2012-02-01 15:49:51 +08:00
}
}
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
rename indbr -> indirectbr to appease the residents of #llvm. llvm-svn: 85351
2009-10-28 08:19:10 +08:00
case Instruction::IndirectBr:
Code = bitc::FUNC_CODE_INST_INDIRECTBR;
add enough support for indirect branch for the feature test to pass (assembler,asmprinter, bc reader+writer) and document it. Codegen currently aborts on it. llvm-svn: 85274
2009-10-28 03:13:16 +08:00
Vals.push_back(VE.getTypeID(I.getOperand(0)->getType()));
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
// Encode the address operand as relative, but not the basic blocks.
pushValue(I.getOperand(0), InstID, Vals, VE);
for (unsigned i = 1, e = I.getNumOperands(); i != e; ++i)
add enough support for indirect branch for the feature test to pass (assembler,asmprinter, bc reader+writer) and document it. Codegen currently aborts on it. llvm-svn: 85274
2009-10-28 03:13:16 +08:00
Vals.push_back(VE.getValueID(I.getOperand(i)));
break;
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
fix build with non-buggy compilers llvm-svn: 36621
2007-05-01 15:03:37 +08:00
case Instruction::Invoke: {
use specialized accessor instead of plain getOperand(0) llvm-svn: 62330
2009-01-17 02:40:27 +08:00
const InvokeInst *II = cast<InvokeInst>(&I);
[opaque pointer type] bitcode: add explicit callee type to invoke instructions llvm-svn: 235735
2015-04-25 02:06:06 +08:00
const Value *Callee = II->getCalledValue();
FunctionType *FTy = II->getFunctionType();
[Bitcode][Asm] Teach LLVM to read and write operand bundles. Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
2015-09-25 07:34:52 +08:00
if (II->hasOperandBundles())
WriteOperandBundles(Stream, II, InstID, VE);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Code = bitc::FUNC_CODE_INST_INVOKE;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Large mechanical patch. s/ParamAttr/Attribute/g s/PAList/AttrList/g s/FnAttributeWithIndex/AttributeWithIndex/g s/FnAttr/Attribute/g This sets the stage - to implement function notes as function attributes and - to distinguish between function attributes and return value attributes. This requires corresponding changes in llvm-gcc and clang. llvm-svn: 56622
2008-09-26 05:00:45 +08:00
Vals.push_back(VE.getAttributeID(II->getAttributes()));
[opaque pointer type] bitcode: add explicit callee type to invoke instructions llvm-svn: 235735
2015-04-25 02:06:06 +08:00
Vals.push_back(II->getCallingConv() | 1 << 13);
use the obvious getters llvm-svn: 61893
2009-01-08 06:39:29 +08:00
Vals.push_back(VE.getValueID(II->getNormalDest()));
Vals.push_back(VE.getValueID(II->getUnwindDest()));
[opaque pointer type] bitcode: add explicit callee type to invoke instructions llvm-svn: 235735
2015-04-25 02:06:06 +08:00
Vals.push_back(VE.getTypeID(FTy));
use specialized accessor instead of plain getOperand(0) llvm-svn: 62330
2009-01-17 02:40:27 +08:00
PushValueAndType(Callee, InstID, Vals, VE);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
// Emit value #'s for the fixed parameters.
for (unsigned i = 0, e = FTy->getNumParams(); i != e; ++i)
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(i), InstID, Vals, VE); // fixed param.
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
// Emit type/value pairs for varargs params.
if (FTy->isVarArg()) {
Finally land the InvokeInst operand reordering. I have audited all getOperandNo calls now, fixing hidden assumptions. CallSite related uglyness will be eliminated successively. Note this patch has a long and griveous history, for all the back-and-forths have a look at CallSite.h's log. llvm-svn: 99399
2010-03-24 21:21:49 +08:00
for (unsigned i = FTy->getNumParams(), e = I.getNumOperands()-3;
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
i != e; ++i)
PushValueAndType(I.getOperand(i), InstID, Vals, VE); // vararg
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
}
break;
fix build with non-buggy compilers llvm-svn: 36621
2007-05-01 15:03:37 +08:00
}
Add the 'resume' instruction for the new EH rewrite. This adds the 'resume' instruction class, IR parsing, and bitcode reading and writing. The 'resume' instruction resumes propagation of an existing (in-flight) exception whose unwinding was interrupted with a 'landingpad' instruction (to be added later). llvm-svn: 136589
2011-07-31 14:30:59 +08:00
case Instruction::Resume:
Code = bitc::FUNC_CODE_INST_RESUME;
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
break;
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
case Instruction::CleanupRet: {
Code = bitc::FUNC_CODE_INST_CLEANUPRET;
const auto &CRI = cast<CleanupReturnInst>(I);
[WinEH] Require token linkage in EH pad/ret signatures Summary: WinEHPrepare is going to require that cleanuppad and catchpad produce values of token type which are consumed by any cleanupret or catchret exiting the pad. This change updates the signatures of those operators to require/enforce that the type produced by the pads is token type and that the rets have an appropriate argument. The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and similarly for `CleanupReturnInst`/`CleanupPadInst`). To accommodate that restriction, this change adds a notion of an operator constraint to both LLParser and BitcodeReader, allowing appropriate sentinels to be constructed for forward references and appropriate error messages to be emitted for illegal inputs. Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad predecessor must have no other predecessors; this ensures that WinEHPrepare will see the expected linear relationship between sibling catches on the same try. Lastly, remove some superfluous/vestigial casts from instruction operand setters operating on BasicBlocks. Reviewers: rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12108 llvm-svn: 245797
2015-08-23 08:26:33 +08:00
pushValue(CRI.getCleanupPad(), InstID, Vals, VE);
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
if (CRI.hasUnwindDest())
Vals.push_back(VE.getValueID(CRI.getUnwindDest()));
break;
}
case Instruction::CatchRet: {
Code = bitc::FUNC_CODE_INST_CATCHRET;
const auto &CRI = cast<CatchReturnInst>(I);
[WinEH] Require token linkage in EH pad/ret signatures Summary: WinEHPrepare is going to require that cleanuppad and catchpad produce values of token type which are consumed by any cleanupret or catchret exiting the pad. This change updates the signatures of those operators to require/enforce that the type produced by the pads is token type and that the rets have an appropriate argument. The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and similarly for `CleanupReturnInst`/`CleanupPadInst`). To accommodate that restriction, this change adds a notion of an operator constraint to both LLParser and BitcodeReader, allowing appropriate sentinels to be constructed for forward references and appropriate error messages to be emitted for illegal inputs. Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad predecessor must have no other predecessors; this ensures that WinEHPrepare will see the expected linear relationship between sibling catches on the same try. Lastly, remove some superfluous/vestigial casts from instruction operand setters operating on BasicBlocks. Reviewers: rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12108 llvm-svn: 245797
2015-08-23 08:26:33 +08:00
pushValue(CRI.getCatchPad(), InstID, Vals, VE);
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
Vals.push_back(VE.getValueID(CRI.getSuccessor()));
break;
}
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
case Instruction::CleanupPad:
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
case Instruction::CatchPad: {
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
const auto &FuncletPad = cast<FuncletPadInst>(I);
Code = isa<CatchPadInst>(FuncletPad) ? bitc::FUNC_CODE_INST_CATCHPAD
: bitc::FUNC_CODE_INST_CLEANUPPAD;
pushValue(FuncletPad.getParentPad(), InstID, Vals, VE);
unsigned NumArgOperands = FuncletPad.getNumArgOperands();
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
Vals.push_back(NumArgOperands);
for (unsigned Op = 0; Op != NumArgOperands; ++Op)
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
PushValueAndType(FuncletPad.getArgOperand(Op), InstID, Vals, VE);
break;
}
case Instruction::CatchSwitch: {
Code = bitc::FUNC_CODE_INST_CATCHSWITCH;
const auto &CatchSwitch = cast<CatchSwitchInst>(I);
pushValue(CatchSwitch.getParentPad(), InstID, Vals, VE);
unsigned NumHandlers = CatchSwitch.getNumHandlers();
Vals.push_back(NumHandlers);
for (const BasicBlock *CatchPadBB : CatchSwitch.handlers())
Vals.push_back(VE.getValueID(CatchPadBB));
if (CatchSwitch.hasUnwindDest())
Vals.push_back(VE.getValueID(CatchSwitch.getUnwindDest()));
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
break;
}
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
case Instruction::Unreachable:
Code = bitc::FUNC_CODE_INST_UNREACHABLE;
add some abbrevs for ret and unreachable, shrinking kc++ from 2717360->2705388 llvm-svn: 36823
2007-05-06 09:28:01 +08:00
AbbrevToUse = FUNCTION_INST_UNREACHABLE_ABBREV;
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
break;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Make better use of the PHINode API. Change various bits of code to make better use of the existing PHINode API, to insulate them from forthcoming changes in how PHINodes store their operands. llvm-svn: 133434
2011-06-20 22:18:48 +08:00
case Instruction::PHI: {
const PHINode &PN = cast<PHINode>(I);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Code = bitc::FUNC_CODE_INST_PHI;
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
// With the newer instruction encoding, forward references could give
// negative valued IDs. This is most common for PHIs, so we use
// signed VBRs.
SmallVector<uint64_t, 128> Vals64;
Vals64.push_back(VE.getTypeID(PN.getType()));
Make better use of the PHINode API. Change various bits of code to make better use of the existing PHINode API, to insulate them from forthcoming changes in how PHINodes store their operands. llvm-svn: 133434
2011-06-20 22:18:48 +08:00
for (unsigned i = 0, e = PN.getNumIncomingValues(); i != e; ++i) {
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValueSigned(PN.getIncomingValue(i), InstID, Vals64, VE);
Vals64.push_back(VE.getValueID(PN.getIncomingBlock(i)));
Make better use of the PHINode API. Change various bits of code to make better use of the existing PHINode API, to insulate them from forthcoming changes in how PHINodes store their operands. llvm-svn: 133434
2011-06-20 22:18:48 +08:00
}
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
// Emit a Vals64 vector and exit.
Stream.EmitRecord(Code, Vals64, AbbrevToUse);
Vals64.clear();
return;
Make better use of the PHINode API. Change various bits of code to make better use of the existing PHINode API, to insulate them from forthcoming changes in how PHINodes store their operands. llvm-svn: 133434
2011-06-20 22:18:48 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial commit of the 'landingpad' instruction. This implements the 'landingpad' instruction. It's used to indicate that a basic block is a landing pad. There are several restrictions on its use (see LangRef.html for more detail). These restrictions allow the exception handling code to gather the information it needs in a much more sane way. This patch has the definition, implementation, C interface, parsing, and bitcode support in it. llvm-svn: 137501
2011-08-13 04:24:12 +08:00
case Instruction::LandingPad: {
const LandingPadInst &LP = cast<LandingPadInst>(I);
Code = bitc::FUNC_CODE_INST_LANDINGPAD;
Vals.push_back(VE.getTypeID(LP.getType()));
Vals.push_back(LP.isCleanup());
Vals.push_back(LP.getNumClauses());
for (unsigned I = 0, E = LP.getNumClauses(); I != E; ++I) {
if (LP.isCatch(I))
Vals.push_back(LandingPadInst::Catch);
else
Vals.push_back(LandingPadInst::Filter);
PushValueAndType(LP.getClause(I), InstID, Vals, VE);
}
break;
}
Roundtrip the inalloca bit on allocas through bitcode This was an oversight in the original support. As it is, I stuffed this bit into the alignment. The alignment is stored in log2 form, so it doesn't need more than 5 bits, given that Value::MaximumAlignment is 1 << 29. Reviewers: nicholas Differential Revision: http://reviews.llvm.org/D3943 llvm-svn: 213118
2014-07-16 09:34:27 +08:00
case Instruction::Alloca: {
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Code = bitc::FUNC_CODE_INST_ALLOCA;
[opaque pointer type] Encode the allocated type of an alloca rather than its pointer result type. llvm-svn: 235998
2015-04-29 00:51:01 +08:00
const AllocaInst &AI = cast<AllocaInst>(I);
Vals.push_back(VE.getTypeID(AI.getAllocatedType()));
Bitcode support for allocas with arbitrary array size types. llvm-svn: 104915
2010-05-28 09:38:28 +08:00
Vals.push_back(VE.getTypeID(I.getOperand(0)->getType()));
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Vals.push_back(VE.getValueID(I.getOperand(0))); // size.
Roundtrip the inalloca bit on allocas through bitcode This was an oversight in the original support. As it is, I stuffed this bit into the alignment. The alignment is stored in log2 form, so it doesn't need more than 5 bits, given that Value::MaximumAlignment is 1 << 29. Reviewers: nicholas Differential Revision: http://reviews.llvm.org/D3943 llvm-svn: 213118
2014-07-16 09:34:27 +08:00
unsigned AlignRecord = Log2_32(AI.getAlignment()) + 1;
assert(Log2_32(Value::MaximumAlignment) + 1 < 1 << 5 &&
"not enough bits for maximum alignment");
assert(AlignRecord < 1 << 5 && "alignment greater than 1 << 64");
AlignRecord |= AI.isUsedWithInAlloca() << 5;
[opaque pointer type] Encode the allocated type of an alloca rather than its pointer result type. llvm-svn: 235998
2015-04-29 00:51:01 +08:00
AlignRecord |= 1 << 6;
Swift Calling Convention: add swifterror attribute. A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst. This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch. Differential Revision: http://reviews.llvm.org/D18092 llvm-svn: 265189
2016-04-02 05:41:15 +08:00
AlignRecord |= AI.isSwiftError() << 7;
Roundtrip the inalloca bit on allocas through bitcode This was an oversight in the original support. As it is, I stuffed this bit into the alignment. The alignment is stored in log2 form, so it doesn't need more than 5 bits, given that Value::MaximumAlignment is 1 << 29. Reviewers: nicholas Differential Revision: http://reviews.llvm.org/D3943 llvm-svn: 213118
2014-07-16 09:34:27 +08:00
Vals.push_back(AlignRecord);
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
Roundtrip the inalloca bit on allocas through bitcode This was an oversight in the original support. As it is, I stuffed this bit into the alignment. The alignment is stored in log2 form, so it doesn't need more than 5 bits, given that Value::MaximumAlignment is 1 << 29. Reviewers: nicholas Differential Revision: http://reviews.llvm.org/D3943 llvm-svn: 213118
2014-07-16 09:34:27 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
case Instruction::Load:
Representation of 'atomic load' and 'atomic store' in IR. llvm-svn: 137170
2011-08-10 07:02:53 +08:00
if (cast<LoadInst>(I).isAtomic()) {
Code = bitc::FUNC_CODE_INST_LOADATOMIC;
PushValueAndType(I.getOperand(0), InstID, Vals, VE);
} else {
Code = bitc::FUNC_CODE_INST_LOAD;
if (!PushValueAndType(I.getOperand(0), InstID, Vals, VE)) // ptr
AbbrevToUse = FUNCTION_INST_LOAD_ABBREV;
}
[opaque pointer type] bitcode support for explicit type parameter to the load instruction Summary: I've taken my best guess at this, but I've cargo culted in places & so explanations/corrections would be great. This seems to pass all the tests (check-all, covering clang and llvm) so I believe that pretty well exercises both the backwards compatibility and common (same version) compatibility given the number of checked in bitcode files we already have. Is that a reasonable approach to testing here? Would some more explicit tests be desired? 1) is this the right way to do back-compat in this case (looking at the number of entries in the bitcode record to disambiguate between the old schema and the new?) 2) I don't quite understand the logarithm logic to choose the encoding type of the type parameter in the abbreviation description, but I found another instruction doing the same thing & it seems to work. Is that the right approach? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7655 llvm-svn: 230414
2015-02-25 09:07:20 +08:00
Vals.push_back(VE.getTypeID(I.getType()));
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Vals.push_back(Log2_32(cast<LoadInst>(I).getAlignment())+1);
Vals.push_back(cast<LoadInst>(I).isVolatile());
Representation of 'atomic load' and 'atomic store' in IR. llvm-svn: 137170
2011-08-10 07:02:53 +08:00
if (cast<LoadInst>(I).isAtomic()) {
Vals.push_back(GetEncodedOrdering(cast<LoadInst>(I).getOrdering()));
Vals.push_back(GetEncodedSynchScope(cast<LoadInst>(I).getSynchScope()));
}
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
case Instruction::Store:
Representation of 'atomic load' and 'atomic store' in IR. llvm-svn: 137170
2011-08-10 07:02:53 +08:00
if (cast<StoreInst>(I).isAtomic())
Code = bitc::FUNC_CODE_INST_STOREATOMIC;
else
Code = bitc::FUNC_CODE_INST_STORE;
Implement address space attribute for LLVM pointer types. Address spaces are regions of memory that have a target specific relationship, as described in the Embedded C Technical Report. This also implements the 2007-12-11-AddressSpaces test, which demonstrates how address space attributes can be used in LLVM IR. In addition, this patch changes the bitcode signature for stores (in a backwards compatible manner), such that the pointer type, rather than the pointee type, is encoded. This permits type information in the pointer (e.g. address space) to be preserved for stores. LangRef updates are forthcoming. llvm-svn: 44858
2007-12-11 16:59:05 +08:00
PushValueAndType(I.getOperand(1), InstID, Vals, VE); // ptrty + ptr
[opaque pointer types] Serialize the value type for store instructions Without pointee types the space optimization of storing only the pointer type and not the value type won't be viable - so add the extra type information that would be missing. Storeatomic coming soon. llvm-svn: 235474
2015-04-22 12:14:42 +08:00
PushValueAndType(I.getOperand(0), InstID, Vals, VE); // valty + val
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Vals.push_back(Log2_32(cast<StoreInst>(I).getAlignment())+1);
Vals.push_back(cast<StoreInst>(I).isVolatile());
Representation of 'atomic load' and 'atomic store' in IR. llvm-svn: 137170
2011-08-10 07:02:53 +08:00
if (cast<StoreInst>(I).isAtomic()) {
Vals.push_back(GetEncodedOrdering(cast<StoreInst>(I).getOrdering()));
Vals.push_back(GetEncodedSynchScope(cast<StoreInst>(I).getSynchScope()));
}
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
break;
LangRef and basic memory-representation/reading/writing for 'cmpxchg' and 'atomicrmw' instructions, which allow representing all the current atomic rmw intrinsics. The allowed operands for these instructions are heavily restricted at the moment; we can probably loosen it a bit, but supporting general first-class types (where it makes sense) might get a bit complicated, given how SelectionDAG works. As an initial cut, these operations do not support specifying an alignment, but it would be possible to add if we think it's useful. Specifying an alignment lower than the natural alignment would be essentially impossible to support on anything other than x86, but specifying a greater alignment would be possible. I can't think of any useful optimizations which would use that information, but maybe someone else has ideas. Optimizer/codegen support coming soon. llvm-svn: 136404
2011-07-29 05:48:00 +08:00
case Instruction::AtomicCmpXchg:
Code = bitc::FUNC_CODE_INST_CMPXCHG;
PushValueAndType(I.getOperand(0), InstID, Vals, VE); // ptrty + ptr
NFC Test Commit whitespace change in a comment Changed whitespace so comments line up. llvm-svn: 258151
2016-01-20 02:01:20 +08:00
PushValueAndType(I.getOperand(1), InstID, Vals, VE); // cmp.
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(2), InstID, Vals, VE); // newval.
LangRef and basic memory-representation/reading/writing for 'cmpxchg' and 'atomicrmw' instructions, which allow representing all the current atomic rmw intrinsics. The allowed operands for these instructions are heavily restricted at the moment; we can probably loosen it a bit, but supporting general first-class types (where it makes sense) might get a bit complicated, given how SelectionDAG works. As an initial cut, these operations do not support specifying an alignment, but it would be possible to add if we think it's useful. Specifying an alignment lower than the natural alignment would be essentially impossible to support on anything other than x86, but specifying a greater alignment would be possible. I can't think of any useful optimizations which would use that information, but maybe someone else has ideas. Optimizer/codegen support coming soon. llvm-svn: 136404
2011-07-29 05:48:00 +08:00
Vals.push_back(cast<AtomicCmpXchgInst>(I).isVolatile());
Vals.push_back(GetEncodedOrdering(
IR: add a second ordering operand to cmpxhg for failure The syntax for "cmpxchg" should now look something like: cmpxchg i32* %addr, i32 42, i32 3 acquire monotonic where the second ordering argument gives the required semantics in the case that no exchange takes place. It should be no stronger than the first ordering constraint and cannot be either "release" or "acq_rel" (since no store will have taken place). rdar://problem/15996804 llvm-svn: 203559
2014-03-11 18:48:52 +08:00
cast<AtomicCmpXchgInst>(I).getSuccessOrdering()));
LangRef and basic memory-representation/reading/writing for 'cmpxchg' and 'atomicrmw' instructions, which allow representing all the current atomic rmw intrinsics. The allowed operands for these instructions are heavily restricted at the moment; we can probably loosen it a bit, but supporting general first-class types (where it makes sense) might get a bit complicated, given how SelectionDAG works. As an initial cut, these operations do not support specifying an alignment, but it would be possible to add if we think it's useful. Specifying an alignment lower than the natural alignment would be essentially impossible to support on anything other than x86, but specifying a greater alignment would be possible. I can't think of any useful optimizations which would use that information, but maybe someone else has ideas. Optimizer/codegen support coming soon. llvm-svn: 136404
2011-07-29 05:48:00 +08:00
Vals.push_back(GetEncodedSynchScope(
cast<AtomicCmpXchgInst>(I).getSynchScope()));
IR: add a second ordering operand to cmpxhg for failure The syntax for "cmpxchg" should now look something like: cmpxchg i32* %addr, i32 42, i32 3 acquire monotonic where the second ordering argument gives the required semantics in the case that no exchange takes place. It should be no stronger than the first ordering constraint and cannot be either "release" or "acq_rel" (since no store will have taken place). rdar://problem/15996804 llvm-svn: 203559
2014-03-11 18:48:52 +08:00
Vals.push_back(GetEncodedOrdering(
cast<AtomicCmpXchgInst>(I).getFailureOrdering()));
IR: add "cmpxchg weak" variant to support permitted failure. This commit adds a weak variant of the cmpxchg operation, as described in C++11. A cmpxchg instruction with this modifier is permitted to fail to store, even if the comparison indicated it should. As a result, cmpxchg instructions must return a flag indicating success in addition to their original iN value loaded. Thus, for uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The second flag is 1 when the store succeeded. At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been added as the natural representation for the new cmpxchg instructions. It is a strong cmpxchg. By default this gets Expanded to the existing ATOMIC_CMP_SWAP during Legalization, so existing backends should see no change in behaviour. If they wish to deal with the enhanced node instead, they can call setOperationAction on it. Beware: as a node with 2 results, it cannot be selected from TableGen. Currently, no use is made of the extra information provided in this patch. Test updates are almost entirely adapting the input IR to the new scheme. Summary for out of tree users: ------------------------------ + Legacy Bitcode files are upgraded during read. + Legacy assembly IR files will be invalid. + Front-ends must adapt to different type for "cmpxchg". + Backends should be unaffected by default. llvm-svn: 210903
2014-06-13 22:24:07 +08:00
Vals.push_back(cast<AtomicCmpXchgInst>(I).isWeak());
LangRef and basic memory-representation/reading/writing for 'cmpxchg' and 'atomicrmw' instructions, which allow representing all the current atomic rmw intrinsics. The allowed operands for these instructions are heavily restricted at the moment; we can probably loosen it a bit, but supporting general first-class types (where it makes sense) might get a bit complicated, given how SelectionDAG works. As an initial cut, these operations do not support specifying an alignment, but it would be possible to add if we think it's useful. Specifying an alignment lower than the natural alignment would be essentially impossible to support on anything other than x86, but specifying a greater alignment would be possible. I can't think of any useful optimizations which would use that information, but maybe someone else has ideas. Optimizer/codegen support coming soon. llvm-svn: 136404
2011-07-29 05:48:00 +08:00
break;
case Instruction::AtomicRMW:
Code = bitc::FUNC_CODE_INST_ATOMICRMW;
PushValueAndType(I.getOperand(0), InstID, Vals, VE); // ptrty + ptr
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(1), InstID, Vals, VE); // val.
LangRef and basic memory-representation/reading/writing for 'cmpxchg' and 'atomicrmw' instructions, which allow representing all the current atomic rmw intrinsics. The allowed operands for these instructions are heavily restricted at the moment; we can probably loosen it a bit, but supporting general first-class types (where it makes sense) might get a bit complicated, given how SelectionDAG works. As an initial cut, these operations do not support specifying an alignment, but it would be possible to add if we think it's useful. Specifying an alignment lower than the natural alignment would be essentially impossible to support on anything other than x86, but specifying a greater alignment would be possible. I can't think of any useful optimizations which would use that information, but maybe someone else has ideas. Optimizer/codegen support coming soon. llvm-svn: 136404
2011-07-29 05:48:00 +08:00
Vals.push_back(GetEncodedRMWOperation(
cast<AtomicRMWInst>(I).getOperation()));
Vals.push_back(cast<AtomicRMWInst>(I).isVolatile());
Vals.push_back(GetEncodedOrdering(cast<AtomicRMWInst>(I).getOrdering()));
Vals.push_back(GetEncodedSynchScope(
cast<AtomicRMWInst>(I).getSynchScope()));
break;
Initial implementation of 'fence' instruction, the new C++0x-style replacement for llvm.memory.barrier. This is just a LangRef entry and reading/writing/memory representation; optimizer+codegen support coming soon. llvm-svn: 136009
2011-07-26 07:16:38 +08:00
case Instruction::Fence:
Code = bitc::FUNC_CODE_INST_FENCE;
Vals.push_back(GetEncodedOrdering(cast<FenceInst>(I).getOrdering()));
Vals.push_back(GetEncodedSynchScope(cast<FenceInst>(I).getSynchScope()));
break;
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
case Instruction::Call: {
resort to ArgOperand API llvm-svn: 106942
2010-06-26 17:35:09 +08:00
const CallInst &CI = cast<CallInst>(I);
[opaque pointer type] Explicit pointee type for call instruction Use an extra bit in the CCInfo to flag the newer version of the instructiont hat includes the type explicitly. Tested the newer error cases I added, but didn't add tests for the finer granularity improvements to existing error paths. llvm-svn: 235160
2015-04-17 14:40:14 +08:00
FunctionType *FTy = CI.getFunctionType();
Make a preemptive bitcode format change to support PR1146. This lets us do pr1146 in llvm 2.1 without ugly code to emulate old behavior. This should be merged into the 2.0 release branch. llvm-svn: 36928
2007-05-08 13:38:01 +08:00
[Bitcode][Asm] Teach LLVM to read and write operand bundles. Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
2015-09-25 07:34:52 +08:00
if (CI.hasOperandBundles())
WriteOperandBundles(Stream, &CI, InstID, VE);
Drop the "2" suffix on some enums. llvm-svn: 133274
2011-06-18 02:17:37 +08:00
Code = bitc::FUNC_CODE_INST_CALL;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
resort to ArgOperand API llvm-svn: 106942
2010-06-26 17:35:09 +08:00
Vals.push_back(VE.getAttributeID(CI.getAttributes()));
add fast-math-flags to 'call' instructions (PR21290) This patch adds optional fast-math-flags (the same that apply to fmul/fadd/fsub/fdiv/frem/fcmp) to call instructions in IR. Follow-up patches would use these flags in LibCallSimplifier, add support to clang, and extend FMF to the DAG for calls. Motivating example: %y = fmul fast float %x, %x %z = tail call float @sqrtf(float %y) We'd like to be able to optimize sqrt(x*x) into fabs(x). We do this today using a function-wide attribute for unsafe-math, but we really want to trigger on the instructions themselves: %z = tail call fast float @sqrtf(float %y) because in an LTO build it's possible that calls with fast semantics have been inlined into a function with non-fast semantics. The code changes and tests are based on the recent commits that added "notail": http://reviews.llvm.org/rL252368 and added FMF to fcmp: http://reviews.llvm.org/rL241901 Differential Revision: http://reviews.llvm.org/D14707 llvm-svn: 255555
2015-12-15 05:59:03 +08:00
unsigned Flags = GetOptimizationFlags(&I);
[Bitcode] Add enums for call instruction markers and flags. NFC. This commit adds enums in LLVMBitCodes.h to improve readability and maintainability. This is a follow-up to r252368 which was discussed here: http://reviews.llvm.org/D12923 llvm-svn: 252395
2015-11-07 10:48:49 +08:00
Vals.push_back(CI.getCallingConv() << bitc::CALL_CCONV |
unsigned(CI.isTailCall()) << bitc::CALL_TAIL |
unsigned(CI.isMustTailCall()) << bitc::CALL_MUSTTAIL |
1 << bitc::CALL_EXPLICIT_TYPE |
add fast-math-flags to 'call' instructions (PR21290) This patch adds optional fast-math-flags (the same that apply to fmul/fadd/fsub/fdiv/frem/fcmp) to call instructions in IR. Follow-up patches would use these flags in LibCallSimplifier, add support to clang, and extend FMF to the DAG for calls. Motivating example: %y = fmul fast float %x, %x %z = tail call float @sqrtf(float %y) We'd like to be able to optimize sqrt(x*x) into fabs(x). We do this today using a function-wide attribute for unsafe-math, but we really want to trigger on the instructions themselves: %z = tail call fast float @sqrtf(float %y) because in an LTO build it's possible that calls with fast semantics have been inlined into a function with non-fast semantics. The code changes and tests are based on the recent commits that added "notail": http://reviews.llvm.org/rL252368 and added FMF to fcmp: http://reviews.llvm.org/rL241901 Differential Revision: http://reviews.llvm.org/D14707 llvm-svn: 255555
2015-12-15 05:59:03 +08:00
unsigned(CI.isNoTailCall()) << bitc::CALL_NOTAIL |
unsigned(Flags != 0) << bitc::CALL_FMF);
if (Flags != 0)
Vals.push_back(Flags);
[opaque pointer type] Explicit pointee type for call instruction Use an extra bit in the CCInfo to flag the newer version of the instructiont hat includes the type explicitly. Tested the newer error cases I added, but didn't add tests for the finer granularity improvements to existing error paths. llvm-svn: 235160
2015-04-17 14:40:14 +08:00
Vals.push_back(VE.getTypeID(FTy));
resort to ArgOperand API llvm-svn: 106942
2010-06-26 17:35:09 +08:00
PushValueAndType(CI.getCalledValue(), InstID, Vals, VE); // Callee
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
// Emit value #'s for the fixed parameters.
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
for (unsigned i = 0, e = FTy->getNumParams(); i != e; ++i) {
// Check for labels (can happen with asm labels).
if (FTy->getParamType(i)->isLabelTy())
Vals.push_back(VE.getValueID(CI.getArgOperand(i)));
else
pushValue(CI.getArgOperand(i), InstID, Vals, VE); // fixed param.
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
fix build with non-buggy compilers llvm-svn: 36621
2007-05-01 15:03:37 +08:00
// Emit type/value pairs for varargs params.
if (FTy->isVarArg()) {
resort to ArgOperand API llvm-svn: 106942
2010-06-26 17:35:09 +08:00
for (unsigned i = FTy->getNumParams(), e = CI.getNumArgOperands();
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
i != e; ++i)
resort to ArgOperand API llvm-svn: 106942
2010-06-26 17:35:09 +08:00
PushValueAndType(CI.getArgOperand(i), InstID, Vals, VE); // varargs
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
}
break;
fix build with non-buggy compilers llvm-svn: 36621
2007-05-01 15:03:37 +08:00
}
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
case Instruction::VAArg:
Code = bitc::FUNC_CODE_INST_VAARG;
Vals.push_back(VE.getTypeID(I.getOperand(0)->getType())); // valistty
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
pushValue(I.getOperand(0), InstID, Vals, VE); // valist.
encode all of the instructions. llvm-svn: 36609
2007-05-01 10:13:26 +08:00
Vals.push_back(VE.getTypeID(I.getType())); // restype.
break;
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
Stream.EmitRecord(Code, Vals, AbbrevToUse);
Vals.clear();
}
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
/// Emit names for globals/functions etc. The VSTOffsetPlaceholder,
[ThinLTO] Renaming of function index to module summary index (NFC) (Resubmitting after fixing missing file issue) With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes. A companion clang patch will immediately succeed this patch to reflect this renaming. llvm-svn: 263513
2016-03-15 08:04:37 +08:00
/// BitcodeStartBit and ModuleSummaryIndex are only passed for the module-level
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
/// VST, where we are including a function bitcode index and need to
/// backpatch the VST forward declaration record.
static void WriteValueSymbolTable(
const ValueSymbolTable &VST, const ValueEnumerator &VE,
BitstreamWriter &Stream, uint64_t VSTOffsetPlaceholder = 0,
uint64_t BitcodeStartBit = 0,
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
DenseMap<const Function *, uint64_t> *FunctionToBitcodeIndex = nullptr) {
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
if (VST.empty()) {
// WriteValueSymbolTableForwardDecl should have returned early as
// well. Ensure this handling remains in sync by asserting that
// the placeholder offset is not set.
assert(VSTOffsetPlaceholder == 0);
return;
}
if (VSTOffsetPlaceholder > 0) {
// Get the offset of the VST we are writing, and backpatch it into
// the VST forward declaration record.
uint64_t VSTOffset = Stream.GetCurrentBitNo();
// The BitcodeStartBit was the stream offset of the actual bitcode
// (e.g. excluding any initial darwin header).
VSTOffset -= BitcodeStartBit;
assert((VSTOffset & 31) == 0 && "VST block not 32-bit aligned");
Stream.BackpatchWord(VSTOffsetPlaceholder, VSTOffset / 32);
}
add a char6 abbrev for bbnames and value names. This represents each character with 6 bits where possible. This shrinks kc++ from 3324164B to 3183584B. The old VST was: Block ID #14 (VALUE_SYMTAB): Total Size: 1.26713e+07b/1.58391e+06B/395978W Average Size: 5403.53b/675.442B/168.86W % of file: 47.6484 The new one is: Block ID #14 (VALUE_SYMTAB): Total Size: 1.15467e+07b/1.44334e+06B/360834W Average Size: 4923.96b/615.495B/153.874W % of file: 45.3368 This is 11% smaller than the VST in the bytecode format. llvm-svn: 36771
2007-05-05 09:26:50 +08:00
Stream.EnterSubblock(bitc::VALUE_SYMTAB_BLOCK_ID, 4);
Encode all value symtab strings as arrays of 8-bit fixed width integers, instead of the default inefficient encoding. This shrinks kc++ from 4134K to 3629K llvm-svn: 36755
2007-05-05 04:34:50 +08:00
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
// For the module-level VST, add abbrev Ids for the VST_CODE_FNENTRY
// records, which are not used in the per-function VSTs.
unsigned FnEntry8BitAbbrev;
unsigned FnEntry7BitAbbrev;
unsigned FnEntry6BitAbbrev;
if (VSTOffsetPlaceholder > 0) {
Fix VST_CODE_* bitcode id comments (NFC) llvm-svn: 260382
2016-02-10 23:02:51 +08:00
// 8-bit fixed-width VST_CODE_FNENTRY function strings.
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::VST_CODE_FNENTRY));
Clang format a few prior patches (NFC) I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
2015-11-03 02:02:11 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // value id
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // funcoffset
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 8));
FnEntry8BitAbbrev = Stream.EmitAbbrev(Abbv);
Fix VST_CODE_* bitcode id comments (NFC) llvm-svn: 260382
2016-02-10 23:02:51 +08:00
// 7-bit fixed width VST_CODE_FNENTRY function strings.
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::VST_CODE_FNENTRY));
Clang format a few prior patches (NFC) I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
2015-11-03 02:02:11 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // value id
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // funcoffset
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 7));
FnEntry7BitAbbrev = Stream.EmitAbbrev(Abbv);
Fix VST_CODE_* bitcode id comments (NFC) llvm-svn: 260382
2016-02-10 23:02:51 +08:00
// 6-bit char6 VST_CODE_FNENTRY function strings.
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::VST_CODE_FNENTRY));
Clang format a few prior patches (NFC) I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
2015-11-03 02:02:11 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // value id
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // funcoffset
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Char6));
FnEntry6BitAbbrev = Stream.EmitAbbrev(Abbv);
}
write the symbol table for function bodies llvm-svn: 36610
2007-05-01 10:14:57 +08:00
// FIXME: Set up the abbrev, we know how many values there are!
// FIXME: We know if the type names can use 7-bit ascii.
SmallVector<unsigned, 64> NameVals;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Rangify for loop, NFC. llvm-svn: 244434
2015-08-10 15:04:29 +08:00
for (const ValueName &Name : VST) {
where possible, encode symtab names with 7 bits per char instead of 8. This shaves 110K off kc++ to 3514K. Before: Block ID #14 (VALUE_SYMTAB): Num Instances: 2345 Total Size: 1.50425e+07b/1.88031e+06B/470077W Average Size: 6414.69b/801.837B/200.459W % of file: 51.8057 Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 2345/1 Tot/Avg Records: 120924/51.5667 % Abbrev Recs: 85.1791 after: Block ID #14 (VALUE_SYMTAB): Num Instances: 2345 Total Size: 1.41229e+07b/1.76536e+06B/441341W Average Size: 6022.56b/752.82B/188.205W % of file: 50.2295 Tot/Avg SubBlocks: 0/0 Tot/Avg Abbrevs: 4690/2 Tot/Avg Records: 120924/51.5667 % Abbrev Recs: 85.1791 llvm-svn: 36758
2007-05-05 04:52:02 +08:00
// Figure out the encoding to use for the name.
Refactor string encoding checks in BitcodeWriter (NFC) llvm-svn: 247891
2015-09-17 22:37:35 +08:00
StringEncoding Bits =
getStringEncoding(Name.getKeyData(), Name.getKeyLength());
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
allow the 8-bit abbrev to be used for either bb or other values llvm-svn: 36761
2007-05-05 05:31:13 +08:00
unsigned AbbrevToUse = VST_ENTRY_8_ABBREV;
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
NameVals.push_back(VE.getValueID(Name.getValue()));
Function *F = dyn_cast<Function>(Name.getValue());
if (!F) {
// If value is an alias, need to get the aliased base object to
// see if it is a function.
auto *GA = dyn_cast<GlobalAlias>(Name.getValue());
if (GA && GA->getBaseObject())
F = dyn_cast<Function>(GA->getBaseObject());
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Fix VST_CODE_* bitcode id comments (NFC) llvm-svn: 260382
2016-02-10 23:02:51 +08:00
// VST_CODE_ENTRY: [valueid, namechar x N]
// VST_CODE_FNENTRY: [valueid, funcoffset, namechar x N]
// VST_CODE_BBENTRY: [bbid, namechar x N]
fix encoding of BB names in the symtab llvm-svn: 36704
2007-05-04 06:18:21 +08:00
unsigned Code;
Rangify for loop, NFC. llvm-svn: 244434
2015-08-10 15:04:29 +08:00
if (isa<BasicBlock>(Name.getValue())) {
Revert r129235 pending a vetting of the EH rewrite. --- Reverse-merging r129235 into '.': D test/Feature/bb_attrs.ll U include/llvm/BasicBlock.h U include/llvm/Bitcode/LLVMBitCodes.h U lib/VMCore/AsmWriter.cpp U lib/VMCore/BasicBlock.cpp U lib/AsmParser/LLParser.cpp U lib/AsmParser/LLLexer.cpp U lib/AsmParser/LLToken.h U lib/Bitcode/Reader/BitcodeReader.cpp U lib/Bitcode/Writer/BitcodeWriter.cpp llvm-svn: 129259
2011-04-11 07:18:04 +08:00
Code = bitc::VST_CODE_BBENTRY;
Refactor string encoding checks in BitcodeWriter (NFC) llvm-svn: 247891
2015-09-17 22:37:35 +08:00
if (Bits == SE_Char6)
Revert r129235 pending a vetting of the EH rewrite. --- Reverse-merging r129235 into '.': D test/Feature/bb_attrs.ll U include/llvm/BasicBlock.h U include/llvm/Bitcode/LLVMBitCodes.h U lib/VMCore/AsmWriter.cpp U lib/VMCore/BasicBlock.cpp U lib/AsmParser/LLParser.cpp U lib/AsmParser/LLLexer.cpp U lib/AsmParser/LLToken.h U lib/Bitcode/Reader/BitcodeReader.cpp U lib/Bitcode/Writer/BitcodeWriter.cpp llvm-svn: 129259
2011-04-11 07:18:04 +08:00
AbbrevToUse = VST_BBENTRY_6_ABBREV;
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
} else if (F && !F->isDeclaration()) {
// Must be the module-level VST, where we pass in the Index and
// have a VSTOffsetPlaceholder. The function-level VST should not
// contain any Function symbols.
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
assert(FunctionToBitcodeIndex);
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
assert(VSTOffsetPlaceholder > 0);
// Save the word offset of the function (from the start of the
// actual bitcode written to the stream).
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
uint64_t BitcodeIndex = (*FunctionToBitcodeIndex)[F] - BitcodeStartBit;
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
assert((BitcodeIndex & 31) == 0 && "function block not 32-bit aligned");
NameVals.push_back(BitcodeIndex / 32);
Code = bitc::VST_CODE_FNENTRY;
AbbrevToUse = FnEntry8BitAbbrev;
if (Bits == SE_Char6)
AbbrevToUse = FnEntry6BitAbbrev;
else if (Bits == SE_Fixed7)
AbbrevToUse = FnEntry7BitAbbrev;
fix encoding of BB names in the symtab llvm-svn: 36704
2007-05-04 06:18:21 +08:00
} else {
Code = bitc::VST_CODE_ENTRY;
Refactor string encoding checks in BitcodeWriter (NFC) llvm-svn: 247891
2015-09-17 22:37:35 +08:00
if (Bits == SE_Char6)
add a char6 abbrev for bbnames and value names. This represents each character with 6 bits where possible. This shrinks kc++ from 3324164B to 3183584B. The old VST was: Block ID #14 (VALUE_SYMTAB): Total Size: 1.26713e+07b/1.58391e+06B/395978W Average Size: 5403.53b/675.442B/168.86W % of file: 47.6484 The new one is: Block ID #14 (VALUE_SYMTAB): Total Size: 1.15467e+07b/1.44334e+06B/360834W Average Size: 4923.96b/615.495B/153.874W % of file: 45.3368 This is 11% smaller than the VST in the bytecode format. llvm-svn: 36771
2007-05-05 09:26:50 +08:00
AbbrevToUse = VST_ENTRY_6_ABBREV;
Refactor string encoding checks in BitcodeWriter (NFC) llvm-svn: 247891
2015-09-17 22:37:35 +08:00
else if (Bits == SE_Fixed7)
add a char6 abbrev for bbnames and value names. This represents each character with 6 bits where possible. This shrinks kc++ from 3324164B to 3183584B. The old VST was: Block ID #14 (VALUE_SYMTAB): Total Size: 1.26713e+07b/1.58391e+06B/395978W Average Size: 5403.53b/675.442B/168.86W % of file: 47.6484 The new one is: Block ID #14 (VALUE_SYMTAB): Total Size: 1.15467e+07b/1.44334e+06B/360834W Average Size: 4923.96b/615.495B/153.874W % of file: 45.3368 This is 11% smaller than the VST in the bytecode format. llvm-svn: 36771
2007-05-05 09:26:50 +08:00
AbbrevToUse = VST_ENTRY_7_ABBREV;
fix encoding of BB names in the symtab llvm-svn: 36704
2007-05-04 06:18:21 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Clang format a few prior patches (NFC) I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
2015-11-03 02:02:11 +08:00
for (const auto P : Name.getKey())
NameVals.push_back((unsigned char)P);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
write the symbol table for function bodies llvm-svn: 36610
2007-05-01 10:14:57 +08:00
// Emit the finished record.
fix encoding of BB names in the symtab llvm-svn: 36704
2007-05-04 06:18:21 +08:00
Stream.EmitRecord(Code, NameVals, AbbrevToUse);
write the symbol table for function bodies llvm-svn: 36610
2007-05-01 10:14:57 +08:00
NameVals.clear();
}
Stream.ExitBlock();
}
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
/// Emit function names and summary offsets for the combined index
/// used by ThinLTO.
Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC) Summary: This should make the code more readable, especially all the map declarations. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18721 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265215
2016-04-02 13:07:53 +08:00
static void WriteCombinedValueSymbolTable(
const ModuleSummaryIndex &Index, BitstreamWriter &Stream,
std::map<GlobalValue::GUID, unsigned> &GUIDToValueIdMap,
uint64_t VSTOffsetPlaceholder) {
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
assert(VSTOffsetPlaceholder > 0 && "Expected non-zero VSTOffsetPlaceholder");
// Get the offset of the VST we are writing, and backpatch it into
// the VST forward declaration record.
uint64_t VSTOffset = Stream.GetCurrentBitNo();
assert((VSTOffset & 31) == 0 && "VST block not 32-bit aligned");
Stream.BackpatchWord(VSTOffsetPlaceholder, VSTOffset / 32);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
Stream.EnterSubblock(bitc::VALUE_SYMTAB_BLOCK_ID, 4);
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Abbv->Add(BitCodeAbbrevOp(bitc::VST_CODE_COMBINED_GVDEFENTRY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // valueid
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // sumoffset
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // guid
unsigned DefEntryAbbrev = Stream.EmitAbbrev(Abbv);
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::VST_CODE_COMBINED_ENTRY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // valueid
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // refguid
unsigned EntryAbbrev = Stream.EmitAbbrev(Abbv);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
Restore "[ThinLTO] Use MD5 hash in function index." with fix This restores commit r260408, along with a fix for a bot failure. The bot failure was caused by dereferencing a unique_ptr in the same call instruction parameter list where it was passed via std::move. Apparently due to luck this was not exposed when I built the compiler with clang, only with gcc. llvm-svn: 260442
2016-02-11 05:55:02 +08:00
SmallVector<uint64_t, 64> NameVals;
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
Pass FunctionInfoIndex by reference to WriteFunctionSummaryToFile (NFC) Implemented suggestion by dblakie in review for r250704. llvm-svn: 250723
2015-10-20 03:06:06 +08:00
for (const auto &FII : Index) {
Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC) Summary: This should make the code more readable, especially all the map declarations. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18721 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265215
2016-04-02 13:07:53 +08:00
GlobalValue::GUID FuncGUID = FII.first;
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
const auto &VMI = GUIDToValueIdMap.find(FuncGUID);
assert(VMI != GUIDToValueIdMap.end());
Restore "[ThinLTO] Use MD5 hash in function index." with fix This restores commit r260408, along with a fix for a bot failure. The bot failure was caused by dereferencing a unique_ptr in the same call instruction parameter list where it was passed via std::move. Apparently due to luck this was not exposed when I built the compiler with clang, only with gcc. llvm-svn: 260442
2016-02-11 05:55:02 +08:00
for (const auto &FI : FII.second) {
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// VST_CODE_COMBINED_GVDEFENTRY: [valueid, sumoffset, guid]
NameVals.push_back(VMI->second);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
NameVals.push_back(FI->bitcodeIndex());
Restore "[ThinLTO] Use MD5 hash in function index." with fix This restores commit r260408, along with a fix for a bot failure. The bot failure was caused by dereferencing a unique_ptr in the same call instruction parameter list where it was passed via std::move. Apparently due to luck this was not exposed when I built the compiler with clang, only with gcc. llvm-svn: 260442
2016-02-11 05:55:02 +08:00
NameVals.push_back(FuncGUID);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// Emit the finished record.
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Stream.EmitRecord(bitc::VST_CODE_COMBINED_GVDEFENTRY, NameVals,
DefEntryAbbrev);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
NameVals.clear();
}
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
GUIDToValueIdMap.erase(VMI);
}
for (const auto &GVI : GUIDToValueIdMap) {
// VST_CODE_COMBINED_ENTRY: [valueid, refguid]
NameVals.push_back(GVI.second);
NameVals.push_back(GVI.first);
// Emit the finished record.
Stream.EmitRecord(bitc::VST_CODE_COMBINED_ENTRY, NameVals, EntryAbbrev);
NameVals.clear();
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
}
Stream.ExitBlock();
}
Bitcode: Serialize (and recover) use-list order Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
2014-07-29 05:19:41 +08:00
static void WriteUseList(ValueEnumerator &VE, UseListOrder &&Order,
BitstreamWriter &Stream) {
assert(Order.Shuffle.size() >= 2 && "Shuffle too small");
unsigned Code;
if (isa<BasicBlock>(Order.V))
Code = bitc::USELIST_CODE_BB;
else
Code = bitc::USELIST_CODE_DEFAULT;
Prefer SmallVector::append/insert over push_back loops. Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
2015-02-17 23:29:18 +08:00
SmallVector<uint64_t, 64> Record(Order.Shuffle.begin(), Order.Shuffle.end());
Bitcode: Serialize (and recover) use-list order Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
2014-07-29 05:19:41 +08:00
Record.push_back(VE.getValueID(Order.V));
Stream.EmitRecord(Code, Record);
}
static void WriteUseListBlock(const Function *F, ValueEnumerator &VE,
BitstreamWriter &Stream) {
uselistorder: Thread bit through ValueEnumerator Canonicalize access to whether to preserve use-list order in bitcode on a `bool` stored in `ValueEnumerator`. Next step, expose this as a `bool` through `WriteBitcodeToFile()`. llvm-svn: 234956
2015-04-15 07:45:11 +08:00
assert(VE.shouldPreserveUseListOrder() &&
"Expected to be preserving use-list order");
Bitcode: Serialize (and recover) use-list order Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
2014-07-29 05:19:41 +08:00
auto hasMore = [&]() {
return !VE.UseListOrders.empty() && VE.UseListOrders.back().F == F;
};
if (!hasMore())
// Nothing to do.
return;
Stream.EnterSubblock(bitc::USELIST_BLOCK_ID, 3);
while (hasMore()) {
WriteUseList(VE, std::move(VE.UseListOrders.back()), Stream);
VE.UseListOrders.pop_back();
}
Stream.ExitBlock();
}
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
/// Emit a function body to the module stream.
Rename FunctionIndex into GlobalValueIndex to reflect the recent changes (NFC) The index used to contain only Function, but now contains GlobalValue in general. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265230
2016-04-03 01:29:47 +08:00
static void
WriteFunction(const Function &F, const Module *M, ValueEnumerator &VE,
BitstreamWriter &Stream,
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
DenseMap<const Function *, uint64_t> &FunctionToBitcodeIndex) {
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
// Save the bitcode index of the start of this function block for recording
// in the VST.
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
FunctionToBitcodeIndex[&F] = Stream.GetCurrentBitNo();
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
Stream.EnterSubblock(bitc::FUNCTION_BLOCK_ID, 4);
Revert name change from r132533. Lower case naming was intended per style guidelines. llvm-svn: 132555
2011-06-04 01:02:19 +08:00
VE.incorporateFunction(F);
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
SmallVector<unsigned, 64> Vals;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
// Emit the number of basic blocks, so the reader can create them ahead of
// time.
Vals.push_back(VE.getBasicBlocks().size());
Stream.EmitRecord(bitc::FUNC_CODE_DECLAREBLOCKS, Vals);
Vals.clear();
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
// If there are function-local constants, emit them now.
unsigned CstStart, CstEnd;
VE.getFunctionConstantRange(CstStart, CstEnd);
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
WriteConstants(CstStart, CstEnd, VE, Stream, false);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
In WriteFunction(), write function-local metadata before we write the instructions, so instruction's references to metadata are fully resolved by the time they get written. llvm-svn: 93403
2010-01-14 09:50:08 +08:00
// If there is function-local metadata, emit it now.
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
writeFunctionMetadata(F, VE, Stream);
In WriteFunction(), write function-local metadata before we write the instructions, so instruction's references to metadata are fully resolved by the time they get written. llvm-svn: 93403
2010-01-14 09:50:08 +08:00
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
// Keep a running idea of what the instruction ID is.
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
unsigned InstID = CstEnd;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
IR: Add assembly/bitcode support for function metadata attachments Add serialization support for function metadata attachments (added in r235783). The syntax is: define @foo() !attach !0 { Metadata attachments are only allowed on functions with bodies. Since they come before the `{`, they're not really part of the body; since they require a body, they're not really part of the header. In `LLParser` I gave them a separate function called from `ParseDefine()`, `ParseOptionalFunctionMetadata()`. In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by instructions. Instruction metadata attachments are included in a special "attachment" block at the end of a `Function`. The attachment records are laid out like this: InstID (KindID MetadataID)+ Note that these records always have an odd number of fields. The new code takes advantage of this to recognize function attachments (which don't need an instruction ID): (KindID MetadataID)+ This means we can use the same attachment block already used for instructions. This is part of PR23340. llvm-svn: 235785
2015-04-25 06:04:41 +08:00
bool NeedsMetadataAttachment = F.hasMetadata();
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-30 00:38:44 +08:00
DILocation *LastDL = nullptr;
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
// Finally, emit all the instructions, in order.
Remove 'unwinds to' support from mainline. This patch undoes r47802 r47989 r48047 r48084 r48085 r48086 r48088 r48096 r48099 r48109 and r48123. llvm-svn: 50265
2008-04-26 00:53:59 +08:00
for (Function::const_iterator BB = F.begin(), E = F.end(); BB != E; ++BB)
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
for (BasicBlock::const_iterator I = BB->begin(), E = BB->end();
I != E; ++I) {
WriteInstruction(*I, InstID, VE, Stream, Vals);
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
This is a major cleanup of the instruction metadata interfaces that I asked Devang to do back on Sep 27. Instead of going through the MetadataContext class with methods like getMD() and getMDs(), just ask the instruction directly for its metadata with getMetadata() and getAllMetadata(). This includes a variety of other fixes and improvements: previously all Value*'s were bloated because the HasMetadata bit was thrown into value, adding a 9th bit to a byte. Now this is properly sunk down to the Instruction class (the only place where it makes sense) and it will be folded away somewhere soon. This also fixes some confusion in getMDs and its clients about whether the returned list is indexed by the MDID or densely packed. This is now returned sorted and densely packed and the comments make this clear. This introduces a number of fixme's which I'll follow up on. llvm-svn: 92235
2009-12-29 07:41:32 +08:00
if (!I->getType()->isVoidTy())
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
++InstID;
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
Add special case bitcode support for DebugLoc. This avoids having the bitcode writer materialize mdnodes for all the debug location tuples when writing out the bc file and stores the information in a more compact form. For example, the -O0 -g bc file for combine.c in 176.gcc shrinks from 739392 to 512096 bytes. This concludes my planned short-term debug info work. llvm-svn: 100261
2010-04-03 10:17:50 +08:00
// If the instruction has metadata, write a metadata attachment later.
NeedsMetadataAttachment |= I->hasMetadataOtherThanDebugLoc();
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
Add special case bitcode support for DebugLoc. This avoids having the bitcode writer materialize mdnodes for all the debug location tuples when writing out the bc file and stores the information in a more compact form. For example, the -O0 -g bc file for combine.c in 176.gcc shrinks from 739392 to 512096 bytes. This concludes my planned short-term debug info work. llvm-svn: 100261
2010-04-03 10:17:50 +08:00
// If the instruction has a debug location, emit it.
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-30 00:38:44 +08:00
DILocation *DL = I->getDebugLoc();
IR: Use the new DebugLoc API, NFC Update lib/IR and lib/Bitcode to use the new `DebugLoc` API. Added an explicit conversion to `bool` (avoiding a conversion to `MDLocation`), since a couple of these use cases need to handle broken code. llvm-svn: 233585
2015-03-31 03:40:05 +08:00
if (!DL)
Bitcode: Reflow code to use early continues, NFC llvm-svn: 233578
2015-03-31 02:29:18 +08:00
continue;
if (DL == LastDL) {
Add special case bitcode support for DebugLoc. This avoids having the bitcode writer materialize mdnodes for all the debug location tuples when writing out the bc file and stores the information in a more compact form. For example, the -O0 -g bc file for combine.c in 176.gcc shrinks from 739392 to 512096 bytes. This concludes my planned short-term debug info work. llvm-svn: 100261
2010-04-03 10:17:50 +08:00
// Just repeat the same debug loc as last time.
Stream.EmitRecord(bitc::FUNC_CODE_DEBUG_LOC_AGAIN, Vals);
Bitcode: Reflow code to use early continues, NFC llvm-svn: 233578
2015-03-31 02:29:18 +08:00
continue;
Add special case bitcode support for DebugLoc. This avoids having the bitcode writer materialize mdnodes for all the debug location tuples when writing out the bc file and stores the information in a more compact form. For example, the -O0 -g bc file for combine.c in 176.gcc shrinks from 739392 to 512096 bytes. This concludes my planned short-term debug info work. llvm-svn: 100261
2010-04-03 10:17:50 +08:00
}
Bitcode: Reflow code to use early continues, NFC llvm-svn: 233578
2015-03-31 02:29:18 +08:00
IR: Use the new DebugLoc API, NFC Update lib/IR and lib/Bitcode to use the new `DebugLoc` API. Added an explicit conversion to `bool` (avoiding a conversion to `MDLocation`), since a couple of these use cases need to handle broken code. llvm-svn: 233585
2015-03-31 03:40:05 +08:00
Vals.push_back(DL->getLine());
Vals.push_back(DL->getColumn());
Vals.push_back(VE.getMetadataOrNullID(DL->getScope()));
Vals.push_back(VE.getMetadataOrNullID(DL->getInlinedAt()));
Bitcode: Reflow code to use early continues, NFC llvm-svn: 233578
2015-03-31 02:29:18 +08:00
Stream.EmitRecord(bitc::FUNC_CODE_DEBUG_LOC, Vals);
Vals.clear();
Bitcode: Set LastDL after writing DebugLocs Somehow I dropped this in r233585, and we haven't had `DEBUG_LOC_AGAIN` records since. Add it back. Also tests that the output assembly looks okay. Fixes PR23436. llvm-svn: 236661
2015-05-07 06:51:12 +08:00
LastDL = DL;
stop encoding type/value pairs when the type is implied by the value. This shrinks the function block of kc++ from 1055K to 906K llvm-svn: 36816
2007-05-06 08:00:00 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
write the symbol table for function bodies llvm-svn: 36610
2007-05-01 10:14:57 +08:00
// Emit names for all the instructions etc.
WriteValueSymbolTable(F.getValueSymbolTable(), VE, Stream);
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
Add special case bitcode support for DebugLoc. This avoids having the bitcode writer materialize mdnodes for all the debug location tuples when writing out the bc file and stores the information in a more compact form. For example, the -O0 -g bc file for combine.c in 176.gcc shrinks from 739392 to 512096 bytes. This concludes my planned short-term debug info work. llvm-svn: 100261
2010-04-03 10:17:50 +08:00
if (NeedsMetadataAttachment)
WriteMetadataAttachment(F, VE, Stream);
uselistorder: Thread bit through ValueEnumerator Canonicalize access to whether to preserve use-list order in bitcode on a `bool` stored in `ValueEnumerator`. Next step, expose this as a `bool` through `WriteBitcodeToFile()`. llvm-svn: 234956
2015-04-15 07:45:11 +08:00
if (VE.shouldPreserveUseListOrder())
Bitcode: Serialize (and recover) use-list order Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
2014-07-29 05:19:41 +08:00
WriteUseListBlock(&F, VE, Stream);
Revert name change from r132533. Lower case naming was intended per style guidelines. llvm-svn: 132555
2011-06-04 01:02:19 +08:00
VE.purgeFunction();
start code for writing out instructions. Separate BB#s from normal value #'s. llvm-svn: 36472
2007-04-26 13:53:54 +08:00
Stream.ExitBlock();
move some code around, fix a bug in the reader reading globalinits (which I just introduced), stub out function reading, purge aggregate values from the value table before reading functions. llvm-svn: 36463
2007-04-26 11:27:58 +08:00
}
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
// Emit blockinfo, which defines the standard abbreviations etc.
static void WriteBlockInfo(const ValueEnumerator &VE, BitstreamWriter &Stream) {
// We only want to emit block info records for blocks that have multiple
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
// instances: CONSTANTS_BLOCK, FUNCTION_BLOCK and VALUE_SYMTAB_BLOCK.
Fix some typos 165739, spotted by Duncan. llvm-svn: 165753
2012-10-12 05:45:16 +08:00
// Other blocks can define their abbrevs inline.
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
Stream.EnterBlockInfoBlock(2);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Fix VST_CODE_* bitcode id comments (NFC) llvm-svn: 260382
2016-02-10 23:02:51 +08:00
{ // 8-bit fixed-width VST_CODE_ENTRY/VST_CODE_BBENTRY strings.
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 8));
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
if (Stream.EmitBlockInfoAbbrev(bitc::VALUE_SYMTAB_BLOCK_ID,
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
Abbv) != VST_ENTRY_8_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Fix VST_CODE_* bitcode id comments (NFC) llvm-svn: 260382
2016-02-10 23:02:51 +08:00
{ // 7-bit fixed width VST_CODE_ENTRY strings.
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::VST_CODE_ENTRY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 7));
if (Stream.EmitBlockInfoAbbrev(bitc::VALUE_SYMTAB_BLOCK_ID,
Abbv) != VST_ENTRY_7_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
}
Fix VST_CODE_* bitcode id comments (NFC) llvm-svn: 260382
2016-02-10 23:02:51 +08:00
{ // 6-bit char6 VST_CODE_ENTRY strings.
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::VST_CODE_ENTRY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Char6));
if (Stream.EmitBlockInfoAbbrev(bitc::VALUE_SYMTAB_BLOCK_ID,
Abbv) != VST_ENTRY_6_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
}
Fix VST_CODE_* bitcode id comments (NFC) llvm-svn: 260382
2016-02-10 23:02:51 +08:00
{ // 6-bit char6 VST_CODE_BBENTRY strings.
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::VST_CODE_BBENTRY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Char6));
if (Stream.EmitBlockInfoAbbrev(bitc::VALUE_SYMTAB_BLOCK_ID,
Abbv) != VST_BBENTRY_6_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
}
Revert r129235 pending a vetting of the EH rewrite. --- Reverse-merging r129235 into '.': D test/Feature/bb_attrs.ll U include/llvm/BasicBlock.h U include/llvm/Bitcode/LLVMBitCodes.h U lib/VMCore/AsmWriter.cpp U lib/VMCore/BasicBlock.cpp U lib/AsmParser/LLParser.cpp U lib/AsmParser/LLLexer.cpp U lib/AsmParser/LLToken.h U lib/Bitcode/Reader/BitcodeReader.cpp U lib/Bitcode/Writer/BitcodeWriter.cpp llvm-svn: 129259
2011-04-11 07:18:04 +08:00
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
{ // SETTYPE abbrev for CONSTANTS_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::CST_CODE_SETTYPE));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed,
BitcodeWriter: Refactor common computation of bits required for a type index. Suggested by Duncan. Happy to bikeshed the name, cache the result, etc. llvm-svn: 230410
2015-02-25 08:51:52 +08:00
VE.computeBitsRequiredForTypeIndicies()));
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
if (Stream.EmitBlockInfoAbbrev(bitc::CONSTANTS_BLOCK_ID,
Abbv) != CONSTANTS_SETTYPE_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
{ // INTEGER abbrev for CONSTANTS_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::CST_CODE_INTEGER));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
if (Stream.EmitBlockInfoAbbrev(bitc::CONSTANTS_BLOCK_ID,
Abbv) != CONSTANTS_INTEGER_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
{ // CE_CAST abbrev for CONSTANTS_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::CST_CODE_CE_CAST));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 4)); // cast opc
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, // typeid
BitcodeWriter: Refactor common computation of bits required for a type index. Suggested by Duncan. Happy to bikeshed the name, cache the result, etc. llvm-svn: 230410
2015-02-25 08:51:52 +08:00
VE.computeBitsRequiredForTypeIndicies()));
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // value id
if (Stream.EmitBlockInfoAbbrev(bitc::CONSTANTS_BLOCK_ID,
Abbv) != CONSTANTS_CE_CAST_Abbrev)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
}
{ // NULL abbrev for CONSTANTS_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::CST_CODE_NULL));
if (Stream.EmitBlockInfoAbbrev(bitc::CONSTANTS_BLOCK_ID,
Abbv) != CONSTANTS_NULL_Abbrev)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add an abbrev for loads. This shrinks the function block about 50K, from: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.8434e+06b/1.10542e+06B/276356W % of file: 35.6726 Average Size: 3772.78b/471.598B/117.899W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 0 to: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.44518e+06b/1.05565e+06B/263912W % of file: 34.6203 Average Size: 3602.89b/450.362B/112.59W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 22.2077 llvm-svn: 36779
2007-05-05 15:44:49 +08:00
// FIXME: This should only use space for first class types!
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add an abbrev for loads. This shrinks the function block about 50K, from: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.8434e+06b/1.10542e+06B/276356W % of file: 35.6726 Average Size: 3772.78b/471.598B/117.899W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 0 to: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.44518e+06b/1.05565e+06B/263912W % of file: 34.6203 Average Size: 3602.89b/450.362B/112.59W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 22.2077 llvm-svn: 36779
2007-05-05 15:44:49 +08:00
{ // INST_LOAD abbrev for FUNCTION_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FUNC_CODE_INST_LOAD));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Ptr
[opaque pointer type] bitcode support for explicit type parameter to the load instruction Summary: I've taken my best guess at this, but I've cargo culted in places & so explanations/corrections would be great. This seems to pass all the tests (check-all, covering clang and llvm) so I believe that pretty well exercises both the backwards compatibility and common (same version) compatibility given the number of checked in bitcode files we already have. Is that a reasonable approach to testing here? Would some more explicit tests be desired? 1) is this the right way to do back-compat in this case (looking at the number of entries in the bitcode record to disambiguate between the old schema and the new?) 2) I don't quite understand the logarithm logic to choose the encoding type of the type parameter in the abbreviation description, but I found another instruction doing the same thing & it seems to work. Is that the right approach? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7655 llvm-svn: 230414
2015-02-25 09:07:20 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, // dest ty
VE.computeBitsRequiredForTypeIndicies()));
add an abbrev for loads. This shrinks the function block about 50K, from: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.8434e+06b/1.10542e+06B/276356W % of file: 35.6726 Average Size: 3772.78b/471.598B/117.899W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 0 to: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.44518e+06b/1.05565e+06B/263912W % of file: 34.6203 Average Size: 3602.89b/450.362B/112.59W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 22.2077 llvm-svn: 36779
2007-05-05 15:44:49 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 4)); // Align
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // volatile
if (Stream.EmitBlockInfoAbbrev(bitc::FUNCTION_BLOCK_ID,
Abbv) != FUNCTION_INST_LOAD_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add an abbrev for loads. This shrinks the function block about 50K, from: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.8434e+06b/1.10542e+06B/276356W % of file: 35.6726 Average Size: 3772.78b/471.598B/117.899W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 0 to: Block ID #12 (FUNCTION_BLOCK): Num Instances: 2344 Total Size: 8.44518e+06b/1.05565e+06B/263912W % of file: 34.6203 Average Size: 3602.89b/450.362B/112.59W Tot/Avg SubBlocks: 4065/1.73422 Tot/Avg Abbrevs: 0/0 Tot/Avg Records: 128487/54.8153 % Abbrev Recs: 22.2077 llvm-svn: 36779
2007-05-05 15:44:49 +08:00
}
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
{ // INST_BINOP abbrev for FUNCTION_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FUNC_CODE_INST_BINOP));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // LHS
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // RHS
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 4)); // opc
if (Stream.EmitBlockInfoAbbrev(bitc::FUNCTION_BLOCK_ID,
Abbv) != FUNCTION_INST_BINOP_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
}
Assembly and Bitcode support for unsigned/signed overflow flags and exact sdiv flags. llvm-svn: 76475
2009-07-21 05:19:07 +08:00
{ // INST_BINOP_FLAGS abbrev for FUNCTION_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FUNC_CODE_INST_BINOP));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // LHS
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // RHS
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 4)); // opc
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 7)); // flags
if (Stream.EmitBlockInfoAbbrev(bitc::FUNCTION_BLOCK_ID,
Abbv) != FUNCTION_INST_BINOP_FLAGS_ABBREV)
llvm_unreachable("Unexpected abbrev ordering!");
}
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
{ // INST_CAST abbrev for FUNCTION_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FUNC_CODE_INST_CAST));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // OpVal
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, // dest ty
BitcodeWriter: Refactor common computation of bits required for a type index. Suggested by Duncan. Happy to bikeshed the name, cache the result, etc. llvm-svn: 230410
2015-02-25 08:51:52 +08:00
VE.computeBitsRequiredForTypeIndicies()));
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 4)); // opc
if (Stream.EmitBlockInfoAbbrev(bitc::FUNCTION_BLOCK_ID,
Abbv) != FUNCTION_INST_CAST_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add abbrevs for binops and casts. This shrinks a testcase from 725132->682500 bytes. llvm-svn: 36829
2007-05-06 10:38:57 +08:00
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add some abbrevs for ret and unreachable, shrinking kc++ from 2717360->2705388 llvm-svn: 36823
2007-05-06 09:28:01 +08:00
{ // INST_RET abbrev for FUNCTION_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FUNC_CODE_INST_RET));
if (Stream.EmitBlockInfoAbbrev(bitc::FUNCTION_BLOCK_ID,
Abbv) != FUNCTION_INST_RET_VOID_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add some abbrevs for ret and unreachable, shrinking kc++ from 2717360->2705388 llvm-svn: 36823
2007-05-06 09:28:01 +08:00
}
{ // INST_RET abbrev for FUNCTION_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FUNC_CODE_INST_RET));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // ValID
if (Stream.EmitBlockInfoAbbrev(bitc::FUNCTION_BLOCK_ID,
Abbv) != FUNCTION_INST_RET_VAL_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add some abbrevs for ret and unreachable, shrinking kc++ from 2717360->2705388 llvm-svn: 36823
2007-05-06 09:28:01 +08:00
}
{ // INST_UNREACHABLE abbrev for FUNCTION_BLOCK.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FUNC_CODE_INST_UNREACHABLE));
if (Stream.EmitBlockInfoAbbrev(bitc::FUNCTION_BLOCK_ID,
Abbv) != FUNCTION_INST_UNREACHABLE_ABBREV)
llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable. This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
2009-07-15 00:55:14 +08:00
llvm_unreachable("Unexpected abbrev ordering!");
add some abbrevs for ret and unreachable, shrinking kc++ from 2717360->2705388 llvm-svn: 36823
2007-05-06 09:28:01 +08:00
}
[opaque pointer type] Bitcode support for explicit type parameter on GEP. Like r230414, add bitcode support including backwards compatibility, for an explicit type parameter to GEP. At the suggestion of Duncan I tried coalescing the two older bitcodes into a single new bitcode, though I did hit a wrinkle: I couldn't figure out how to create an explicit abbreviation for a record with a variable number of arguments (the indicies to the gep). This means the discriminator between inbounds and non-inbounds gep is a full variable-length field I believe? Is my understanding correct? Is there a way to create such an abbreviation? Should I just use two bitcodes as before? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7736 llvm-svn: 230415
2015-02-25 09:08:52 +08:00
{
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FUNC_CODE_INST_GEP));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, // dest ty
Log2_32_Ceil(VE.getTypes().size() + 1)));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));
if (Stream.EmitBlockInfoAbbrev(bitc::FUNCTION_BLOCK_ID, Abbv) !=
FUNCTION_INST_GEP_ABBREV)
llvm_unreachable("Unexpected abbrev ordering!");
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
Stream.ExitBlock();
}
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
/// Write the module path strings, currently only used when generating
/// a combined index file.
[ThinLTO] Renaming of function index to module summary index (NFC) (Resubmitting after fixing missing file issue) With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes. A companion clang patch will immediately succeed this patch to reflect this renaming. llvm-svn: 263513
2016-03-15 08:04:37 +08:00
static void WriteModStrings(const ModuleSummaryIndex &I,
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
BitstreamWriter &Stream) {
Stream.EnterSubblock(bitc::MODULE_STRTAB_BLOCK_ID, 3);
// TODO: See which abbrev sizes we actually need to emit
// 8-bit fixed-width MST_ENTRY strings.
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::MST_CODE_ENTRY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 8));
unsigned Abbrev8Bit = Stream.EmitAbbrev(Abbv);
// 7-bit fixed width MST_ENTRY strings.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::MST_CODE_ENTRY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 7));
unsigned Abbrev7Bit = Stream.EmitAbbrev(Abbv);
// 6-bit char6 MST_ENTRY strings.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::MST_CODE_ENTRY));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Char6));
unsigned Abbrev6Bit = Stream.EmitAbbrev(Abbv);
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
// Module Hash, 160 bits SHA1. Optionally, emitted after each MST_CODE_ENTRY.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::MST_CODE_HASH));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 32));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 32));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 32));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 32));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 32));
unsigned AbbrevHash = Stream.EmitAbbrev(Abbv);
SmallVector<unsigned, 64> Vals;
for (const auto &MPSE : I.modulePaths()) {
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
StringEncoding Bits =
getStringEncoding(MPSE.getKey().data(), MPSE.getKey().size());
unsigned AbbrevToUse = Abbrev8Bit;
if (Bits == SE_Char6)
AbbrevToUse = Abbrev6Bit;
else if (Bits == SE_Fixed7)
AbbrevToUse = Abbrev7Bit;
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
Vals.push_back(MPSE.getValue().first);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
Clang format a few prior patches (NFC) I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
2015-11-03 02:02:11 +08:00
for (const auto P : MPSE.getKey())
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
Vals.push_back((unsigned char)P);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// Emit the finished record.
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
Stream.EmitRecord(bitc::MST_CODE_ENTRY, Vals, AbbrevToUse);
Vals.clear();
// Emit an optional hash for the module now
auto &Hash = MPSE.getValue().second;
bool AllZero = true; // Detect if the hash is empty, and do not generate it
for (auto Val : Hash) {
if (Val)
AllZero = false;
Vals.push_back(Val);
}
if (!AllZero) {
// Emit the hash record.
Stream.EmitRecord(bitc::MST_CODE_HASH, Vals, AbbrevHash);
}
Vals.clear();
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
}
Stream.ExitBlock();
}
// Helper to emit a single function summary record.
static void WritePerModuleFunctionSummaryRecord(
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
SmallVector<uint64_t, 64> &NameVals, GlobalValueInfo *Info,
unsigned ValueID, const ValueEnumerator &VE, unsigned FSCallsAbbrev,
unsigned FSCallsProfileAbbrev, BitstreamWriter &Stream, const Function &F) {
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
NameVals.push_back(ValueID);
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
FunctionSummary *FS = cast<FunctionSummary>(Info->summary());
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
NameVals.push_back(getEncodedLinkage(FS->linkage()));
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
NameVals.push_back(FS->instCount());
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
NameVals.push_back(FS->refs().size());
for (auto &RI : FS->refs())
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
NameVals.push_back(VE.getValueID(RI.getValue()));
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
bool HasProfileData = F.getEntryCount().hasValue();
[ThinLTO] Rename edges() to calls() for clarity (NFC) Helps distinguish from refs() which iterates over non-call references. llvm-svn: 264445
2016-03-26 02:59:13 +08:00
for (auto &ECI : FS->calls()) {
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
NameVals.push_back(VE.getValueID(ECI.first.getValue()));
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
assert(ECI.second.CallsiteCount > 0 && "Expected at least one callsite");
NameVals.push_back(ECI.second.CallsiteCount);
if (HasProfileData)
NameVals.push_back(ECI.second.ProfileCount);
}
unsigned FSAbbrev = (HasProfileData ? FSCallsProfileAbbrev : FSCallsAbbrev);
unsigned Code =
(HasProfileData ? bitc::FS_PERMODULE_PROFILE : bitc::FS_PERMODULE);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// Emit the finished record.
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Stream.EmitRecord(Code, NameVals, FSAbbrev);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
NameVals.clear();
}
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// Collect the global value references in the given variable's initializer,
// and emit them in a summary record.
static void WriteModuleLevelReferences(const GlobalVariable &V,
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
const ModuleSummaryIndex &Index,
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
const ValueEnumerator &VE,
SmallVector<uint64_t, 64> &NameVals,
unsigned FSModRefsAbbrev,
BitstreamWriter &Stream) {
[ThinLTO] Record all global variable defs in the summary Record all variable defs with a summary record to aid in building a complete reference graph and locating constant variable defs to import. llvm-svn: 263576
2016-03-16 03:35:45 +08:00
// Only interested in recording variable defs in the summary.
if (V.isDeclaration())
return;
NameVals.push_back(VE.getValueID(&V));
NameVals.push_back(getEncodedLinkage(V.getLinkage()));
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
auto *Info = Index.getGlobalValueInfo(V);
GlobalVarSummary *VS = cast<GlobalVarSummary>(Info->summary());
for (auto Ref : VS->refs())
NameVals.push_back(VE.getValueID(Ref.getValue()));
[ThinLTO] Record all global variable defs in the summary Record all variable defs with a summary record to aid in building a complete reference graph and locating constant variable defs to import. llvm-svn: 263576
2016-03-16 03:35:45 +08:00
Stream.EmitRecord(bitc::FS_PERMODULE_GLOBALVAR_INIT_REFS, NameVals,
FSModRefsAbbrev);
NameVals.clear();
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
}
/// Emit the per-module summary section alongside the rest of
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
/// the module's bitcode.
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
static void WritePerModuleGlobalValueSummary(const Module *M,
const ModuleSummaryIndex &Index,
const ValueEnumerator &VE,
BitstreamWriter &Stream) {
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
if (M->empty())
return;
Stream.EnterSubblock(bitc::GLOBALVAL_SUMMARY_BLOCK_ID, 3);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// Abbrev for FS_PERMODULE.
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Abbv->Add(BitCodeAbbrevOp(bitc::FS_PERMODULE));
Clang format a few prior patches (NFC) I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
2015-11-03 02:02:11 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // valueid
[ThinLTO] Include linkage type in function summary Summary: Adds the linkage type to both the per-module and combined function summaries, which subsumes the current islocal bit. This will eventually be used to optimized linkage types based on global summary-based analysis. Reviewers: joker.eph Subscribers: joker.eph, davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D16943 llvm-svn: 259993
2016-02-07 00:07:35 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // linkage
Clang format a few prior patches (NFC) I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
2015-11-03 02:02:11 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // instcount
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 4)); // numrefs
// numrefs x valueid, n x (valueid, callsitecount)
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
unsigned FSCallsAbbrev = Stream.EmitAbbrev(Abbv);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// Abbrev for FS_PERMODULE_PROFILE.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FS_PERMODULE_PROFILE));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // valueid
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // linkage
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // instcount
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 4)); // numrefs
// numrefs x valueid, n x (valueid, callsitecount, profilecount)
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
unsigned FSCallsProfileAbbrev = Stream.EmitAbbrev(Abbv);
// Abbrev for FS_PERMODULE_GLOBALVAR_INIT_REFS.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FS_PERMODULE_GLOBALVAR_INIT_REFS));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // valueid
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // linkage
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array)); // valueids
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
unsigned FSModRefsAbbrev = Stream.EmitAbbrev(Abbv);
SmallVector<uint64_t, 64> NameVals;
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
// Iterate over the list of functions instead of the Index to
[ThinLTO] Ensure function summary output order is stable Iterate over the function list instead of a DenseMap of Function pointers when emitting the function summary into the module. This fixes PR26419. llvm-svn: 259398
2016-02-02 04:16:35 +08:00
// ensure the ordering is stable.
for (const Function &F : *M) {
if (F.isDeclaration())
continue;
Revert "Make aliases explicit in the summary" Inadvertently commited... This reverts commit e618ec93786d99df2ddf280ad2d5e02f5516cecf. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266215
2016-04-14 01:20:07 +08:00
// Skip anonymous functions. We will emit a function summary for
// any aliases below.
[ThinLTO] Ensure function summary output order is stable Iterate over the function list instead of a DenseMap of Function pointers when emitting the function summary into the module. This fixes PR26419. llvm-svn: 259398
2016-02-02 04:16:35 +08:00
if (!F.hasName())
Revert "Make aliases explicit in the summary" Inadvertently commited... This reverts commit e618ec93786d99df2ddf280ad2d5e02f5516cecf. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266215
2016-04-14 01:20:07 +08:00
continue;
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
auto *Info = Index.getGlobalValueInfo(F);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
WritePerModuleFunctionSummaryRecord(
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
NameVals, Info,
VE.getValueID(M->getValueSymbolTable().lookup(F.getName())), VE,
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
FSCallsAbbrev, FSCallsProfileAbbrev, Stream, F);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
}
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// Capture references from GlobalVariable initializers, which are outside
// of a function scope.
for (const GlobalVariable &G : M->globals())
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
WriteModuleLevelReferences(G, Index, VE, NameVals, FSModRefsAbbrev, Stream);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
Stream.ExitBlock();
}
[ThinLTO] Renaming of function index to module summary index (NFC) (Resubmitting after fixing missing file issue) With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes. A companion clang patch will immediately succeed this patch to reflect this renaming. llvm-svn: 263513
2016-03-15 08:04:37 +08:00
/// Emit the combined summary section into the combined index file.
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
static void WriteCombinedGlobalValueSummary(
Rename parameter I to Index for WriteCombinedGlobalValueSummary() (NFC) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265729
2016-04-08 05:49:31 +08:00
const ModuleSummaryIndex &Index, BitstreamWriter &Stream,
Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC) Summary: This should make the code more readable, especially all the map declarations. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18721 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265215
2016-04-02 13:07:53 +08:00
std::map<GlobalValue::GUID, unsigned> &GUIDToValueIdMap,
unsigned GlobalValueId) {
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Stream.EnterSubblock(bitc::GLOBALVAL_SUMMARY_BLOCK_ID, 3);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// Abbrev for FS_COMBINED.
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Abbv->Add(BitCodeAbbrevOp(bitc::FS_COMBINED));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // modid
[ThinLTO] Include linkage type in function summary Summary: Adds the linkage type to both the per-module and combined function summaries, which subsumes the current islocal bit. This will eventually be used to optimized linkage types based on global summary-based analysis. Reviewers: joker.eph Subscribers: joker.eph, davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D16943 llvm-svn: 259993
2016-02-07 00:07:35 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // linkage
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // instcount
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 4)); // numrefs
// numrefs x valueid, n x (valueid, callsitecount)
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
unsigned FSCallsAbbrev = Stream.EmitAbbrev(Abbv);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// Abbrev for FS_COMBINED_PROFILE.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FS_COMBINED_PROFILE));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // modid
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // linkage
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // instcount
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 4)); // numrefs
// numrefs x valueid, n x (valueid, callsitecount, profilecount)
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
unsigned FSCallsProfileAbbrev = Stream.EmitAbbrev(Abbv);
// Abbrev for FS_COMBINED_GLOBALVAR_INIT_REFS.
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::FS_COMBINED_GLOBALVAR_INIT_REFS));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // modid
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // linkage
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array)); // valueids
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8));
unsigned FSModRefsAbbrev = Stream.EmitAbbrev(Abbv);
SmallVector<uint64_t, 64> NameVals;
Rename parameter I to Index for WriteCombinedGlobalValueSummary() (NFC) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265729
2016-04-08 05:49:31 +08:00
for (const auto &FII : Index) {
Restore "[ThinLTO] Use MD5 hash in function index." with fix This restores commit r260408, along with a fix for a bot failure. The bot failure was caused by dereferencing a unique_ptr in the same call instruction parameter list where it was passed via std::move. Apparently due to luck this was not exposed when I built the compiler with clang, only with gcc. llvm-svn: 260442
2016-02-11 05:55:02 +08:00
for (auto &FI : FII.second) {
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
GlobalValueSummary *S = FI->summary();
assert(S);
if (auto *VS = dyn_cast<GlobalVarSummary>(S)) {
Rename parameter I to Index for WriteCombinedGlobalValueSummary() (NFC) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265729
2016-04-08 05:49:31 +08:00
NameVals.push_back(Index.getModuleId(VS->modulePath()));
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
NameVals.push_back(getEncodedLinkage(VS->linkage()));
for (auto &RI : VS->refs()) {
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
const auto &VMI = GUIDToValueIdMap.find(RI.getGUID());
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
unsigned RefId;
// If this GUID doesn't have an entry, assign one.
if (VMI == GUIDToValueIdMap.end()) {
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
GUIDToValueIdMap[RI.getGUID()] = ++GlobalValueId;
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
RefId = GlobalValueId;
} else {
RefId = VMI->second;
}
NameVals.push_back(RefId);
}
// Record the starting offset of this summary entry for use
// in the VST entry. Add the current code size since the
// reader will invoke readRecord after the abbrev id read.
FI->setBitcodeIndex(Stream.GetCurrentBitNo() +
Stream.GetAbbrevIDWidth());
// Emit the finished record.
Stream.EmitRecord(bitc::FS_COMBINED_GLOBALVAR_INIT_REFS, NameVals,
FSModRefsAbbrev);
NameVals.clear();
continue;
}
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
BitcodeWriter dyn_cast cleanup for r263275 (NFC) Address review suggestions from dblaikie: change a few dyn_cast to cast and fold a cast into if condition. llvm-svn: 263526
2016-03-15 10:41:29 +08:00
auto *FS = cast<FunctionSummary>(S);
Rename parameter I to Index for WriteCombinedGlobalValueSummary() (NFC) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265729
2016-04-08 05:49:31 +08:00
NameVals.push_back(Index.getModuleId(FS->modulePath()));
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
NameVals.push_back(getEncodedLinkage(FS->linkage()));
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
NameVals.push_back(FS->instCount());
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
NameVals.push_back(FS->refs().size());
for (auto &RI : FS->refs()) {
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
const auto &VMI = GUIDToValueIdMap.find(RI.getGUID());
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
unsigned RefId;
// If this GUID doesn't have an entry, assign one.
if (VMI == GUIDToValueIdMap.end()) {
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
GUIDToValueIdMap[RI.getGUID()] = ++GlobalValueId;
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
RefId = GlobalValueId;
} else {
RefId = VMI->second;
}
NameVals.push_back(RefId);
}
bool HasProfileData = false;
[ThinLTO] Rename edges() to calls() for clarity (NFC) Helps distinguish from refs() which iterates over non-call references. llvm-svn: 264445
2016-03-26 02:59:13 +08:00
for (auto &EI : FS->calls()) {
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
HasProfileData |= EI.second.ProfileCount != 0;
if (HasProfileData)
break;
}
[ThinLTO] Rename edges() to calls() for clarity (NFC) Helps distinguish from refs() which iterates over non-call references. llvm-svn: 264445
2016-03-26 02:59:13 +08:00
for (auto &EI : FS->calls()) {
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
const auto &VMI = GUIDToValueIdMap.find(EI.first.getGUID());
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// If this GUID doesn't have an entry, it doesn't have a function
// summary and we don't need to record any calls to it.
if (VMI == GUIDToValueIdMap.end())
continue;
NameVals.push_back(VMI->second);
assert(EI.second.CallsiteCount > 0 && "Expected at least one callsite");
NameVals.push_back(EI.second.CallsiteCount);
if (HasProfileData)
NameVals.push_back(EI.second.ProfileCount);
}
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// Record the starting offset of this summary entry for use
// in the VST entry. Add the current code size since the
// reader will invoke readRecord after the abbrev id read.
FI->setBitcodeIndex(Stream.GetCurrentBitNo() + Stream.GetAbbrevIDWidth());
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
unsigned FSAbbrev =
(HasProfileData ? FSCallsProfileAbbrev : FSCallsAbbrev);
unsigned Code =
(HasProfileData ? bitc::FS_COMBINED_PROFILE : bitc::FS_COMBINED);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// Emit the finished record.
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
Stream.EmitRecord(Code, NameVals, FSAbbrev);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
NameVals.clear();
}
}
Stream.ExitBlock();
}
Add an (optional) identification block in the bitcode Processing bitcode from a different LLVM version can lead to unexpected behavior. The LLVM project guarantees autoupdating bitcode from a previous minor revision for the same major, but can't make any promise when reading bitcode generated from a either a non-released LLVM, a vendor toolchain, or a "future" LLVM release. This patch aims at being more user-friendly and allows a bitcode produce to emit an optional block at the beginning of the bitcode that will contains an opaque string intended to describe the bitcode producer information. The bitcode reader will dump this information alongside any error it reports. The optional block also includes an "epoch" number, monotonically increasing when incompatible changes are made to the bitcode. The reader will reject bitcode whose epoch is different from the one expected. Differential Revision: http://reviews.llvm.org/D13666 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 251325
2015-10-27 02:37:00 +08:00
// Create the "IDENTIFICATION_BLOCK_ID" containing a single string with the
// current llvm version, and a record for the epoch number.
static void WriteIdentificationBlock(const Module *M, BitstreamWriter &Stream) {
Stream.EnterSubblock(bitc::IDENTIFICATION_BLOCK_ID, 5);
// Write the "user readable" string identifying the bitcode producer
BitCodeAbbrev *Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::IDENTIFICATION_CODE_STRING));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Char6));
auto StringAbbrev = Stream.EmitAbbrev(Abbv);
WriteStringRecord(bitc::IDENTIFICATION_CODE_STRING,
"LLVM" LLVM_VERSION_STRING, StringAbbrev, Stream);
// Write the epoch version
Abbv = new BitCodeAbbrev();
Abbv->Add(BitCodeAbbrevOp(bitc::IDENTIFICATION_CODE_EPOCH));
Abbv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));
Fix Abbrev emission in WriteIdentificationBlock This Abbrev was not emitted and basically unused, just leacking there. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 252110
2015-11-05 08:25:03 +08:00
auto EpochAbbrev = Stream.EmitAbbrev(Abbv);
Add an (optional) identification block in the bitcode Processing bitcode from a different LLVM version can lead to unexpected behavior. The LLVM project guarantees autoupdating bitcode from a previous minor revision for the same major, but can't make any promise when reading bitcode generated from a either a non-released LLVM, a vendor toolchain, or a "future" LLVM release. This patch aims at being more user-friendly and allows a bitcode produce to emit an optional block at the beginning of the bitcode that will contains an opaque string intended to describe the bitcode producer information. The bitcode reader will dump this information alongside any error it reports. The optional block also includes an "epoch" number, monotonically increasing when incompatible changes are made to the bitcode. The reader will reject bitcode whose epoch is different from the one expected. Differential Revision: http://reviews.llvm.org/D13666 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 251325
2015-10-27 02:37:00 +08:00
SmallVector<unsigned, 1> Vals = {bitc::BITCODE_CURRENT_EPOCH};
Fix Abbrev emission in WriteIdentificationBlock This Abbrev was not emitted and basically unused, just leacking there. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 252110
2015-11-05 08:25:03 +08:00
Stream.EmitRecord(bitc::IDENTIFICATION_CODE_EPOCH, Vals, EpochAbbrev);
Add an (optional) identification block in the bitcode Processing bitcode from a different LLVM version can lead to unexpected behavior. The LLVM project guarantees autoupdating bitcode from a previous minor revision for the same major, but can't make any promise when reading bitcode generated from a either a non-released LLVM, a vendor toolchain, or a "future" LLVM release. This patch aims at being more user-friendly and allows a bitcode produce to emit an optional block at the beginning of the bitcode that will contains an opaque string intended to describe the bitcode producer information. The bitcode reader will dump this information alongside any error it reports. The optional block also includes an "epoch" number, monotonically increasing when incompatible changes are made to the bitcode. The reader will reject bitcode whose epoch is different from the one expected. Differential Revision: http://reviews.llvm.org/D13666 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 251325
2015-10-27 02:37:00 +08:00
Stream.ExitBlock();
}
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
static void writeModuleHash(BitstreamWriter &Stream,
SmallVectorImpl<char> &Buffer,
size_t BlockStartPos) {
// Emit the module's hash.
// MODULE_CODE_HASH: [5*i32]
SHA1 Hasher;
Hasher.update(ArrayRef<uint8_t>((uint8_t *)&Buffer[BlockStartPos],
Buffer.size() - BlockStartPos));
auto Hash = Hasher.result();
SmallVector<uint64_t, 20> Vals;
auto LShift = [&](unsigned char Val, unsigned Amount)
-> uint64_t { return ((uint64_t)Val) << Amount; };
for (int Pos = 0; Pos < 20; Pos += 4) {
uint32_t SubHash = LShift(Hash[Pos + 0], 24);
SubHash |= LShift(Hash[Pos + 1], 16) | LShift(Hash[Pos + 2], 8) |
(unsigned)(unsigned char)Hash[Pos + 3];
Vals.push_back(SubHash);
}
// Emit the finished record.
Stream.EmitRecord(bitc::MODULE_CODE_HASH, Vals);
}
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
/// WriteModule - Emit the specified module to the bitstream.
uselistorder: Pull the bit through WriteToBitcodFile() Change the callers of `WriteToBitcodeFile()` to pass `true` or `shouldPreserveBitcodeUseListOrder()` explicitly. I left the callers that want to send `false` alone. I'll keep pushing the bit higher until hopefully I can delete the global `cl::opt` entirely. llvm-svn: 234957
2015-04-15 08:10:50 +08:00
static void WriteModule(const Module *M, BitstreamWriter &Stream,
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
bool ShouldPreserveUseListOrder,
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
uint64_t BitcodeStartBit,
const ModuleSummaryIndex *Index, bool GenerateHash,
SmallVectorImpl<char> &Buffer) {
implement reading of abbrevs, and writing of abbreviated global varrs. llvm-svn: 36367
2007-04-24 02:58:34 +08:00
Stream.EnterSubblock(bitc::MODULE_BLOCK_ID, 3);
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
size_t BlockStartPos = Buffer.size();
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
SmallVector<unsigned, 1> Vals;
unsigned CurVersion = 1;
Vals.push_back(CurVersion);
Stream.EmitRecord(bitc::MODULE_CODE_VERSION, Vals);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// Analyze the module, enumerating globals, functions, etc.
uselistorder: Pull the bit through WriteToBitcodFile() Change the callers of `WriteToBitcodeFile()` to pass `true` or `shouldPreserveBitcodeUseListOrder()` explicitly. I left the callers that want to send `false` alone. I'll keep pushing the bit higher until hopefully I can delete the global `cl::opt` entirely. llvm-svn: 234957
2015-04-15 08:10:50 +08:00
ValueEnumerator VE(*M, ShouldPreserveUseListOrder);
add abbrevs for the constants tables. This shrinks it from 4.49755e6 bits to 3.85972e6 bits in kc++ llvm-svn: 36778
2007-05-05 15:36:14 +08:00
// Emit blockinfo, which defines the standard abbreviations etc.
WriteBlockInfo(VE, Stream);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Add code for emitting the attribute groups. This is some initial code for emitting the attribute groups into the bitcode. NOTE: This format *may* change! Do not rely upon the attribute groups' bitcode not changing. llvm-svn: 174845
2013-02-11 07:09:32 +08:00
// Emit information about attribute groups.
WriteAttributeGroupTable(VE, Stream);
trivial scaffolding for param attrs llvm-svn: 36720
2007-05-04 08:44:52 +08:00
// Emit information about parameter attributes.
Large mechanical patch. s/ParamAttr/Attribute/g s/PAList/AttrList/g s/FnAttributeWithIndex/AttributeWithIndex/g s/FnAttr/Attribute/g This sets the stage - to implement function notes as function attributes and - to distinguish between function attributes and return value attributes. This requires corresponding changes in llvm-gcc and clang. llvm-svn: 56622
2008-09-26 05:00:45 +08:00
WriteAttributeTable(VE, Stream);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// Emit information describing all of the types in the module.
WriteTypeTable(VE, Stream);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
IR: Add COMDATs to the IR This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
2014-06-28 02:19:56 +08:00
writeComdats(VE, Stream);
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
// Emit top-level description of module, including target triple, inline asm,
// descriptors for global variables, and function prototype info.
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
uint64_t VSTOffsetPlaceholder = WriteModuleInfo(M, VE, Stream);
Introduce MetadataBase, a base class for MDString and MDNode. Derive MDString directly from MetadataBase. Introduce new bitcode block to hold metadata. llvm-svn: 76759
2009-07-23 01:43:22 +08:00
Derive MDNode from MetadataBase instead of Constant. Emit MDNodes into METADATA_BLOCK in bitcode file. llvm-svn: 76834
2009-07-23 09:07:34 +08:00
// Emit constants.
WriteModuleConstants(VE, Stream);
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
// Emit metadata.
BitcodeWriter: Rename some functions for consistency, NFC To match writeMetadataRecords, writeNamedMetadata and writeMetadataStrings, change: WriteModuleMetadata => writeModuleMetadata WriteFunctionLocalMetadata => writeFunctionMetadata Write##CLASS => write##CLASS The only major change is "FunctionLocal" => "Function". The point is to be less specific, in preparation for emitting normal metadata records inside function metadata blocks (currently we only emit `LocalAsMetadata` there). llvm-svn: 264556
2016-03-28 07:56:04 +08:00
writeModuleMetadata(*M, VE, Stream);
Revert recent bitcode writer patches. llvm-svn: 78053
2009-08-04 13:01:35 +08:00
Write and read metadata attachments. llvm-svn: 82259
2009-09-19 03:26:43 +08:00
// Emit metadata.
rename getHandlerNames to getMDKindNames, simplify its interface and simplify all the clients that use it. llvm-svn: 92224
2009-12-29 04:10:43 +08:00
WriteModuleMetadataStore(M, Stream);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Bitcode: Serialize (and recover) use-list order Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
2014-07-29 05:19:41 +08:00
// Emit module-level use-lists.
uselistorder: Thread bit through ValueEnumerator Canonicalize access to whether to preserve use-list order in bitcode on a `bool` stored in `ValueEnumerator`. Next step, expose this as a `bool` through `WriteBitcodeToFile()`. llvm-svn: 234956
2015-04-15 07:45:11 +08:00
if (VE.shouldPreserveUseListOrder())
Bitcode: Serialize (and recover) use-list order Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
2014-07-29 05:19:41 +08:00
WriteUseListBlock(nullptr, VE, Stream);
Begin adding experimental support for preserving use-list ordering of bitcode files. First, add a new block USELIST_BLOCK to the bitcode format. This is where USELIST_CODE_ENTRYs will be stored. The format of the USELIST_CODE_ENTRYs have not yet been defined. Add support in the BitcodeReader for parsing the USELIST_BLOCK. Part of rdar://9860654 and PR5680. llvm-svn: 146078
2011-12-08 05:44:12 +08:00
[Bitcode][Asm] Teach LLVM to read and write operand bundles. Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
2015-09-25 07:34:52 +08:00
WriteOperandBundleTags(M, Stream);
Enable streaming of bitcode This CL delays reading of function bodies from initial parse until materialization, allowing overlap of compilation with bitcode download. llvm-svn: 149918
2012-02-07 06:30:29 +08:00
// Emit function bodies.
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
DenseMap<const Function *, uint64_t> FunctionToBitcodeIndex;
Enable streaming of bitcode This CL delays reading of function bodies from initial parse until materialization, allowing overlap of compilation with bitcode download. llvm-svn: 149918
2012-02-07 06:30:29 +08:00
for (Module::const_iterator F = M->begin(), E = M->end(); F != E; ++F)
if (!F->isDeclaration())
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
WriteFunction(*F, M, VE, Stream, FunctionToBitcodeIndex);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// Need to write after the above call to WriteFunction which populates
// the summary information in the index.
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
if (Index)
WritePerModuleGlobalValueSummary(M, *Index, VE, Stream);
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
WriteValueSymbolTable(M->getValueSymbolTable(), VE, Stream,
Rename FunctionIndex into GlobalValueIndex to reflect the recent changes (NFC) The index used to contain only Function, but now contains GlobalValue in general. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265230
2016-04-03 01:29:47 +08:00
VSTOffsetPlaceholder, BitcodeStartBit,
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
&FunctionToBitcodeIndex);
Enable streaming of bitcode This CL delays reading of function bodies from initial parse until materialization, allowing overlap of compilation with bitcode download. llvm-svn: 149918
2012-02-07 06:30:29 +08:00
Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
2016-04-01 13:33:11 +08:00
if (GenerateHash) {
writeModuleHash(Stream, Buffer, BlockStartPos);
}
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Stream.ExitBlock();
}
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
/// EmitDarwinBCHeader - If generating a bc file on darwin, we have to emit a
/// header and trailer to make it compatible with the system archiver. To do
/// this we emit the following header, and then emit a trailer that pads the
/// file out to be a multiple of 16 bytes.
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
///
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
/// struct bc_header {
/// uint32_t Magic; // 0x0B17C0DE
/// uint32_t Version; // Version, currently always 0.
/// uint32_t BitcodeOffset; // Offset to traditional bitcode file.
/// uint32_t BitcodeSize; // Size of traditional bitcode file.
/// uint32_t CPUType; // CPU specifier.
/// ... potentially more later ...
/// };
BitstreamWriter: Change primary output buffer to be a SmallVector instead of an std::vector. - Good for 1-2% speedup on writing PCH for Cocoa.h. - Clang side API match to follow shortly, there wasn't an easy way to make this non-breaking. llvm-svn: 151750
2012-03-01 04:31:09 +08:00
static void WriteInt32ToBuffer(uint32_t Value, SmallVectorImpl<char> &Buffer,
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
uint32_t &Position) {
[Bitcode] Replace hand-coded little endian handling with Endian.h functions. No functional change intended. llvm-svn: 239944
2015-06-18 04:55:30 +08:00
support::endian::write32le(&Buffer[Position], Value);
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
Position += 4;
}
BitstreamWriter: Change primary output buffer to be a SmallVector instead of an std::vector. - Good for 1-2% speedup on writing PCH for Cocoa.h. - Clang side API match to follow shortly, there wasn't an easy way to make this non-breaking. llvm-svn: 151750
2012-03-01 04:31:09 +08:00
static void EmitDarwinBCHeaderAndTrailer(SmallVectorImpl<char> &Buffer,
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
const Triple &TT) {
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
unsigned CPUType = ~0U;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Add ARM bitcode file magic. llvm-svn: 96006
2010-02-13 04:13:44 +08:00
// Match x86_64-*, i[3-9]86-*, powerpc-*, powerpc64-*, arm-*, thumb-*,
Also recognize armv6t2-* and armv5te-* triplets. llvm-svn: 96008
2010-02-13 04:39:35 +08:00
// armv[0-9]-*, thumbv[0-9]-*, armv5te-*, or armv6t2-*. The CPUType is a magic
// number from /usr/include/mach/machine.h. It is ok to reproduce the
// specific constants here because they are implicitly part of the Darwin ABI.
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
enum {
DARWIN_CPU_ARCH_ABI64 = 0x01000000,
DARWIN_CPU_TYPE_X86 = 7,
Add ARM bitcode file magic. llvm-svn: 96006
2010-02-13 04:13:44 +08:00
DARWIN_CPU_TYPE_ARM = 12,
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
DARWIN_CPU_TYPE_POWERPC = 18
};
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Update BitcodeWriter to match recent Triple changes. rdar://9603399 llvm-svn: 132959
2011-06-14 09:51:33 +08:00
Triple::ArchType Arch = TT.getArch();
if (Arch == Triple::x86_64)
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
CPUType = DARWIN_CPU_TYPE_X86 | DARWIN_CPU_ARCH_ABI64;
Update BitcodeWriter to match recent Triple changes. rdar://9603399 llvm-svn: 132959
2011-06-14 09:51:33 +08:00
else if (Arch == Triple::x86)
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
CPUType = DARWIN_CPU_TYPE_X86;
Update BitcodeWriter to match recent Triple changes. rdar://9603399 llvm-svn: 132959
2011-06-14 09:51:33 +08:00
else if (Arch == Triple::ppc)
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
CPUType = DARWIN_CPU_TYPE_POWERPC;
Update BitcodeWriter to match recent Triple changes. rdar://9603399 llvm-svn: 132959
2011-06-14 09:51:33 +08:00
else if (Arch == Triple::ppc64)
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
CPUType = DARWIN_CPU_TYPE_POWERPC | DARWIN_CPU_ARCH_ABI64;
Update BitcodeWriter to match recent Triple changes. rdar://9603399 llvm-svn: 132959
2011-06-14 09:51:33 +08:00
else if (Arch == Triple::arm || Arch == Triple::thumb)
Add ARM bitcode file magic. llvm-svn: 96006
2010-02-13 04:13:44 +08:00
CPUType = DARWIN_CPU_TYPE_ARM;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
// Traditional Bitcode starts after header.
[llvm-bcanalyzer] Dump bitcode wrapper header This patch enables llvm-bcanalyzer to print the bitcode wrapper header if the file has one, which is needed to test the changes made in r258627 (bitcode-wrapper-header-armv7m.ll is the test case for r258627). Differential Revision: http://reviews.llvm.org/D16642 llvm-svn: 259162
2016-01-29 13:55:09 +08:00
assert(Buffer.size() >= BWH_HeaderSize &&
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
"Expected header size to be reserved");
[llvm-bcanalyzer] Dump bitcode wrapper header This patch enables llvm-bcanalyzer to print the bitcode wrapper header if the file has one, which is needed to test the changes made in r258627 (bitcode-wrapper-header-armv7m.ll is the test case for r258627). Differential Revision: http://reviews.llvm.org/D16642 llvm-svn: 259162
2016-01-29 13:55:09 +08:00
unsigned BCOffset = BWH_HeaderSize;
unsigned BCSize = Buffer.size() - BWH_HeaderSize;
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
// Write the magic and version.
unsigned Position = 0;
WriteInt32ToBuffer(0x0B17C0DE , Buffer, Position);
WriteInt32ToBuffer(0 , Buffer, Position); // Version.
WriteInt32ToBuffer(BCOffset , Buffer, Position);
WriteInt32ToBuffer(BCSize , Buffer, Position);
WriteInt32ToBuffer(CPUType , Buffer, Position);
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
// If the file is not a multiple of 16 bytes, insert dummy padding.
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
while (Buffer.size() & 15)
Buffer.push_back(0);
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
}
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
/// Helper to write the header common to all bitcode files.
static void WriteBitcodeHeader(BitstreamWriter &Stream) {
// Emit the file header.
Stream.Emit((unsigned)'B', 8);
Stream.Emit((unsigned)'C', 8);
Stream.Emit(0x0, 4);
Stream.Emit(0xC, 4);
Stream.Emit(0xE, 4);
Stream.Emit(0xD, 4);
}
Add raw_ostream versions of WriteBitcodeToFile and BitcodeWriterPass. - The old versions are still hanging around, but should be migrated away from. llvm-svn: 57989
2008-10-23 01:39:14 +08:00
/// WriteBitcodeToFile - Write the specified module to the specified output
/// stream.
uselistorder: Pull the bit through WriteToBitcodFile() Change the callers of `WriteToBitcodeFile()` to pass `true` or `shouldPreserveBitcodeUseListOrder()` explicitly. I left the callers that want to send `false` alone. I'll keep pushing the bit higher until hopefully I can delete the global `cl::opt` entirely. llvm-svn: 234957
2015-04-15 08:10:50 +08:00
void llvm::WriteBitcodeToFile(const Module *M, raw_ostream &Out,
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
bool ShouldPreserveUseListOrder,
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
const ModuleSummaryIndex *Index,
bool GenerateHash) {
Since this SmallVector immediately grows on the next line, don't waste stack space. SmallVector is still needed due to existing APIs growing their arguments llvm-svn: 169157
2012-12-04 05:29:36 +08:00
SmallVector<char, 0> Buffer;
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
Buffer.reserve(256*1024);
Add support for writing LLVM IR to a specified BitstreamWriter. Patch by Lukasz Janyst! llvm-svn: 61251
2008-12-20 02:37:59 +08:00
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
// If this is darwin or another generic macho target, reserve space for the
// header.
Update BitcodeWriter to match recent Triple changes. rdar://9603399 llvm-svn: 132959
2011-06-14 09:51:33 +08:00
Triple TT(M->getTargetTriple());
[Bitcode] Insert the darwin wrapper at the beginning of a file when the target is macho. It looks like the check for macho was accidentally dropped in r132959. I don't have a test case, but I'll add one if anyone knows how this can be tested. llvm-svn: 258627
2016-01-24 00:02:10 +08:00
if (TT.isOSDarwin() || TT.isOSBinFormatMachO())
[llvm-bcanalyzer] Dump bitcode wrapper header This patch enables llvm-bcanalyzer to print the bitcode wrapper header if the file has one, which is needed to test the changes made in r258627 (bitcode-wrapper-header-armv7m.ll is the test case for r258627). Differential Revision: http://reviews.llvm.org/D16642 llvm-svn: 259162
2016-01-29 13:55:09 +08:00
Buffer.insert(Buffer.begin(), BWH_HeaderSize, 0);
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
// Emit the module into the buffer.
{
BitstreamWriter Stream(Buffer);
Restore "Function bitcode index in Value Symbol Table and lazy reading support" This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
2015-09-18 04:12:00 +08:00
// Save the start bit of the actual bitcode, in case there is space
// saved at the start for the darwin header above. The reader stream
// will start at the bitcode, and we need the offset of the VST
// to line up.
uint64_t BitcodeStartBit = Stream.GetCurrentBitNo();
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
// Emit the file header.
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
WriteBitcodeHeader(Stream);
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
Add an (optional) identification block in the bitcode Processing bitcode from a different LLVM version can lead to unexpected behavior. The LLVM project guarantees autoupdating bitcode from a previous minor revision for the same major, but can't make any promise when reading bitcode generated from a either a non-released LLVM, a vendor toolchain, or a "future" LLVM release. This patch aims at being more user-friendly and allows a bitcode produce to emit an optional block at the beginning of the bitcode that will contains an opaque string intended to describe the bitcode producer information. The bitcode reader will dump this information alongside any error it reports. The optional block also includes an "epoch" number, monotonically increasing when incompatible changes are made to the bitcode. The reader will reject bitcode whose epoch is different from the one expected. Differential Revision: http://reviews.llvm.org/D13666 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 251325
2015-10-27 02:37:00 +08:00
WriteIdentificationBlock(M, Stream);
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
// Emit the module.
[ThinLTO] Move summary computation from BitcodeWriter to new pass Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
2016-04-11 21:58:45 +08:00
WriteModule(M, Stream, ShouldPreserveUseListOrder, BitcodeStartBit, Index,
GenerateHash, Buffer);
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
}
Add a little wrapper header that is put around bc files when emitting bc files for modules with a target triple that indicates they are for darwin. The reader unconditionally handles this, and the writer could turn this on for more targets if we care. This change has two benefits for darwin: 1) it allows us to encode the cpu type of the file in an easy to read place that doesn't require decoding the bc file. 2) it works around a bug (IMO) in darwin's AR where it is incapable of handling files that are not a multiple of 8 bytes long. BC files are only guaranteed to be multiples of 4 bytes long. llvm-svn: 53275
2008-07-09 13:14:23 +08:00
[Bitcode] Insert the darwin wrapper at the beginning of a file when the target is macho. It looks like the check for macho was accidentally dropped in r132959. I don't have a test case, but I'll add one if anyone knows how this can be tested. llvm-svn: 258627
2016-01-24 00:02:10 +08:00
if (TT.isOSDarwin() || TT.isOSBinFormatMachO())
BitcodeWriter: Expose less implementation details -- make BackpatchWord private and remove getBuffer(). llvm-svn: 151748
2012-03-01 04:31:01 +08:00
EmitDarwinBCHeaderAndTrailer(Buffer, TT);
// Write the generated bitstream to "Out".
Out.write((char*)&Buffer.front(), Buffer.size());
Initial support for writing bitcode files. This currently only writes types, the type symtab, and global/function protos, and is missing the important size optimization, but it is a place to start. llvm-svn: 36331
2007-04-22 14:24:45 +08:00
}
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// Write the specified module summary index to the given raw output stream,
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// where it will be written in a new bitcode block. This is used when
// writing the combined index file for ThinLTO.
[ThinLTO] Renaming of function index to module summary index (NFC) (Resubmitting after fixing missing file issue) With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes. A companion clang patch will immediately succeed this patch to reflect this renaming. llvm-svn: 263513
2016-03-15 08:04:37 +08:00
void llvm::WriteIndexToFile(const ModuleSummaryIndex &Index, raw_ostream &Out) {
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
SmallVector<char, 0> Buffer;
Buffer.reserve(256 * 1024);
BitstreamWriter Stream(Buffer);
// Emit the bitcode header.
WriteBitcodeHeader(Stream);
Stream.EnterSubblock(bitc::MODULE_BLOCK_ID, 3);
SmallVector<unsigned, 1> Vals;
unsigned CurVersion = 1;
Vals.push_back(CurVersion);
Stream.EmitRecord(bitc::MODULE_CODE_VERSION, Vals);
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// If we have a VST, write the VSTOFFSET record placeholder and record
// its offset.
uint64_t VSTOffsetPlaceholder = WriteValueSymbolTableForwardDecl(Stream);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// Write the module paths in the combined index.
WriteModStrings(Index, Stream);
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
// Assign unique value ids to all functions in the index for use
// in writing out the call graph edges. Save the mapping from GUID
// to the new global value id to use when writing those edges, which
// are currently saved in the index in terms of GUID.
Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC) Summary: This should make the code more readable, especially all the map declarations. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18721 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265215
2016-04-02 13:07:53 +08:00
std::map<GlobalValue::GUID, unsigned> GUIDToValueIdMap;
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
unsigned GlobalValueId = 0;
for (auto &II : Index)
GUIDToValueIdMap[II.first] = ++GlobalValueId;
// Write the summary combined index records.
WriteCombinedGlobalValueSummary(Index, Stream, GUIDToValueIdMap,
GlobalValueId);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
// Need a special VST writer for the combined index (we don't have a
// real VST and real values when this is invoked).
[ThinLTO] Support for reference graph in per-module and combined summary. Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
2016-03-12 02:52:24 +08:00
WriteCombinedValueSymbolTable(Index, Stream, GUIDToValueIdMap,
VSTOffsetPlaceholder);
Support for function summary index bitcode sections and files. Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
2015-10-04 22:33:43 +08:00
Stream.ExitBlock();
Out.write((char *)&Buffer.front(), Buffer.size());
}