This is the mail archive of the
mailing list for the GCC project.
Re: organization of optimization options in manual
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Sandra Loosemore <sandra at codesourcery dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 15 Jan 2015 12:10:44 +0100
- Subject: Re: organization of optimization options in manual
- Authentication-results: sourceware.org; auth=none
- References: <54B70059 dot 3030808 at codesourcery dot com>
On Thu, Jan 15, 2015 at 12:48 AM, Sandra Loosemore
> The "Options That Control Optimization" section of the manual is
> currently divided into three parts (not subsections, just separate option
> (1) General options like -O[n]
> (2) Options that individually control options enabled by default at some
> -O[n] setting
> (3) Options controlling optimizations that aren't enabled by default, or
> that are experimental
> I've noted that a lot of options that belong in group (3) have been added to
> group (2), and at least one from (2) into group (3). I'm thinking that the
> distinction between (2) and (3) is not really useful anyway; there are
> already both lists of which options are enabled at each -O level, and info
> in the descriptions of individual options to say what -O levels they're
> enabled at.
> 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.
> The other option would be just to list the options alphabetically, but the
> index already does that if readers know the name of what they're looking for
> (or they can search for it in their browser).
Just to chime in late ...
I think users are interested in (1) (of course) and in additional
things they can enable ontop of them, thus (3). (2) is not so much
interesting and especially disabling passes enabled by (1) should
be done with care.
I think what we should do is merge (2) and (3) (because as you have
seen it gets disordered quite easily) and add a section after (1)
explaining what to do to get "more" optimization or what to do when
trying to debug a problem with the compiler. Stuff like
Generally enabling or disabling individual options listed in (2)/(3)
is discouraged as anything but the basic options in (1) receives
much testing and thus enabling or disabling individual options
may uncover bugs in the compiler.
If you are compiling a scientific application try using -ffast-math
(also enabled by -Ofast) and -funroll-loops.
If you are concerned for both binary size and runtime performance
profiling will help you a lot.
If you run into issues with your application and blame the compiler
first try -fsanitize=... and -fno-strict-aliasing (also see bugs.html).
After all the documentation of most of the options in (2) and (3)
doesn't mean much to a user of the compiler.
I agree that some options should receive separate sections,
LTO for example, but that has one already. The individual
options should still be documented in (2)/(3), possibly refering
to the separate section.
Keep in mind that invoke.texi is supposed to be user documentation
and users are generally not compiler developers ;)