This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] require sse3 for fisttp

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

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.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]