Seems like a great idea!

I'm not convinced by the approach.

Looks good.

We indeed have a user of Z3 for LLVM coming soon. (it is not upstreamed yet because the binding with Z3 was botched, it would never have been accepted)
To spill the beans: we wrote a more aggressive SCEV Canonicalizer, as a support class. It does not rely on Z3 to perform the transformation itself, but it uses Z3 into the verifier. (mostly to find potential mistakes, but we could use it to find missed opportunities too)

Great! I have some use cases for verifiers, and in general for research purposes it can be quite useful.

In D48338#1138675, @timshen wrote:

Though I can't easily reduce to a test case, the code I'm specifically looking at looks like the following:

%11 = udiv i32 %10, 112
%12 = mul i32 %11, 112
%13 = sub i32 %10, %12
%14 = urem i32 %11, 112
%15 = udiv i32 %10, 12544
%16 = zext i32 %15 to i64
%17 = zext i32 %14 to i64
%18 = zext i32 %13 to i64
%19 = getelementptr inbounds [128 x [112 x [112 x [64 x float]]]], [128 x [112 x [112 x [64 x float]]]] addrspace(1)* %ptr, i64 0, i64 %16, i64 %17, i64 %18, i64 %3

The idea is that %10 is a flat index of %ptr, and the whole GEP should be equivalent to (in C) &%ptr[%10]. This already works for a case where there is no zexts and everything is i32. This patch makes it work with zexts.

That might be related, for instance, such expressions:

In D48338#1137930, @alexandre.isoard wrote:

It transforms: (sext i57 (199 * (trunc i64 (-1 + (2780916192016515319 * %n)) to i57)) to i64) into (sext i57 (-199 + (trunc i64 %n to i57)) to i64) (not sure if that is correct).

In D48338#1137890, @timshen wrote:

What about zext(%a + %b) + %c? I think zext(%a) + zext(%b) + %c is in a much better state than, idk, zext(%a + %b + trunc(%c)).

Ah, you are right, I misinterpreted the purpose.

I have been working on related issue but my strategy is different:

Fixed RUN_ON macro typo

Hello, is there any modifications I didn't apply or do you have any change you would like to see?

Updated the test cases and simplified the power-of-two special case.

Please check I didn't introduce new errors (off by one?).

I added handling for urem by a power-of-two so as to fix the failing test-case.

Fixed the short-circuit. (should be 0, not x)

Updated testcase, outlined into a getURemExpr and added a x urem 1 shortcut.

Added an additional testcase with a loop.