[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