Re: Confusion about delay slots and using condition-code register

[Hans-Peter Nilsson]

On Wed, 6 Mar 2013, Alan Lehotsky wrote:

> So, am I constructing my RTL incorrectly?

No.

>  Do I need to be
> making the clobbers inside a parallel instead of just emitting
> them sequentially?

Exactly.

> (define_insn "*addsi"
>  [(set (match_operand:SI  0 "nonimmediate_operand" "=rm,rm,rS,rm")
>(plus:SI (match_operand:SI 1 "nonimmediate_operand"  "%0, 0, 0,rm")
> (match_operand:SI 2 "general_operand"   "QI, K, i,rm")))]
> ,

Missing clobber.

That's right, define_insn has an implicit parallel when more
than one RTL clause is present, but you must emit one explicitly
in define_expand.

brgds, H-P

Re: Could not identify that register is clobbered already

[K_s, Vishnu]

> 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.