> Brooks Moses wrote on 11/06/06 17:41: > > >Is there a need for any fine-grained control on this knob, though, or > >would it be sufficient to add an -O4 option that's equivalent to -O3 but > >with no optimization throttling? > > > We need to distinguish two orthogonal issues here: effort and enabled > transformations. Currently, -O3 means enabling transformations that (a) > may not result in an optimization improvement, and (b) may change the > semantics of the program. -O3 will also enable "maximum effort" out of
-O3 enables inlining, unswitching and GCSE after reload. How those change semantics of the program? For me -O3 always meant that we enable the code expanding optimization that usualy speeds up, but the code size cost might not be worth it. Honza > every transformation. > > In terms of effort, we currently have individual knobs in the form of -f > and/or --params settings. It should not be hard to introduce a global > -Oeffort=xxx parameter. But, it will take some tweaking to coordinate > what -f/--params/-m switches should that enable.
