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

[Eric Christopher]

On Feb 8, 2012, at 8:43 AM, 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.
> 

It's going to be removed anyhow.

>>> 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.

Then make the generic IR match what you think should happen. I see no win
for anyone with this.

-eric