> On 12 Nov 2024, at 18:55, Richard Sandiford <richard.sandif...@arm.com> wrote: > > Wilco Dijkstra <wilco.dijks...@arm.com> writes: >> Hi, >> >>>>> What do you think about disabling late scheduling as well? >>>> >>>> I think this would definitely need separate consideration and evaluation >>>> given the above. >>>> >>>> Another thing to consider is the macro fusion machinery. IIRC it works >>>> during scheduling so if we don’t run any scheduling we don’t get an >>>> opportunity to bring those instructions together? >>>> >>>> That said, I’m not sure the scheduling actually tries to bring macro fused >>>> instructions together rather than simply avoiding moving them apart. >>> >>> I will run the numbers, but if useful, late scheduling could be disabled >>> separately from fusion >>> scheduling. However fusion really shouldn't be done as a scheduling hack - >>> we should use >>> fused RTL patterns like we do for GOT accesses and AES fusion. >> >> I ran the numbers, late scheduling (using the ancient Cortex-A57 model) gives >> 0.23% speedup on SPECINT and 0.73% on SPECFP. I guess the gains come from >> scheduling loads and other critical operations earlier and perhaps improved >> dispatch >> due to increased interleaving of operations. > > Thanks. So yeah, I agree we should keep it. > > I think it was common ground that the benefits are kind-of incidental > (in that the scheduler really is trying to fill Cortex-A57 pipeline bubbles > rather than find a good frontend mix for modern cores) and that it would > be better to try to target the effect that we want directly. But in terms > of whether the switch we have should be on or off, I agree it should be on. > > The patch is OK if there are no objections by Thursday morning UTC.
The patch is fine by me. Thanks for running the numbers. Kyrill > > Richard
