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

[Pete Cooper]

> On Aug 19, 2014, at 6:45 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> FWIW, I largely agree with Rafael's position here, at least in the near term.
> 
> The nice thing about it is that even if we don't stay there forever, it is a nice incremental improvement over the current state of the world, and we can actually be mindful going forward of whether the restriction it imposes (an inability to use "internal" knobs from within a library context that have multiple different library users in a single address space) proves to be a significant on-going burden.
I actually disagree with this for two reasons.

The first is that if there are going to be changes to the code anyway to remove static initializers, and we can move the storage to the pass at the same time, the we should make just one change and not two.

The second reason is that in most cases these knobs should not be globals. If I had a piece of data (not a CL::opt) in global scope, only used by one pass, then I'm sure people would question why it's a global at all and move it inside the class. We're treating cl::opt as special here when there's no reason for the opt or the storage to be global. 

We frown upon the use of globals, otherwise LLVM would be littered with them like many other C++ code bases. I don't think cl::opts should be special at all in this respect.

Thanks
Pete
> 
>> On Tue, Aug 19, 2014 at 3:57 PM, Chris Bieneman <beanz at apple.com> wrote:
>> > On Aug 19, 2014, at 3:10 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> >
>> >> There are two reasons this doesn’t work:
>> >>
>> >> (1) Cases where I might want to set a debug variable for the WebKit JIT but not for Mesa - if the option storage is global it will get overwritten for all users
>> >
>> > This really comes up? Really, we are not talking -O2/-O3 or inlining
>> > thresholds. We are talking things like lcr-max-depth being needed for
>> > a debugging session.
>> 
>> I’ve toggled on SROA's "sroa-random-shuffle-slices” before for testing, I've played with InstCombine’s "enable-double-float-shrink”, so it does (although admittedly not terribly often).
> 
> I'm somewhat surprised that this comes up much in a context where you *can't* extract a test case and play with it using 'opt' or some other stand-alone context.
> 
> If these come up so rarely, would it be unreasonable to just flip the flag in the source code, and build a DSO to test with? For example, this is how I have done counter-based bisection and combine-based bisection of things (a similarly rare but necessary activity I suspect) and it seems to work well.
> 
> -Chandler
> _______________________________________________
> 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/20140819/e5b98266/attachment.html>