I think his point was that DAG combine wouldn't have allowed ZERO_EXT to be nested so that should only be one of them. Which means you shouldn't need a loop.<br><br><div class="gmail_quote">On Tue, Aug 7, 2012 at 6:05 AM, Liao, Michael <span dir="ltr"><<a href="mailto:michael.liao@intel.com" target="_blank">michael.liao@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Most flag-generating intrinsics returns i32 instead of i8 and do zero-extend after SETcc. We need skip them.<br>
<br>
Yours<br>
<span class="HOEnZb"><font color="#888888">- Michael<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: Evan Cheng [mailto:<a href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>]<br>
Sent: Monday, August 06, 2012 1:02 PM<br>
To: Liao, Michael<br>
Cc: <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
Subject: Re: [llvm-commits] [PATCH 1/2] Fix PR12312<br>
<br>
The patch looks fine. But this part looks funny to me:<br>
<br>
+  // Skip all 'zext' nodes.<br>
+  while (SetCC.getOpcode() == ISD::ZERO_EXTEND)<br>
+    SetCC = SetCC.getOperand(0);<br>
+<br>
<br>
Why is a loop needed?<br>
<br>
Evan<br>
<br>
On Aug 3, 2012, at 12:53 PM, Michael Liao <<a href="mailto:michael.liao@intel.com">michael.liao@intel.com</a>> wrote:<br>
<br>
> Hi<br>
><br>
> Just ping after 2 days. Does this patch looks good?<br>
><br>
> Yours<br>
> - Michael<br>
><br>
> On Wed, 2012-08-01 at 12:46 -0700, Michael Liao wrote:<br>
>> Hi<br>
>><br>
>> This patch is to fix <a href="http://llvm.org/bugs/show_bug.cgi?id=12312" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=12312</a>,<br>
>> where a special use of i128 needs efficient code generation with<br>
>> PTEST from SSE4.1.<br>
>><br>
>> To fix this issue, 2 patches are developed. The first part is to<br>
>> simplify a common pattern introduced by most intrinsics generating<br>
>> boolean values. Their boolean result are re-evaluated again to get<br>
>> EFLAGS updated for BRCOND/CMOV or even SETCC again to consume. The<br>
>> attached patch adds a X86-specific DAG optimzation to simplify this<br>
>> common pattern by directly consuming the EFLAGS updated from the<br>
>> original intrinsics, e.g. llvm.x86.sse41.ptest, if we found that<br>
>> integer result is checked as a boolean value.<br>
>><br>
>> Yours<br>
>> - Michael<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> llvm-commits mailing list<br>
>> <a href="mailto:llvm-commits@cs.uiuc.edu">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/mailman/listinfo/llvm-commits</a><br>
><br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">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/mailman/listinfo/llvm-commits</a><br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">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/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>~Craig<br>