Re: RFA: patch solving PR37514

[Vladimir Makarov <vmakarov at redhat dot com>]

Jeff Law wrote:
> Vladimir Makarov wrote:
> >   The following patch fixes a latent reload inheritance bug triggered 
> > by IRA.  The details of the bug could be found in
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37514
> >
> > The patch was successfully tested on sh and itanium (as one more 
> > target using INC/DEC in addressing).  Is it ok to commit?
> >
> > 2008-11-24  Vladimir Makarov  <vmakarov@redhat.com>
> >
> >    PR rtl-optimization/37514
> >    * reload1.c (emit_input_reload_insns): Invalidate reg_last_reload
> >    for input register too.
> Presumably you can't do this in inc_for_reload because incloc is a MEM 
> and you can't map from the MEM back to the appropriate REG, right?
Yes, right.
> I think the comment in the new code is rather confusing.  I think you 
> could just adjust the comment from inc_for_reload and note how 
> inc_for_reload and your new code differ in how they handle pseudos 
> living in memory.
>
> With the comment adjustment, this patch is fine.
Jeff, sorry for waisting your time on review of the patch.  After some 
thoughts I decided to work more on the problem.  Although the current 
patch is safe, it removes some optimization opportunities for 
inheritance of incremented values.

If we increment pseudo P and use hard register A for this, we still 
could use A in the subsequent insns for P (if A is not modified).  The 
current patch prohibits it.  What we need is to invalidate inheritance 
for P set in a previous insn if the inheritance for P is not set for the 
current insn.

In the test in consideration we have

p551<-p434:   p551 value now in hard register 1 (that is a reload reg 
for p434).  So reg_last_reload_reg[551] is (REG 1).
...
p289<-mem[p551++]: hard register 0 is a reload reg for p551++  but for 
some reason we don't set up reg_last_reload_reg[551] in this insn.

usage p551:  reload uses hard register 1 (reg_last_reload_reg[551]) here 
which is wrong.