This is the mail archive of the
mailing list for the GCC project.
Re: [patch] require sse3 for fisttp
5) If a vendor wants the default -march on i386 to be something other
than a circa 1980s processor at configure time, *and* support an
x86_64 biarch compiler, it's difficult to pick a --with-arch that
isn't nocona or later, since otherwise gcc will complain that the
explicitly selected -march value does not support the x86-64
instruction set. Having separate compiler default -march values for 32-
bit and 64-bit might also allow the underlying issue of "why are you
picking nocona when you don't really want that" to be addressed.
6) If your default arch is "opteron" or something and you pass -msse3,
you probably also want fisttp instructions generated. As far as I can
tell fisttp will only be generated if you specify an Intel CPU, since
it is keyed off prescott/nocona.
On Sep 18, 2006, at 12:15 AM, Paolo Bonzini wrote:
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, butThe user should not have used -march=nocona but instead -mtune=nocona
doesn't have the sse3 instruction set. This will cause an invalid
if he wants the tuning but not the architecture features that the
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
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).