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

[Chandler Carruth]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140819/c3a5be6b/attachment.html>