[llvm-commits] [llvm] r92939 - /llvm/trunk/include/llvm/IntrinsicsX86.td

[Dan Gohman]

On Jan 7, 2010, at 1:18 PM, David Greene wrote:

> On Thursday 07 January 2010 14:45, Eric Christopher wrote:
>> On Jan 7, 2010, at 12:22 PM, David Greene wrote:
>>> What llvm intrinsics?
>>> 
>>> We don't "need" them in the sense of functionality, but gcc defines them
>>> so it makes sense to support them.
>>> 
>>> Adding them also makes the SIMD reorganization a bit simpler.
>> 
>> I don't think you're understanding what Evan was saying.  We don't need, at
>> least, the "gcc intrinsic" part of it because the gcc intrinsic should be
>> lowered to explicit llvm instructions instead of llvm intrinsics.
> 
> Yes, I misread "instruction" as "intrinsic."
> 
>> The gcc intrinsics should be supported, but if possible they should be
>> lowered to instructions instead of intrinsics.
> 
> The non-orthogonality of having the "ss" intrinsics but not the "ps"
> intrinsics (and sd/pd) means that we would need to special-case these
> operations in the .td files rather than generating one pattern for all
> variants (ss/sd/ps/pd intrinsics and those matched from llvm instructions).
> This makes specifying SIMD instructions unnecessarily verbose.
> 
> Why do we have the scalar intrinsics anyway?  Those operations can match to 
> llvm instructions as well, can't they?

Almost, but unfortunately not quite. The problem with the "scalar" intrinsics
is that they are still defined to have vector operands. Theoretically the addss
intrinsic could be lowered to extractelement+fadd+insertelement. Theoretically
it could optimize down to the same eventual result; in practice, it'll probably
take someone to look at it.

> If we get rid of the scalar intrinsics, I have no problem dumping the vector
> ones.  I just want consistency.

If you do the whole thing up with multiclasses or whatever and the overall
result looks good except for a few intrinsics in the output that aren't
really needed, I, for my part, wouldn't complain.

Dan