[PATCH] Schedule by INSN_COST in case of tie

[Kyrill Tkachov]

Hi Ramana,

On 11/09/18 15:55, Ramana Radhakrishnan wrote:
> On Tue, 11 Sep 2018, 14:38 Vlad Lazar, <vlad.lazar@arm.com> wrote:
>
> > Hi.
> >
> > This patch makes the scheduler prefer instructions with higher cost if two
> > given instructions are equally good.
> > Issuing more restricted instructions first is particularly useful on
> > in-order cores because it increases the
> > number of dual issue opportunities.
> >
> > For example, on AArch64, instead of:
> >
> >    add     x11, x2, 96
> >    mov     x4, x2
> >    mov     w10, 1
> >    ldrh    w5, [x0]
> >    ldrh    w13, [x0, 2]
> >    ldrh    w9, [x0, 4]
> >    ldrh    w12, [x0, 6]
> >    b       .L759
> >
> > Generate:
> >
> >    ldrh    w5, [x0]
> >    add     x11, x2, 96
> >    ldrh    w13, [x0, 2]
> >    mov     x4, x2
> >    ldrh    w9, [x0, 4]
> >    mov     w10, 1
> >    ldrh    w12, [x0, 6]
> >    b       .L759
> >
> > Bootstrapped and regtested on aarch64-none-linux-gnu and there are no
> > regressions.
> > Ok for trunk?
> >
>
> This to me feels like the wrong approach as it feels like you are assuming
> INSN_COST is latency in some way ? Surely, we shouldn't be introducing
> INSN_COST based stuff into the scheduler.
>
> Have you investigated  using TARGET_SCHED_ADJUST_COST (IIRC, look for the
> right name in the internals documents) and such hooks that come from the
> scheduler rather than trying to massage INSN_COST into the target
> independent parts of the scheduler ?
>

In the context of haifa-sched.c, INSN_COST is the latency cost.
It is not the rtx_cost of the insn, as used by combine and others.
So this approach looks reasonable to me (though I haven't done a deep review).

Thanks,
Kyrill

> Ramana
>
>
> >
> > Thanks,
> > Vlad
> >
> > gcc/
> > Changelog for gcc/Changelog
> > 2018-09-11  Vlad Lazar  <vlad.lazar@arm.com>
> >
> >         * haifa-sched.c (rank_for_schedule): Schedule by INSN_COST.
> >         (rfs_decision): New scheduling decision.
> >