<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Sep 18, 2013, at 9:56 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Sep 18, 2013, at 9:03 PM, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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?</div>
</div></div></div></blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div>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.</div></blockquote><div><br></div></div><div><div>I'll coalesce my responses to Chris and Chandler here:</div><div><br></div><div>This fixes a particularly horrible bug where LLVM crashes during PassRegistry::removeRegistrationListener when a multi-threaded process exits while compiler threads are running.</div><div><br></div><div>This patch was meant to</div><div>(a) fix a bug</div><div>(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.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>Ok, the juxtaposition of the two discussions made this confusing.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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.</div></blockquote><div><br></div><div>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)?</div></div></blockquote><br></div><div><div><div>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 :)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Andy</div></div></div></body></html>