RE: Could not identify that register is clobbered already

[S, Pitchumani]

> -----Original Message-----
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Wednesday, February 13, 2013 4:24 AM
> To: S, Pitchumani
> Cc: gcc@gcc.gnu.org; Denis Chertykov
> Subject: Re: Could not identify that register is clobbered already
> 
> [Removing avr-gcc-list from CC because there is no need to cross-post]
> 
> S, Pitchumani wrote:
> 
> > I was analyzing an issue for avr target (gcc-4.7.2).
> >
> > Issue is that already clobbered register is used after the
> transformation
> > in post reload pass.
> >
> > insns after reload pass:
> >
> > set (reg:HI r24
> >     (const:HI (plus:HI (symbol_ref:HI ("array"))
> >                        (const_int 4))
> >     ))
> > ...
> > parallel set (reg:HI r14
> >              (and:HI (reg:HI r14)
> >                      (const_int 3)))
> >          clobber:QI r25
> > ...
> > set (reg:HI r28
> >     (const:HI (plus:HI (symbol_ref:HI ("array"))
> >                        (const_int 4))
> >     ))
> >
> > After post reload pass, insn-3 transformed as follows:
> >
> > set (reg:HI r28
> >      reg:HI r24)
> >
> > this transformation happened in reload_cse_move2add function.
> >
> > Since r25 is clobbered in insn-2, above transformation (r28/29 <=
> r24/25)
> > become incorrect.
> 
> You have a test case so that this can be reproduced?
> 
> > Function 'move2add_use_add3_insn' sets only r24 info for insn-1 instead
> > of setting info for both r24/25. Function 'validate_change' checks only
> r24
> > info for insn-3 transformation.
> > is it possible to identify clobbered register and avoid transformation?
> 
> Some passes assume that the frame pointer only spans one register, which
> does not hold for the avr target where FP lives in R28/R29.
> 
> Trying to introduce hard_frame_pointer was dropped because the code
> turned out to have unusable had efficiency.  I don't find the patch,
> AFAIR it is Denis' work, thus CCing him.
> 
> But without a test case nobody can tell...

This behavior is observed for dejagnu test case "gcc.dg/var-expand2.c" when 
gcc-4.7.2 is used.

Options used: -O2 -funroll-loops -ffast-math -mmcu=atxmega128b1

But, this issue is not reproducible with gcc trunk (4.8).

Thanks,
Pitchumani