On 9/11/18 9:00 AM, Kyrill Tkachov wrote: > Hi Ramana, > > On 11/09/18 15:55, Ramana Radhakrishnan wrote: >> On Tue, 11 Sep 2018, 14:38 Vlad Lazar, <vlad.la...@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). It looks reasonable to me as well. Essentially it's a new tie-breaker if everything else is equal.
jeff
