[llvm] r189101 - Add function attribute 'optnone'.

[Robinson, Paul]

> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> bounces at cs.uiuc.edu] On Behalf Of Nick Lewycky
> Sent: Thursday, September 19, 2013 11:47 PM
> To: Bedwell, Greg
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm] r189101 - Add function attribute 'optnone'.
> 
> Greg_Bedwell at sn.scee.net wrote:
> > Hi,
> >
> >> I think that being able to specify the optimization level on a per
> > function
> >> basis, like in GCC, would be useful (I think several people are
> > interested in
> >> this, so it may actually happen).  One of my gripes with optnone is
> that
> > it is
> >> heading in this direction but isn't solving the general problem.  I
> > would be
> >> much happier with a more general approach than optnone that made it
> >> possible to
> >> say "optimize this function at -O0" but that also allowed you to
> > say"optimize
> >> it at -O1" (or whatever).  Then you could optimize most of the
> program
> > with
> >> -O2/-O3 and the problematic functions with -O1 (or -O0).  So from
> >> this point of
> >> view I don't think optnone goes far enough.  [Having the optimization
> > level on
> >> the function also means that per-function passes could look up
> >> whether they are
> >> supposed to be doing -Og optimization and turn problematic transforms
> > off].
> >>
> >
> > This sounds good to me.  Our original proposal was for this very
> feature:
> > http://llvm.1065342.n5.nabble.com/PROPOSAL-per-function-optimization-
> level-control-td57094.html
> >
> >
> > Unfortunately, it didn't seem to register any particular interest at
> time,
> > so we were advised to scale-back our ambitions and go for something
> less
> > ambitious/controversial, hence 'optnone' which would still fulfil our
> > primary use-case and possibly be a stepping stone to more fully blown
> > per-function optimization later on.  Maybe now that there is firm talk
> of
> > a new pass manager the proposal can be revisited w.r.t making sure the
> new
> > implementation could support this type of feature as part of its
> design?
> 
> So I second Duncan's idea that we should have control over optimization
> level. Here's the thing: we already have detailed control over the
> IR-level optimizations. We can run PassManagers over particular
> functions, choose the particular pipeline, etc. I think that should be
> enough, or should be extended. The existing API for this doesn't use
> function attributes, and I think the natural extension wouldn't either.

Hmm, by "we" do you actually mean "clang but not opt or any other tool"
here?  Some of us were chatting about this stuff yesterday and thought
that while the PassManager manipulation idea would work for clang it 
wouldn't generalize to other tools.  This suggests that optnone really 
does need to be an IR attribute.  (I could easily be wrong, I don't
really understand this PassManager stuff.)
--paulr

> 
> The backend however, doesn't offer this sort of control, nor could it
> with its current design. Its pass list is fixed, each pass has semantic
> requirements that other passes ran before it. Hence, having function
> attributes for "make the backend codegen this at -O0" (there's an enum
> in codegen with four settings in it) would be fantastic.
> 
> Nick
> 
> >
> > Thanks for bearing with us whilst we stumble around trying to
> integrate
> > into the community properly!
> >
> > Greg Bedwell
> > SN Systems - Sony Computer Entertainment Group
> >
> >
> > **********************************************************************
> > This email and any files transmitted with it are confidential and
> intended
> > solely for the use of the individual or entity to whom they are
> addressed.
> > If you have received this email in error please notify
> postmaster at scee.net
> > This footnote also confirms that this email message has been checked
> for
> > all known viruses.
> > Sony Computer Entertainment Europe Limited
> > Registered Office: 10 Great Marlborough Street, London W1F 7LP, United
> > Kingdom
> > Registered in England: 3277793
> > **********************************************************************
> >
> > P Please consider the environment before printing this e-mail
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits