[llvm-commits] [llvm] r150060 - in /llvm/trunk: include/llvm/IntrinsicsX86.td lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86InstrSSE.td
baldrick at free.fr
Wed Feb 8 11:59:58 PST 2012
>>>> then I guess you will have to use inline asm.
>>> We can't use inline asm. Our compiler does not support it.
>> your front-end can expand the builtin into the corresponding LLVM inline
>> asm expression when generating the IR.
> So now our frontend has to be a code generator? And understand all
> possible targets, asm formats, etc.?
> That's ridiculous.
I didn't try, but turning __builtin_ia32_vpermilpd into an inline asm is
presumably rather trivial. I'm not sure why you think you need to know
all kinds of stuff to do so (maybe you do - as I said I didn't try). You
obviously have a rather good idea of the target since these are x86 intrinsics,
you already need to know the parameter types; hopefully sprinkling a little
magic pixie dust would do the job. Anyway, it seems rather natural to me
to use an inline asm: you say "my customers are using __builtin_ia32_vpermilpd
because they want the vpermilpd instruction". I.e. they want it to act like an
inline asm. So let it be one! But as I mentioned, it may be harder than I'm
imagining - if it was easy to use inline asm, why were the intrinsics
introduced in the first place? But why not give it a go?
> What is so difficult about keeping intrinsics around? Are they causing
> some major issue?
I'm not the one removing intrinsics, and I don't know what the reason is.
However keeping useless functionality does create a maintenance burden for
no real benefit. I call these intrinsics useless since you can get the same
semantic effect using generic IR, or exactly the instruction using inline asm.
If turning them into inline asm is a real pain as you suspect, then I for one
would vote to keep the intrinsics.
More information about the llvm-commits