Re: [PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)

[Kenneth Zadeck <Kenneth dot Zadeck at NaturalBridge dot com>]

On 10/14/07, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> > > > I think this demonstrates that REG_LIBCALL_ID is a bad idea: we now have
> > > > insns between REG_LIBCALL and REG_RETVAL notes that don't seem to be part
> > > > of the libcall sequence.
> > >
> > > Which is simply a bug, not indicitative bad idea.
> >
> > Properly fixing the bug would mean adding code all over the RTL middle-end to
> > propagate REG_LIBCALL_ID .  The semantics of libcalls is clear: all insns
> > between REG_LIBCALL and REG_RETVAL are part of the libcall sequence.
> 
> Clear != useful :)
> 
> For the record, REG_LIBCALL_ID also has very clear semantics.
> REG_LIBCALL_ID signifies the current instruction is part of a libcall
> sequence. All insns that are part of the same libcall share the same
> ID number.
> 
> 
> >
> > > It's only a bad idea if you think doing linear walks all the time to
> > > figure out whether an INSN is part of a libcall is a good idea.
> >
> > Can't we just do it only one time?  I'll give it a try.
> 
> Why make DCE slower instead of fixing the bug?
> 
> >
> > > IMHO, REG_LIBCALL and REG_RETVAL is the real bad idea.
> >
> > Possibly, but I think that trying to undo it with REG_LIBCALL_ID doesn't help.
> 
> Why?
> It is an incremental step towards fixing the underlying problem.

Eric, 

While, I belive that it will be possible for you to make dce not need
the LIB_CALL_ID, I think that it misses the points that danny was
trying to make.

We added the LIB_CALL_ID because we foresaw that as we modernize the
rtl passes, that more and more of these passes will be using either
use-def or def-use chains.  For these optimizations, you rarely make
linear passes over the instructions, you simply follow the chains from
one insn of interest to another.  The LIB_CALL_ID provides a simple
constant time test to find out if you have landed inside of a lib
call.  Removing this structure will only make it harder to add passes
that only deal with the instructions of interest and essentially
forces us into the endless inefficient rescanning of blocks paradyme
that the rtl passes are famous for.

I have not looked at this bug.  I am happy to if you want.  I am sure
that it will be trivial to modify the pass that moved/created the insn
in the middle of the libcall to inherit the LIB_CALL_ID from the
previous insn. 

Kenny