This is an archive of the discontinued LLVM Phabricator instance.

[IndVarSimplify] Rotate exit comparisons to make them more invariant
AbandonedPublic

Authored by reames on May 14 2019, 3:19 PM.

Details

Summary

(If anyone has better terminology for this than "rotation", please throw it out.)

If we have a loop exit test which involves a loop varying binary op compared to a loop invariant value, see if we can invert that binary op on both sides of the comparison. This doesn't directly remove any instructions, but does make more of the computation loop invariant. This both helps directly for long running loops, and also simplifies the loop structure such that other transforms may run.

Diff Detail

Event Timeline

reames created this revision.May 14 2019, 3:19 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 14 2019, 3:19 PM

Hm, it looks like there may be an overlap w/LFTR. With a slightly less reduced test case, we end up being able to prove nsw/nuw on several of the adds if we allow CVP to do so. We may be better off fixing https://bugs.llvm.org/show_bug.cgi?id=31181, and then extending LFTR slightly to catch the remaining cases.

I'd appreciate review in case I missed something, but I think I'm going to delay landing this until I've dug into that option a bit.

Hm, it looks like there may be an overlap w/LFTR. With a slightly less reduced test case, we end up being able to prove nsw/nuw on several of the adds if we allow CVP to do so. We may be better off fixing https://bugs.llvm.org/show_bug.cgi?id=31181, and then extending LFTR slightly to catch the remaining cases.

I'd appreciate review in case I missed something, but I think I'm going to delay landing this until I've dug into that option a bit.

There's a lot less overlap then there first looked to be. My test cases turned out to be over-reduced in another manner. :) This approach has the advantage of a) not requiring a statically computable loop exit count and b) working on multiple exit loops. LFTR could probably be extended to handle (b), but (a) is quite useful on it's own. I think having both is quite useful.

reames abandoned this revision.Jun 17 2019, 2:14 PM

No longer actively pursuing. The idea is reasonable, and only partly overlaps with LFTR, but all of the non-reduced motivating cases are covered by multiple exit LFTR.

If anyone wants to pick this up, feel free. There's probably some commonality with the existing simplifyIVUsers code, particularly the truncate path. Might be worth reframing in those terms. Or maybe I'll get back to this someday.