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

[Robinson, Paul]

Any further thoughts on this?  If the "screw around with PassManagers"
idea has to be replicated in each tool (clang, opt, etc) then I think
we are really better off with an attribute that LLVM itself understands.
--paulr

> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> bounces at cs.uiuc.edu] On Behalf Of Robinson, Paul
> Sent: Friday, September 20, 2013 9:36 AM
> To: Nick Lewycky; Bedwell, Greg
> Cc: llvm-commits at cs.uiuc.edu
> Subject: RE: [llvm] r189101 - Add function attribute 'optnone'.
> 
> > -----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
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits