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

[Chris Bieneman]

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?

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 <mailto: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 <mailto:resistor at mac.com>> wrote:
>> 
>>> 
>>>> On Aug 19, 2014, at 10:24 PM, Chandler Carruth <chandlerc at google.com <mailto: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 <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         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/f1e3e323/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl_opt.diff
Type: application/octet-stream
Size: 9063 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/f1e3e323/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/f1e3e323/attachment-0001.html>