URem operations with constant power-of-2 second operands are modeled as
such. This patch on its own has very little impact (e.g. no changes in
CodeGen for MultiSource/SPEC2000/SPEC2006 on X86 -O3 -flto), but I'll
soon post follow-up patches that make use of it to more accurately
determine the trip multiple.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I would expect that you should be able to showcase the effect with opt -analyze -scalar-evolution-based test:
https://godbolt.org/z/xddz8d (because there's zext(A % B) --> zext(A) % zext(B) matchURem()-driven fold)
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
12857 | What if Expr isn't an zext itself, but it is used by zext (which is the case in the single user of this method)? | |
12860–12861 | What if we had zext(zext(trunc)), so we end up with a wider type than A was? |
llvm/unittests/Analysis/ScalarEvolutionTest.cpp | ||
---|---|---|
1334 | Could you please make a 64-bit version of this test to catch bug with 1u << size if it happens? |
Address comments: use APInt instead unsigned for shift, handle different zext sizes, add test with divisor > 1 << 32.
Thanks!
Not sure if that's possible, because the expression is already in the form zext (trunc ... to iX) to iY and I think if there was an outer zext, it would be already folded into the inner zext.
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
12857 | Hm, I not sure what to do about that case. I think we need to zext (trunc) combo to match that. | |
12860–12861 | Originally the code had a check to ensure the type of the starting expression matched the type of A, but I now updated things to do a ZExt on demand to make A match the type of Expr. | |
12868 | Thanks, updated to use APInt and added a test where the LHS is > 1 << 32. |
What if Expr isn't an zext itself, but it is used by zext (which is the case in the single user of this method)?