Chandler Carruth
2014-Aug-20 05:24 UTC
[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>
Owen Anderson
2014-Aug-20 17:42 UTC
[LLVMdev] [RFC] Removing static initializers for command line options
> 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>
Rafael Avila de Espindola
2014-Aug-20 19:16 UTC
[LLVMdev] [RFC] Removing static initializers for command line options
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>
Maybe Matching Threads
- [LLVMdev] [RFC] Removing static initializers for command line options
- [LLVMdev] [RFC] Removing static initializers for command line options
- [LLVMdev] [RFC] Removing static initializers for command line options
- [LLVMdev] [RFC] Removing static initializers for command line options
- [LLVMdev] [RFC] Removing static initializers for command line options