[llvm-commits] [llvm] r123547 - /llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp

Chris Lattner clattner at apple.com
Sat Jan 15 21:15:17 PST 2011


On Jan 15, 2011, at 8:55 PM, Jakob Stoklund Olesen wrote:

> 
> On Jan 15, 2011, at 6:51 PM, Jakob Stoklund Olesen wrote:
> 
>> 
>> On Jan 15, 2011, at 5:02 PM, Chris Lattner wrote:
>> 
>>> One major advantage of recognizing popcount though is that the optimizer has a chance of hacking on it, and there are a lot of instcombine xforms that we could do.  Here are some that I note looking at the bc file for crafy (when hacked to use builtin_popcount).  I attached the bc file below if you're interested.
>> 
>> I noticed that we have intrinsics and ISD nodes for ctlz, cttz, and ctpop, but none for parity. Is that on purpose?
>> 
>> Currently, clang compiles __builtin_parity to:
>> 
>> define i32 @f(i32 %x) nounwind readnone ssp {
>> entry:
>>   %tmp1 = tail call i32 @llvm.ctpop.i32(i32 %x)
>>   %tmp2 = and i32 %tmp1, 1
>>   ret i32 %tmp2
>> }
> 
> I found an old PR1983 covering this.
> 
> I don't know if there would be any advantage to a parity intrinsic over the current ctpop(x)&1 representation.

I think that representing it as ctpop(x)&1 in IR is reasonable, but you're right that codegen should turn that into an ISD::PARITY node if it can lower it to something better.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110115/8592abee/attachment.html>


More information about the llvm-commits mailing list