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

[Nick Lewycky]

Robinson, Paul wrote:
>> -----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.

Absolutely yes, but normally we build high-level interfaces on top of 
the low-level interfaces. It's a design "smell" when we can't, even 
though it happens sometimes, often for efficiency reasons.

So at this point, I think we have a consensus that there's two ways to 
do it with nothing technically wrong either, just a difference in 
opinions/priorities with respect to the design. I'm satisfied that you 
know why I have my opinions, and I don't plan to stand in the way of 
somebody with patches. (I mean, I still do that they they're *wrong on 
the internet*, but in this case it's not clear cut.)

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

Dunno offhand. If I had to guess, to solve a layering violation?

Nick