[llvm] r189101 - Add function attribute 'optnone'.
nicholas at mxc.ca
Tue Oct 1 00:11:10 PDT 2013
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
>>>>>>> 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
>>>>>>> enough, or should be extended. The existing API for this doesn't
>>>>>>> function attributes, and I think the natural extension wouldn't
>>>>>> Hmm, by "we" do you actually mean "clang but not opt or any other
>>>> 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
>>>>>> wouldn't generalize to other tools. This suggests that optnone
>>>>>> 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
>>>> 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
>>>> attribute. There are some questions that are hard to answer, like
>>>> 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
>>>> use the API directly.
>>>> Mostly I just don't like the idea of replicating "mechanism to
>>>> passmanager" in the IR. We already have a mechanism to control the
>>>> passmanager, and this new one doesn't fit. If the passmanager
>>>> took the list of passes to run as a module attribute, I wouldn't be
>>> I hadn't looked closely at the pass manager previously but this
>>> 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
>>> of command-line options and left these details up to the
>>> I had naively assumed that Clang/LLVM would use this sensible design
>>> So much attention to good structure, not to mention layering,
>>> 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
>>> 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.
> 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?
More information about the llvm-commits