On 10/30/24 4:05 AM, Richard Sandiford wrote:
Vineet Gupta <vine...@rivosinc.com> writes:
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.
Right, that's the key. The current algorithm was tuned on an in-order
core for which GCC already had a relatively accurate pipeline model.
The question is whether this is better on a core like that: that is,
on an in-order core for which GCC has a relatively accurate pipeline model.
No amount of benchmarking on out-of-order cores will answer that.
Somewhat surprisingly, we don't AFAIK have a target hook for "is the
current target out-of-order?". Why not make the target hook that
instead? I think everyone agrees (including me in the previous
thread) that the current behaviour isn't right for OoO cores.
If someone has an OoO core that for some reason prefers the current
approach (unlikely), we can decide what to do then. But in the meantime,
keying of OoO-ness seems simpler and easier to document.
But the data from the BPI (spacemit k1 chip) is an in-order core.
Granted we don't have a good model of its pipeline, but it's definitely
in-order.
jeff
