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

Robinson, Paul Paul_Robinson at playstation.sony.com
Mon Sep 30 11:55:09 PDT 2013

> -----Original Message-----
> From: Nick Lewycky [mailto:nicholas at mxc.ca]
> Sent: Saturday, September 28, 2013 10:02 PM
> To: Robinson, Paul
> Cc: Bedwell, Greg; llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm] r189101 - Add function attribute 'optnone'.
> Robinson, Paul wrote:
> >>>>> 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?
> >>
> >> I was referring to clang, or to your frontend if you have one.
> >>
> >>     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.)
> >>
> >> Opt offers control of the passmanager all the way out to the
> >> command-line. It currently doesn't offer per-function control, but
> you
> >> can do the same things with the existing command-line tools if you
> >> really wanted. Use llvm-extract to pull out the functions, then opt,
> >> then llvm-link to merge them back in.
> >>
> >> I don't understand why you think it would need to be an IR attribute
> >> just because the other tools wouldn't "support" it. There are plenty
> >> language attributes in clang which aren't represented in the IR (and
> >> hence not supported there).
> >>
> >> It's also difficult to describe what goes wrong with having an
> optnone
> >> attribute. There are some questions that are hard to answer, like
> "what
> >> about module passes?" which I claim is a symptom of this having the
> >> wrong design. It's very clear what happens with module passes when
> you
> >> use the API directly.
> >>
> >> Mostly I just don't like the idea of replicating "mechanism to
> control
> >> passmanager" in the IR. We already have a mechanism to control the
> >> passmanager, and this new one doesn't fit. If the passmanager
> currently
> >> took the list of passes to run as a module attribute, I wouldn't be
> so
> >> bothered.
> >>
> >> Nick
> >
> > I hadn't looked closely at the pass manager previously but this
> morning
> > I spent some time with it.  Now I understand why you're proposing
> > what you do--because this pass-management interface MAKES NO SENSE.
> >
> > The front end has no business knowing the names and reasonable sets of
> > optimization and codegen passes.
> Except that sometimes it does. The frontend might not be a C compiler,
> it may be that the input is already in SSA form (or equivalent, see
> function programming) or written using continuation passing, etc., and
> this leads to very different decisions of what passes you want and in
> what order. The frontend might be a JIT that knows exactly which passes
> it's willing to run over the IR it just constructed, based on lots of
> work timing this sort of thing in the past.
>    The four other compiler systems I've
> > worked with previously all had the frontend provide the moral
> equivalent
> > of command-line options and left these details up to the
> middle/backend.
> > I had naively assumed that Clang/LLVM would use this sensible design
> too.
> > So much attention to good structure, not to mention layering,
> throughout
> > the project; and here's this-- this-- gah!
> >
> > Okay... deep breaths... ommmmm...
> >
> > What we proposed would make sense if this aspect of the Clang/LLVM
> > interface had a reasonable, or even rational, division of
> responsibility.
> > Now I don't know what to think.
> There's a convenience wrapper called the PassManagerBuilder in
> include/llvm/Transforms/IPO/PassManagerBuilder.h for those who don't
> need that low level control.
> Nick

I don't have a problem with LLVM providing a fine-grained interface
for those callers that need or want such fine-grained control.

I do have a problem with a normal front-end (e.g. Clang) thinking
that it needs to use such a fine-grained control interface to do
normal stuff.

I especially have a problem if Clang _correctly_ thinks it needs
such a fine-grained control interface, because the higher-level
interface is inadequate.  Which does appear to be the case; I think
Clang has no business sticking its fingers so far into the inlining
pass decision (for example) or some of the other things it's doing
in BackendUtil.cpp.

(And why is PassManagerBuilder buried inside Transforms/IPO in the
first place?  That's a very silly place to put it.)


More information about the llvm-commits mailing list