| Message ID | 562997A9.3090203@gmail.com |
|---|---|
| State | New |
| Headers | show |
Ping. Thanks in advance for a review. On 10/22/2015 08:12 PM, Martin Sebor wrote: > [Sending to the right list this time] > > The documentation of the -Q --help=optimizers options leads some > to expect that when options are reported as enabled imply the > corresponding optimization will take place. (See the following > question on gcc-help: > https://gcc.gnu.org/ml/gcc-help/2015-10/msg00133.html) > > The patch below tries to make it clear that that's not always > the case. > > Martin > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index 4f89fa1..337639e 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -1506,6 +1506,16 @@ options, an indication is given as to whether the > option is enabled, > disabled or set to a specific value (assuming that the compiler > knows this at the point where the @option{--help=} option is used). > > +It's important to note that when a given optimization option is > +enabled, either explicitly on the command line or implicitly, whether > +or not the optimization it controls will be performed during an > +invocation of the compiler may depend on other options. This is > +so because many options control various finer aspects of other more > +general optimizations that must be enabled in order for the former > +option to have any effect. There is currently no command line > +interface to determine such dependencies between optimization > +options. > + > Here is a truncated example from the ARM port of @command{gcc}: > > @smallexample > >
On Thu, 22 Oct 2015, Martin Sebor wrote: > [Sending to the right list this time] > > The documentation of the -Q --help=optimizers options leads some > to expect that when options are reported as enabled imply the > corresponding optimization will take place. (See the following > question on gcc-help: > https://gcc.gnu.org/ml/gcc-help/2015-10/msg00133.html) > > The patch below tries to make it clear that that's not always > the case. Hi, The issue is due to optimization passes being skipped at -O0, and yet corresponding optimization options not explicitely disabled. The effect of -O is an old source of confusion, and now the intro to "Optimization Options" says, Most optimizations are only enabled if an -O level is set on the command line. Otherwise they are disabled, even if individual optimization flags are specified. (added with this patch: https://gcc.gnu.org/ml/gcc-patches/2009-10/msg00739.html ) As we observe, it's not visible enough, and I'm not sure saying that again in the documentation (in a different section) is a good way to go. Maybe we'd warn for attempts to enable optimizations at -O0, but that's not trivial. Perhaps go with Richard's suggestion in the end of this mail ("Thus, at the end of --help-optimizers print ...")? https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00113.html Thanks. Alexander
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 4f89fa1..337639e 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -1506,6 +1506,16 @@ options, an indication is given as to whether the option is enabled, disabled or set to a specific value (assuming that the compiler knows this at the point where the @option{--help=} option is used). +It's important to note that when a given optimization option is +enabled, either explicitly on the command line or implicitly, whether +or not the optimization it controls will be performed during an +invocation of the compiler may depend on other options. This is +so because many options control various finer aspects of other more +general optimizations that must be enabled in order for the former +option to have any effect. There is currently no command line +interface to determine such dependencies between optimization +options. + Here is a truncated example from the ARM port of @command{gcc}: