<div dir="ltr"><div dir="ltr">Hello Matthias.</div><div dir="ltr"><br><div>The idea of having a separate API for options in <span class="" id=":1jh.1" tabindex="-1" style="">LLVMContext</span> is good but difficult to implement. That is probably why it has not been evolved.</div><div>There are so many cl::opt all over the code to change ... This would also split all cl::opt into incompatible groups: those that are bound to <span class="" id=":1jh.2" tabindex="-1" style="">LLVMContext</span> and those that are not.</div><div>With the proposed thread local option context (<a href="https://reviews">https://reviews</a>.<span class="" id=":1jh.3" tabindex="-1" style="">llvm</span>.org/D53424) your idea can be simulated by binding <span class="" id=":1jh.4" tabindex="-1" style="">LLVMContexts</span> with <span class="" id=":1jh.5" tabindex="-1" style="">ContextValues</span> and setting threads to their LLVMContexts' <span class="" id=":1jh.6" tabindex="-1" style="">ContextValues</span>.</div><div>I believe that D53424 is a minimal change that can greatly extend the cl::opt-based configuration flexibility without affecting other aspects. This change does not contradict with module flags, <span class="" id=":1jh.7" tabindex="-1" style="">LLVMContext</span> Debug options and other ways we have to customize the pipeline.</div><div><br></div><div>Thanks.</div><div>-<span class="" id=":1jh.8" tabindex="-1" style="">Yevgeny</span> <span class="" id=":1jh.9" tabindex="-1" style="">Rouban</span></div><div><br></div></div></div>