This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: #pragma optimization_level
- From: Geoffrey Keating <geoffk at geoffk dot org>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 01 Apr 2005 18:55:46 -0800
- Subject: Re: RFC: #pragma optimization_level
- References: <c2be513156e77e58189807976b82956f@apple.com><m28y42gou4.fsf@greed.local><3b8decd250b0208fbc3ccd962544d9c2@apple.com>
Dale Johannesen <dalej@apple.com> writes:
> On Apr 1, 2005, at 1:38 PM, Geoffrey Keating wrote:
> > 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.
>
> This is outside the scope of what I'm planning to do.
No, I mean that "if you can do this for -Ox, then all you need to do
for PCH is document that it works".
Likewise, as you verify that each optimization pass controlled by a -f
flag works in this environment, you can add it to the list of -f flags
that are PCH-safe.
> > 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.
>
> Another good point. That optimization may be one that has to be
> disallowed, for the first cut. Unfortunately, controlling it may very
> well be something people will want to do. (Limiting the pragma
> to -On may keep them from asking for it :)
I mentioned strict-aliasing because it is part of -O2 but not -O1.
It sounds like what you'll really end up with is a *different* set of
optimisation levels than the command-line -O flags produce. It seems
like that might be confusing for users.