This is the mail archive of the
mailing list for the GCC project.
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
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
The points are:
1) Nocona has SSE3, so -march=nocona behavior would not be affected by
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
(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).