Re: organization of optimization options in manual

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 14 Jan 2015, Sandra Loosemore wrote:

> What would you think about reorganizing this section to add some subsections
> grouping options by purpose, instead?  E.g., loop optimizations,
> floating-point optimizations, inlining, LTO, profiling options, etc?  The
> section is almost 60 pages long in the printed manual and adding some
> structure would probably make it easier for users to find things.

For the floating-point options the classification as optimization options 
is a bit questionable anyway; they're more like language dialect options 
(with some dialects being more optimizable than others).  But while you 
might have divisions such as (language dialect options, options such as 
LTO or profiling that may affect your build system, non-semantic options 
that are quite likely to be useful in normal use, miscellaneous options 
enabled by -On that it probably only makes sense to turn on and off 
individually when debugging the compiler), organizing the manual that way 
could have issues with closely related options falling in different 
categories.

(E.g. -Ofast is like the other -O options, but also changes the language 
dialect by enabling -ffast-math.  -fno-strict-aliasing can be used as a 
language dialect option, but unless you're doing that sort of aliasing 
it's an option it doesn't make much sense to turn on or off on its own 
rather than through -O2.  -fmerge-all-constants is a language dialect 
option, but is naturally described next to the non-semantic option 
-fmerge-constants.)

-- 
Joseph S. Myers
joseph@codesourcery.com