> >> That'll be the first thing to look at. THe costing change was supposed > >> only affect if-then-else constructs, not sets in general. > > > > > > If so, I think the most simple fix is adding more checks on the set > > cost - only check the SET_SRC is if-then-else? > No, the simple fix is to just remove the errant part of the commit :-0 > My tests aren't done, but that does seem to dramatically help. Given it > wasn't supposed to go in as-is and it's causing major problems, I'll > probably just rip it out even though my testing isn't done.
OK, so I'm going to retreat from there, I've another lld issue that needs to be fixed before the LLVM 17 release :) > > > > > Let me run the regression to see if that works - although the current > > vsetvli cost is too high (4x~5x), but I think it should be fixed later > > with a more complete expermantal. > Exactly. I think we need to do a full audit of the costing paths. I've > been slowly devising a way to do that and I'll probably give it to > Raphael or Jivan once I've fleshed it out a bit more in my head. > > The goal is to make sure the costs are sensible and consistent across > the different interfaces. A cost failure is actually a bit hard to find > because all that happens is you get the wrong set of transformations -- > but the code still works correctly, it's just not as efficient as it > should be. It doesn't have to be perfect, but we've clearly got a problem. > > WRT vsetvli costing. That may ultimately be something that's uarch > dependent. We're working on the assumption that vsetvlis are common in > the code stream and they need to be very efficient from the hardware > standpoint (think as cheap or cheaper than any simple ALU instruction). > I probably can't say what we're doing, but I bet it wouldn't be a > surprise to others doing a high performance V implementation. Yeah, it should be cheap, but might be expensive on some HW implementation, anyway our cost model really needs to be tidy up at some point...:P > jeff
