This is the mail archive of the gcc@gcc.gnu.org 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: Apple's -fast option for gcc


On Wednesday, September 17, 2003, at 11:32 AM, Jim Wilson wrote:
Mike Stump wrote:
-fast is very, very small. It just turns on 5-25 other, existing flags. There isn't a reason why it could not be contributed. Do others want it? It is _good_ for SPEC.

The set of options that gives best performance on SPEC for a PPC970 is unlikely to be right for other targets or for other programs. So what exactly does -fast mean when that is considered?

It means give the best numbers that are real and possible for SPEC. This is target and host and build independent. The details of what exactly is done to achieve this on any particular target is, uhm, target specific, however, some things, like turning on all the flags implied by -O2 or unsigned characters and turning off pic, need not be target specific. This doesn't mean this would be the end-all-be-all for setting the flags, as later, the target config can inspect and set or reset flags, as it sees fit.


How do we choose which options to include?

Uhm, those that give lower overall spec score. If you mean for the mi part, oh, any half way reasonable set, tending to fewer, than to many. Maybe just -O2, for example.


Apple probably doesn't want to sacrifice SPEC performance to make the option useful to others, so perhaps it makes more sense to rename it to something like -mfast-spec to make it clear that it is target dependent, and is the set of options that is known to give best SPEC performance.

The exact spelling doesn't really matter too much to anyone. Trivially, we can make any spelling work. Internally, we use -fast currently. -mfast isn't out of the question.


However, if the mi parts of the compiler inspect a flag, necessarily, that flag has to be mi, hence, easier if the flag is mi, though, obviously, a hook would work.

The question of spelling can be deferred until such time as someone submits a patch. With luck, we can avoid the -mcpu, -mtune, -march, -m386 fun...


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