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

Another point:

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, 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]