I think the example is correct.
Even before this patch:
TC > 0 is translated to max (TC, 1)
TC < 99 is translated to min (TC, 98)

In D141823#4092531, @mkazantsev wrote:

I think this needs stronger test coverage. At least I want tests for all operations (either IR tests or unittests in CPP, whatever is easier) exercising corner case scenarios, such as bit width overflow with mul.

I wonder if it might make sense to address this first? I'm a bit worried that the only test coverage for this functionality we have right now is very indirect, by the effect the multiple has on ranges. It would be great if we could test this functionality directly based on the trip multiple.

ping

• added a CondGuardInst that consists of assumes and guards
• added to AC's basic.ll test

In D141850#4064581, @alonkom wrote:

In D141850#4064477, @caojoshua wrote:

The improved trip multiples from the test results look good. Ordering in applyLoopGuards is an issue. However, I think we can simplify this down a bit. What if we always applied min/max first, before we apply divisibility guards? For example, given:

__builtin_assume(TC % 8 == 0);
__builtin_assume(TC > 0);
__builtin_assume(TC < 100);

1. apply max: umax(1, TC)
2. apply min: umin(100, umax(1, TC))
3. apply divisibility info: 8 * (umin(100, umax(1, TC))) / 8

This makes divisibility info obvious. And traversing the SCEV, we can still see TC > 0 and TC < 100. I believe that if we always apply max/min first, we will never lose this info. This approach seems much simpler and easier to understand.

FYI. I haven't been around that long, and this change is non-trivial enough where I prefer a longstanding developer to give the final approval. I will still be around to give my thoughts.

Thanks for the reply.
This works in this example, but what would happen if we had only these assumes:

__builtin_assume(TC % 8 == 0);
__builtin_assume(TC > 0);

In that case, we would have created the following SCEV:

8 * (umax(1, TC) / 8)

since umax(1, TC) may still be between [1,7], when we divide it by 8, and multiply by 8, we get 0. So this doesn't preserve the fact that TC > 0.
In order to do that we must align up 1 to 8, and then umax(8, TC) / 8 is always > 0.

The improved trip multiples from the test results look good. Ordering in applyLoopGuards is an issue. However, I think we can simplify this down a bit. What if we always applied min/max first, before we apply divisibility guards? For example, given:

What is the relation to https://reviews.llvm.org/D128701? Seems maybe you should close the other one.

In D141823#4057047, @nikic wrote:

In D141823#4056673, @caojoshua wrote:

In D141823#4055951, @nikic wrote:

Precommit tests please.

What is precommit test? I've been running llvm-lit llvm/test

Commit the new tests with baseline checks (without your patch), and then rebase on top, so it only shows diffs.

• Fix typos
• Don't assume multiples hold through truncation, unless they are a power of 2
• only show diffs for updated test outputs

In D141823#4055951, @nikic wrote:

Precommit tests please.

• support UMinSequential. Add a test (see note below)
• single isa<SCEVMinMaxExpr>(S) instead of checking each subtype
• fix code style based on comments

Thanks for review. Implemented all feedback.

Add a test where trip multiple is 1

edit comment in test

ping

In D141243#4035889, @nikic wrote:

We should add support for guard intrinsics to AssumptionCache instead. For all practical purposes, they need the same handling, and it makes little sense that we keep implementing separate handling for assumes and guards each time.

Added suggested note that print<scalar-evolution> is needed to populate scev caches. I don't have commit access right now. I sent a request today, but can I get help merging this for now?

Added note that print<scalar-evolution> is used to populate scev caches

• explicit type of ProcessInstr, do not pass it to itself as parameter
• if I is in AftBlocks, we don't need to check its parent is in LocBB
• remove unnecessary run from test

Add -verify-scev to test

ping

Thanks for the review. I am not a committer. Can I get help merging this? I have the commit in https://github.com/caojoshua/llvm-project/commit/8c5290e665a5e0c9276d6dcc0a1a56e3e23da27c

Can I get help merging this? I'm not a committer. I have the patch in https://github.com/caojoshua/llvm-project/commit/cac29ca43207f316e2b0904bee45d778d903a76e

update test with update_test_checks.py

Change redundant ifs into asserts. Change constant range check to use CR1.icmp(icmp_ult, CR2).

In D139109#3978212, @fhahn wrote:

It looks like this tries to address the same issue as D138526. Might be goo to sync up with @caojoshua

In D138526#3962885, @fhahn wrote:

This seems to try to unswitch every select, but https://github.com/llvm/llvm-project/issues/58122 would only require unswitching conditions that are fed by selects with (some) constant values. Would it be possible to just unswitch such branches, rather than all selects?

ping

ping

I have my git commit in in my github fork

In D137893#3923303, @avogelsgesang wrote:

LGTM, with small nit:

There is a typo in the commit description

I did not write a dedicated this for this change

should be

I did not write a dedicated test for this change

Please fix before merging