summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Writer
Commit message (Collapse)AuthorAgeFilesLines
...
* [ThinLTO] Create AliasSummary when building indexTeresa Johnson2016-10-281-1/+3
| | | | | | | | | | | | | | | | | | | Summary: Previously we were creating the alias summary on the fly while writing the summary to bitcode. This moves the creation of these summaries to the module summary index builder where we build the rest of the summary index. This is going to be necessary for setting the NoRename flag for values possibly used in inline asm or module level asm. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26049 llvm-svn: 285379
* [ThinLTO] Rename HasSection to NoRename (NFC)Teresa Johnson2016-10-281-1/+1
| | | | | | | | | | | | | | Summary: This is in preparation for a change to utilize this flag for symbols referenced/defined in either inline or module level assembly. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26048 llvm-svn: 285376
* Fix spelling mistake in comment.Simon Pilgrim2016-10-201-1/+1
| | | | llvm-svn: 284714
* Fix MSVC bool -> uint64_t promotion warningSimon Pilgrim2016-10-201-1/+1
| | | | llvm-svn: 284713
* DebugInfo: preparation to implement DW_AT_alignmentVictor Leschuk2016-10-201-1/+17
| | | | | | | | | | | | - Add alignment attribute to DIVariable family - Modify bitcode format to match new DIVariable representation - Update tests to match these changes (also add bitcode upgrade test) - Expect that frontend passes non-zero align value only when it is not default (was forcibly aligned by alignas()/_Alignas()/__atribute__(aligned()) Differential Revision: https://reviews.llvm.org/D25073 llvm-svn: 284678
* Use StringRef in Pass/PassManager APIs (NFC)Mehdi Amini2016-10-011-1/+1
| | | | llvm-svn: 283004
* [thinlto] Basic thinlto fdo heuristicPiotr Padlewski2016-09-261-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch improves thinlto importer by importing 3x larger functions that are called from hot block. I compared performance with the trunk on spec, and there were about 2% on povray and 3.33% on milc. These results seems to be consistant and match the results Teresa got with her simple heuristic. Some benchmarks got slower but I think they are just noisy (mcf, xalancbmki, omnetpp)- running the benchmarks again with more iterations to confirm. Geomean of all benchmarks including the noisy ones were about +0.02%. I see much better improvement on google branch with Easwaran patch for pgo callsite inlining (the inliner actually inline those big functions) Over all I see +0.5% improvement, and I get +8.65% on povray. So I guess we will see much bigger change when Easwaran patch will land (it depends on new pass manager), but it is still worth putting this to trunk before it. Implementation details changes: - Removed CallsiteCount. - ProfileCount got replaced by Hotness - hot-import-multiplier is set to 3.0 for now, didn't have time to tune it up, but I see that we get most of the interesting functions with 3, so there is no much performance difference with higher, and binary size doesn't grow as much as with 10.0. Reviewers: eraman, mehdi_amini, tejohnson Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D24638 llvm-svn: 282437
* [ThinLTO] Always emit a summary when compiling in ThinLTO modeTeresa Johnson2016-09-201-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Emit an empty summary section, instead of no summary section, when there are no global variables in the index. This ensures that LTO will treat these files as ThinLTO inputs, instead of as regular LTO inputs. In addition to not being what the user likely intended when compiling with -flto=thin, the current behavior is problematic for distributed build systems that expect to get ThinLTO index and imports files back for each input compiled with -flto=thin. Combining into a single regular LTO module also reduces the backend parallelism. And in the case where the index was suppressed due to uses in inline assembly, combining into a single LTO module could provoke renaming of duplicates that we were trying to prevent by suppressing the index. This change required a couple of fixes to handle the empty summary section. Reviewers: mehdi_amini Subscribers: mehdi_amini, llvm-commits, pcc Differential Revision: https://reviews.llvm.org/D24779 llvm-svn: 282037
* BitcodeWriter: fix emission of invoke when calling a var-arg function with ↵Mehdi Amini2016-09-191-1/+1
| | | | | | operand bundles llvm-svn: 281940
* Don't create a SymbolTable in Function when the LLVMContext discards value ↵Mehdi Amini2016-09-171-1/+2
| | | | | | | | | | | | | | names (NFC) The ValueSymbolTable is used to detect name conflict and rename instructions automatically. This is not needed when the value names are automatically discarded by the LLVMContext. No functional change intended, just saving a little bit of memory. This is a recommit of r281806 after fixing the accessor to return a pointer instead of a reference and updating all the call-sites. llvm-svn: 281813
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-131-1/+1
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* DebugInfo: Add flag to CU to disable emission of inline debug info into the ↵David Blaikie2016-08-241-0/+1
| | | | | | | | | | skeleton CU In cases where .dwo/.dwp files are guaranteed to be available, skipping the extra online (in the .o file) inline info can save a substantial amount of space - see the original r221306 for more details there. llvm-svn: 279650
* Constify some path in the bitcode writer (NFC)Mehdi Amini2016-08-191-6/+6
| | | | llvm-svn: 279211
* [PM] Port ModuleSummaryIndex analysis to new pass managerTeresa Johnson2016-08-121-6/+5
| | | | | | | | | | | | | | | | | | | Summary: Port the ModuleSummaryAnalysisWrapperPass to the new pass manager. Use it in the ported BitcodeWriterPass (similar to how we use the legacy ModuleSummaryAnalysisWrapperPass in the legacy WriteBitcodePass). Also, pass the -module-summary opt flag through to the new pass manager pipeline and through to the bitcode writer pass, and add a test that uses it. Reviewers: mehdi_amini Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23439 llvm-svn: 278508
* Don't import variadic functionsPiotr Padlewski2016-08-111-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds IsVariadicFunction bit to summary in order to not import variadic functions. Inliner doesn't inline variadic functions because it is hard to reason about it. This one small fix improves Importer by about 16% (going from 86% to 100% of imported functions that are inlined anywhere) on some spec benchmarks like 'int' and others. Reviewers: eraman, mehdi_amini, tejohnson Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23339 llvm-svn: 278432
* [ThinLTO] Address review comments from PGO indirect call promotion (NFC)Teresa Johnson2016-07-181-13/+17
| | | | | | Address a couple of post-commit review comments from r275707. llvm-svn: 275867
* [ThinLTO] Perform profile-guided indirect call promotionTeresa Johnson2016-07-171-4/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: To enable profile-guided indirect call promotion in ThinLTO mode, we simply add call graph edges for each profitable target from the profile to the summaries, then the summary-guided importing will consider the callee for importing as usual. Also we need to enable the indirect call promotion pass creation in the PassManagerBuilder when PerformThinLTO=true (we are in the ThinLTO backend), so that the newly imported functions are considered for promotion in the backends. The IC promotion profiles refer to callees by GUID, which required adding GUIDs to the per-module VST in bitcode (and assigning them valueIds similar to how they are assigned valueIds in the combined index). Reviewers: mehdi_amini, xur Subscribers: mehdi_amini, davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D21932 llvm-svn: 275707
* Add an assertion for the value enumerator (bitcode writer) NFCMehdi Amini2016-07-081-1/+6
| | | | | | | | I have an LTO snapshot (for which I don't have sources) that can't be read back by LLVM. It seems the writer emitted broken bitcode and this assertions aims at catching such cases. llvm-svn: 274819
* Add writeonly IR attributeNicolai Haehnle2016-07-041-0/+2
| | | | | | | | | | | | | | | | | Summary: This complements the earlier addition of IntrWriteMem and IntrWriteArgMem LLVM intrinsic properties, see D18291. Also start using the attribute for memset, memcpy, and memmove intrinsics, and remove their special-casing in BasicAliasAnalysis. Reviewers: reames, joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18714 llvm-svn: 274485
* [codeview] Add DISubprogram::ThisAdjustmentReid Kleckner2016-07-011-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: This represents the adjustment applied to the implicit 'this' parameter in the prologue of a virtual method in the MS C++ ABI. The adjustment is always zero unless multiple inheritance is involved. This increases the size of DISubprogram by 8 bytes, unfortunately. The adjustment really is a signed 32-bit integer. If this size increase is too much, we could probably win it back by splitting out a subclass with info specific to virtual methods (virtuality, vindex, thisadjustment, containingType). Reviewers: aprantl, dexonsmith Subscribers: aaboud, amccarth, llvm-commits Differential Revision: http://reviews.llvm.org/D21614 llvm-svn: 274325
* BitcodeWriter: Remove redundant (and incorrect) check for whether to emit ↵Peter Collingbourne2016-06-241-3/+0
| | | | | | | | | | | | | | | module summary. The function name Module::empty() is slightly misleading in that it only tests for the presence of functions in the module. However we still want to emit the module summary if the module contains only global variables or aliases. The presence of such entities can be determined simply by checking the summary directly, as we are doing below. Differential Revision: http://reviews.llvm.org/D21669 llvm-svn: 273638
* IR: Allow metadata attachments on declarations, and fix lazy loaded metadata ↵Peter Collingbourne2016-06-213-23/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
* [PM] Remove support for omitting the AnalysisManager argument to newChandler Carruth2016-06-171-1/+1
| | | | | | | | | | | | | | | | | | | | pass manager passes' `run` methods. This removes a bunch of SFINAE goop from the pass manager and just requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead argument. This is a small price to pay for the simplicity of the system as a whole, despite the noise that changing it causes at this stage. This will also helpfull allow us to make the signature of the run methods much more flexible for different kinds af passes to support things like intelligently updating the pass's progression over IR units. While this touches many, many, files, the changes are really boring. Mostly made with the help of my trusty perl one liners. Thanks to Sean and Hal for bouncing ideas for this with me in IRC. llvm-svn: 272978
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* [DebugInfo] Add calling convention support for DWARF and CodeViewReid Kleckner2016-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If it is present and non-zero, the backend will emit it as a DW_AT_calling_convention attribute. On the CodeView side, we translate it to the appropriate enum for the LF_PROCEDURE record. I added a new LLVM vendor specific enum to the list of DWARF calling conventions. DWARF does not appear to attempt to standardize these, so I assume it's OK to do this until we coordinate with GCC on how to emit vectorcall convention functions. Reviewers: dexonsmith, majnemer, aaboud, amccarth Subscribers: mehdi_amini, llvm-commits Differential Revision: http://reviews.llvm.org/D21114 llvm-svn: 272197
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-011-0/+2
| | | | | | | | | | This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
* Add support for metadata attachments for global variables.Peter Collingbourne2016-05-313-19/+43
| | | | | | | | | | This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
* Avoid temporary vector for sorting in BitcodeWriterMehdi Amini2016-05-161-13/+10
| | | | | | | As suggested by Duncan, fixup for r269634 and r269635 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269715
* ThinLTO: fix non-determinism in bitcode writingMehdi Amini2016-05-161-1/+8
| | | | | | | | Calls are initialized from a DenseMap. We can sort them using the value id to recover some determinism during serialization. From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8> llvm-svn: 269638
* Revert "ThinLTO: fix non-determinism in bitcode writing"Mehdi Amini2016-05-161-7/+1
| | | | | | | This reverts commit r269634, bots are broken. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269637
* ThinLTO: fix another non-determinism in bitcode writingMehdi Amini2016-05-161-2/+9
| | | | | | | | GlobalVars Refs are initialized from a DenseSet. We can sort them using the value id to recover some determinism during serialization. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269635
* ThinLTO: fix non-determinism in bitcode writingMehdi Amini2016-05-161-1/+7
| | | | | | | | Calls are initialized from a DenseMap. We can sort them using the value id to recover some determinism during serialization. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269634
* ThinLTO: fix non-determinism in bitcode writingMehdi Amini2016-05-161-1/+7
| | | | | | | | Refs are initialized from a DenseSet. We can sort them using the value id to recover some determinism during serialization. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269629
* Move helper classes into anonymous namespaces. NFC.Benjamin Kramer2016-05-151-0/+2
| | | | llvm-svn: 269591
* [ThinLTO] Fix Windows debug failure in new iteratorTeresa Johnson2016-05-111-2/+13
| | | | | | | | | | | | This fixes a debug assert on Windows from the new iterator implementation added in r269059. The Windows std::vector iterator operator== checks in debug mode that the containers being iterated over are the same, which they may not be. Fixed by checking that we are iterating over the same container before comparing the container iterators. llvm-svn: 269232
* Restore "[ThinLTO] Emit individual index files for distributed backends"Teresa Johnson2016-05-101-71/+215
| | | | | | | | | | | | | | | | | | | This restores commit r268627: Summary: When launching ThinLTO backends in a distributed build (currently supported in gold via the thinlto-index-only plugin option), emit an individual index file for each backend process as described here: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098272.html ... Differential Revision: http://reviews.llvm.org/D19556 Address msan failures by avoiding std::prev on map.end(), the theory is that this is causing issues due to some known UB problems in __tree. llvm-svn: 269059
* Implement a safer bitcode upgrade for DISubprogram.Adrian Prantl2016-05-061-1/+2
| | | | | | | | | | | | | | | | | | The bitcode upgrade I added for DISubprogram in r266446 was based on the assumption that the CU node for the subprogram was already materialized by the time the DISubprogram is visited. This assumption may not hold true as future versions of LLVM may decide to write out bitcode in a different order. This patch corrects this by introducing a versioning bit next to the distinct flag to unambiguously differentiate the new from the old record layouts. Note for people stabilizing LLVM out-of-tree: This patch introduces a bitcode incompatibility with llvm trunk revisions from r266446 — this commit. (But D19987 will ensure that it degrades gracefully). http://reviews.llvm.org/D20004 rdar://problem/26074194 llvm-svn: 268816
* BitcodeWriter: Simplify. NFC.Peter Collingbourne2016-05-061-4/+2
| | | | llvm-svn: 268707
* Revert "[ThinLTO] Emit individual index files for distributed backends"Vitaly Buka2016-05-051-209/+71
| | | | | | | | | MemorySanitizer: use-of-uninitialized-value in lib/Bitcode/Writer/BitcodeWriter.cpp:364:70 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12544/steps/check-llvm%20msan/logs/stdio This reverts commit 0c4a898ea550699d1b2f4fe3767251c8f9a48d52. llvm-svn: 268660
* [ThinLTO] Emit individual index files for distributed backendsTeresa Johnson2016-05-051-71/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When launching ThinLTO backends in a distributed build (currently supported in gold via the thinlto-index-only plugin option), emit an individual index file for each backend process as described here: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098272.html The individual index file encodes the summary and module information required for implementing the importing/exporting decisions made for a given module in the thin link step. This is in place of the current mechanism that uses the combined index to make importing decisions in each back end independently. It is an enabler for doing global summary based optimizations in the thin link step (which will be recorded in the individual index files), and reduces the size of the index that must be sent to each backend process, and the amount of work to scan it in the backends. Rather than create entirely new ModuleSummaryIndex structures (and all the included unique_ptrs) for each backend index file, a map is created to record all of the GUID and summary pointers needed for a particular index file. The IndexBitcodeWriter walks this map instead of the full index (hiding the details of managing the appropriate summary iteration in a new iterator subclass). This is more efficient than walking the entire combined index and filtering out just the needed summaries during each backend bitcode index write. Depends on D19481. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D19556 llvm-svn: 268627
* Clean up to avoid compiler warnings for casting away const qualifiers.Sjoerd Meijer2016-04-271-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D19598 llvm-svn: 267753
* [ThinLTO] Use valueid instead of bitcode offsets in combined index fileTeresa Johnson2016-04-271-61/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With the removal of support for lazy parsing of combined index summary records (e.g. r267344), we no longer need to include the summary record bitcode offset in the VST entries for definitions. Change the combined index format to be similar to the per-module index format in using value ids to cross-reference from the summary record to the VST entry (rather than the summary record bitcode offset to cross-reference in the other direction). The visible changes are: 1) Add the value id to the combined summary records 2) Remove the summary offset from the combined VST records, which has the following effects: - No longer need the VST_CODE_COMBINED_GVDEFENTRY record, as all combined index VST entries now only contain the value id and corresponding GUID. - No longer have duplicate VST entries in the case where there are multiple definitions of a symbol (e.g. weak/linkonce), as they all have the same value id and GUID. An implication of #2 above is that in order to hook up an alias to the correct aliasee based on the value id of the aliasee recorded in the combined index alias record, we need to scan the entries in the index for that GUID to find the one from the same module (i.e. the case where there are multiple entries for the aliasee). But the reader no longer has to maintain a special map to hook up the alias/aliasee. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19481 llvm-svn: 267712
* [ThinLTO] Remove GlobalValueInfo class from indexTeresa Johnson2016-04-241-38/+39
| | | | | | | | | | | | | | | | Summary: Remove the GlobalValueInfo and change the ModuleSummaryIndex to directly reference summary objects. The info structure was there to support lazy parsing of the combined index summary objects, which is no longer needed and not supported. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19462 llvm-svn: 267344
* Silence two C4806 warnings ('|': unsafe operation: no value of type 'bool' ↵Aaron Ballman2016-04-241-2/+2
| | | | | | promoted to type 'const unsigned int' can equal the given constant). The fact that they trigger with this code seems like it may be a bug, but the warning itself is still generally useful enough to retain it for now. llvm-svn: 267337
* Add "hasSection" flag in the SummaryMehdi Amini2016-04-241-2/+8
| | | | | | | | | | | Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19405 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267329
* Reorganize GlobalValueSummary with a "Flags" bitfield.Mehdi Amini2016-04-241-15/+23
| | | | | | | | | | Right now it only contains the LinkageType, but will be extended with "hasSection", "isOptSize", "hasInlineAssembly", etc. Differential Revision: http://reviews.llvm.org/D19404 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267319
* Add a version field in the bitcode for the summaryMehdi Amini2016-04-241-0/+8
| | | | | | | Differential Revision: http://reviews.llvm.org/D19456 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267318
* Store and emit original name in combined indexMehdi Amini2016-04-231-0/+14
| | | | | | | | | | | | | | | | | | | Summary: As discussed in D18298, some local globals can't be renamed/promoted (because they have a section, or because they are referenced from inline assembly). To be able to detect naming collision, we need to keep around the "GUID" using their original name without taking the linkage into account. Reviewers: tejohnson Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19454 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267304
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-231-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around DIType*. It is no longer legal to refer to a DICompositeType by its 'identifier:', and DIBuilder no longer retains all types with an 'identifier:' automatically. Aside from the bitcode upgrade, this is mainly removing logic to resolve an MDString-based reference to an actualy DIType. The commits leading up to this have made the implicit type map in DICompileUnit's 'retainedTypes:' field superfluous. This does not remove DITypeRef, DIScopeRef, DINodeRef, and DITypeRefArray, or stop using them in DI-related metadata. Although as of this commit they aren't serving a useful purpose, there are patchces under review to reuse them for CodeView support. The tests in LLVM were updated with deref-typerefs.sh, which is attached to the thread "[RFC] Lazy-loading of debug info metadata": http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html llvm-svn: 267296
* BitcodeWriter: Emit uniqued subgraphs after all distinct nodesDuncan P. N. Exon Smith2016-04-232-1/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since forward references for uniqued node operands are expensive (and those for distinct node operands are cheap due to DistinctMDOperandPlaceholder), minimize forward references in uniqued node operands. Moreover, guarantee that when a cycle is broken by a distinct node, none of the uniqued nodes have any forward references. In ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs first, delaying distinct nodes until all uniqued nodes have been handled. This guarantees that uniqued nodes only have forward references when there is a uniquing cycle (since r267276 changed ValueEnumerator::organizeMetadata to partition distinct nodes in front of uniqued nodes as a post-pass). Note that a single uniqued subgraph can hit multiple distinct nodes at its leaves. Ideally these would themselves be emitted in post-order, but this commit doesn't attempt that; I think it requires an extra pass through the edges, which I'm not convinced is worth it (since DistinctMDOperandPlaceholder makes forward references quite cheap between distinct nodes). I've added two testcases: - test/Bitcode/mdnodes-distinct-in-post-order.ll is just like test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes instead of uniqued ones. This confirms that, in the absence of uniqued nodes, distinct nodes are still emitted in post-order. - test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal example where a naive post-order traversal would cause one uniqued node to forward-reference another. IOW, it's the motivating test. llvm-svn: 267278
OpenPOWER on IntegriCloud