On Thu, Jan 15, 2015 at 12:48 AM, Sandra Loosemore <san...@codesourcery.com> 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 ;) Richard. > -Sandra >
