DEBUG_INSN that is not an insn

DEBUG_INSN that is not an insn

[Steven Bosscher]

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?

Thanks,

Gr.
Steven

Re: DEBUG_INSN that is not an insn

[Richard Guenther]

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.

Re: DEBUG_INSN that is not an insn

[Eric Botcazou]

> 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.

I share your concerns, but I've not looked at the specifics.

-- 
Eric Botcazou

Re: DEBUG_INSN that is not an insn

[Alexandre Oliva]

On Nov  5, 2007, "Steven Bosscher" <stevenb.gcc@gmail.com> wrote:

> 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.

In some senses, yes.  In others, no.

It is a note in the sense that we don't generate code for it.

It's an insn in the sense that optimization passes need to adjust
references in it as they modify the code elsewhere.

So it's more like a USE insn, except that it's a weak USE, in that
optimization passes shouldn't refrain from performing optimizations
just because of such weak USEs.

> 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.

I don't think there's any consensus, indeed.  What I have is a
proposal of WIP, but I'm quite convinced that there's no better
alternative.  See http://gcc.gnu.org/ml/gcc/2007-11/msg00176.html for
the rationale on the design I've chosen.

> Also, registers mentioned in DEBUG_INSNs are counted as real uses,

Except when they aren't because I've modified the counting routines so
as to disregard them ;-)

> which is bound to confuse some existing RTL analyses, and makes it
> harder to implement new ones safely.

The alternative is to keep them out of band, which makes it even more
likely that they are forgotten and left out of date.  And since we
don't have comprehensive debug info testing infrastructure, we have
silent failures.  With the approach I've taken, there's still a
possibility of silent failures in debug info, but it's far less
likely, for the most common failure mode I've observed (with the
caveat that I don't have a debug info testsuite) has been that of
failure to perform optimizations because of the presence of debug
annotations.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: DEBUG_INSN that is not an insn

[Alexandre Oliva]

On Nov  5, 2007, "Steven Bosscher" <stevenb.gcc@gmail.com> wrote:

> Alex, maybe you could add a Wiki page about this project

Done, at last! :-)

http://gcc.gnu.org/wiki/Var_Tracking_Assignments

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: DEBUG_INSN that is not an insn

[Steven Bosscher]

On Dec 20, 2007 9:00 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Nov  5, 2007, "Steven Bosscher" <stevenb.gcc@gmail.com> wrote:
>
> > Alex, maybe you could add a Wiki page about this project
>
> Done, at last! :-)
>
> http://gcc.gnu.org/wiki/Var_Tracking_Assignments

Very nice. Thanks!

Gr.
Steven