[llvm-commits] [llvm] r150060 - in /llvm/trunk: include/llvm/IntrinsicsX86.td lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86InstrSSE.td
echristo at apple.com
Wed Feb 8 10:43:08 PST 2012
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
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.
More information about the llvm-commits