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
