[llvm] r190974 - Encapsulate PassManager debug flags to avoid static init and cxa_exit.

[Andrew Trick]

On Sep 18, 2013, at 9:56 PM, Chris Lattner <clattner at apple.com> wrote:

> On Sep 18, 2013, at 9:03 PM, Andrew Trick <atrick at apple.com> wrote:
>>>> Where is the requirement for the core library to have no static initializers coming from? What is the support plan here? What problem are you actually trying to fix?
>>>> 
>>>> Just for clarity, I have read the llvmdev thread, and I understand the *general* goal, but this patch itself doesn't seem like a clean incremental step toward that goal, doesn't reference any of the constructs under discussion in that thread.
>>> 
>>> I totally agree.  This seems like a hack that would be resolved by making cl::opt's get compiled out in non-assert builds, which you already described.
>> 
>> I'll coalesce my responses to Chris and Chandler here:
>> 
>> This fixes a particularly horrible bug where LLVM crashes during PassRegistry::removeRegistrationListener when a multi-threaded process exits while compiler threads are running.
>> 
>> This patch was meant to
>> (a) fix a bug
>> (b) handle one of the handful of special cl::opt cases that won't be covered by the general approach I outlined in the RFC.
>> 
>> The proposal talked about handling the majority of options incrementally without enormous churn. This case is an exception that I wanted to get out of the way first.
> 
> Ok, the juxtaposition of the two discussions made this confusing.
> 
>> This case is special because we want the PassManager options to be availabe in non-assert builds, or so I thought. These are clearly "tool" options that need to be exported to a number of LLVM-based tools.
> 
> Ok.  In that case, I'd still rather you solve this a different way.  How about hoisting these options up to the opt tool (the only one that they make sense?  or do they also belong in llc)?

My goal was to deal with all the options uniformly, keep current tool behavior consistent, and provide a way for experimental tools to inherit these options without redefining them. Pretty much the opposite of what you're saying, which is fine :)

I've been confusing people by refering to "tool" options. I really meant internal library options that can be imported by tools. I'll try to straighten this out on the RFC thread.

We currently have two mechanisms to deal with these kind of options: -mllvm and CodeGen/CommandFlags.h. IMO both are a disaster in terms of usability and overhead reproducing optimizer/backend problems.

The internal pass manager debugging options should be available to any tool that uses the pass manager: opt,llc,clang,dragonegg,llvm-???. Likewise for other LLVM components. The tool should not define its own interface for internal options. We should be able to copy/paste command line snippets across tools reliably.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130919/5e03817b/attachment.html>