Re: i386/x86-64 UNSPEC_NOP usage

[Jim Wilson <wilson at specifixinc dot com>]

On Mon, 2004-06-28 at 00:04, Jan Beulich wrote:
>>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...

I think you missed the point of my suggestion.  If we knew why the
UNSPEC_NOP were there, then there would be no need for an experiment. 
It is precisely because we are unsure of why they are there that we need
to do an experiment.  The experiment is to delete them, then do a
bootstrap and make check, and look to see what broke.  If something did
break, then you have your answer.  If nothing broke, then there was no
harm done.  Keep in mind that many people are good about adding
testcases to the testsuite  when they add patches, and hence there is a
good chance that running the testsuite will find something that is
broken.

Anyways, I think we already answered the question.  If there were no
UNSPEC_NOP, then combine would generate logical DImode MMX instructions,
which would then fail at runtime because of the lack of the emms
instruction.  Or something like that.  I'm not an MMX expert.  I suspect
the experiment I already suggested would prove this.

> 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
> without any built-in function, implying that __builtin_ia32_addps is not needed)

OK.  That certainly makes sense.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com