<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 4, 2016 at 5:21 PM, Matthias Reisinger <span dir="ltr"><<a href="mailto:matthias.j.reisinger@gmail.com" target="_blank">matthias.j.reisinger@gmail.<wbr>com</a>></span> wrote:<span></span><br><span></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
</span>… InstCombine will now eventually get to:<br>
<span><br>
define i8 @zext_or_icmp_icmp(i8 %a, i8 %b) {<br>
</span>  %1 = icmp ne i8 %b, 0<br>
<span>  %2 = zext i1 %1 to i8<br>
</span>  %zext.demorgan = and i8 %2, %a<br>
  %zext = xor i8 %zext.demorgan, 1<br>
  ret i8 %zext<br>
}<br>
<br>
just what we wanted :)<br></blockquote><div><br></div><div>Great!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The only problem that I am currently facing is symmetry: when we replace `%or = or i8 %xor, %zext ` by `%or = or i8 %zext, %xor` in the above `foo` the patterns obviously won’t trigger anymore. So to handle `(A ^ 1) | zext(B == 0)` and ` zext(B == 0) | (A ^ 1)` in a uniform way we may need another transform. Is it feasible, for example, to introduce a canonicalization that moves a cast always to the right-hand side of a binary operation?<br></blockquote><div><br></div><div>This is a general problem for any pattern matching of commutative operators. Search for "matchSelectFromAndOr" to see a particularly bad example. :)<br><br>In theory, we should be able to use "value complexity" in this situation, but it's broken:<br><a href="https://llvm.org/bugs/show_bug.cgi?id=28296" target="_blank">https://llvm.org/bugs/show_<wbr>bug.cgi?id=28296</a><br></div><div><br></div><div>So either we need to fix that or we'll have to include extra patterns to match the commuted possibilities.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> We may need to answer this question first though:<br>
>  define i8 @notLowBit(i8 %a) {<br>
>   %lowBit = and i8 %a, 1<br>
>   %not = xor i8 %lowBit, 1<br>
>   ret i8 %not<br>
> }<br>
><br>
> Should this be canonicalized to:<br>
> define i8 @notLowBit(i8 %a) {<br>
>   %not = xor i8 %a, -1<br>
>   %lowBit = and i8 %not, 1<br>
>   ret i8 %lowBit<br>
> }<br>
><br>
> ...because xor with -1 is the canonical 'not' operation?<br>
<br>
</span>Do we need such a canonicalization in the presence of the above patterns?<br></blockquote><div><br></div><div>This one is interesting. When I wrote the example, I didn't realize that we actually have the inverse canonicalization: the 2nd case is always transformed to the 1st because it reduces the demanded bits of the constant. However, there is a FIXME comment about that in SimplifyDemandedUseBits:<br><br></div></div>    // FIXME: for XOR, we prefer to force bits to 1 if they will make a -1.<br><br></div><div class="gmail_extra">So either we fix that and adjust the patterns that you are about to add or...<br><br></div><div class="gmail_extra">Welcome to InstCombine. :)<br></div><div class="gmail_extra"><br></div></div>