[LLVMdev] [RFC] Internal command line options should not be statically initialized.

[Sean Silva]

On Wed, Sep 18, 2013 at 11:58 AM, Chris Lattner <clattner at apple.com> wrote:

> On Sep 17, 2013, at 10:10 AM, Andrew Trick <atrick at apple.com> wrote:
>
> LLVM's internal command line library needs to evolve. We have an immediate
> need to build LLVM as a library free of static initializers, but before
> brute-force fixing this problem, I'd like outline the incremental steps
> that will lead to a desirable long term solution. We want infrastructure in
> place to provide an evolutionary path.
>
>
> Thank you for tackling this, we should have fixed this years ago.
>
> Please do a pass over the cl::opts we have, and remove ones that are long
> dead or unused.   Do we still need -join-liveintervals? :-)
>
>
>
> On Sep 17, 2013, at 12:03 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>
> On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote:
>
>> Wait, I have a terrible idea.  Why don't we roll our own .init_array
>> style appending section?  I think we can make this work for all toolchains
>> we support.
>>
>
> Andy and I talked about this, but I don't think its worth it. My opinion
> is:
> 1. For tool options (the top-level llc, opt, llvm-as etc. opts) it doesn't
> matter.
> 2. For experimental options (options that we would be happy if they were
> compiled out of a production compiler/JIT client/whatever), it doesn't
> matter.
> 3. For backend options that need to always be available, lots of them
> probably already need to get promoted to real API.
> 4. For the remaining options (ones that don't need to become API, but also
> aren't purely experimental), many of them can probably easily be
> initialized by some existing initialization hook (pass initialization,
> target initialization).
> 5. There aren't enough options left not in those categories to motivate
> some kind of clever solution.
>
>
> I think that this is a great summary of the problem.  Having cl::opt's
> compiled *out* of non-assert build by default makes a lot of sense to me,
> and having tool options use toolopt<> (or something) also makes perfect
> sense.
>
> If you're going to go and tackle pass-specific options, I think that we
> should consider changing the syntax and overall design of the command line
> options.   We already have some manual name mangling/namespacification of
> options (e.g. -tail-dup-limit=). Perhaps we should formalize this somehow?
>
>
In my work on LTO this summer, I kept getting a desire to be able to
"parameterize" passes to see how their behavior changes. One thing I wanted
to do related to some mailing list discussions was to try running a "light"
inlining pass at various stages, but AFAIK LLVM doesn't have a way to do
something like `opt ... -simple-inliner(40) ... -inline`. In one of
Shuxin's preliminary LTO experiment patches, in order to get a
SimpleInliner with threshold 40, he had to add C++ code (admittedly little,
but still requiring a recompile, and the threshold was hardcoded).

Another example where "pass parametrization" was a huge win that I ran into
this summer was with the ASan instrumentation pass that uses cl::opt's for
this (it has a LOT of cl::opt's btw). Being able to dynamically configure
the shadow offset and scale with the existing SDK compiler was a crucial
productivity win, so losing that would be a shame. Maybe there could be
something like a clang option to allow
`-configure-pass=asan(mapping-scale=...,offset-log=...)` that actually
associates that configuration with ASan? Idk (that's just off the top of my
head).

-- Sean Silva


> -Chris
>
>
> _______________________________________________
> 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/20130918/5ea6adf8/attachment.html>