Re: [patch] require sse3 for fisttp

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

Andrew Pinski wrote:
> On Sat, 2006-09-16 at 14:58 -0700, Eric Christopher wrote:
> > No, this isn't OK if he has a core that is very like nocona, but
> > doesn't 
> > have the sse3 instruction set. This will cause an invalid instruction
> > error. 
>
> The user should not have used -march=nocona but instead -mtune=nocona
> if he wants the tuning but not the architecture features that the nocona
> core has.

The points are:

1) Nocona has SSE3, so -march=nocona behavior would not be affected by 
Eric's patch.

2) Somebody thinks it is unfortunate that there is no -mfisttp option.

3) -mtune=nocona is suboptimal in the case of a core that is "very like" 
nocona, but doesn't have the sse3 instruction set; OTOH -march=nocona is 
only for cores that support everything that is in nocona, so it is the 
wrong option for cores that are "very like nocona but without SSE3".

4) Without calling it "stupid" or "incompetent", it is indeed 
unfortunate that Intel puts MONITOR/MWAIT/FISTTP under the SSE3 name, 
i.e. under an acronym that includes SIMD in its name.  The question is 
whether the compiler should be affected by the marketing choice of 
calling PNI with such an acronym.  Andrew argues that the compiler's 
SSE3 flag should affect SIMD instructions only, Eric argues that it 
should behave as in the original "PNI" name and affect all instructions. 
 The obvious answer is that it should be the least confusing to the 
user.  Which one is less confusing, I don't know.


Now:

1) -mtune=nocona is suboptimal, but you can also have -mtune=nocona 
-march=foobar.  That would be the right option combination to specify to 
have a core that "has the feature set of Foobar but is otherwise very 
similar to Nocona", for example.

2) We may add -mfisttp, and have -mno-sse3 disable the instruction; then 
-mfisttp shall override -mno-sse3, and -mno-fisttp shall override 
-msse3.  But then, are there cores that have FISTTP but not the SIMD 
SSE3 instructions, or viceversa have SIMD SSE3 but not FISTTP?  I don't 
know the answer but if not, we do not need a new -mfisttp option, and 
Eric's patch may look weird (FISTTP is not SIMD) but makes sense after 
all.  If yes, that may be a reason to object to Eric's patch -- but then 
we also need a new -march=FOO option.


So my proposal is:

1) (When a maintainer approves it) let's apply Eric's patch.

2) If a core with SIMD SSE3 but no FISTTP is there/comes out, let's add 
-mfisttp with the semantics I outlined above.  Otherwise, it would be 
useless featurism.

(I shall point out that the first time I read about Eric's patch, I also 
thought it made no sense, at least without a -mfisttp option.  After 
reading all the thread, however, I changed my mind).

Paolo