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

[Chandler Carruth]

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141119/158d8ac0/attachment.html>