@mkazantsev I made some changes due to the rebase on https://reviews.llvm.org/D145230 which was merged recently.
Should be ok, but let me know if it looks fine to you

@mkazantsev let me know if you have any other comments

In D141850#4152680, @caojoshua wrote:

Why was this reverted?

@mkazantsev Let me know if you have any other comments

@mkazantsev can you commit on my behalf? I'm still having some github issues

In D141850#4072675, @caojoshua wrote:

After this patch, depending on the assume processing order applyLoopGuards could create the following SCEV:
max(min((8 * (TC / 8)) , 96), 8)

This example looks wrong. I think min/max should be switched. Should be

min(max((8 * (TC / 8)), 96), 8)

Please update description.

---

In terms of overall approach, I'm not sure. Feels a bit hacky to have custom logic to check that an expressions is a min/max of mul/div. I'll let others chime in here.

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.

In D141850#4057996, @caojoshua wrote:

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

Can you make the commit title more specific, and add more info in the commit message? In particular, I would like to see something like:

after applyLoopGuards, turns <A> into <B>

where A and B are SCEV expressions.

Other information like, what the problem was before, and how you address it, is also helpful. I would suggest looking at the git log of ScalarEvolution.cpp for examples of descriptive commit messages. This will save the reviewers time, and will be helpful when people look at the git log/blame.

Ping. Can you please address this change?

In D130014#3706032, @RKSimon wrote:

@alonkom Please can you send me your email details for the git commit message?

In D130014#3693394, @RKSimon wrote:

LGTM - I still expect we'll end up having to add MVT::v3i1 at some point - but since we've done without it with various v3iX types already it can probably wait for now.

In D130014#3668072, @RKSimon wrote:

which target is this from - and does a MVT::v3i1 need adding at the same time?

In D126460#3580946, @fhahn wrote:

In D126460#3580497, @alonkom wrote:

In D126460#3579739, @fhahn wrote:

LGTM, thanks!

Can you please submit it on my behalf?
I still have commit permission issues

Sure, please let me know what name & email to use for the git authorship.

In D126460#3579739, @fhahn wrote:

LGTM, thanks!

I'm having Github commit permission issues so I would appreciate if someone can submit it on behalf of me

In D56270#1352596, @craig.topper wrote:

How do you get your target to be able to type legalize an abs of any type? The interface for enabling custom legalization requires calling setOperation with a specific type does it not?

In D56270#1351232, @craig.topper wrote:

Do you do custom type legalization for ABS in your target? There's no support for legalizing it in the target type independent legalizer.

The test is now placed in memdep.ll