Hi Sjoerd,

LGTM. Thanks.

I am not suggesting that I will ask you to refactor by the way! I just want to spend some more time looking at these functions and having a play with your other two patches.

Hi Diogo,

Hi Diogo,

Hi Diogo,

Hi Sjoerd,

Many thanks Eli!

Hi Sjoerd,

Thanks for the feedback. I've removed my new test and updated the existed one. Also modified the code style.

Hi Diogo,

Hi Diogo,

Hi Diogo,

LGTM.

LGTM, thanks!

LGTM, thanks Max!

LGTM, cheers.

I had missed that the output operands where not the same, indeed it's not convenient and readability is also a valid reason.

Hi Sander,

Ah, thanks for clearing that up for me.

Ok, for my sanity, I don't think the document descriptions match up, do you agree? The useful link you pointed me to only shows Xm as the scalar index, but 5.2.2 of the PDF supplement shows that the index can be scaled with LSL.

Thanks!

Hi Sander,

Great stuff, LGTM.

Hi Sander,

I think you're fine to commit tests without review.

LGTM, cheers!

Now that we're only looking for nsw with equality predicates, we should now be able to use nuw as well as nsw. HasNoSignedWrap has been renamed and queries hasNoSelfWrap, while still attempting to also search for nsw.

Sure Max, thanks for doing the testing.

Hi Sjoerd,

After starting and playing around for the day, I've got to the root question of: why do we do the wrap checks anyway? Aren't the following range checks in the IsIncreasing/Decreasing blocks enough?

Hi Max,

Split the helper function out to D45481 and rebased.

Thanks. Yes, I will do.

The trunc_i64_mask_srl test has been added. This example showed that I had a typo in my patch, I was checking the user of N and not 'N0'! So I've also renamed some variables to reduce the chance of possible confusion again.

I kindly got a reproducer from @nemanjai so now I've, hopefully, sorted out the issue that was causing big endian stage two builders to fail.

Hi Max,

Hi Dave,

LGTM

LGTM.

Sorry for the delay, LGTM. Thanks.

Review: https://reviews.llvm.org/D44515

Hi Dave,

Makes sense, LGTM.

Committed in https://reviews.llvm.org/rL328480

Thanks for the review and your help. I'll make the changes and commit at the start of next week. I'll also prepare the patch for the decreasing case.

Hi Max,

Hi Sjoerd,

Slight format change and added AvailableAtLoopEntry check in CannotBeMinInLoop.

Thanks Max, I've now:

• corrected the loop guard logic, including using the entry instead of backedge guard.
• extracted the bound checking into one function, merging the Max check into it.

I've replaced SumCanReachMax with SumCannotBeMaxInLoop, which uses similar logic to the new CannotBeMinInLoop, querying SCEV's LoopBackedgeGuardedBy. These two updated checks are need together to get this to work. Other changes:

• Removed whitespace.
• re-inserted the range metadata into test.
• bracket style changes

Thanks for the comments, I've made these changes:

• CanBeMin has now been replaced with CannotBeMinInLoop.
• The function arguments have been renamed and reordered.
• KnownNonNegative check removed.
• debug comments removed.

Hi Sjoerd, this LGTM.

Added forgotten test.

I'm happy to see this! LGTM with just one small comment, no need to re-review. Thanks!

Thanks, LGTM.

Could you provide me with an example to illustrate your concern please? I keep going around in circles and I just see either the number of instructions or register pressure being reduced. Could the codegen of my new tests be improved?

Yes, this is a really nice approach for lower constant bounds. My transform selects a region of conditionally executed blocks and then attempts to hoist conditional statements into the head block of that region. Currently I can find loop unrolled induction variable idioms as well as finding a connected path of conditional values. From there I can produce a fast path free of compares and branches, as well as leaving the original code as a fallback. I also split and remove selects because performing conditional moves is still expensive on our small cores as well as the increased register pressure they create.

Just FYI, I am also currently working on a pass to handle slightly more generic cases within the loop body, such like:

Hi John,

Thanks John, I'll try those changes.

Fixed typo.

LGTM, thanks.