summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
* Remove "ExportingModule" from ThinLTO Index (NFC)Mehdi Amini2015-12-031-3/+2
| | | | | | | | | | | | | | | | | | | | | There is no real reason the index has to have the concept of an exporting Module. We should be able to have one single unique instance of the Index, and it should be read-only after creation for the whole ThinLTO processing. The linker plugin should be able to process multiple modules (in parallel or in sequence) with the same index. The only reason the ExportingModule was present seems to be to implement hasExportedFunctions() that is used by the Module linker to decide what to do with the current Module. For now I replaced it with a query to the map of Modules path to see if this module was declared in the Index and consider that if it is the case then it is probably exporting function. On the long term the Linker interface needs to evolve and this call should not be needed anymore. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 254581
* [ThinLTO] Handle bitcode without function summary sections gracefullyTeresa Johnson2015-11-211-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Several fixes to the handling of bitcode files without function summary sections so that they are skipped during ThinLTO processing in llvm-lto and the gold plugin when appropriate instead of aborting. 1 Don't assert when trying to add a FunctionInfo that doesn't have a summary attached. 2 Skip FunctionInfo structures that don't have attached function summary sections when trying to create the combined function summary. 3 In both llvm-lto and gold-plugin, check whether a bitcode file has a function summary section before trying to parse the index, and skip the bitcode file if it does not. 4 Fix hasFunctionSummaryInMemBuffer in BitcodeReader, which had a bug where we returned to early while looking for the summary section. Also added llvm-lto and gold-plugin based tests for cases where we don't have function summaries in the bitcode file. I verified that either the first couple fixes described above are enough to avoid the crashes, or fixes 1,3,4. But have combined them all here for added robustness. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14903 llvm-svn: 253796
* Move new assert to correct locationTeresa Johnson2015-11-211-3/+3
| | | | | | | | | This assert was meant to execute at the end of parseMetadata, but we return early and never reach the end of the function. Caught by a compile-time warning since the function doesn't return a value from that location. llvm-svn: 253762
* [ThinLTO] Add MODULE_CODE_METADATA_VALUES recordTeresa Johnson2015-11-203-6/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Do not require a Context to extract the FunctionIndex from Bitcode (NFC)Mehdi Amini2015-11-191-23/+16
| | | | | | | | | | The LLVMContext was only used for Diagnostic. Pass a DiagnosticHandler instead. Differential Revision: http://reviews.llvm.org/D14794 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 253540
* [OperandBundles] Tighten OperandBundleDef's interface; NFCSanjoy Das2015-11-181-4/+2
| | | | llvm-svn: 253446
* Use a different block id for block of metadata kind recordsTeresa Johnson2015-11-152-9/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* use range-based for loop; NFCISanjay Patel2015-11-131-4/+3
| | | | llvm-svn: 253048
* [OperandBundles] Identify operand bundles with both their names and IDsSanjoy Das2015-11-101-1/+1
| | | | | | | No code uses this functionality yet. This change just exposes information / structure that was already present. llvm-svn: 252644
* Add a method to the BitcodeReader to parse only the identification blockMehdi Amini2015-11-091-0/+49
| | | | | | | | | | | Summary: Mimic parseTriple(); and exposes it to LTOModule.cpp Reviewers: dexonsmith, rafael Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 252442
* [Bitcode] Add enums for call instruction markers and flags. NFC.Akira Hatanaka2015-11-072-8/+10
| | | | | | | | | | 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
* [OperandBundles] Rename accessor, NFCSanjoy Das2015-11-071-1/+1
| | | | | | Rename getOperandBundle to getOperandBundleAt since that's more obvious. llvm-svn: 252388
* Add 'notail' marker for call instructions.Akira Hatanaka2015-11-062-1/+4
| | | | | | | | | | | | This marker prevents optimization passes from adding 'tail' or 'musttail' markers to a call. Is is used to prevent tail call optimization from being performed on the call. rdar://problem/22667622 Differential Revision: http://reviews.llvm.org/D12923 llvm-svn: 252368
* Add a new attribute: norecurseJames Molloy2015-11-062-0/+4
| | | | | | 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
* DI: Reverse direction of subprogram -> function edge.Peter Collingbourne2015-11-052-15/+35
| | | | | | | | | | | | | | | | | | | | | | | Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
* Fix Abbrev emission in WriteIdentificationBlockMehdi Amini2015-11-051-1/+2
| | | | | | | This Abbrev was not emitted and basically unused, just leacking there. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 252110
* Error out when faced with value names containing '\0'Filipe Cabecinhas2015-11-041-1/+4
| | | | | | Bug found with afl-fuzz. llvm-svn: 252048
* Don't assert if materializing before seeing any function bodiesFilipe Cabecinhas2015-11-031-1/+3
| | | | | | | | | This assert was reachable from user input. A minimized test case (no FUNCTION_BLOCK_ID record) is attached. Bug found with afl-fuzz llvm-svn: 251910
* Don't use Twine objects after their lifetimes end.Filipe Cabecinhas2015-11-031-6/+6
| | | | | | | | No test, since it would depend on what the compiler can optimize/reuse. My next commit made this bug visible on Linux Release compiles with some versions of gcc. llvm-svn: 251909
* Restore "Support for ThinLTO function importing and symbol linking."Teresa Johnson2015-11-031-2/+2
| | | | | | | This restores commit r251837, with the new library dependence added to llvm-link/Makefile to address bot failures. llvm-svn: 251866
* Revert "Support for ThinLTO function importing and symbol linking."Teresa Johnson2015-11-021-2/+2
| | | | | | | | | | | | | | | | | | | | This reverts commit r251837, due to a number of bot failures of the form: /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined reference to 'llvm::object::FunctionIndexObjectFile::create(llvm::MemoryBufferRef, llvm::LLVMContext&, llvm::Module const*, bool)' /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined reference to 'llvm::object::FunctionIndexObjectFile::takeIndex()' I'm not sure why these are happening - I added Object to the requred libraries in tools/llvm-link/LLVMBuild.txt and the LLVM_LINK_COMPONENTS in tools/llvm-link/CMakeLists.txt. Confirmed for my build that these symbols come out of libLLVMObject.a. What am I missing? llvm-svn: 251841
* Support for ThinLTO function importing and symbol linking.Teresa Johnson2015-11-021-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Support for necessary linkage changes and symbol renaming during ThinLTO function importing. Also includes llvm-link support for manually importing functions and associated llvm-link based tests. Note that this does not include support for intelligently importing metadata, which is currently imported duplicate times. That support will be in the follow-on patch, and currently is ignored by the tests. Reviewers: dexonsmith, joker.eph, davidxl Subscribers: tobiasvk, tejohnson, llvm-commits Differential Revision: http://reviews.llvm.org/D13515 llvm-svn: 251837
* Clang format a few prior patches (NFC)Teresa Johnson2015-11-022-215/+243
| | | | | | | I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
* Revert "Don't assert if materializing before seeing any function bodies"Filipe Cabecinhas2015-10-301-3/+1
| | | | | | This reverts r251667 since it broke the bots. llvm-svn: 251671
* Don't assert if materializing before seeing any function bodiesFilipe Cabecinhas2015-10-291-1/+3
| | | | | | | | | This assert was reachable from user input. A minimized test case (no FUNCTION_BLOCK_ID record) is attached. Bug found with afl-fuzz llvm-svn: 251667
* Bitcode: Fix more unsigned integer overflow bugs.Peter Collingbourne2015-10-271-3/+3
| | | | llvm-svn: 251464
* [IR] Limit bits used for CallingConv::ID, update testsVedant Kumar2015-10-271-4/+7
| | | | | | | | | | | | Use 10 bits to represent calling convention ID's instead of 13, and update the bitcode compatibility tests accordingly. We now error-out in the bitcode reader when we see bad calling conv ID's. Thanks to rnk and dexonsmith for feedback! Differential Revision: http://reviews.llvm.org/D13826 llvm-svn: 251452
* Use Twin instead of std::to_string.Oleksiy Vyalov2015-10-261-4/+3
| | | | | | http://reviews.llvm.org/D14095 llvm-svn: 251365
* Add an (optional) identification block in the bitcodeMehdi Amini2015-10-262-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Silence Visual C++ warning in function summary parsing code (NFC)Teresa Johnson2015-10-211-0/+1
| | | | llvm-svn: 250929
* Pass FunctionInfoIndex by reference to WriteFunctionSummaryToFile (NFC)Teresa Johnson2015-10-191-8/+8
| | | | | | Implemented suggestion by dblakie in review for r250704. llvm-svn: 250723
* BitcodeReader: Remove ilist iterator implicit conversions, NFCDuncan P. N. Exon Smith2015-10-131-6/+5
| | | | | | | Get LLVMBitReader building without relying on `ilist_iterator` implicit conversions. llvm-svn: 250181
* BitcodeWriter: Stop using implicit ilist iterator conversion, NFCDuncan P. N. Exon Smith2015-10-132-30/+23
| | | | | | | | | | 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
* Fix PR25101 - Handle anonymous functions without VST entriesTeresa Johnson2015-10-101-28/+73
| | | | | | | | | | | | | | | | Summary: The change to use the VST function entries for lazy deserialization did not handle the case of anonymous functions without aliases. In that case we must fall back to scanning the function blocks as there is no VST entry. Reviewers: dexonsmith, joker.eph, davidxl Subscribers: tstellarAMD, llvm-commits Differential Revision: http://reviews.llvm.org/D13596 llvm-svn: 249947
* Fix combined function index abbrev (NFC)Teresa Johnson2015-10-081-3/+0
| | | | | | | | | | | | Removed an unused abbrev op in the VST_CODE_COMBINED_FNENTRY abbrev. I noticed while writing/testing an array string dumper for llvm-bcanalyze that the combined function's VST entry abbrevs contained an old field that I am not using. Everything was working fine since the bitcode writer and reader were in sync on how the record fields were actually being set up and interpreted. llvm-svn: 249691
* Make sure the CastInst is valid before trying to create itFilipe Cabecinhas2015-10-061-1/+4
| | | | | | Bug found with afl-fuzz. llvm-svn: 249396
* Remove unused private field introduced by r249270.Teresa Johnson2015-10-041-5/+2
| | | | llvm-svn: 249277
* Support for function summary index bitcode sections and files.Teresa Johnson2015-10-043-41/+898
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Bitcode][Asm] Teach LLVM to read and write operand bundles.Sanjoy Das2015-09-242-2/+135
| | | | | | | | | | | | | | | | | | 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
* Silencing a -Wsign-compare warning; NFC.Aaron Ballman2015-09-181-1/+1
| | | | llvm-svn: 247986
* [opaque pointer types] Add an explicit pointee type to alias records in the IRDavid Blaikie2015-09-172-24/+41
| | | | | | | | | | 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
* Restore "Function bitcode index in Value Symbol Table and lazy reading support"Teresa Johnson2015-09-172-40/+306
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Function bitcode index in Value Symbol Table and lazy reading support"Teresa Johnson2015-09-172-299/+40
| | | | | | | | | | Temporarily revert to fix some buildbot issues. One is a minor issue with a variable unused in NDEBUG mode. More concerning are some test failures on win7 that I need to dig into. This reverts commit 4e66a74543459832cfd571db42b4543580ae1d1d. llvm-svn: 247898
* Function bitcode index in Value Symbol Table and lazy reading supportTeresa Johnson2015-09-172-40/+299
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 247894
* Refactor string encoding checks in BitcodeWriter (NFC)Teresa Johnson2015-09-171-14/+23
| | | | llvm-svn: 247891
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-1/+2
| | | | | | | | | | | | | | | | | rather than decomposing it into pointee type + address space" This was a flawed change - it just caused the getElementType call to be deferred until later, when we really need to remove it. Now that the IR for GlobalAliases has been updated, the root cause is addressed that way instead and this change is no longer needed (and in fact gets in the way - because we want to pass the pointee type directly down further). Follow up patches to push this through GlobalValue, bitcode format, etc, will come along soon. This reverts commit 236160. llvm-svn: 247585
* [WinEH] Add cleanupendpad instructionJoseph Tremoulet2015-09-032-0/+27
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add a `cleanupendpad` instruction, used to mark exceptional exits out of cleanups (for languages/targets that can abort a cleanup with another exception). The `cleanupendpad` instruction is similar to the `catchendpad` instruction in that it is an EH pad which is the target of unwind edges in the handler and which itself has an unwind edge to the next EH action. The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad` argument indicating which cleanup it exits. The unwind successors of a `cleanuppad`'s `cleanupendpad`s must agree with each other and with its `cleanupret`s. Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12433 llvm-svn: 246751
* [BitcodeReader] Ensure we can read constant vector selects with an i1 conditionFilipe Cabecinhas2015-08-311-4/+5
| | | | | | | | | | | | | | | Summary: Constant vectors weren't allowed to have an i1 condition in the BitcodeReader. Make sure we have the same restrictions that are documented, not more. Reviewers: nlewycky, rafael, kschimpf Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12440 llvm-svn: 246459
* Change comment to verify commit accesss.Karl Schimpf2015-08-311-1/+1
| | | | llvm-svn: 246451
* DI: Require subprogram definitions to be distinctDuncan P. N. Exon Smith2015-08-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | As a follow-up to r246098, require `DISubprogram` definitions (`isDefinition: true`) to be 'distinct'. Specifically, add an assembler check, a verifier check, and bitcode upgrading logic to combat testcase bitrot after the `DIBuilder` change. While working on the testcases, I realized that test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its purpose was to check for a corner case in PR22792 where two subprogram definitions match exactly and share the same metadata node. The new verifier check, requiring that subprogram definitions are 'distinct', precludes that possibility. I updated almost all the IR with the following script: git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' | grep -v test/Bitcode | xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/' Likely some variant of would work for out-of-tree testcases. llvm-svn: 246327
OpenPOWER on IntegriCloud