[PATCH] D33262: [JumpThreading] Teach jump threading how to analyze (and (cmp A, C1), (cmp A, C2)) after InstCombine has turned it into (cmp (add A, C3), C4)

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 12 09:14:59 PDT 2017


reames added a comment.

In https://reviews.llvm.org/D33262#774151, @craig.topper wrote:

> @reames   For 1. were you envisioning detecting the add at the time we're visiting the compare similar to what I do now? Or were you envisioning propagating the add result as we unwind CVKInP after visiting the directly. The latter I think would require us to make CVKInP work in ConstantRanges like suggestion 2. For the former I think I'd also have to replicate some of the compare handling from LVI to calculate the result for the range from the add?


I was picturing roughly the following:

1. Pattern match add leading to compare (as done today)
2. Ask LVI for constant range representing each input to the add
3. Forward propagate those CRs using CR functions.
4. Expose the compare handling you mention as a helper function and use it.

> For 2, I think our range solving capabilities are considerably weaker than our ConstantExpr handling so I think we'd still need to rely on ConstantExpr when we have single element ranges?

This sounds like a reasonable implementation technique for ConstantRange when dealing with single element ranges, but the interface to caller code shouldn't reflect that.  :)


https://reviews.llvm.org/D33262





More information about the llvm-commits mailing list