Jeff Law <jeffreya...@gmail.com> writes: > 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.
Damn :) (I did try to clarify what was being tested earlier, but the response wasn't clear.) So how representative is the DFA model being used for the BPI? Is it more "pretty close, but maybe different in a few minor details"? Or is it more "we're just using an existing DFA model for a different core and hoping for the best"? Is the issue width accurate? If we're scheduling for an in-order core without an accurate pipeline model then that feels like the first thing to fix. Otherwise we're in danger of GIGO. Thanks, Richard
