================ @@ -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 ---------------- SLTozer wrote:
I originally considered a `DebugLoc::FixMe()` option for distinguishing those cases - in practise as I went around applying annotations, I found that in most cases where it wasn't clear what the right location was, it also wasn't clear what the solution would be or whether one would be possible without some broader change. At the moment, I _lean_ towards using a single "unknown" location, and if we find concrete unrepresentable cases then the next step would be to create a new special location kind for them; that way, we can also get a view as to what % of instructions end up without a location as a result of that particular limitation. With that said, there is at least one clear set of cases right now that is just a "FixMe" (a lot of instructions produced by the vectorizers), so it would still be useful to have - I could go one way or the other. 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
