Re: [PATCH/RFC] Fix PR optimization/15100

[Roger Sayle <roger at eyesopen dot com>]

On Wed, 12 May 2004, Joern Rennecke wrote:
> > 	* combine.c (distribute_notes): Don't create a dangling
> > 	REG_LIBCALL/REG_RETVAL note.
>
> If there is a REG_LIBCALL note, it should contain an instruction with a
> REG_RETVAL note, and vice versa.  AFAICT we should just abort when tem
> is 0.  Of course that begs the question why the inconsistency appears
> initially  and how to fix it.

I believe that this is the correct fix.  I suspect the problem occurs
when combine manages "combine" the REG_LIBCALL instruction with the
REG_RETVAL instruction replacing them by a single instruction.  It deletes
both original instructions simultaneously and then tries placing the
their original notes on the replacement.  If only the REG_LIBCALL insn or
the REG_RETVAL insn was deleted the existing logic to keep these notes
paired works fine.  However, if combine deletes both instructions, i.e.
we manage to eliminate the libcall entirely, then as pointed out by Kaz
we can potentially end up with dangling/unpaired notes.

I don't think this requires an abort, combine being able to eliminate
a libcall should be a desirable feature.  The apparent inconsistency is
only an intermediate state in combine.  Most other passes only work with
a single instruction at a time, so only combine has to worry about
updating both REG_LIBCAL and REG_RETVAL simultaneously.

Certainly, placing one of these notes on an instruction even if we
can't find its paired partner seems suspect, and the fix does restore
bootstrap on sh-linux.

Roger
--