[RFC] Introduce -Ofast

[RFC] Introduce -Ofast

[Richard Guenther]

This is a proposal to introduce an optimization level -Ofast
that can collect (target specific) optimization flags that
can affect runtime behavior such as -funsafe-math-optimizations
or -mrecip.

Currently none of the standard optimization levels have this
kind of affect and we should not change that (people might
argue that -funsafe-math-optimizations can go into -O3).

For floating-point intensive programs people often disregard
the various special (and target dependent) flags and/or do
not know about -ffast-math.  -Ofast on the other hand is
recognized by many compilers and is widely known to affect
program behavior in corner cases.

I would initially propose to make -Ofast be -O3 -ffast-math
and would strongly encourage target maintainers that consider
adding to -Ofast make sure that popular benchmarks for
their target still behave correctly when using -Ofast.

Any comments or objections?

After the discussion has died down I will propose a patch
to gcc-patches.

Thanks,
Richard.

Re: [RFC] Introduce -Ofast

[Tobias Burnus]

On 05/06/2010 04:24 PM, Richard Guenther wrote:
> I would initially propose to make -Ofast be -O3 -ffast-math
> and would strongly encourage target maintainers that consider
> adding to -Ofast make sure that popular benchmarks for
> their target still behave correctly when using -Ofast.

I am in favour of the suggestion.

How about also adding "-march=native" (for targets where it is
available)? Otherwise, one may end up, e.g. on x86, to compile for i386
- and then -O3 -ffast-math won't help. But also on other systems
configuring for the compile system is useful - but it should be
overridable. Another option one could consider is -funroll-loops.

(Intel's "-fast" also implies "-xHost". Pathscale (always) defaults to
"-march=auto", Portland also [unless "-tp..." is used].)

Tobias

Re: [RFC] Introduce -Ofast

[Ian Lance Taylor]

Richard Guenther <rguenther@suse.de> writes:

> This is a proposal to introduce an optimization level -Ofast
> that can collect (target specific) optimization flags that
> can affect runtime behavior such as -funsafe-math-optimizations
> or -mrecip.

Sounds like a good idea to me.  I don't like the name -Ofast, which is
ambiguous, but I see that there is precedent in the PathScale and PGI
compilers.  I don't think a potentially confusing name is enough of a
reason to buck the trend.

Ian

Re: [RFC] Introduce -Ofast

[Dave Korn]

On 06/05/2010 21:25, Ian Lance Taylor wrote:
> Richard Guenther <rguenther@suse.de> writes:
> 
>> This is a proposal to introduce an optimization level -Ofast
>> that can collect (target specific) optimization flags that
>> can affect runtime behavior such as -funsafe-math-optimizations
>> or -mrecip.
> 
> Sounds like a good idea to me.  I don't like the name -Ofast, which is
> ambiguous, but I see that there is precedent in the PathScale and PGI
> compilers.  I don't think a potentially confusing name is enough of a
> reason to buck the trend.

  Maybe then we should also add -Osmall and -Of, just to be thoroughly
symmetric and orthogonal :)

    cheers,
      DaveK

Re: [RFC] Introduce -Ofast

[Mark Mitchell]

Richard Guenther wrote:

> This is a proposal to introduce an optimization level -Ofast
> that can collect (target specific) optimization flags that
> can affect runtime behavior such as -funsafe-math-optimizations
> or -mrecip.

I think that makes sense.  Defining what's allowed in these cases is
always tricky (there was a long thread a couple of years back in which
we tried to get some scoping on just what -ffast-math might be allowed
to do), but I think the short answer is "this option will try to make
your program go faster, even if that means doing things the standards do
not allow the compiler to do".

> Currently none of the standard optimization levels have this
> kind of affect and we should not change that (people might
> argue that -funsafe-math-optimizations can go into -O3).

I agree that -O3 should not violate the standards.  However, I don't
agree that it shouldn't be target-specific.  (It's quite possible that
we agree; I'm interpreting your words.)  If there's a magic option that
makes MIPS go faster but makes Power go slower, then -O3 on MIPS should
most definitely turn it on, and -O3 on Power most definitely should not.
 As a user, I don't want to know about the option; I just want -O3 to
generate fast code.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [RFC] Introduce -Ofast

[Diego Novillo]

On 5/6/10 10:24 , Richard Guenther wrote:

> Any comments or objections?

I agree.  It sounds useful.  It's a bit confusing in that I don't know
whether it means 'compile very fast' or 'make my code run very fast'.
I've seen it mean the latter in most places, so I guess that's fine.

Allowing backends to alter the meaning of -Ofast with target-specific
switches (and even -f switches) is a good idea too.

The documentation should be clear in that -Ofast WILL produce surprising
results in non-standard code and it will also enable transformations
that do not follow the standard.


Diego.