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

Wed Aug 20 16:17:51 PDT 2014

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

>
> On Aug 20, 2014, at 3:12 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
>
> 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.
>
>
> Most cl::opts are in the passes, so they do have a convenient place to put
> the CreateOption call. There are others in places that are less convenient
> - like ISel lowering. However there are always initialization calls that
> CreateOption calls can be put into (in targets, libraries, etc).
>
> Fundamentally you and I are looking at this problem differently. My
> proposal has the following requirements:
> 1) Preserve existing command line option function *exactly* as it is today
> 2) Eliminate all static initializers associated with command line options
> and their storage
> 3) Design a solution that can be phased in with existing code so we don’t
> need to change all cl::opts in the same commit
>

I think your approach makes sense in view of those requirements.

-- Sean Silva

>
> These requirements unfortunately made your requirements unfeasible.
>

> One important point I would make, is that while my changes may make it
> slightly less convenient to create new command line options, it does not
> impact the ability of a developer to manipulate the values of the options.
> The flags behave as they do today, and there is still one line of code
> somewhere that sets the value the compiler actually uses. In my example
> this is in the constructor for the pass.
>
> -Chris
>
>
> -- 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/b21e2926/attachment.html>