================ @@ -169,6 +169,47 @@ See the discussion in the section about :ref:`merging locations<WhenToMergeLocation>` for examples of when the rule for dropping locations applies. +.. _NewInstLocations: + +Setting locations for new instructions +-------------------------------------- + +Whenever a new instruction is created and there is no suitable location for that +instruction, that instruction should be annotated accordingly. There are a set +of special ``DebugLoc`` values that can be set on an instruction to annotate the +reason that it does not have a valid location. These are as follows: + +* ``DebugLoc::getCompilerGenerated()``: This indicates that the instruction is a + compiler-generated instruction, i.e. it is not associated with any user source + code. + +* ``DebugLoc::getDropped()``: This indicates that the instruction has + intentionally had its source location removed, according to the rules for + :ref:`dropping locations<WhenToDropLocation>`; this is set automatically by + ``Instruction::dropLocation()``. + +* ``DebugLoc::getUnknown()``: This indicates that the instruction does not have ---------------- dwblaikie wrote:
Wonder whether it's worth splitting these cases from "there could be a right answer here, but it's Too Hard(tm) to find it right now" (places to look to fix bugs/improve location coverage) from "this is unrepresentable" (places that would benefit from representational changes, but aren't otherwise fixable) But I don't feel strongly about it. Otherwise the doc changes look good to me https://github.com/llvm/llvm-project/pull/107279 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
