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

[Jonathan Roelofs]

On 8/20/14, 2:07 PM, Owen Anderson 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.
+ 1
>
> • 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.
+ 1
>
> 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>