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

Jakob Stoklund Olesen stoklund at 2pi.dk
Sat Jan 15 20:55:20 PST 2011


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110115/5de7e773/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110115/5de7e773/attachment.bin>


More information about the llvm-commits mailing list