> From: Georg-Johann Lay
> Subject: Re: Could not identify that register is clobbered already
>
> S, Pitchumani schrieb:
> >
> > From: Georg-Johann Lay
> >> 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
>
> The generated code is wrong. You can file a PR. Thanks.
Similar behavior is observed in gcc-4.8 trunk.
Test case : dejagnu test gcc.c-torture/execute/simd-1.c
gcc options : -O1 -mmcu=atmega1280
(snip of assembly)
ldi r30,lo8(res) ; r30/r31 is loaded with address of res
ldi r31,hi8(res) ;
st Z,r24
ldd r31,Y+1 ; Modifying r31 register
sts res+1,r31
sts res+2,r27
sts res+3,r26
sts res+4,r23
...
lds r22,res+4+2
lds r23,res+4+3
ld r24,Z ; regsiter pair r30/r31 is used to load from res
ldd r25,Z+1
ldd r26,Z+2
ldd r27,Z+3
sbiw r24,2
(snip of assembly)
It looks like r31 is corrupted after reload pass.
Shall we consider this as same bug or should we file a new PR.
