[llvm-commits] [PATCH] RDRAND intrinsics

[Chandler Carruth]

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?


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120712/7c79ea77/attachment.html>