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

[Sean Silva]

On Fri, Sep 27, 2013 at 5:15 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> 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.  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!
>

Remember that LLVM serves a wider variety of use cases than just being a
"compiler backend".

I think that historically Clang has been so tightly coupled to LLVM that it
has just been easier to directly use the "low level" pass management API.
Without having a larger number of production-quality language frontends
actively participating in LLVM development (most just take LLVM as it is,
and report a couple bugs here and there), it's hard to pin down what a
higher-level API should look like that would best serve frontends.

-- Sean Silva


>
> 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.
>
> --paulr
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



On Fri, Sep 27, 2013 at 5:15 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> 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.  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.
>
> --paulr
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130928/bf114c97/attachment.html>