This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Schedule by INSN_COST in case of tie
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: Vlad dot Lazar at arm dot com, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Vladimir Makarov <vmakarov at redhat dot com>, gnu at the-meissners dot org, wilson at tuliptree dot org, nd <nd at arm dot com>
- Date: Tue, 11 Sep 2018 16:03:07 +0100
- Subject: Re: [PATCH] Schedule by INSN_COST in case of tie
- References: <5B97C539.1020009@arm.com> <CAJA7tRaKdX5q0=N8EswsDrwpTQtY=SNz_6G2MqGicvMNAUqr_g@mail.gmail.com> <5B97D87F.9050100@foss.arm.com>
>
> > 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.
Ah, I was conflating rtx_cost with INSN_COST, sorry about the noise.
Ramana
> 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.
> > >
>