[PATCH] D143624: Inlining: Run the legacy AlwaysInliner before the regular inliner.

Dave Green via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 10 10:50:32 PST 2023


dmgreen added a comment.

> I’ll take a look, but this indicates to me that there’s something missing from the vectoriser or later passes rather than a problem with the inliners behaviour.

Sure. I'm not saying that this patch is wrong. I'm just saying that unfortunately it leads to some pretty large regressions. Hopefully we can figure out why and put fixes in place instead of just bodging the tests. Hopefully it's just some missing fold to get the code into the same form it was before, after all the inlining has happened.

I took a look at one of the other cases, it appears to be a pretty unfortunate case of the load order in loops leading to LSR not recognizing chains of instructions due to them being order with offsets [2,0,6,4,10,8,..], as opposed to the order they were in before [0,2,4,6,8,10...], which was an easier to reason about. https://godbolt.org/z/Grv64xoxW. I'm not sure exactly what the best way to fix that would be, without making other cases worse.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143624/new/

https://reviews.llvm.org/D143624



More information about the llvm-commits mailing list