summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
...
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-062-24/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* IR: Introduce ConstantAggregate, NFCDuncan P. N. Exon Smith2016-04-051-2/+1
| | | | | | | | | | | | 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
* [IFUNC] Use GlobalIndirectSymbol when aliases and ifuncs have something similarDmitry Polukhin2016-04-051-19/+26
| | | | | | | | | | | Second part extracted from http://reviews.llvm.org/D15525 Use GlobalIndirectSymbol in all cases when aliases and ifuncs have something in common. Differential Revision: http://reviews.llvm.org/D18754 llvm-svn: 265382
* [ThinLTO] Refactor some common code into getGlobalValueInfo method (NFC)Teresa Johnson2016-04-051-12/+2
| | | | | | | | Refactor common code that queries the ModuleSummaryIndex for a value's GlobalValueInfo struct into getGlobalValueInfo helper methods, which will also be used by D18763. llvm-svn: 265370
* [ThinLTO] Add option to dump value name to GUID mappingTeresa Johnson2016-04-041-5/+17
| | | | | | | | | | | | | | | Summary: Useful for debugging since we lose this correlation after the permodule summary/VST is read and until we later materialize source modules in the function importer. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18555 llvm-svn: 265327
* Rename FunctionIndex into GlobalValueIndex to reflect the recent changes (NFC)Mehdi Amini2016-04-021-21/+23
| | | | | | | | The index used to contain only Function, but now contains GlobalValue in general. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265230
* Bitcode: Try to emit metadata in function blocksDuncan P. N. Exon Smith2016-04-023-39/+231
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix doxygen comments from r265224, NFCDuncan P. N. Exon Smith2016-04-021-2/+2
| | | | llvm-svn: 265225
* BitcodeWriter: Further unify function metadata, NFCDuncan P. N. Exon Smith2016-04-023-12/+17
| | | | | | | | | | | | | 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
* BitcodeReader: Check for unresolved function metadataDuncan P. N. Exon Smith2016-04-021-2/+12
| | | | | | | | | | | | | | A follow-up commit will start using function metadata blocks more heavily. This commit adds some error checking to confirm that metadata is fully resolved before (and after) materializing each function. This is valid even when reading very old bitcode from before the metadata/value split. The global metadata block always came before the function blocks. However, in case somehow this causes a regression (i.e., an old LLVM did produce such bitcode after all) I'm committing separately. llvm-svn: 265223
* Reverts r265219.Mehdi Amini2016-04-021-15/+15
| | | | | | | Unintentionally commited... time to call the day off! From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265221
* wipMehdi Amini2016-04-021-15/+15
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265219
* Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC)Mehdi Amini2016-04-022-21/+22
| | | | | | | | | | | | | 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
* Swift Calling Convention: add swifterror attribute.Manman Ren2016-04-012-5/+10
| | | | | | | | | | | | 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
* Add a module Hash in the bitcode and the combined index, implementing a kind ↵Mehdi Amini2016-04-012-19/+109
| | | | | | | | | | | | | 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
* Revert "Add support for computing SHA1 in LLVM"Mehdi Amini2016-04-012-109/+19
| | | | | | | | This reverts commit r265096, r265095, and r265094. Windows build is broken, and the validation does not pass. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265102
* Add a module Hash in the bitcode and the combined index, implementing a kind ↵Mehdi Amini2016-04-012-19/+109
| | | | | | | | | | | of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265095
* BitcodeReader: Fix weird whitespace, NFCDuncan P. N. Exon Smith2016-03-301-1/+1
| | | | llvm-svn: 264822
* [ThinLTO] Remove post-pass metadata linking supportTeresa Johnson2016-03-291-38/+0
| | | | | | | | | | | Since we have moved to a model where functions are imported in bulk from each source module after making summary-based importing decisions, there is no longer a need to link metadata as a postpass, and all users have been removed. This essentially reverts r255909 and follow-on fixes. llvm-svn: 264763
* Swift Calling Convention: add swiftself attribute.Manman Ren2016-03-292-0/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D17866 llvm-svn: 264754
* BitcodeReader: Allow METADATA_STRINGS to only have !""Duncan P. N. Exon Smith2016-03-291-1/+1
| | | | | | | Support parsing a METADATA_STRINGS record that only has a single piece of metadata, !"". Fixes a corner case in r264551. llvm-svn: 264699
* BitcodeWriter: Replace dead code with an assertion, NFCDuncan P. N. Exon Smith2016-03-281-7/+1
| | | | | | | The caller of ValueEnumerator::EnumerateOperandType never sends in metadata. Assert that, and remove the unnecessary logic. llvm-svn: 264558
* BitcodeWriter: Reuse writeMetadataRecords, NFCDuncan P. N. Exon Smith2016-03-271-5/+2
| | | | | | | | 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
* BitcodeWriter: Rename some functions for consistency, NFCDuncan P. N. Exon Smith2016-03-271-35/+34
| | | | | | | | | | | | | | | | 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
* BitcodeWriter: Split out writeMetadataRecords, NFCDuncan P. N. Exon Smith2016-03-271-9/+17
| | | | | | | Besides being a nice cleanup, this is preparation for reusing the code in function metadata blocks. llvm-svn: 264555
* BitcodeWriter: Restructure WriteFunctionLocalMetadata, NFCDuncan P. N. Exon Smith2016-03-271-11/+9
| | | | | | Use an early return to simplify logic. llvm-svn: 264554
* BitcodeWriter: Simplify tracking of function-local metadata, NFCDuncan P. N. Exon Smith2016-03-273-12/+5
| | | | | | | | We don't really need a separate vector here; instead, point at a range inside the main MDs array. This matches how r264551 references the ranges of strings and non-strings. llvm-svn: 264552
* Reapply ~"Bitcode: Collect all MDString records into a single blob"Duncan P. N. Exon Smith2016-03-274-33/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support: Implement StreamingMemoryObject::getPointerDuncan P. N. Exon Smith2016-03-271-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The implementation is fairly obvious. This is preparation for using some blobs in bitcode. For clarity (and perhaps future-proofing?), I moved the call to JumpToBit in BitstreamCursor::readRecord ahead of calling MemoryObject::getPointer, since JumpToBit can theoretically (a) read bytes, which (b) invalidates the blob pointer. This isn't strictly necessary the two memory objects we have: - The return of RawMemoryObject::getPointer is valid until the memory object is destroyed. - StreamingMemoryObject::getPointer is valid until the next chunk is read from the stream. Since the JumpToBit call is only going ahead to a word boundary, we'll never load another chunk. However, reordering makes it clear by inspection that the blob returned by BitstreamCursor::readRecord will be valid. I added some tests for StreamingMemoryObject::getPointer and BitstreamCursor::readRecord. llvm-svn: 264549
* Bitcode: Add SimpleBitstreamCursor::getPointerToByte, etc.Duncan P. N. Exon Smith2016-03-271-3/+1
| | | | | | | | | | | | | | | Add API to SimpleBitstreamCursor to allow users to translate between byte addresses and pointers. - jumpToPointer: move the bit position to a particular pointer. - getPointerToByte: get the pointer for a particular byte. - getPointerToBit: get the pointer for the byte of the current bit. - getCurrentByteNo: convenience function for assertions and tests. Mainly adds unit tests (getPointerToBit/Byte already has a use), but also preparation for eventually using jumpToPointer. llvm-svn: 264546
* Bitcode: Split out SimpleBitstreamCursorDuncan P. N. Exon Smith2016-03-271-9/+13
| | | | | | | | | | | Split out SimpleBitstreamCursor from BitstreamCursor, which is a lower-level cursor with no knowledge of bitcode blocks, abbreviations, or records. It just knows how to read bits and navigate the stream. This is mainly organizational, to separate the API for manipulating raw bits from that for bitcode concepts like Record and Block. llvm-svn: 264545
* Rename ModuleSummaryIndex::modPathStringEntries() into modulePaths()Mehdi Amini2016-03-261-1/+1
| | | | | | | It now return the map instead of an iterator. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 264489
* [ThinLTO] Rename edges() to calls() for clarity (NFC)Teresa Johnson2016-03-251-3/+3
| | | | | | Helps distinguish from refs() which iterates over non-call references. llvm-svn: 264445
* Revert "Bitcode: Collect all MDString records into a single blob"Duncan P. N. Exon Smith2016-03-255-129/+34
| | | | | | | This reverts commit r264409 since it failed to bootstrap: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/ llvm-svn: 264410
* Bitcode: Collect all MDString records into a single blobDuncan P. N. Exon Smith2016-03-255-34/+129
| | | | | | | | | | | | | | | | | | | | | | | Optimize output of MDStrings in bitcode. This emits them in big blocks (currently 1024) in a pair of records: - BULK_STRING_SIZES: the sizes of the strings in the block, and - BULK_STRING_DATA: a single blob, which is the concatenation of all the strings. 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. I needed to add support for blobs to streaming input to get the test suite passing. - StreamingMemoryObject::getPointer reads ahead and returns the address of the blob. - To avoid a possible reallocation of StreamingMemoryObject::Bytes, BitstreamCursor::readRecord needs to move the call to JumpToEnd forward so that getPointer is the last bitstream operation. llvm-svn: 264409
* Bitcode: Use std::stable_partition for reproducible buildsDuncan P. N. Exon Smith2016-03-251-2/+2
| | | | | | | Caught by inspection while working on partitioning metadata. It's nice to produce the same bitcode if you run the compiler twice. llvm-svn: 264381
* Bitcode: Stop using MODULE_CODE_METADATA_VALUESDuncan P. N. Exon Smith2016-03-252-67/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The motivation for MODULE_CODE_METADATA_VALUES was to enable an -flto=thin scheme where: 1. First, one function is cherry-picked from a bitcode file. 2. Later, another function is cherry-picked. 3. Later, ... 4. Finally, the metadata needed by all the previous functions is loaded. This was abandoned in favour of: 1. Calculate the superset of functions needed from a Module. 2. Link all functions at once. Delayed metadata reading no longer serves a purpose. It also adds a few complication, since we can't count on metadata being properly parsed when exiting the BitcodeReader. After discussing with Teresa, we agreed to remove it. The code that depended on this was removed/updated in r264326. llvm-svn: 264378
* IR: Stop upgrading !llvm.loop attachments via MDStringDuncan P. N. Exon Smith2016-03-251-2/+13
| | | | | | | | | | | | Remove logic to upgrade !llvm.loop by changing the MDString tag directly. This old logic would check (and change) arbitrary strings that had nothing to do with loop metadata. Instead, check !llvm.loop attachments directly, and change which strings get attached. Rather than updating the assembly-based upgrade, drop it entirely. It has been quite a while since we supported upgrading textual IR. llvm-svn: 264373
* BitcodeWriter: Move abbreviation for GenericDINode; almost NFCDuncan P. N. Exon Smith2016-03-243-21/+19
| | | | | | | | | | | | 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
* BitcodeWriter: Move abbreviation for DILocation; almost NFCDuncan P. N. Exon Smith2016-03-243-20/+18
| | | | | | | | | | | 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
* BitcodeWriter: Split out named metadata; almost NFCDuncan P. N. Exon Smith2016-03-241-25/+31
| | | | | | | | | | | | 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
* Bitcode: Module* -> Module&, NFCDuncan P. N. Exon Smith2016-03-241-5/+5
| | | | llvm-svn: 264299
* Add getBlockProfileCount method to BlockFrequencyInfoEaswaran Raman2016-03-231-7/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D18233 llvm-svn: 264179
* Bitcode: Error out instead of crashing on corrupt metadataJustin Bogner2016-03-171-20/+38
| | | | | | | | | | | | | | | | | I hit a crash in the bitcode reader on some corrupt input where an MDString had somehow been attached to an instruction instead of an MDNode. This input is pretty bogus, but we shouldn't be crashing on bad input here. This change adds error handling in all of the places where we currently have unchecked casts from Metadata to MDNode, which means we'll error out instead of crashing for that sort of input. Unfortunately, I don't have tests. Hitting this requires flipping bits in the input bitcode, and committing corrupt binary files to catch these cases is a bit too opaque and unmaintainable. llvm-svn: 263742
* Upgrade TBAA *before* upgrading intrinsicsChris Bieneman2016-03-161-3/+5
| | | | | | | | | | | | Summary: If TBAA is on an intrinsic and it gets upgraded and drops the TBAA we hit an odd assert. We should just upgrade the TBAA first because it doesn't have side-effects. Reviewers: reames, apilipenko, manmanren Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18229 llvm-svn: 263673
* [ThinLTO] Record all global variable defs in the summaryTeresa Johnson2016-03-151-11/+10
| | | | | | | 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
* BitcodeWriter dyn_cast cleanup for r263275 (NFC)Teresa Johnson2016-03-151-8/+5
| | | | | | | Address review suggestions from dblaikie: change a few dyn_cast to cast and fold a cast into if condition. llvm-svn: 263526
* Move global ID computation from Function to GlobalValue (NFC)Teresa Johnson2016-03-151-6/+7
| | | | | | | | Since the static getGlobalIdentifier and getGUID methods are now called for global values other than functions, reflect that by moving these methods to the GlobalValue class. llvm-svn: 263524
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-153-83/+79
| | | | | | | | | | | | | | | (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
* Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"Teresa Johnson2016-03-143-79/+83
| | | | | | This reverts commit r263490. Missed a file. llvm-svn: 263493
OpenPOWER on IntegriCloud