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

[Robinson, Paul]

> >>> 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