<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I think that per the discussion up-thread that we should keep things as they are - downstream clients that don’t want the overhead should conditionalize themselves using local techniques.<div class=""><br class=""></div><div class="">If we keep LLVM_ENABLE_THREADS, then I think it would make sense to move that inline into the Threading.h header file, so everything can be constant propagated without LTO. Right now we have this in the .cpp file:</div><div class=""><br class=""></div><div class="">bool llvm::llvm_is_multithreaded() {<br class="">#if LLVM_ENABLE_THREADS != 0<br class=""> return true;<br class="">#else<br class=""> return false;<br class="">#endif<br class="">}</div><div class=""><br class=""></div><div class="">In any case, thank you all for the discussion, this all makes sense to me!</div><div class=""><br class=""></div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 14, 2020, at 4:34 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">My only input on this is that, if we do add this back, threading should be enabled by default, and then apps can disable it if they know it is safe to do so.<div dir="auto" class=""><br class=""></div><div dir="auto" class="">As Eli mentioned, C++11 threading primitives have proliferated in LLVM, and I would hesitate to add wrappers for them all. Either way I don't feel super strongly about it.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 11, 2020, 5:15 PM Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">Hi all,<div class=""><br class=""></div><div class="">I was looking at the profile for a tool I’m working on, and noticed that it is spending 10% of its time doing locking related stuff. The structure of the tool is that it reading in a ton of stuff (e.g. one moderate example I’m working with is 40M of input) into MLIR, then uses its multithreaded pass manager to do transformations.</div><div class=""><br class=""></div><div class="">As it happens, the structure of this is that the parsing pass is single threaded, because it is parsing through a linear file (the parser is simple and fast, so this is bound by IR construction). This means that none of the locking during IR construction is useful.</div><div class=""><br class=""></div><div class="">Historically, LLVM had a design where you could dynamically enable and disable multithreading support in a tool, which would be perfect for this use case, but it got removed by <a href="https://github.com/llvm/llvm-project/commit/9c9710eaf4c1f01b8b518bdba89aba059ab14175#diff-bb772a7e6d4ebf2b46c6d42c95f40ddf" target="_blank" rel="noreferrer" class="">this patch</a>: (xref <a href="https://reviews.llvm.org/D4216" target="_blank" rel="noreferrer" class="">https://reviews.llvm.org/D4216</a>). The rationale in the patch doesn’t make sense to me - this mode had nothing to do with the old LLVM global lock, this had to do with whether llvm::llvm_is_multithreaded() returned true or false … which all the locking stuff is guarded on.</div><div class=""><br class=""></div><div class="">Would it make sense to re-enable this, or am I missing something?</div><div class=""><br class=""></div><div class="">-Chris</div></div></blockquote></div>
</div></blockquote></div><br class=""></div></body></html>