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

Duncan Sands baldrick at free.fr
Wed Feb 8 08:13:13 PST 2012

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

   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.

More information about the llvm-commits mailing list