[LLVMdev] [RFC] Removing static initializers for command line options

[Sean Silva]

On Wed, Aug 20, 2014 at 2:16 PM, Chris Bieneman <beanz at apple.com> wrote:

> I think Rafael’s suggestion of using the address of a global as the key to
> the option store gives us the ability to accomplish all our goals without
> introducing a string keyed option store.
>
> I’ve updated my patches from the original proposal to reflect those
> changes.
>
> Does this look reasonable?
>

The design seems to require no less than 4 not-too-close-to-each-other code
changes to add an option (and LLVMOptionKey declaration, an LLVMOptionKey
initialization, a call to GetValue, and a call to CreateOption). I think
that the convenience for developers is an important aspect and this
solution regresses significantly on that front.

Especially, I think that we need to evaluate the viability of an explicit
CreateOption call. Do all uses of cl::opt in the library code have a
relatively convenient place to put that call? If not, then we won't be able
to migrate them, and we will be stuck with a partial solution. If we are
willing to accept a partial solution, then the design discussion needs to
change; at the very least we need to consider the scope of the partial
solution.

-- Sean Silva


>
> Thanks,
> -Chris
>
>
> On Aug 20, 2014, at 1:07 PM, Owen Anderson <resistor at mac.com> wrote:
>
>
> On Aug 20, 2014, at 12:16 PM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
>
> There nothing magical about llc or opt. If you need to pass debug options
> to your own tools, you can do that with command line options like llc or
> opt, but the important factors remain:
>
> * this is a debugging session, not regular use.
> * the option storage can remain static.
> * we don't need and API for setting the value of the option, command line
> is sufficient.
>
>
> #2 and #3 are not true.
>
> •  As Chris has pointed out, it’s a perfectly normal circumstance in the
> systems we deal with to have multiple instances of LLVM resident for
> different clients.  Lots of applications bring in both WebKit and the
> OpenGL, including the browser itself via WebGL!  If I’m debugging or
> testing one component of the system, I definitely do not want debug options
> I have set to cause differences in the other components.
>
> • A lot of these users are not launched at the command line in a typical
> fashion.  They’re either embedded into the address space of an existing
> application (which may have a totally different command line interface, or
> indeed none at all), or running in daemons whose lifetime is controlled by
> other parts of the system.  Either way, setting options at the command line
> in not always viable.
>
> I agree that llc, opt and clang *shouldn’t* be special, but everything
> you’re saying here is firmly rooted in a world where they are special, or
> at least all use cases for debugging LLVM look like them.
>
> —Owen
>
>
> Sent from my iPhone
>
> On Aug 20, 2014, at 13:42, Owen Anderson <resistor at mac.com> wrote:
>
>
> On Aug 19, 2014, at 10:24 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> For example, we don't require all constants to be per-pass, and instead
> have per-file constants. Rafael is suggesting that one use case for cl::opt
> global variables is, in essence, a constant that is somewhat easier for a
> developer of LLVM (*not* a user) to change during debugging and active
> development. I don't think the desire for convenience and only supporting
> the default value in production contexts are completely invalid.
>
>
> I think this statement ignores important debugging use cases, and
> over-simplifies the model of how LLVM-based frameworks are often developed.
>  As an example, say I develop an LLVM backend for a custom co-processor,
> and the compiler for it runs inside the software stack of the driver for my
> co-processor.  Per what you and Rafael are saying, the driver should not be
> able to programmatically set command line options to LLVM.  But this
> ignores the reality that, when developing my backend, I may still need to
> be able to twiddle debugging options when debugging a live driver stack.
>
> Fundamentally, you argument is rooted in a world where LLVM debugging is
> always done on the llc or clang binaries, where the LLVM developer can
> easily modify the command line arguments themselves.  That’s not true of
> many use cases where LLVM as a shared library is relevant.
>
> —Owen
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> 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/20140820/75fe7e4c/attachment.html>