https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104596
--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> I am trying to understand what you are trying to do.
> You want to mark an insn with a comment
One ore more insns, yes.
> which is emitted during formation of
> the prologue generation as being generated because of a specific option?
Not necessarily in the prologue, it could be anywhere.
> and you don't want to add some extra patterns to do the marking?
>
Yes. Instead, ideally I'd like gcc to provide a gen_comment (or, some
alternative, like the ability to tag insns themselves with a comment that is
output before the insn).
[ Both approaches raise questions in the context of optimizations. But I'm
planning to use this late enough in the compiler not to have to bother with
those questions. ]
> Is there a reason why you want to annotate the instruction in the assembly
> besides just easier to see if it was emitted because of that option or is
> there some assembler reason?
>
No, it's just the former.
> If it is just for debugging, why not while emitting the prologue, print out
> the instruction # that was added (if details dump is enabled) and then use
> -dP to see the instruction outputs the assembler.
>
That's feasible if you're interested in say, one insn (and it still requires
you to go and reproduce the command line to generate the code, add the dump
flags, find the relevant line in the dump file and then find the corresponding
insn in the assembly. If the compiler already emits the comment, all you need
to do is read the assembly).
Another scenario is: I have assembly for an entire executable, including all
libraries, and I want to easily be able to find all insns that where introduced
because of a compiler pass, without having to diff against a version with that
pass disabled.
Note that for nvptx, a library or executable is assembly, so those comments can
still be useful when 'disassembling' an executable. F.i. there are various
workarounds in the nvptx port that introduce insns, and an executable is
hand-editable, so we can do the sort of tinkering of: the executable fails,
this code introduced by the workaround looks suspicious, lets disable it and
see if it passes.
> The other thing you could is have a INSN_NOTE which takes a string which you
> then output during the final scan. This requires adding some extra stuff to
> the rest of the compiler but it should work.
Sure, that would work as well. Though I think the concept just maps very well
on the user-level 'asm ("// comment")'.
