aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/Metadata.cpp
AgeCommit message (Collapse)AuthorFilesLines
5 days[AMDGPU] Add NoaliasAddrSpace to AAMDnodes (#149247)Shoreshen1-0/+2
This is the following PR of https://github.com/llvm/llvm-project/pull/136553 which calculate NoaliasAddrSpace. This PR carries the info calculated into MIR by adding it into AAMDnodes
2025-07-18[llvm] Introduce callee_type metadataPrabhu Rajasekaran1-0/+18
Introduce `callee_type` metadata which will be attached to the indirect call instructions. The `callee_type` metadata will be used to generate `.callgraph` section described in this RFC: https://lists.llvm.org/pipermail/llvm-dev/2021-July/151739.html Reviewers: morehouse, petrhosek, nikic, ilovepi Reviewed By: nikic, ilovepi Pull Request: https://github.com/llvm/llvm-project/pull/87573
2025-07-01[IR] Remove an unnecessary cast (NFC) (#146464)Kazu Hirata1-1/+1
The destructor does not return anything.
2025-06-25[NFC][PGO] Use constants rather than free strings for metadata labels (#145721)Mircea Trofin1-2/+3
2025-04-17Reapply [Metadata] Preserve MD_prof when merging instructions when one is ↵Snehasish Kumar1-0/+20
missing. (#135418) Preserve branch weight metadata when merging instructions if one of the instructions is missing metadata. This is similar in behaviour to what we do today for other types of metadata such as mmra, memprof and callsite metadata. Also add a legality check when merging prof metadata based on instruction type. Without this check GVN PRE optimizations result in prof metadata on phi nodes which break the module verifier. Build failure caught by https://lab.llvm.org/buildbot/#/builders/113/builds/6621 ``` !9185 = !{!"branch_weights", i32 3912, i32 802} Wrong number of operands !9185 = !{!"branch_weights", i32 3912, i32 802} fatal error: error in backend: Broken module found, compilation aborted! ``` Reverts #134200 with additional changes.
2025-03-23[llvm] Use range constructors for *Set (NFC) (#132636)Kazu Hirata1-2/+1
2025-03-20[llvm] Use *Set::insert_range (NFC) (#132325)Kazu Hirata1-1/+1
DenseSet, SmallPtrSet, SmallSet, SetVector, and StringSet recently gained C++23-style insert_range. This patch replaces: Dest.insert(Src.begin(), Src.end()); with: Dest.insert_range(Src); This patch does not touch custom begin like succ_begin for now.
2025-03-03[Metadata] Replace `undef` VAMs with `poison` VAMs (#129450)Pedro Lobo1-3/+4
`undef` debug info can be replaced with `poison` debug info.
2024-11-26Local: Handle noalias_addrspace in combineMetadata (#103938)Matt Arsenault1-0/+38
This should act like range. Previously ConstantRangeList assumed a 64-bit range. Now query from the actual entries. This also means that the empty range has no bitwidth, so move asserts to avoid checking the bitwidth of empty ranges.
2024-11-10[llvm] Migrate away from PointerUnion::{is,get,dyn_cast} (NFC) (#115626)Kazu Hirata1-5/+5
Note that PointerUnion::{is,get,dyn_cast} have been soft deprecated in PointerUnion.h: // FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T>
2024-11-02[IR] Remove unused includes (NFC) (#114679)Kazu Hirata1-1/+0
Identified with misc-include-cleaner.
2024-09-19[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)Jay Foad1-3/+3
It is almost always simpler to use {} instead of std::nullopt to initialize an empty ArrayRef. This patch changes all occurrences I could find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor could be deprecated or removed.
2024-08-08Globalopt pass produces invalid debug info (#100654)ykhatav1-0/+6
This patch fixes an issue in the GlobalOpt pass where deleting a global variable fails to update the corresponding dbg.value and it references an empty metadata entry. The SalvageDebugInfo() function has been updated to handle dbg.value intrinsic when globals are deleted.
2024-08-04[Metadata] Use const APInt &. NFC (#101865)Craig Topper1-2/+2
getValue returns a const APInt &. So using a const APInt & will avoid a copy.
2024-08-04[Metadata] Try to merge the first and last ranges. (#101860)DianQK1-2/+3
Fixes #101859. If we have at least 2 ranges, we have to try to merge the last and first ones to handle the wrap range.
2024-07-22[Metadata] Make range boundary variables unsigned (NFC) (#99338)AtariDreams1-5/+5
They should be unsigned because the source and target value are too.
2024-07-15[IR] Use SmallSet with more inline elements in dropUnknownNonDebugMetadata ↵Kazu Hirata1-1/+1
(NFC) (#98853) SmallSet here often ends up allocating memory via std::set inside SmallSet because KnownIDs.size() goes up to 17 on an x86 host. This patch switches to SmallSet<unsigned, 32> to avoid memory allocations. The increased inline elements here save 0.57% of heap allocations during the compilation of X86ISelLowering.cpp.ii, a preprocessed version of X86ISelLowering.cpp.
2024-06-12Reapply "[llvm][IR] Extend BranchWeightMetadata to track provenance o… ↵Paul Kirth1-4/+4
(#95281) …f weights" #95136 Reverts #95060, and relands #86609, with the unintended code generation changes addressed. This patch implements the changes to LLVM IR discussed in https://discourse.llvm.org/t/rfc-update-branch-weights-metadata-to-allow-tracking-branch-weight-origins/75032 In this patch, we add an optional field to MD_prof meatdata nodes for branch weights, which can be used to distinguish weights added from llvm.expect* intrinsics from those added via other methods, e.g. from profiles or inserted by the compiler. One of the major motivations, is for use with MisExpect diagnostics, which need to know if branch_weight metadata originates from an llvm.expect intrinsic. Without that information, we end up checking branch weights multiple times in the case if ThinLTO + SampleProfiling, leading to some inaccuracy in how we report MisExpect related diagnostics to users. Since we change the format of MD_prof metadata in a fundamental way, we need to update code handling branch weights in a number of places. We also update the lang ref for branch weights to reflect the change.
2024-06-11Revert "[llvm][IR] Extend BranchWeightMetadata to track provenance of ↵Paul Kirth1-4/+4
weights" (#95060) Reverts llvm/llvm-project#86609 This change causes compile-time regressions for stage2 builds (https://llvm-compile-time-tracker.com/compare.php?from=3254f31a66263ea9647c9547f1531c3123444fcd&to=c5978f1eb5eeca8610b9dfce1fcbf1f473911cd8&stat=instructions:u). It also introduced unintended changes to `.text` which should be addressed before relanding.
2024-06-10[llvm][IR] Extend BranchWeightMetadata to track provenance of weights (#86609)Paul Kirth1-4/+4
This patch implements the changes to LLVM IR discussed in https://discourse.llvm.org/t/rfc-update-branch-weights-metadata-to-allow-tracking-branch-weight-origins/75032 In this patch, we add an optional field to MD_prof metadata nodes for branch weights, which can be used to distinguish weights added from `llvm.expect*` intrinsics from those added via other methods, e.g. from profiles or inserted by the compiler. One of the major motivations, is for use with MisExpect diagnostics, which need to know if branch_weight metadata originates from an llvm.expect intrinsic. Without that information, we end up checking branch weights multiple times in the case if ThinLTO + SampleProfiling, leading to some inaccuracy in how we report MisExpect related diagnostics to users. Since we change the format of MD_prof metadata in a fundamental way, we need to update code handling branch weights in a number of places. We also update the lang ref for branch weights to reflect the change.
2024-04-30[IR] Use StringRef::operator== instead of StringRef::equals (NFC) (#90550)Kazu Hirata1-2/+1
I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator== outnumbers StringRef::equals by a factor of 22 under llvm/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str".
2024-03-19[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)Stephen Tozer1-14/+17
This is the major rename patch that prior patches have built towards. The DPValue class is being renamed to DbgVariableRecord, which reflects the updated terminology for the "final" implementation of the RemoveDI feature. This is a pure string substitution + clang-format patch. The only manual component of this patch was determining where to perform these string substitutions: `DPValue` and `DPV` are almost exclusively used for DbgRecords, *except* for: - llvm/lib/target, where 'DP' is used to mean double-precision, and so appears as part of .td files and in variable names. NB: There is a single existing use of `DPValue` here that refers to debug info, which I've manually updated. - llvm/tools/gold, where 'LDPV' is used as a prefix for symbol visibility enums. Outside of these places, I've applied several basic string substitutions, with the intent that they only affect DbgRecord-related identifiers; I've checked them as I went through to verify this, with reasonable confidence that there are no unintended changes that slipped through the cracks. The substitutions applied are all case-sensitive, and are applied in the order shown: ``` DPValue -> DbgVariableRecord DPVal -> DbgVarRec DPV -> DVR ``` Following the previous rename patches, it should be the case that there are no instances of any of these strings that are meant to refer to the general case of DbgRecords, or anything other than the DPValue class. The idea behind this patch is therefore that pure string substitution is correct in all cases as long as these assumptions hold.
2024-02-07[RemoveDIs][DebugInfo] Handle RAUW from dead constants (#80837)Stephen Tozer1-0/+6
Ensure that when a constant value dies, all ValueAsMetadata uses of that constant in a DebugValueUser will be replaced with a PoisonValue instead of a nullptr. This has little visible effect currently, as any nullptr metadata uses in a DebugValueUser would be converted to an empty MDNode in the end anyway, but this patch adds an assert that would be triggered by two existing tests without the functional component of this patch: llvm/test/Transforms/Inline/delete-function-with-metadata-use.ll llvm/test/DebugInfo/X86/array2.ll
2024-01-19[AsmParser] Add support for reading incomplete IR (part 1) (#78421)Nikita Popov1-10/+24
Add an `-allow-incomplete-ir` flag to the IR parser, which allows reading IR with missing declarations. This is intended to produce a best-effort interpretation of the IR, along the same lines of what we would manually do when taking, for example, a function from `-print-after-all` output and fixing it up to be valid IR. This patch only supports dropping references to undeclared metadata, either by dropping metadata attachments from instructions/functions, or by dropping calls to certain intrinsics (like debug intrinsics). I will implement support for inserting missing function/global declarations in a followup patch. We don't have real use lists for metadata, so the approach here is to iterate over the whole IR and identify metadata that needs to be dropped. This does not support all possible cases, but should handle anything that's relevant for the function-only IR use case.
2024-01-18[IR] Allow type change in ValueAsMetadata::handleRAUW (#76969)Jannik Silvanus1-1/+1
`ValueAsMetadata::handleRAUW` is a mechanism to replace all metadata referring to one value by a different value. Relax an assert that used to enforce the old and new value to have the same type. This seems to be a sanity plausibility assert only, as the implementation actually supports mismatching types. This is motivated by a downstream mechanism where we use poison ValueAsMetadata values to annotate pointee types of opaque pointer function arguments. When replacing one type with a different one to work around DXIL vs LLVM incompatibilities, we need to update type annotations, and handleRAUW is more efficient than creating new MD nodes.
2024-01-17[RemoveDIs][DebugInfo] Make DIAssignID always replaceable (#78300)Stephen Tozer1-5/+11
This patch is a necessary step to allowing the new non-intrinsic debug info to replace llvm.dbg.assign intrinsics. DIAssignIDs must be able to look up the debug assigns that refer to them, and this patch makes them always be considered "replaceable", allowing us to track and replace uses for non-temporary instances.
2024-01-16[RemoveDIs][DebugInfo] Explicitly convert iterator to pointer for std::distanceStephen Tozer1-1/+1
This is a small patch attempting to fix an error with a prior patch which caused buildbot failures on certain targets; for example: https://lab.llvm.org/buildbot/#/builders/127/builds/60931 The compile error comes from std::distance not having an overload for a std::array iterator and a raw pointer; this patch converts the iterator to a pointer to resolve this. Fixes d499df02
2024-01-16[RemoveDIs][DebugInfo] Add DPVAssign variant of DPValue (#77912)Stephen Tozer1-15/+36
This implements the DbgAssignIntrinsic class as a variant of DPValues - unfortunately this involves increasing the size of the `DebugValueUser` storage by 3x, but this is necessary to enable assigns to be represented, and can be offset in a future patch by splitting DPValue into subclasses such that each variant can store only the fields it needs. This patch does not actually create DPVAssigns in any case; future patches will handle this variant in all cases where generic DPValue handling does not. This patch also does not implement tracking support for DIAssignIDs, which is necessary to find DPVAssigns that reference a given DIAssignID; that is added in a subsequent patch.
2023-12-17[IR] Use llvm::find (NFC)Kazu Hirata1-1/+1
2023-12-05[DebugInfo][RemoveDIs] Reverse order of DPValues from findDbgUsers (#74099)Jeremy Morse1-1/+6
The order of dbg.value intrinsics appearing in the output can affect the order of tables in DWARF sections. This means that DPValues, our dbg.value replacement, needs to obey the same ordering rules. For dbg.values returned by findDbgUsers it's reverse order of creation (due to how they're put on use-lists). Produce that order from findDbgUsers for DPValues. I've got a few IR files where the order of dbg.values flips, but it's a fragile test -- ultimately it needs the number of times a DPValue is handled by findDbgValues to be odd.
2023-11-17Reapply "[DebugInfo] Make DIArgList inherit from Metadata and always unique"Stephen Tozer1-13/+5
This reverts commit 0fd5dc94380d5fe666dc6c603b4bb782cef743e7. The original commit removed DIArgLists from being in an MDNode map, but did not insert a new `delete` in the LLVMContextImpl destructor. This reapply adds that call to delete, preventing a memory leak.
2023-11-17Revert "[DebugInfo] Make DIArgList inherit from Metadata and always unique" ↵Stephen Tozer1-5/+13
(#72682) Reverts llvm/llvm-project#72147 Reverted due to buildbot failure: https://lab.llvm.org/buildbot/#/builders/5/builds/38410
2023-11-17[DebugInfo] Make DIArgList inherit from Metadata and always unique (#72147)Stephen Tozer1-13/+5
This patch changes the `DIArgList` class's inheritance from `MDNode` to `Metadata, ReplaceableMetadataImpl`, and ensures that it is always unique, i.e. a distinct DIArgList should never be produced. This should not result in any changes to IR or bitcode parsing and printing, as the format for DIArgList is unchanged, and the order in which it appears should also be identical. As a minor note, this patch also fixes a gap in the verifier, where the ValueAsMetadata operands to a DIArgList would not be visited.
2023-11-09[llvm][metadata][NFC] Minimize local variable scopes (#68438)Paul Kirth1-10/+6
Don't eagerly construct the MDBuilder until it is used, and reduce the scope of local variables.
2023-11-08Reapply 7d77bbef4ad92, adding new debug-info classesJeremy Morse1-1/+69
This reverts commit 957efa4ce4f0391147cec62746e997226ee2b836. Original commit message below -- in this follow up, I've shifted un-necessary inclusions of DebugProgramInstruction.h into being forward declarations (fixes clang-compile time I hope), and a memory leak in the DebugInfoTest.cpp IR unittests. I also tracked a compile-time regression in D154080, more explanation there, but the result of which is hiding some of the changes behind the EXPERIMENTAL_DEBUGINFO_ITERATORS compile-time flag. This is tested by the "new-debug-iterators" buildbot. [DebugInfo][RemoveDIs] Add prototype storage classes for "new" debug-info This patch adds a variety of classes needed to record variable location debug-info without using the existing intrinsic approach, see the rationale at [0]. The two added files and corresponding unit tests are the majority of the plumbing required for this, but at this point isn't accessible from the rest of LLVM as we need to stage it into the repo gently. An overview is that classes are added for recording variable information attached to Real (TM) instructions, in the form of DPValues and DPMarker objects. The metadata-uses of DPValues is plumbed into the metadata hierachy, and a field added to class Instruction, which are all stimulated in the unit tests. The next few patches in this series add utilities to convert to/from this new debug-info format and add instruction/block utilities to have debug-info automatically updated in the background when various operations occur. This patch was reviewed in Phab in D153990 and D154080, I've squashed them together into this commit as there are dependencies between the two patches, and there's little profit in landing them separately. [0] https://discourse.llvm.org/t/rfc-instruction-api-changes-needed-to-eliminate-debug-intrinsics-from-ir/68939
2023-11-02Revert "[DebugInfo][RemoveDIs] Add prototype storage classes for "new" ↵Jeremy Morse1-60/+1
debug-info" And some intervening fixups. There are two remaining problems: * A memory leak via https://lab.llvm.org/buildbot/#/builders/236/builds/7120/steps/10/logs/stdio * A performance slowdown with -g where I'm not completely sure what the cause it These might be fairly straightforwards to fix, but it's the end of the day hear, so I figure I'll clear the buildbots til tomorrow. This reverts commit 7d77bbef4ad9230f6f427649373fe46a668aa909. This reverts commit 9026f35afe6ffdc5e55b6615efcbd36f25b11558. This reverts commit d97b2b389a0e511c65af6845119eb08b8a2cb473.
2023-11-02[DebugInfo][RemoveDIs] Add prototype storage classes for "new" debug-infoJeremy Morse1-1/+60
This patch adds a variety of classes needed to record variable location debug-info without using the existing intrinsic approach, see the rationale at [0]. The two added files and corresponding unit tests are the majority of the plumbing required for this, but at this point isn't accessible from the rest of LLVM as we need to stage it into the repo gently. An overview is that classes are added for recording variable information attached to Real (TM) instructions, in the form of DPValues and DPMarker objects. The metadata-uses of DPValues is plumbed into the metadata hierachy, and a field added to class Instruction, which are all stimulated in the unit tests. The next few patches in this series add utilities to convert to/from this new debug-info format and add instruction/block utilities to have debug-info automatically updated in the background when various operations occur. This patch was reviewed in Phab in D153990 and D154080, I've squashed them together into this commit as there are dependencies between the two patches, and there's little profit in landing them separately. [0] https://discourse.llvm.org/t/rfc-instruction-api-changes-needed-to-eliminate-debug-intrinsics-from-ir/68939
2023-10-31Metadata: Optimize metadata queries (#70700)Matthias Braun1-26/+19
Optimize metadata query code: - Avoid `DenseMap::operator[]` in situations where it is known that the key exists in the map. Instead use `DenseMap::at()`/ `DenseMap::find()->second`. This avoids code-bloat and bad inlining decisions for the unused insertion/growing code in `operator[]`. - Avoid a redundant `Value::hasMetadata()` check. - Move the `KindID == LLVMContext::MD_dbg` case to `Instruction::getMetadata` and check it first assuming that it can be constant folded after inlining in many situations. The motivation for this change is a regression triggered by e3cf80c5c1fe55efd8216575ccadea0ab087e79c which could attributed to the compiler inlining the insertion part of `DenseMap::operator[]` in more cases while unbeknownst to a compiler (without PGO) that code is never used in this context. This change improves performance and eliminates difference before and after that change in my measurements.
2023-06-09[Metadata] Fix `addAnnotationMetadata` when appending a string tuple to an ↵Zain Jaffal1-1/+3
existing MDTuple. Currently if the MD_Annotation node containd a string node when we add a string tuple node the string will not be preserved. This change fixes that issue. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D152448
2023-05-19[IR] Adds Instruction::setNoSanitizeMetadata()Enna11-0/+5
This patch adds a new method setNoSanitizeMetadata() for Instruction, and use it in SanitizerMetadata and SanitizerCoverage. Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D150632
2023-05-16Partially revert "Use llvm::less_second (NFC)"Kazu Hirata1-1/+3
This reverts part of commit e0039b8d6a5bd05e70203962f448569f2d2ef1c2. This should fix the issue reported in: https://github.com/llvm/llvm-project/issues/62546
2023-05-09[IRGen] Change annotation metadata to support inserting tuple of strings ↵Zain Jaffal1-5/+34
into annotation metadata array. Annotation metadata supports adding singular annotation strings to annotation block. This patch adds the ability to insert a tuple of strings into the metadata array. The idea here is that each tuple of strings represents a piece of information that can be all related. It makes it easier to parse through related metadata information given it will be contained in one tuple. For example in remarks any pass that implements annotation remarks can have different type of remarks and pass additional information for each. The original behaviour of annotation remarks is preserved here and we can mix tuple annotations and single annotations for the same instruction. Reviewed By: paquette Differential Revision: https://reviews.llvm.org/D148328
2023-04-27[PGO]Implement metadata combine for 'branch_weights' of directMingming Liu1-0/+64
callsites when none of the instructions folds the rest away. - Merge cases are added for simplify-cfg {sink,hoist}, based on https://gcc.godbolt.org/z/avGvc38W7 and https://gcc.godbolt.org/z/dbWbjGhaE - When one instruction folds the others in, do not update branch_weights with sum (see test/Transforms/GVN/calls-readonly.ll) Differential Revision: https://reviews.llvm.org/D148877
2023-04-17[nfc][llvm] Replace pointer cast functions in PointerUnion by llvm casting ↵Shraiysh Vaishay1-10/+10
functions. This patch replaces the uses of PointerUnion.is function by llvm::isa, PointerUnion.get function by llvm::cast, and PointerUnion.dyn_cast by llvm::dyn_cast_if_present. This is according to the FIXME in the definition of the class PointerUnion. This patch does not remove them as they are being used in other subprojects. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D148449
2023-01-19[llvm][ir] Purge MD_prof custom accessorsChristian Ulmann1-1/+1
This commit purges direct accesses to MD_prof metadata and replaces them with the accessors provided from the utility file wherever possible. This commit can be seen as the first step towards switching the branch weights to 64 bits. See post here: https://discourse.llvm.org/t/extend-md-prof-branch-weights-metadata-from-32-to-64-bits/67492 Reviewed By: davidxl, paulkirth Differential Revision: https://reviews.llvm.org/D141393
2022-12-21[NFC] Rename Function::isDebugInfoForProfiling to shouldEmit[...]Mircea Trofin1-1/+1
The function name was misleading - the expectation set both by the name and by other members of Function (like isDeclaration or isIntrinsic) would be that the function somehow would "be" "debug info for profiling". But that's not the case - the property indicates (as the comment over the declaration also explains) whether debug info should be emitted (for profiling).
2022-12-06[ADT] Don't including None.h (NFC)Kazu Hirata1-1/+0
These source files no longer use None, so they do not need to include None.h. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-02[IR] Use std::nullopt instead of None (NFC)Kazu Hirata1-2/+2
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-11-09[Assignment Tracking][9/*] Don't drop DIAssignID in dropUnknownNonDebugMetadataOCHyams1-6/+3
The Assignment Tracking debug-info feature is outlined in this RFC: https://discourse.llvm.org/t/ rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir A DIAssignID attachment is debug metadata, so don't drop it. Reviewed By: jmorse Differential Revision: https://reviews.llvm.org/D133292
2022-11-08Reapply [Assignment Tracking][5/*] Add core infrastructure for instruction ↵OCHyams1-0/+41
reference Previously reverted in 41f5a0004e442ae71c8e754fdadb4bd1e172fb2d. Fold in D133576 previously reverted in d29d5ffb6332569e85d5eda5130603bbd8664635. --- The Assignment Tracking debug-info feature is outlined in this RFC: https://discourse.llvm.org/t/ rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir Overview It's possible to find intrinsics linked to an instruction by looking at the MetadataAsValue uses of the attached DIAssignID. That covers instruction -> intrinsic(s) lookup. Add a global DIAssignID -> instruction(s) map which gives us the ability to perform intrinsic -> instruction(s) lookup. Add plumbing to keep the map up to date through optimisations and add utility functions including two that perform those lookups. Finally, add a unittest. Details In llvm/lib/IR/LLVMContextImpl.h add AssignmentIDToInstrs which maps DIAssignID * attachments to Instruction *s. Because the DIAssignID * is the key we can't use a TrackingMDNodeRef for it, and therefore cannot easily update the mapping when a temporary DIAssignID is replaced. Temporary DIAssignID's are only used in IR parsing to deal with metadata forward references. Update llvm/lib/AsmParser/LLParser.cpp to avoid using temporary DIAssignID's for attachments. In llvm/lib/IR/Metadata.cpp add Instruction::updateDIAssignIDMapping which is called to remove or add an entry (or both) to AssignmentIDToInstrs. Call this from Instruction::setMetadata and add a call to setMetadata in Intruction's dtor that explicitly unsets the DIAssignID so that the mappging gets updated. In llvm/lib/IR/DebugInfo.cpp and DebugInfo.h add utility functions: getAssignmentInsts(const DbgAssignIntrinsic *DAI) getAssignmentMarkers(const Instruction *Inst) RAUW(DIAssignID *Old, DIAssignID *New) deleteAll(Function *F) deleteAssignmentMarkers(const Instruction *Inst) These core utils are tested in llvm/unittests/IR/DebugInfoTest.cpp. Reviewed By: jmorse Differential Revision: https://reviews.llvm.org/D132224