[llvm-commits] [llvm] r150060 - in /llvm/trunk: include/llvm/IntrinsicsX86.td lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86InstrSSE.td

Nick Lewycky nlewycky at google.com
Wed Feb 8 15:06:59 PST 2012


On 8 February 2012 08:43, David A. Greene <dag at cray.com> wrote:

> Duncan Sands <baldrick at free.fr> writes:
>
> >> My experience with the C backend says otherwise.  I've run across lots
> >> of cases where shuffles could not be handled.
> >
> > then fix the C backend?
>
> Not possible with the current C backend.  It uses illegal types, for
> one.
>
> >> I don't know of any way to generate generic IR and guarantee that the
> >> instruction the user selected through an intrinsic will be the
> >> instruction selected by LLVM's isel.  There are too many transformation
> >> steps in-between.
> >
> > Of course there is no such guarantee.  The question is whether doing
> things
> > using generic IR is mostly a win or not.  Maybe today it's often not a
> win,
> > but since that's fixable it seems to me that the "use generic IR if not
> too
> > crazy" path is on the whole the right way to go.
>
> Whether generic IR is a "win" isn't the primary issue here.  The issue
> is that the user wrote code using intrinsics and expects that exact code
> to be in the asm.  Whether or not that is the best performing code
> possible doesn't matter.  It's what they want and we have to respect it.
> Our customers demand it.
>

Okay. This is a different issue then, and isn't even solved by using
intrinsics; the optimization passes are absolutely allowed to modify uses
of intrinsics. We do this in obvious cases for things like memset or ctz,
but there is no reason the optimization passes won't optimize the llvm.x86
intrinsics too. It's rare, but you can see code in ValueTracking.cpp that
will analyze Intrinsic::x86_sse42_crc32_64_8 for one example,
ConstantFolding.cpp will fold through x86_sse_cvtss2si for another.

Suppose you emit code like this: create your own functions with definitions
that use the IR implementations, and mark them noinline. At the very end,
you inline them with a pass that calls InlineFunction() directly. Does this
preserve the order, or do you still have trouble with the backend doing too
much reordering?

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120208/c2f9cec5/attachment.html>


More information about the llvm-commits mailing list