llvm dev - Aug 2014 - [LLVMdev] [RFC] Removing static initializers for command line options

On Tue, Aug 19, 2014 at 10:10 PM, Pete Cooper <peter_cooper at apple.com>
wrote:
> 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.
>
No one is suggesting otherwise that I have seen? At least, my
interpretation (perhaps incorrect, I've not had time to read all of this
thread in 100% detail) was that the removal of static initializers wouldn't
require changing every cl::opt variable.

>
> 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.
>
Sure, you're arguing against the core design of cl::opt. However, we have
it, and it wasn't an accident or for lack of other patterns that we chose
it.

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.

Once you factor those in, we have a tradeoff. Historically, the tradeoff
was made in the direction of convenience, relying on a very narrow
interpretation of the use cases. It isn't clear to me that we should,
today, make a different tradeoff. It certainly doesn't make sense why you
would gate removing static initializers (a clear win) on forcing a change
on a core design pattern within LLVM which not all of the developers are
really supportive of (at this point).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140819/daa8dc07/attachment.html>

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

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.

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