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

[Duncan Sands]

Hi David,

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

Ciao, Duncan.