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

[Chandler Carruth]

On Wed, Nov 19, 2014 at 8:44 PM, Bob Wilson <bob.wilson at apple.com> wrote:

>
> On Nov 19, 2014, at 6:06 PM, Chandler Carruth <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>
> 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.


>
>
> 2) Keep the options as module-level options, but insist that they match
> for all modules being merged in LTO.
>
> 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
>>
>
> 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         http://llvm.cs.uiuc.edu
> 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/5b772037/attachment.html>