[PATCH] D18841: [InstCombine] Canonicalize icmp instructions based on dominating conditions.

[Balaram Makam via llvm-commits]

bmakam added a comment.

In http://reviews.llvm.org/D18841#411704, @sanjoy wrote:

> Hi Balaram,
>
> I've replied to your inline comment, but it is possible that we're just talking past each other.  I'm usually on #llvm as `sanjoyd` on PDT daytime, we can chat there in realtime if you think that'll help.


Thanks Sanjoy, sure I will be available on #llvm as `bmakam`. I think I have misinterpreted what you mean by non-singleton RHS. However, I think the current logic as is should be able to generalize to what you define as non-singleton RHS ranges.

> since for "[2, 5)" == 4 and "[3, 5)" == 4 and a == 3, the first program would have called abort() but the new program will call print().


The condition here is u< [2,5) so the allowed range is [0,4) which means `a` can never be == 4 for the first/dominating if condition and the program will abort() as expected.

If it helps to clarify, I think of the if conditions allowed ranges as set A for the dominating if condition and set B for the second(`Parent`) if condition. If dominating if condition is true, then the second if condition is true iff A ∩ B is true. So if {A ∩ B} == {ε} then it is sufficient to canonicalize the second if condition to icmp eq ε. OTOH, the second if condition is false iff A\B (aka relative complement) is true. So if {A\B} == {ε} then it is sufficient to canonicalize the second if condition to icmp ne ε. Similarly, if the dominating if condition is false, then the second if condition is true iff ~A ∩ B is true and the second if condition is false iff ~A\B is true. For non-singleton RHS ranges, the satisfying range is ⊆ allowed range, so it is sufficient to check for allowed range.


http://reviews.llvm.org/D18841