[llvm-commits] [PATCH] RDRAND intrinsics

[Benjamin Kramer]

On 12.07.2012, at 11:24, Chandler Carruth <chandlerc at google.com> wrote:

> FYI, the clang bits seem fine to me.
> 
> I assume you've verified the signatures of the builtins match any other implementations in the wild?

Yep, I took the signatures from the intel and GCC docs. I got an OK from Duncan for the LLVM part, it seems to be working in reality too (see comments in PR13284). I'm going to land this now.

Thanks to all the reviewers!

- Ben
> 
> 
> On Wed, Jul 11, 2012 at 2:47 AM, Benjamin Kramer <benny.kra at gmail.com> wrote:
> 
> On 08.07.2012, at 13:56, Benjamin Kramer <benny.kra at gmail.com> wrote:
> 
> >
> > On 07.07.2012, at 11:12, Benjamin Kramer wrote:
> >
> >>
> >> On 06.07.2012, at 23:30, Eli Friedman wrote:
> >>
> >>> On Fri, Jul 6, 2012 at 2:03 PM, Benjamin Kramer <benny.kra at gmail.com> wrote:
> >>>>
> >>>> On 06.07.2012, at 22:52, Eli Friedman wrote:
> >>>>
> >>>>> On Fri, Jul 6, 2012 at 1:00 PM, Benjamin Kramer <benny.kra at gmail.com> wrote:
> >>>>>> The attached patch adds support for intel's rdrand intrinsics to LLVM.
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>>> It would be much more friendly to the optimizer to use multiple return
> >>>>> values... but it might not be worth the hassle, considering that
> >>>>> rdrand is relatively slow.
> >>>>
> >>>> 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.
> >>>
> >>> X86TargetLowering::ReplaceNodeResults?
> >>
> >> 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.
> >
> > 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.
> >
> > declare { i16, i32 } @llvm.x86.rdrand.16()
> >
> > 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.
> >
> > - Ben
> >
> > <0001-Add-intrinsics-for-Ivy-Bridge-s-rdrand-instruction.patch><0001-Add-_rdrand-16-32-64-_step-intrinsics-to-immintrin.h.patch>
> 
> ping.
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>