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


On Apr 2, 2005 8:44 AM, Andrew Pinski <pinskia@physics.uc.edu> wrote:
> 
> On Apr 1, 2005, at 8:40 PM, Dale Johannesen wrote:
> 
> > On Apr 1, 2005, at 1:38 PM, Geoffrey Keating wrote:
> >> 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.
> >
> > I wasn't aware of this.  It should be easy enough to keep track of the
> > pragmas
> > as seen so these symbols have the right value during preprocessing.
> > But that won't work in combination with inlining, because the saved
> > form
> > used for inlining is after preprocessing is done; I don't see an
> > approach
> > for that problem that doesn't involve major surgery.  I'm inclined to
> > just
> > let it work in the natural way and document it.
> 
> One more note, the C++ front-end does lexing all at once which means
> #pragma is
> not processed until after all of the preprocessing is done. So I don't
> know
> how this will work with the C++ front-end.

This suggests using the preprocessor for #pragma optimization-level
implementation, no?  At least if it recognizes the pragmas, it could
adjust the related defines.

Richard.


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