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

[David A. Greene]

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.

                                -Dave