latent issues with stack_ties on ppc ?

[Olivier Hainque <hainque at adacore dot com>]

Hello,

A question on the stack/frame_tie circuitry for a ppc/V4_abi target, to
check about a potential remaining latent problem in this area.

With gcc 4.3, we had a case where the prologue generation emitted
a sequence like

 (insn 191 190 192 9 t.adb:30:8 (set (reg:SI 25 25)
       (mem/c:SI (plus:SI (reg:SI 11 11)
               (const_int -28 [0xffffffffffffffe4])) [11 S4 A32])) -1 (nil))
 ...
 (insn 199 198 200 9 t.adb:30:8 (set (mem/c:BLK (reg/f:SI 1 1) [11 A8])
       (unspec:BLK [
               (mem/c:BLK (reg/f:SI 1 1) [11 A8])

 (insn 200 199 201 9 t.adb:30:8 (set (reg/f:SI 1 1)
       (reg:SI 11 11)) -1 (nil))

insn 199 was a stack_tie intended to prevent the stack pointer restore from
moving prior to the register restores, which failed with sched2 moving both
the tie and the sp restore up, prior to insn 191. My understanding is that
that was allowed by the tie referencing the mem with r1 while the restores
access the frame via r11.

There were many PRs about similar issues, on ppc and other targets,
e.g. 38644, or 44199.

PR 44199 resulted in changes for powerpc, which introduced variations in a
couple of tie insertions. We can, however, still observe epilogue patterns
similar to the above one out of mainline today, e.g.

   (note 54 31 55 2 NOTE_INSN_EPILOGUE_BEG)
   ...
   (insn 58 57 59 2 (set (reg:SI 25 25)
       (mem/c:SI (plus:SI (reg:SI 11 11)
           (const_int -28 [0xffffffffffffffe4])) [6 S4 A8])) im.adb:10 -1
   ...
   (insn 60 59 61 2 (set (mem/c:BLK (reg/f:SI 1 1) [6 A8])
       (unspec:BLK [
           (mem/c:BLK (reg/f:SI 1 1) [6 A8])
           ] 5)) im.adb:10 -1

   (insn/f 61 60 62 2 (set (reg/f:SI 1 1)
       (reg:SI 11 11)) im.adb:10 -1
    (expr_list:REG_CFA_DEF_CFA (reg/f:SI 1 1)
       (expr_list:REG_CFA_RESTORE (reg/f:SI 31 31)
           (expr_list:REG_CFA_RESTORE (reg:SI 25 25)

for the Ada testcase below, at -O2 with a compiler configured for
powerpc-wrs-vxworks.

While I don't quite see what would prevent sched2 to issue the troublesome
reordering, I haven't been able to trigger it so far.

So my question is:

  Is there indeed something blocking the tie/sp move up here (new since 4.3) ?

  Or do we still have a latent problem in this case ?

Thanks in advance for your feedback,

Olivier

--

with Machine_Code;

function Im (X : Integer) return Integer is
   S : String (1 .. X);
   pragma Volatile (S);
begin
   Machine_Code.Asm
     ("nop", Clobber => "25", Volatile => True);
   return X;
end;