On 10/29/24 11:51, Wilco Dijkstra wrote: > Hi Vineet, >> I agree the NARROW/WIDE stuff is obfuscating things in technicalities. > Is there evidence this change would make things significantly worse for > some targets?
Honestly I don't think this needs to be behind any toggle or made optional at all. The old algorithm was overly eager in spilling. But per last discussion with Richard [1] at least back in 2012 for some in-order arm32 core this was better. And also that's where the wide vs. narrow discussions came up and that it really mattered, as far as I understood. [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659847.html > I did a few runs on Neoverse V2 with various options and > it looks beneficial both for integer and FP. On the example and options > you mentioned I got 20.1% speedup! This is a very wide core, so wide > vs narrow is not the right terminology as the gains are on both. Would you be able to test this on some inorder core, maybe a 32-bit one But agree lets just drop the wide vs. narrow terminology and rephrase this in terms of spill aggressiveness. >> How about TARGET_SCHED_PRESSURE_SPILL_AGGRESSIVE with true (default) being >> existing behavior >> and false being new semantics. >> Its a bit verbose but I think clear enough. > Another option may be to treat it like a new type of pressure algorithm, eg. > --param sched-pressure-algorithm=3 or update one of the existing ones. > There are already too many features in the scheduler - it would be better > to reduce the many variants and focus on doing really well on modern cores. A purist might argue it is not really new algorithm, just a little tweak to model algo. But I agree there's a zoo of sched toggles out there so this might be ok. Anyhow I'm fine either way, whatever is more palatable for the community / maintainers. @Jeff what say you. And while we are at it - I'd prefer the new behavior to be default for all targets unless they explicitly opt out (and it would be insightful understanding those not made up cases). But given how late we are in the release cycle, I think it would be kosher to keep the old behavior for now and maybe after gcc-15 is released we can flip the switch and deal with any potential fallout. Thanks a bunch for giving this a look. -Vineet
