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

[David A. Greene]

Duncan Sands <baldrick at free.fr> writes:

>> 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 don't know how hard it would be.  The frontend would have to know
about mnemonics, at least.  And it would have to know whether to
generate AT&T or Intel syntax.  It strikes me as the wrong place to do
this when the mechanisms already exist in the current codegen.

> But why not give it a go?

Because it works now, we've been using it for years and I have a million
other things to fix and improve.

Could it be done?  Sure.  Is it worth the expense to do it given an
existing solution?  No way.

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

They're not useless.  We are using them.  And I question whether it is
much of a maintenance burden at all.  Who goes and changes existing
intrinsics?

> I call these intrinsics useless since you can get the same
> semantic effect using generic IR

Users expect more than the same semantic effect.

> or exactly the instruction using inline asm.  

With a lot of extra work which is completely unnecessary given that a
solution already exists.

> If turning them into inline asm is a real pain as you suspect, then I
> for one would vote to keep the intrinsics.

It is infinitely more painful than just using what we already have, what
we know works and which requires zero effort to keep working.

                          -Dave