RE: PATCH [function-specific, committed] Add #pragma support, make cold functions compile with -Os

["Meissner, Michael" <michael dot meissner at amd dot com>]

> -----Original Message-----
> From: Sylvain Pion [mailto:Sylvain.Pion@sophia.inria.fr]
> Sent: Wednesday, June 18, 2008 6:40 AM
> To: Meissner, Michael; gcc-patches@gcc.gnu.org; karthikkumar@gmail.com;
> Harle, Christophe
> Subject: Re: PATCH [function-specific, committed] Add #pragma support,
> make cold functions compile with -Os
> 
> Michael Meissner a écrit :
> > This patch also allows a function to be compiled with different
> optimization
> > options than the standard in addition to different target options.
> Right now,
> > the only use is to compile cold functions with -Os.  I am stilling
> mulling over
> > how much of the optimization interface to allow users to use via
> attribute or
> > #pragma.  I would be interested in hearing from potential users whether
> you
> > really need to set say -ftree-vectorize in a function, or just having
> > -O1/-O2/-O3/-Os is sufficient, and have the -f options inherited from
> the
> > command line.
> 
> As I mentioned previously, I'm still interested in -frounding-math, on a
> per-function level.  A bonus if this does not stop inlining, of course,
> but this is not a strong requirement for me (this is related to the
> FENV_ACCESS
> pragma).  This is useful for implementing interval arithmetic efficiently
> as a C++ library, like the one which is proposed for TR2, and not forcing
> its users to add -frounding-math on the command line.
> 
> Is something like this on your todo-list?

My original message may have bounced, due to some internal firewall issues.

I think you and Andi make points that it is useful to widen the scope beyond just -On.  At the internal level, it is fairly simple to add, since the current interface just copies all of the optimization switches in one step, and we just have to add some parsing to add the syntax.

I did get feedback that if you allow arbitrarily switching things around you can confuse the optimizers.

I also agree that ultimately it would be nice to allow this at the statement level, rather than just the function level, but that will need some more thought and is a 4.5 feature and not 4.4. 

--
Michael Meissner
AMD, MS 83-29
90 Central Street
Boxborough, MA 01719