summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* IR: Enable debug info type ODR uniquing for forward declsDuncan P. N. Exon Smith2016-04-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Add a new method, DICompositeType::buildODRType, that will create or mutate the DICompositeType for a given ODR identifier, and use it in LLParser and BitcodeReader instead of DICompositeType::getODRType. The logic is as follows: - If there's no node, create one with the given arguments. - Else, if the current node is a forward declaration and the new arguments would create a definition, mutate the node to match the new arguments. - Else, return the old node. This adds a missing feature supported by the current DITypeIdentifierMap (which I'm slowly making redudant). The only remaining difference is that the DITypeIdentifierMap has a "the-last-one-wins" rule, whereas DICompositeType::buildODRType has a "the-first-one-wins" rule. For now I'm leaving behind DICompositeType::getODRType since it has obvious, low-level semantics that are convenient for unit testing. llvm-svn: 266786
* IR: getOrInsertODRUniquedType => DICompositeType::getODRType, NFCDuncan P. N. Exon Smith2016-04-191-16/+27
| | | | | | | | | | | | | | Lift the API for debug info ODR type uniquing up a layer. Instead of clients managing the map directly on the LLVMContext, add a static method to DICompositeType called getODRType and handle the map in the background. Also adds DICompositeType::getODRTypeIfExists, so far just for convenience in the unit tests. This simplifies the logic in LLParser and BitcodeReader. Because of argument spam there are actually a few more lines of code now; I'll see if I come up with a reasonable way to clean that up. llvm-svn: 266742
* IR: Require DICompositeType for ODR uniquing type mapDuncan P. N. Exon Smith2016-04-191-2/+2
| | | | | | | | Tighten up the API for debug info ODR type uniquing in LLVMContext. The only reason to allow other DIType subclasses is to make the unit tests prettier :/. llvm-svn: 266737
* IR: Rename API for enabling ODR uniquing of DITypes, NFCDuncan P. N. Exon Smith2016-04-191-1/+1
| | | | | | | | | | | As per David's review, rename everything in the new API for ODR type uniquing of debug info. ensureDITypeMap => enableDebugTypeODRUniquing destroyDITypeMap => disableDebugTypeODRUniquing hasDITypeMap => isODRUniquingDebugTypes llvm-svn: 266713
* IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith2016-04-171-10/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than relying on the structural equivalence of DICompositeType to merge type definitions, use an explicit map on the LLVMContext that LLParser and BitcodeReader consult when constructing new nodes. Each non-forward-declaration DICompositeType with a non-empty 'identifier:' field is stored/loaded from the type map, and the first definiton will "win". This map is opt-in: clients that expect ODR types from different modules to be merged must call LLVMContext::ensureDITypeMap. - Clients that just happen to load more than one Module in the same LLVMContext won't magically merge types. - Clients (like LTO) that want to continue to merge types based on ODR identifiers should opt-in immediately. I have updated LTOCodeGenerator.cpp, the two "linking" spots in gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to set this. With this in place, it will be straightforward to remove the DITypeRef concept (i.e., referencing types by their 'identifier:' string rather than pointing at them directly). llvm-svn: 266549
* ThinLTO: Make aliases explicit in the summaryMehdi Amini2016-04-161-0/+51
| | | | | | | | | | | To be able to work accurately on the reference graph when taking decision about internalizing, promoting, renaming, etc. We need to have the alias information explicit. Differential Revision: http://reviews.llvm.org/D18836 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266517
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-16/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
* Revert "Make aliases explicit in the summary"Mehdi Amini2016-04-131-51/+0
| | | | | | | | | Inadvertently commited... This reverts commit e618ec93786d99df2ddf280ad2d5e02f5516cecf. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266215
* Make aliases explicit in the summaryMehdi Amini2016-04-131-0/+51
| | | | | | | | | | | | | | | | Summary: To be able to work accurately on the reference graph when taking decision about internalizing, promoting, renaming, etc. We need to have the alias information explicit. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18836 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266214
* Add the allocsize attribute to LLVM.George Burgess IV2016-04-121-0/+4
| | | | | | | | | | | | | | | | `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
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-071-3/+6
| | | | | | | | | | | 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
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-17/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* 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
* Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC)Mehdi Amini2016-04-021-13/+14
| | | | | | | | | | | | | 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-011-3/+7
| | | | | | | | | | | | 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-011-10/+44
| | | | | | | | | | | | | 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-011-44/+10
| | | | | | | | 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-011-10/+44
| | | | | | | | | | | 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-291-0/+2
| | | | | | 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
* Reapply ~"Bitcode: Collect all MDString records into a single blob"Duncan P. N. Exon Smith2016-03-271-2/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Bitcode: Collect all MDString records into a single blob"Duncan P. N. Exon Smith2016-03-251-33/+1
| | | | | | | 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-251-1/+33
| | | | | | | | | | | | | | | | | | | | | | | 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: Stop using MODULE_CODE_METADATA_VALUESDuncan P. N. Exon Smith2016-03-251-50/+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
* 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
* 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-151-67/+66
| | | | | | | | | | | | | | | (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-141-66/+67
| | | | | | This reverts commit r263490. Missed a file. llvm-svn: 263493
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-141-67/+66
| | | | | | | | | | | | | 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: 263490
* [ThinLTO] Support for reference graph in per-module and combined summary.Teresa Johnson2016-03-111-120/+341
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ThinLTO] Add missing breaks when parsing summaries (NFC)Teresa Johnson2016-02-241-0/+2
| | | | | | | This wasn't causing a correctness issue, but was causing extra duplicate entries to be added to the SummaryMap. llvm-svn: 261757
* Restore "[ThinLTO] Use MD5 hash in function index." with fixTeresa Johnson2016-02-101-9/+44
| | | | | | | | | | | 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
* Revert "[ThinLTO] Use MD5 hash in function index." due to bot failureTeresa Johnson2016-02-101-45/+9
| | | | | | This reverts commit r260408. Bot failure that I need to investigate. llvm-svn: 260412
* [ThinLTO] Use MD5 hash in function index.Teresa Johnson2016-02-101-9/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch uses the lower 64-bits of the MD5 hash of a function name as a GUID in the function index, instead of storing function names. Any local functions are first given a global name by prepending the original source file name. This is the same naming scheme and GUID used by PGO in the indexed profile format. This change has a couple of benefits. The primary benefit is size reduction in the combined index file, for example 483.xalancbmk's combined index file was reduced by around 70%. It should also result in memory savings for the index file in memory, as the in-memory map is also indexed by the hash instead of the string. Second, this enables integration with indirect call promotion, since the indirect call profile targets are recorded using the same global naming convention and hash. This will enable the function importer to easily locate function summaries for indirect call profile targets to enable their import and subsequent promotion. The original source file name is recorded in the bitcode in a new module-level record for use in the ThinLTO backend pipeline. Reviewers: davidxl, joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D17028 llvm-svn: 260408
* Fix VST_CODE_* bitcode id comments (NFC)Teresa Johnson2016-02-101-4/+4
| | | | llvm-svn: 260382
* [ThinLTO] Include linkage type in function summaryTeresa Johnson2016-02-061-5/+7
| | | | | | | | | | | | | | | | 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
* Fix Clang-tidy modernize-use-nullptr and modernize-use-override warnings; ↵Eugene Zelenko2016-01-261-11/+6
| | | | | | | | other minor fixes. Differential revision: reviews.llvm.org/D16568 llvm-svn: 258831
* [ThinLTO] Avoid unnecesary hash lookups during metadata linking (NFC)Teresa Johnson2016-01-211-3/+4
| | | | | | | Replace sequences of count() followed by operator[] with either find() or insert(), depending on the context. llvm-svn: 258405
* Fix typo in an error string. NFC.George Burgess IV2016-01-201-1/+1
| | | | llvm-svn: 258357
* Bring back "Assert that we have all use/users in the getters."Rafael Espindola2016-01-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | This reverts commit r257751, bringing back r256105. The problem the assert found was fixed in r257915. Original commit message: Assert that we have all use/users in the getters. An error that is pretty easy to make is to use the lazy bitcode reader and then do something like if (V.use_empty()) The problem is that uses in unmaterialized functions are not accounted for. This patch adds asserts that all uses are known. llvm-svn: 257920
* Revert "Assert that we have all use/users in the getters."Michael Zolotukhin2016-01-141-3/+2
| | | | | | This reverts commit fdb838f3f8a8b6896bbbd5285555874eb3b748eb. llvm-svn: 257751
* Bitcode: Fix reading and writing of ConstantDataVectors of halfsJustin Bogner2016-01-061-11/+12
| | | | | | | | | | | | 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
* Ensure MDNode used as key in metadata linking map cannot be RAUWedTeresa Johnson2015-12-301-0/+5
| | | | | | | | | | | | As suggested in review for r255909, add a way to ensure that temporary MD used as keys in the MetadataToID map during ThinLTO importing are not RAUWed. Add support for marking an MDNode as not replaceable. Clear the new CanReplace flag when adding a temporary MD node to the MetadataToID map and clear it when destroying the map. llvm-svn: 256648
OpenPOWER on IntegriCloud