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?


> Richard Kenner wrote:
> >I don't see why it would be any worse than all the -f options we
> >currently have.
> 
> I agree.
> 
> 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.
> 
> Hmmm... I'm still not certain if that's too complicated. for right now,
> I'm just tossing out ideas; working out the interactions of the axes
> would be the next step, if the model makes sense.

Too many choices will give us no way to actually check that the switches
are behaving as expected.  We already do have enought suprises where -Os
produces faster code than -O2 and -O2 smaller than -Os.  In order to
make the settings usefull, I think we need periodic perfomrance, code
size and compilation time testing of each switch, so there needs to be
relatively few of them.

In order to reduce the amount of possible settings, I think we can keep
-Ospeed as -O1.  There are not very many optimization choices that
differ radically for size/speed and are fast enough for -O1.  Similarly
-Osize/-Ofast shall be exclusive (it does not much sense to specify
things like speed is 3 times as importnat to me than size and expect
compiler to get it in a way you expect it to behave).
For -Oaccuracy I think current -ffast-math is doing good job.  It gives
user feeling "hey I am doing something dangerous but cool" and if
someone needs something more specific he needs to understand what so he
needs to dig into -f switches dealing with mathematics.

So that way of thinking leaves us with discussion on whether we actually
needs multiple levels on size/speed settings.. 

Just my 2 cents...
Honza
> 
> -- 
> Scott Robert Ladd
> Coyote Gulch Productions (http://www.coyotegulch.com)
> Software Invention for High-Performance Computing
> 
> 


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