<p dir="ltr">Agreed. Especially about ensuring we canonicalize even user written variations of the <u variant.</p>
<div class="gmail_quote">On Apr 13, 2013 9:19 AM, "Duncan Sands" <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi David,<br>
<br>
On 13/04/13 00:31, David Majnemer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch reorders two transforms that collide with each other:<br>
<br>
One performs: (X == 13 | X == 14) -> X-13 <u 2<br>
The other: (A == C1 || A == C2) -> (A & ~(C1 ^ C2)) == C1<br>
<br>
The problem is that there are certain values of C1 and C2 that trigger both<br>
transforms but the first one blocks out the second, this generates suboptimal code.<br>
<br>
Reordering the transforms should be better in every case and allows us to do<br>
interesting stuff like turn:<br>
   %shr = lshr i32 %X, 4<br>
   %and = and i32 %shr, 15<br>
   %add = add i32 %and, -14<br>
   %tobool = icmp ne i32 %add, 0<br>
<br>
into:<br>
   %and = and i32 %X, 240<br>
   %tobool = icmp ne i32 %and, 224<br>
</blockquote>
<br>
this seems reasonable to me.  Another possibility is to recognize that some<br>
forms of "X-13 <u 2" can be turned into "(A & ~(C1 ^ C2)) == C1", which would<br>
catch hand-written cases of this coming straight from the original source code.<br>
Personally I think you should apply your patch and maybe consider the second<br>
possibility as an additional, future, optimization that could be implemented.<br>
<br>
Ciao, Duncan.<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</blockquote></div>