Olivier Hainque wrote:
> do we still have a latent problem in this case ?
I believe we do. Here is a C testcase recreating one problematic
situation artificially
char mysym;
char * volatile g;
void foo (long x)
{
char volatile s [x];
register char * volatile ptr asm("11");
asm volatile ("" : : : "25");
ptr = &mysym;
g = ptr;
}
With a recent mainline configured for powerpc-wrs-vxworks,
./cc1 t.c -O2 generates
...
addi 11,31,48
stw 0,g@l(9)
mr 1,11 <===
lwz 0,4(11)
lwz 25,-28(11) <===
mtlr 0
lwz 31,-4(11)
blr
the stack pointer restore was moved prior to the registers restore ops,
despite an attempt at preventing that (as required by the ABI) from
emit_prologue:
(note 39 24 40 2 NOTE_INSN_EPILOGUE_BEG)
(insn 40 39 41 2 (set (reg:SI 11 11)
(plus:SI (reg/f:SI 31 31)
(const_int 48 [0x30]))) t.c:11 -1
...
(insn 43 42 44 2 (set (reg:SI 25 25)
(mem/c:SI (plus:SI (reg:SI 11 11)
(const_int -28 [0xffffffffffffffe4])) [3 S4 A8])) t.c:11 -1
...
(insn 45 44 46 2 (set (mem/c:BLK (reg/f:SI 1 1) [3 A8]) <===
(unspec:BLK [ <===
(mem/c:BLK (reg/f:SI 1 1) [3 A8]) <===
(insn/f 46 45 47 2 (set (reg/f:SI 1 1)
(reg:SI 11 11)) t.c:11 -1
In the specific case at hand, there's no mem access dependence
established between insns 45 and 43, so both 45 and 46 are allowed to
move up.
While I see what's going on in the dependency computation here, I'm not
sure whether the correction should be in this area or if the mem accesses
are not supposed to be claimed conflicting anyway, in which case the stack
tie insn should be adjusted.
Olivier
