FYI, the clang bits seem fine to me.<div><br></div><div>I assume you've verified the signatures of the builtins match any other implementations in the wild?</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Jul 11, 2012 at 2:47 AM, Benjamin Kramer <span dir="ltr"><<a href="mailto:benny.kra@gmail.com" target="_blank">benny.kra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On 08.07.2012, at 13:56, Benjamin Kramer <<a href="mailto:benny.kra@gmail.com">benny.kra@gmail.com</a>> wrote:<br>
<br>
><br>
> On 07.07.2012, at 11:12, Benjamin Kramer wrote:<br>
><br>
>><br>
>> On 06.07.2012, at 23:30, Eli Friedman wrote:<br>
>><br>
>>> On Fri, Jul 6, 2012 at 2:03 PM, Benjamin Kramer <<a href="mailto:benny.kra@gmail.com">benny.kra@gmail.com</a>> wrote:<br>
>>>><br>
>>>> On 06.07.2012, at 22:52, Eli Friedman wrote:<br>
>>>><br>
>>>>> On Fri, Jul 6, 2012 at 1:00 PM, Benjamin Kramer <<a href="mailto:benny.kra@gmail.com">benny.kra@gmail.com</a>> wrote:<br>
>>>>>> The attached patch adds support for intel's rdrand intrinsics to LLVM.<br>
>>>>>><br>
>>>>>> The tricky part is that the intrinsics have to return two values (the random value and the carry flag). This is solved with a pointer argument and a cmov to materialize CF, which matches GCC's output. This approach requires some custom lowering code, but I don't see a way to do it with tablegenerated patterns only.<br>

>>>>><br>
>>>>> It would be much more friendly to the optimizer to use multiple return<br>
>>>>> values... but it might not be worth the hassle, considering that<br>
>>>>> rdrand is relatively slow.<br>
>>>><br>
>>>> I tried this first as it also looks cleaner, but I couldn't find a way to smuggle it past legalization into the target specific lowering.<br>
>>><br>
>>> X86TargetLowering::ReplaceNodeResults?<br>
>><br>
>> Doesn't work because TLI.getOperationAction bails out early when it sees an extended type. The legalizer then tries to expand the node and aborts.<br>
><br>
> Apparently I made some mistake yesterday, it *does* work without applying any tricks as long as all return values are legal individually. I attached an updated patch which uses the following intrinsic signature, allowing the store to stay in IR.<br>

><br>
> declare { i16, i32 } @llvm.x86.rdrand.16()<br>
><br>
> Here i16 is the random value and i32 is the boolean indicating whether it is considered valid. I also attached the clang part of this patch and reverified that the code matches what ICC and GCC emit.<br>
><br>
> - Ben<br>
><br>
</div></div>> <0001-Add-intrinsics-for-Ivy-Bridge-s-rdrand-instruction.patch><0001-Add-_rdrand-16-32-64-_step-intrinsics-to-immintrin.h.patch><br>
<br>
ping.<br>
<div class="HOEnZb"><div class="h5"><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></div>