[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]

reames added a comment.

Ok, my previous comment was wrong.  This isn't something the existing infrastructure can handle because CVKInP reasons only about constants and we need to forward propagate constant ranges here to discharge the icmp.  That's what I'd missed on the first look.

I think there's a couple of reasonable ways to implement this:

1. ask for the constant range of each input to the add, then forward propagate using the ConstantRange accessors.  Doing this specifically for add directly in CVKInP doesn't seem too ugly.
2. restructure CVKInP to work in terms of constant ranges.  If we'd directly returned the CRs from the inputs, and unwound the recursion in CVKInP applying the forward propagation rules (i.e. the add), then we'd handle not just this case, but many others.  (CVKInPred essentially does this today for constants using the constant expressions.)
3. we could sink the result of (2) directly into LVI - this is close to what you're doing currently, but substantially more general.
4. In an alternate approach, we could backwards propagate a predicate (think weakest precondition style) to the beginning of the block, then ask LVI to discharge that predicate for each incoming value.

(1-3) and (4) have slightly different power.  Doing (2) is probably the most straight forward extension of the existing logic, but we already have some reasoning ala (4) in LVI itself.  Either approach seems reasonable and I could be convinced we should do either.  I'd lean towards forward propagation of constant ranges just because that'd probably be easier to write and reason about.


https://reviews.llvm.org/D33262