summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Metadata.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Extend the GlobalObject metadata interfaceBenjamin Kramer2018-05-311-26/+29
| | | | | | | | | | | | - Make eraseMetadata return whether it changed something - Wire getMetadata for a single MDNode efficiently into the attachment map - Add hasMetadata, which is less weird than checking getMetadata == nullptr on a multimap. Use it to simplify code. llvm-svn: 333649
* [IR] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-051-2/+2
| | | | | | | | | | | | | | r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer D44363 for a list of all the required patches. llvm-svn: 329353
* [DeadArgumentElimination] Preserve llvm.dbg.values's first argumentPetar Jovanovic2018-01-301-8/+16
| | | | | | | | | | | | | When removing return value Dead Argument Elimination pass clobbers first llvm.dbg.value’s argument for live arguments of that function by replacing it with nullptr. In the next pass it will be deleted, so debug location about those arguments are lost. This change fixes it. Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D42541 llvm-svn: 323784
* Move the stripping of invalid debug info from the Verifier to AutoUpgrade.Adrian Prantl2017-10-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | This came out of a recent discussion on llvm-dev (https://reviews.llvm.org/D38042). Currently the Verifier will strip the debug info metadata from a module if it finds the dbeug info to be malformed. This feature is very valuable since it allows us to improve the Verifier by making it stricter without breaking bcompatibility, but arguable the Verifier pass should not be modifying the IR. This patch moves the stripping of broken debug info into AutoUpgrade (UpgradeDebugInfo to be precise), which is a much better location for this since the stripping of malformed (i.e., produced by older, buggy versions of Clang) is a (harsh) form of AutoUpgrade. This change is mostly NFC in nature, the one big difference is the behavior when LLVM module passes are introducing malformed debug info. Prior to this patch, a NoAsserts build would have printed a warning and stripped the debug info, after this patch the Verifier will report a fatal error. I believe this behavior is actually more desirable anyway. Differential Revision: https://reviews.llvm.org/D38184 llvm-svn: 314699
* [IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko2017-06-191-6/+8
| | | | llvm-svn: 305755
* Align definition of DW_OP_plus with DWARF spec [3/3]Florian Hahn2017-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things. The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack. This is done in three stages: • The first patch (LLVM) adds support for DW_OP_plus_uconst. • The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst. • The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions. Patch by Sander de Smalen. Reviewers: echristo, pcc, aprantl Reviewed By: aprantl Subscribers: fhahn, javed.absar, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D33894 llvm-svn: 305386
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [Metadata] Fix typos in comments. NFCCraig Topper2017-04-271-2/+2
| | | | llvm-svn: 301517
* Fix the InstCombine to reserve the VP metadata and sets correct call count.Dehao Chen2017-03-311-8/+17
| | | | | | | | | | | | | | Summary: Currently the VP metadata was dropped when InstCombine converts a call to direct call. This patch converts the VP metadata to branch_weights so that its hotness is recorded. Reviewers: eraman, davidxl Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31344 llvm-svn: 299228
* [IR] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-02-171-5/+34
| | | | | | minor fixes (NFC). llvm-svn: 295383
* Encode duplication factor from loop vectorization and loop unrolling to ↵Dehao Chen2017-02-101-0/+9
| | | | | | | | | | | | | | | | | | | | | discriminator. Summary: This patch starts the implementation as discuss in the following RFC: http://lists.llvm.org/pipermail/llvm-dev/2016-October/106532.html When optimization duplicates code that will scale down the execution count of a basic block, we will record the duplication factor as part of discriminator so that the offline process tool can find the duplication factor and collect the accurate execution frequency of the corresponding source code. Two important optimization that fall into this category is loop vectorization and loop unroll. This patch records the duplication factor for these 2 optimizations. The recording will be guarded by a flag encode-duplication-in-discriminators, which is off by default. Reviewers: probinson, aprantl, davidxl, hfinkel, echristo Reviewed By: hfinkel Subscribers: mehdi_amini, anemet, mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D26420 llvm-svn: 294782
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-201-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-14/+7
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-14/+7
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* Add -strip-nonlinetable-debuginfo capabilityMichael Ilseman2016-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This adds a new function to DebugInfo.cpp that takes an llvm::Module as input and removes all debug info metadata that is not directly needed for line tables, thus effectively stripping all type and variable information from the module. The primary motivation for this feature was the bitcode work flow (cf. http://lists.llvm.org/pipermail/llvm-dev/2016-June/100643.html for more background). This is not wired up yet, but will be in subsequent patches. For testing, the new functionality is exposed to opt with a -strip-nonlinetable-debuginfo option. The secondary use-case (and one that works right now!) is as a reduction pass in bugpoint. I added two new bugpoint options (-disable-strip-debuginfo and -disable-strip-debug-types) to control the new features. By default it will first attempt to remove all debug information, then only the type info, and then proceed to hack at any remaining MDNodes. Thanks to Adrian Prantl for stewarding this patch! llvm-svn: 285094
* Retire llvm::alignOf in favor of C++11 alignof.Benjamin Kramer2016-10-201-3/+3
| | | | | | No functionality change intended. llvm-svn: 284733
* Allow Switch instruction to have extractProfTotalWeight called as it can ↵Dehao Chen2016-10-111-1/+2
| | | | | | terminate a basic block. (NFC) llvm-svn: 283918
* Move computation past early returnAditya Kumar2016-09-261-3/+2
| | | | | | | | | | Reviewers: rafael spatel Differential Revision: https://reviews.llvm.org/D24843 llvm-svn: 282440
* Change extractProfMetadata and extractProfTotalWeight to const member function.Dehao Chen2016-09-161-26/+18
| | | | llvm-svn: 281760
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-131-0/+27
| | | | | | | | | | | | | 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
* Make MDNode::intersect faster than O(n * m)David Majnemer2016-08-161-5/+4
| | | | | | | | It is pretty easy to get it down to O(nlogn + mlogm). This implementation has the added benefit of automatically deduplicating entries between the two sets. llvm-svn: 278837
* Don't passively concatenate MDNodesDavid Majnemer2016-08-161-13/+5
| | | | | | | | | | | I have audited all the callers of concatenate and none require duplicate entries to service concatenation. These duplicates serve no purpose but to needlessly embiggen the IR. N.B. Layering getMostGenericAliasScope on top of concatenate makes it O(nlogn + mlogm) instead of O(n*m). llvm-svn: 278836
* Use the range variant of find/find_if instead of unpacking begin/endDavid Majnemer2016-08-121-2/+2
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278469
* IR: Drop uniquing when an MDNode Value operand is deletedDuncan P. N. Exon Smith2016-08-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for PR28697. An MDNode can indirectly refer to a GlobalValue, through a ConstantAsMetadata. When the GlobalValue is deleted, the MDNode operand is reset to `nullptr`. If the node is uniqued, this can lead to a hard-to-detect cache invalidation in a Metadata map that's shared across an LLVMContext. Consider: 1. A map from Metadata* to `T` called RemappedMDs. 2. A node that references a global variable, `!{i1* @GV}`. 3. Insert `!{i1* @GV} -> SomeT` in the map. 4. Delete `@GV`, leaving behind `!{null} -> SomeT`. Looking up the generic and uninteresting `!{null}` gives you `SomeT`, which is likely related to `@GV`. Worse, `SomeT`'s lifetime may be tied to the deleted `@GV`. This occurs in practice in the shared ValueMap used since r266579 in the IRMover. Other code that handles more than one Module (with different lifetimes) in the same LLVMContext could hit it too. The fix here is a partial revert of r225223: in the rare case that an MDNode operand is a ConstantAsMetadata (i.e., wrapping a node from the Value hierarchy), drop uniquing if it gets replaced with `nullptr`. This changes step #4 above to leave behind `distinct !{null} -> SomeT`, which can't be confused with the generic `!{null}`. In theory, this can cause some churn in the LLVMContext's MDNode uniquing map when Values are being deleted. However: - The number of GlobalValues referenced from uniqued MDNodes is expected to be quite small. E.g., the debug info metadata schema only references GlobalValues from distinct nodes. - Other Constants have the lifetime of the LLVMContext, whose teardown is careful to drop references before deleting the constants. As a result, I don't expect a compile time regression from this change. llvm-svn: 277625
* Rename StringMap::emplace_second to try_emplace.Benjamin Kramer2016-07-211-1/+1
| | | | | | | Coincidentally this function maps to the C++17 try_emplace. Rename it for consistentcy with C++17 std::map. NFC. llvm-svn: 276276
* Fix the assertion failure caused by http://reviews.llvm.org/D22118Dehao Chen2016-07-111-1/+2
| | | | | | | | | | | | Summary: http://reviews.llvm.org/D22118 uses metadata to store the call count, which makes it possible to have branch weight to have only one elements. Also fix the assertion failure in inliner when checking the instruction type to include "invoke" instruction. Reviewers: mkuper, dnovillo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D22228 llvm-svn: 275079
* [IR] Stop a -Wsign-compare warning from firingDavid Majnemer2016-07-111-1/+1
| | | | llvm-svn: 275077
* Implement callsite-hotness based inline cost for Sample-based PGODehao Chen2016-07-111-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For sample-based PGO, using BFI to calculate callsite count is sometime not accurate. This is because with sampling based approach, if a callsite resides in a hot loop deeply nested in a bunch of cold branches, the callsite's BFI frequency would be inaccurately calculated due to lack of samples in the cold branch. E.g. if (A1 && A2 && A3 && ..... && A10) { for (i=0; i < 100000000; i++) { callsite(); } } Assume that A1 to A100 are all 100% taken, and callsite has 1000 samples and thus is considerred hot. Because the loop's trip count is huge, it's normal that all branches outside the loop has no sample at all. As a result, we can only use static branch probability to derive the the frequency of the loop header. Assuming that static heuristic thinks each branch is 50% taken, then the count calculated from BFI will be 1/(2^10) of the actual value. In order to get more accurate callsite count, we directly annotate the weight on the call instruction, and directly use it when checking callsite hotness. Note that this mechanism can also be shared by instrumentation based callsite hotness analysis. The side benefit is that it breaks the dependency from Inliner to BFI as call count is embedded in the IR. Reviewers: davidxl, eraman, dnovillo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D22118 llvm-svn: 275073
* IR: Introduce llvm.type.checked.load intrinsic.Peter Collingbourne2016-06-251-1/+0
| | | | | | | | | | | | | | | | This intrinsic safely loads a function pointer from a virtual table pointer using type metadata. This intrinsic is used to implement control flow integrity in conjunction with virtual call optimization. The virtual call optimization pass will optimize away llvm.type.checked.load intrinsics associated with devirtualized calls, thereby removing the type check in cases where it is not needed to enforce the control flow integrity constraint. This patch also introduces the capability to copy type metadata between global variables, and teaches the virtual call optimization pass to do so. Differential Revision: http://reviews.llvm.org/D21121 llvm-svn: 273756
* IR: New representation for CFI and virtual call optimization pass metadata.Peter Collingbourne2016-06-241-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than being directly associated with a global. This makes it harder to manipulate the metadata when rebuilding global variables, summarise it as part of ThinLTO and drop unused metadata when associated globals are dropped. For this reason, CFI does not currently work correctly when both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable globals, and fails to associate metadata with the rebuilt globals. As I understand it, the same problem could also affect ASan, which rebuilds globals with a red zone. This patch solves both of those problems in the following way: 1. Rename the metadata to "type metadata". This new name reflects how the metadata is currently being used (i.e. to represent type information for CFI and vtable opt). The new name is reflected in the name for the associated intrinsic (llvm.type.test) and pass (LowerTypeTests). 2. Attach metadata directly to the globals that it pertains to, rather than using the "llvm.bitsets" global metadata node as we are doing now. This is done using the newly introduced capability to attach metadata to global variables (r271348 and r271358). See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21053 llvm-svn: 273729
* Linker: Copy metadata when linking declarations.Peter Collingbourne2016-06-241-0/+7
| | | | | | Differential Revision: http://reviews.llvm.org/D21624 llvm-svn: 273692
* [STLExtras] Introduce and use llvm::count_if; NFCSanjoy Das2016-06-101-1/+1
| | | | | | (This is split out from was D21115) llvm-svn: 272435
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-011-40/+76
| | | | | | | | | | 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-311-13/+13
| | | | | | | | | | 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
* [CodeGenPrepare] use branch weight metadata to decide if a select should be ↵Sanjay Patel2016-04-261-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | turned into a branch This is part of solving PR27344: https://llvm.org/bugs/show_bug.cgi?id=27344 CGP should undo the SimplifyCFG transform for the same reason that earlier patches have used this same mechanism: it's possible that passes between SimplifyCFG and CGP may be able to optimize the IR further with a select in place. For the TLI hook default, >99% taken or not taken is chosen as the default threshold for a highly predictable branch. Even the most limited HW branch predictors will be correct on this branch almost all the time, so even a massive mispredict penalty perf loss would be overcome by the win from all the times the branch was predicted correctly. As a follow-up, we could make the default target hook less conservative by using the SchedMachineModel's MispredictPenalty. Or we could just let targets override the default by implementing the hook with that and other target-specific options. Note that trying to statically determine mispredict rates for close-to-balanced profile weight data is generally impossible if the HW is sufficiently advanced. Ie, 50/50 taken/not-taken might still be 100% predictable. Finally, note that this patch as-is will not solve PR27344 because the current __builtin_unpredictable() branch weight default values are 4 and 64. A proposal to change that is in D19435. Differential Revision: http://reviews.llvm.org/D19488 llvm-svn: 267572
* BitcodeReader: Avoid referencing unresolved nodes from distinct onesDuncan P. N. Exon Smith2016-04-231-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each reference to an unresolved MDNode is expensive, since the RAUW support in MDNode uses a separate allocation and side map. Since a distinct MDNode doesn't require its operands on creation (unlike uniuqed nodes, there's no need to check for structural equivalence), use nullptr for any of its unresolved operands. Besides reducing the burden on MDNode maps, this can avoid allocating temporary MDNodes in the first place. We need some way to track operands. Invent DistinctMDOperandPlaceholder for this purpose, which is a Metadata subclass that holds an ID and points at its single user. DistinctMDOperandPlaceholder::replaceUseWith is just like RAUW, but its name highlights that there is only ever exactly one use. There is no support for moving (or, obviously, copying) these. Move support would be possible but expensive; leaving it unimplemented prevents user error. In the BitcodeReader I originally considered allocating on a BumpPtrAllocator and keeping a vector of pointers to them, and then I realized that std::deque implements exactly this. A couple of obvious follow-ups: - Change ValueEnumerator to emit distinct nodes first to take more advantage of this optimization. (How convenient... I think I might have a couple of patches for this.) - Change DIBuilder and its consumers (like CGDebugInfo in clang) to use something like this when constructing debug info in the first place. llvm-svn: 267270
* IR: Use std::vector instead of SmallPtrSet for distinct nodes, NFCDuncan P. N. Exon Smith2016-04-191-1/+1
| | | | | | | | | We never use the set-ness of SmallPtrSet for distinct nodes. Eventually we may start garbage-collecting or reference-counting nodes (in which cases we'd want to remove things from this collection, and a fast erase would be valuable), but in the meantime a vector is sufficient. llvm-svn: 266835
* [NFC] Header cleanupMehdi Amini2016-04-181-2/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* IR: Lazily create ReplaceableMetadataImpl on MDNodeDuncan P. N. Exon Smith2016-04-031-31/+60
| | | | | | | | | | | | | | | | | | | RAUW support on MDNode usually requires an extra allocation for ReplaceableMetadataImpl. This is only strictly necessary if there are tracking references to the MDNode. Make the construction of ReplaceableMetadataImpl lazy, so that we don't get allocations if we don't need them. Since MDNode::isResolved now checks MDNode::isTemporary and MDNode::NumUnresolved instead of whether a ReplaceableMetadataImpl is allocated, the internal changes are intrusive (at various internal checkpoints, isResolved now has a different answer). However, there should be no real functionality change here; just slightly lazier allocation behaviour. The external semantics should be identical. llvm-svn: 265279
* [ThinLTO] Remove post-pass metadata linking supportTeresa Johnson2016-03-291-6/+1
| | | | | | | | | | | 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
* Query the StringMap only once when creating MDString (NFC)Mehdi Amini2016-03-251-11/+6
| | | | | | | | | | | | | | | | Summary: Loading IR with debug info improves MDString::get() from 19ms to 10ms. This is a rework of D16597 with adding an "emplace" method on the StringMap to avoid requiring the MDString move ctor to be public. Reviewers: dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17920 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 264386
* fix documentation comments; NFCSanjay Patel2016-03-121-7/+2
| | | | llvm-svn: 263346
* Revert "Query the StringMap only once when creating MDString (NFC)"Mehdi Amini2016-02-171-6/+11
| | | | | | | | | This reverts commit r261030 and r261036. (The revision was marked "approved" on phabricator, but some concerns were raised on the mailing list. Thanks D. Blaikie for notifying me.) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 261055
* Query the StringMap only once when creating MDString (NFC)Mehdi Amini2016-02-161-11/+6
| | | | | | | | | | | | | Summary: Loading IR with debug info improves MDString::get() from 19ms to 10ms. Reviewers: dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16597 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 261030
* Relax assertion in ReplaceableMetadataImpl::replaceAllUsesWith().Adrian Prantl2016-02-061-2/+0
| | | | | | | | | | There is a legitimate use-case in clang where we need to replace a temporary placeholder node with the temporary node that may be a forward declaration. <rdar://problem/24493203> llvm-svn: 259973
* Update to use new name alignTo().Rui Ueyama2016-01-141-2/+2
| | | | llvm-svn: 257804
* Split resolveCycles(bool AllowTemps) into two interfaces and documentTeresa Johnson2016-01-111-1/+1
| | | | | | | | | | | | | | Address review feedback from r255909. Move body of resolveCycles(bool AllowTemps) to resolveRecursivelyImpl(bool AllowTemps). Revert resolveCycles back to asserting on temps, and add new resolveNonTemporaries interface to invoke the new implementation with AllowTemps=true. Document the differences between these interfaces, specifically the effect on RAUW support and uniquing. Call appropriate interface from ValueMapper. llvm-svn: 257389
* [ThinLTO] Rename variables used in metadata linking (NFC)Teresa Johnson2015-12-301-2/+2
| | | | | | | | As suggested in review for r255909, rename MDMaterialized to AllowTemps, and identify the name of the boolean flag being set in calls to saveMetadataList. llvm-svn: 256653
OpenPOWER on IntegriCloud