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

[Nick Lewycky]

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