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

[Akira Hatanaka]

On Wed, 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.
>
>
Maybe there is some misunderstanding here. The patch I sent doesn't change
llvm to control the behavior of passes through cl::opt options that are
currently defined as static variables. The function attributes embedded in
the IR control the behavior. The option variables (defined as CodeGenOpt,
which is a subclass of cl:opt) have only two roles:

1. Enable parsing the option that appears in the command line.
2. Provide the default value of the option in case neither the bitcode nor
command line had the attribute/option the pass is looking for.

It isn't absolutely necessary to keep those variables in the file, they can
be safely moved to another file as long as there is a way to get the
default value.

Also, I'm not sure customizing the behavior of passes through constructors
is a good idea, Wouldn't that mean you have to instantiate the passes
multiple times if there are functions that require different behaviors in
the module?

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.
>
> 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/20141120/586747fa/attachment.html>