This is the mail archive of the 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: organization of optimization options in manual

On Thu, Jan 15, 2015 at 12:48 AM, Sandra Loosemore
<> wrote:
> The "Options That Control Optimization" section of the manual is
> currently divided into three parts (not subsections, just separate option
> lists):
> (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 ;)


> -Sandra

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