[PATCH] sched: Do not reorder RTX_FRAME_RELATED_P insns (PR78029)

[Segher Boessenkool]

On Wed, Oct 26, 2016 at 12:48:54PM +0200, Bernd Schmidt wrote:
> On 10/25/2016 06:57 PM, Segher Boessenkool wrote:
> >This patch makes scheduling not reorder any RTX_FRAME_RELATED_P insns
> >(relative to each other), to fix PR78029.  I originally was a bit worried
> >that this would degrade code quality, but it seems to even improve it:
> >more other insns are scheduled between the prologue insns.
> >
> >The problem in PR78029:
> >We have two insns, in this order:
> >
> >(insn/f 300 299 267 8 (set (reg:DI 65 lr)
> >        (reg:DI 0 0)) 579 {*movdi_internal64}
> >     (expr_list:REG_DEAD (reg:DI 0 0)
> >        (expr_list:REG_CFA_RESTORE (reg:DI 65 lr)
> >            (nil))))
> >...
> >(insn/f 310 268 134 8 (set (mem/c:DI (plus:DI (reg/f:DI 1 1)
> >                (const_int 144 [0x90])) [6  S8 A8])
> >        (reg:DI 0 0)) 579 {*movdi_internal64}
> >     (expr_list:REG_DEAD (reg:DI 0 0)
> >        (expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 1 1)
> >                        (const_int 144 [0x90])) [6  S8 A8])
> >                (reg:DI 65 lr))
> >            (nil))))
> >
> >and sched swaps them (when compiling for power6, it tries to put memory
> >stores together, so insn 310 is moved up past 300 to go together with
> >some other store).  But the REG_CFA_RESTORE and REG_CFA_OFFSET cannot be
> >swapped (they both say where the orig value of LR now lives).
> 
> How are these two insns generated, and how does this differ from a 
> normal prologue? Can you post the entire dump (maybe to bugzilla) so we 
> can verify whether the code generation makes sense?

The first is a piece of epilogue and the second a piece of prologue
(both those components need two insns, we cannot store LR to memory
directly, so it is moved via GPR0).  These are generated by separate
shrink-wrapping.  PR78029 has a testcase (also not the compilation
options).

This patch will also most likely fix PR77687, a problem that has been
plaguing us for ages.

Separate shrink-wrapping creates this not-all-that-smart code because
the profile is quite messed up, and spread_components isn't super smart
to begin with.  I'll have a patch for that soon, but even with it (and
also without separate shrink-wrapping as far as I see) sched should not
reorder insns that have CFI notes that conflict.

I attached a dump (before sched2) to PR78029.

Thanks,


Segher