Re: i386/x86-64 UNSPEC_NOP usage

["Jan Beulich" <JBeulich at novell dot com>]

>>> Jim Wilson <wilson@specifixinc.com> 25.06.04 19:59:52 >>>
>Jan Beulich wrote:
>> Would you be able to explain what UNSPEC_NOP is really good for.
>
>Try deleting it and see what breaks.

I'd have tried doing so if I had at least a slight idea of what might break...

>Since the comments refer to combine cleverness, and the affected 
>patterns are mostly DImode/TImode ones, I assume the problem is that the 
>optimizer does not know much about how to optimize vector modes, but it 
>does know how to optimize integer modes.  So perhaps our carefully 
>crafted mmx DImode patterns are being rewritten in ways that prevent us 
>from later emitting the mms/sse instructions we want.  Or maybe mmx 
>instructions are being created where we don't want them.
>
>> While I'm trying
>> to fix various inconsistencies in the MMX/SSE support, I'd like to also
>> do away with some of the superfluous builtins.
>
>Superfluous how?  Just because there are builtins that are not useful to 
>users does not mean they can be eliminated.  If there is a standard, or 
>a reference compiler (e.g. icc) that has them, then we need them also, 
>even if they aren't really needed by end users.

I'm referring to the builtin functions, not the inline functions in the various *mmintrin.h headers. The latter have to survive, but in the set of builtin functions there's quite a bit of superfluous ones (just as an example, _mm_add_ps could * thanks to the vector mode arithmetic already existing * easily be

static __inline __m128
_mm_add_ps (__m128 __A, __m128 __B)
{
  return (__m128)((__v4sf)__A + (__v4sf)__B);
}

without any built-in function, implying that __builtin_ia32_addps is not needed)

Jan