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

[Duncan Sands]

Hi Dave,

>>> Intrinsics are used by users and we want to respect that.
>>>
>>> The builtins are useful for running the C backend to get something
>>> compilable by gcc.  This is very helpful for debugging.
>>
>> once auto-upgrade support for these intrinsics goes in, won't everything be
>> fine?  Old bitcode using the intrinsics will be turned into generic LLVM IR
>> (shuffles).  The C backend should turn this into valid C, though indeed not
>> into the GCC builtins anymore.
>
> 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?  I mean, it is clear that any shuffle can be written
in C (not necessarily efficiently).  Or maybe you mean that the C backend
outputs something but that it is too horrible and inefficient for your
needs?

   Remember, gcc is not the
> only vectorizer out there.
>
> That's part of the reason I started to write a new C backend.  Though
> that's stalled at the moment, it's still on my TODO list.

Ah, OK!

>
>>   Frontends can pretty easily just generate the generic IR rather than
>> the intrinsics (at least I hope it's easy, since I'm going to have to
>> do this in my front-end).
>
> 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.

Ciao, Duncan.