[LLVMdev] [RFC] Embedding command line options in bitcode (PR21471)

Wed Nov 19 22:23:52 PST 2014

> On Nov 19, 2014, at 7:00 PM, Jim Grosbach <grosbach at apple.com> wrote:
> 
> 
>> On Nov 19, 2014, at 6:51 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>> 
>> On Wed, Nov 19, 2014 at 8:44 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote:
>> 
>>> On Nov 19, 2014, at 6:06 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>>> 
>>> So I am deeply concerned about the direction this is taking. I'm trying to catch up on the thread, but I think Chris already highlighted my issue:
>>> 
>>> On Fri, Nov 14, 2014 at 4:57 PM, Chris Bieneman <cbieneman at apple.com <mailto:cbieneman at apple.com>> wrote:
>>>>> 1. How do we make sure we continue to be able to use the command line options we've been using for llc and other tools?
>>> 
>>> In discussions about the new cl::opt API I believe the general idea was that most of the options expressed using cl::opt are actually only relevant as debug options, so I think one big part of this work is really going to be identifying a subset of the current options which are actually relevant to expose in the IR.
>>> 
>>> I think this is critical.
>>> 
>>> The whole idea of cl::opt API is for *debugging* options. IE, not supported, expected variations on how passes behave. Those should always be controlled (at the LLVM API layer) through constructors and parameters, not through a side-layer.
>>> 
>>> There are parts of LLVM currently abusing the cl::opt mechanism to control fundamental functionality, but we should *absolutely* not bake any part of that or support for that into the IR! We should go find and fix those places to use reasonable APIs. Once we have that, I am very supportive of getting a good system for transmitting these options in bitcode and such in order to better support LTO. However, I think that in essentially every case there are going to be two options:
>>> 
>>> 1) Turn these options into function attributes because they can reasonably live as function attributes and different variations can co-exist within a module.
>> 
>> I have heard several people express strong opinions that even when those options are represented as function attributes, we will want a mechanism to override those with llc command line options for experimentation and debugging. If so, they will still need to exist as cl::opt (or some other equivalent). Are you suggesting otherwise?
>> 
>> Yes and no.
>> 
>> You might have a debug override option using cl::opt (or whatever we replace it with).
>> 
>> Or you might have an LLC option (which might be implemented with cl::opt but is categorically different from the debugging options in common LLVM libraries) that explicitly constructs passes with options, and the passes might skip the function attribute when given a specific override.
>> 
>> Probably lots of other alternative ways of achieving this goal I haven't thought of really....
>> 
>> My point is that regardless of what technique you use to override options, the things that can be serialized through the IR should *not* include debugging only 'cl::opt' options in the common LLVM libraries.
> 
> I think I agree (I’m one of those “several people” Bob mentioned) with this. Depends on which options you consider debugging only and what that implies for when/how they interact with the rest of the stuff. Maybe a specific example or two on each side of the divide to help make sure we’re all defining terms in a somewhat compatible way?

Yes, I think a specific example would help.

I keep saying this, but repetition might help: this is one piece of a much bigger problem and this proposal is NOT about moving all the cl::opt options into the IR. That would be insane. (Akira showed a bunch of them as an example because Eric asked what they would look like, but that wasn’t meant to imply that all those options would necessarily be put into the IR.) We need to look carefully at each option to decide whether it should be serialized in the IR.

This proposal is about the mechanism that we use to do that for one subset of the relevant options.

Let’s make it more specific and only consider the “-arm-long-calls” option. (I’m picking that arbitrarily as a simple example of something that seems like a good fit for a function attribute.) My assertion is that there are a number of other options that need to be handled in a similar way. We should figure out how to handle that kind of option and then we can talk later about which specific options fall into the category. If it turns out that “-arm-long-calls” is controversial or a bad example, we can pick a different one to discuss.

* The clang driver translates the “-mlong-calls” option into “-backend-option -arm-long-calls”. Nothing in clang outside the driver knows anything about “-arm-long-calls". We need a way for clang to recognize “-arm-long-calls” and translate it to a function attribute. As Eric suggested (and as I had originally assumed we would do), one option would be to teach clang to recognize that as a cc1 option and then to translate it to a function attribute. That is certainly a possibility, but there are quite of lot of target-specific options like this, and I’m not convinced there is much to be gained by baking them all into clang.

* There are a bunch of tests in llvm that pass “-arm-long-calls” as a command line option to llc. We could rewrite all those tests to add the function attribute instead, but it is useful to have the llc option available for debugging and experiments, and it would be nice to avoid the test churn to rewrite them all.

* There are a few places in ARMFastISel.cpp and ARMISelLowering.cpp that check the EnableARMLongCalls option. These should be changed to check for the function attribute once it is available. It would be good to avoid having to check BOTH the option and the attribute. One way to do that is to have the the llc option cause the corresponding attribute to be added to all the functions. Then the backend can just check for the attribute.

* The same backend option parsing is shared between llc and clang. When they see the “-arm-long-calls” option, they both need to do the same thing. If the option is one that gets serialized into the IR as a function attribute, both llc and clang need to go through all the functions and add the attribute to each of them. This is exactly what Akira’s patch supports. For the backend options that we choose to mark with codegenoption::FunctionAttrCategory, it will translate them to function attributes.

Akira and I talked about this with Chris B. and Pete Cooper, and I think we reached agreement that this is mostly orthogonal to Chris’s work. Chris wants to have an OptionRegistry and an OptionStore. If we had those things, we would still need a way to translate “-arm-long-calls” into a function attribute.

The best alternative proposal I can see is to have clang understand all these backend options and have code to map each one to a function attribute. But, that doesn’t do anything to support keeping the llc option. Personally I think it would be a very nice design to just completely drop all those llc options (at least for the set of options that we choose to serialize as function attributes) and rely on the function attributes as the only way to specify those things. Jim and Evan seemed to think I was crazy for even suggesting that…. and I suspect they’re probably right.

> 
>>  
>> 
>>> 
>>> 2) Keep the options as module-level options, but insist that they match for all modules being merged in LTO.

Yes, we will need to do this for some set of options, hopefully not too many. That’s outside the scope of this proposal, though. We can probably use a similar approach for module-level options, but let’s take it one step at a time.

>>> 
>>> 3) (very rare) have clean, well specified merge semantics to merge different options from different modules in LTO. I think these only come up quite rarely. The only really good example I know of would be something like "library link dependencies" where it is a list that we clearly just take the union to merge.
>>> 
>>> 
>>>>> 3. Where should the command line options or module/function attributes be stored once they are read out from the IR?
>>> 
>>> My suggestion would be the OptionStore that I proposed here: http://reviews.llvm.org/D6207 <http://reviews.llvm.org/D6207>
>>> Not to knock the option store (i quite like it), but I think that should be reserved for the cl::opt-style (but with your new API which is way better) debugging options, and never touch the IR._______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141119/9ae8a065/attachment.html>