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: Should -fcross-jumping be part of -O1?


Scott Robert Ladd <coyote@coyotegulch.com> writes:

> A thought experiment: Allow a complexity of switches for those of us
> that want to fine-tune code, while implementing "general purpose"
> switches (e.g., -Os/-Ospeed) for people who are less complexity in their
> use of GCC.
> 
> Based on personal experience and the conversation herein, optimization
> appears to be a five-dimensional space with these axis:
> 
>    * compilation speed (-Ospeed)
>    * debugability      (-Odebug)
>    * code size	      (-Osize)
>    * execution speed   (-Ofast)
>    * FP accuracy       (-Oaccuracy)
> 
> The switches would be weighted; for example, specifying -Osize=0
> -Ospeed=2 -Oaccuracy=3 would request the highest-accuracy, with speed as
> a secondary consideration, and no concern for code size.

Would we really want -Oaccuracy to range from 0 to 3?  It seems to me
that you either care about accurate floating point, or you do not.
It's hard for me to see why anybody would set -Oaccuracy to anything
other than 0 or 3.  Even if they did, it's hard for me to see how they
could possibly understand what was going to happen.  The reason to use
accurate floating point is to be able to prove characteristics about
your algorithm.  If you use anything other than -Oaccuracy=3, you
would need a clear understanding of precisely what was going to
happen.  In such cases, you more or less have to use a specific
option, such as -mfused-madd.

I'm also not sure about -Ospeed.  For compilation speed, the options I
see would be ``fast as possible'' or ``don't care.''  I suppose I can
imagine a setting for ``use exponential algorithms,'' aka the
24-hour-compile option, but in general I think people would more
effectively use -f options to select the particular slow algorithms
they were interested in.

Also, I think it would be quite difficult to maintain consistency of
these options over time.  For any given optimization, there will be a
lot of knobs to check in considering whether to implement the
optimization.  Different people will make different decisions.  I
think this will tend to mute the effects.  One way to avoid this would
be to have each optimization controlled by a specific variable, and
then have some matrix in which the -O... options set the optimization
control variables.  But that would be a moderately complex approach.

Also -Ospeed and -Ofast will be confused with each other, so one of
them needs to be renamed.

Ian


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