This is the mail archive of the gcc-patches@gcc.gnu.org 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: RFC: #pragma optimization_level


Dale Johannesen <dalej@apple.com> writes:

> - As a first cut I intend to allow only -O[0123s] to be specified in
> the pragma, as suggested by Geert Bosch.  I don't think there's any
> reason this couldn't be extended to single flags.

How do you plan to deal with preprocessor macros?  On some systems,
like Linux and possibly even Darwin, the system headers will define
some macros or inline functions differently depending on the setting
of __OPTIMIZE__ and __OPTIMIZE_SIZE__ and so on.

If you do get a solution for preprocessor macros, you can remove the
restriction that the -Ox settings must match for PCH files, another
much-requested feature.  You would define the behaviour to be the same
as if the PCH file had been surrounded by '#pragma optimize -Oy' and
'#pragma optimize pop', where -Oy is the -O setting that the PCH file
was built with.

It hasn't been done because it seems to be hard; in addition to
solving the preprocessor macro problem, you have to check that the
passes (or other optimisations) will actually work when they are
enabled or disabled.  For instance, you need to ensure that if an
optimization has an per-compilation initialisation step, that step
eventually gets run even if the pass is not enabled at the start of
compilation.  Another example: what happens if strict-aliasing is
switched off half-way through the compilation?  And then back on
again?  Look at the assert in mems_in_disjoint_alias_sets_p.

You'd also need to document how this interacts with inlining.  A
simple implementation will just say "if X gets inlined into Y, it gets
Y's flags; use an attribute to prevent this if it's undesired".
Alternatively, you could prevent inlining in this case.

My suggestion would be that instead of doing it for -Ox, you could do
it for individual -f flags.  Discussions with our customers indicated
that this is what they really wanted anyway; they want to be able to
disable optimisation passes if the passes appeared to be buggy or if
they turned out to be de-optimizing the code, or to switch on
particular passes which are expected to have an especially good effect
on a particular function.  You could then do it only for those -f
flags which seem most likely to be safe (which is probably most of
them).


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