Re: DEBUG_INSN that is not an insn

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 11/5/07, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> Hello,
>
> While browsing through the mailing list archives a bit, I noticed
> Alex's project to improve GCC's debug information.  This seems like a
> really interesting and worthwhile project. Alex, maybe you could add a
> Wiki page about this project, in the style of
> http://gcc.gnu.org/wiki/SampleProjectTemplate ... ?
>
> I am worried about some of the things going on in the
> var-tracking-assignments branch.  The thing that worries me most, is
> the introduction of an insn that is not an instruction:
>
> /* An annotation for variable assignment tracking.  */
> DEF_RTL_EXPR(DEBUG_INSN, "debug_insn", "iuuBieie", RTX_INSN)
>
> DEBUG_INSN is more like a note, AFAIU. I couldn't find any discussions
> about this idea, so I don't know if there is "sufficient" concensus
> that this is the right thing to do.
>
> IMHO, anything that is not an instruction should not be true under
> INSN_P.  Yet, INSN_P returns true for DEBUG_INSN.  This is already
> leading to a lot of special-casing of DEBUG_INSN throughout the RTL
> bits of the compiler on the branch.
>
> Also, registers mentioned in DEBUG_INSNs are counted as real uses,
> which is bound to confuse some existing RTL analyses, and makes it
> harder to implement new ones safely.
>
> The same issues arise with DEBUG_STMT for tree-ssa.
>
> Is this really a design that has the necessary support to make the
> branch eligible for merging into the trunk?  What are the reasons for
> using a fake insn instead of a note for DEBUG_INSN?

No, I don't think so.  Also, see

http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00200.html

for a different approach (ok, that's not the current state).  For RTL we chose
to extend SET by a bitmap argument featuring the debug symbols affected
by this set.

Richard.