<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 12, 2020 at 3:56 PM Eli Friedman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-4229286402721459753WordSection1">
<p class="MsoNormal">(reply inline)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-left:0.5in"><b>From:</b> Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>>
<br>
<b>Sent:</b> Sunday, April 12, 2020 3:28 PM<br>
<b>To:</b> Eli Friedman <<a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] LLVM multithreading support<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">On Apr 12, 2020, at 2:23 PM, Eli Friedman <<a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>> wrote:<u></u><u></u></p>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal" style="margin-left:0.5in">So probably I’d recommend two things:<u></u><u></u></p>
</div>
<p class="gmail-m_-4229286402721459753MsoListParagraph" style="margin-right:0in;margin-left:1in;margin-bottom:0.0001pt">
<u></u><span>1.<span style="font:7pt "Times New Roman"">
</span></span><u></u>If locking uncontended locks is showing up on profiles as a performance bottleneck, it’s probably worth looking into ways to reduce that overhead in both single-threaded and multi-threaded contexts. (Reducing the number of locks taken
in frequently called code, or using a better lock implementation).<u></u><u></u></p>
<p class="gmail-m_-4229286402721459753MsoListParagraph" style="margin-right:0in;margin-left:1in;margin-bottom:0.0001pt">
<u></u><span>2.<span style="font:7pt "Times New Roman"">
</span></span><u></u>If you want some mechanism to disable MLIR locking, it should probably be a boolean attached to the MLIR context in question, not a global variable.<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> <u></u><u></u></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Ok, but let me argue the other way. We currently have a cmake flag that sets LLVM_ENABLE_THREADS, and that flag enables an across the board speedup. That cmake flag is the *worst* possible thing for library composability.
:-). Are you suggesting that we remove it?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
<p class="MsoNormal">Yes, I would like to remove LLVM_ENABLE_THREADS. Assuming you’re not building for some exotic target that doesn’t have threads, there isn’t any reason to randomly shut off all thread-related functionality in the LLVM support libraries.
There isn’t any significant performance or codesize gain to be had outside of MLIR, as far as I know, and it increases the number of configurations we have to worry about. I have no idea if turning it off even works on master; I don’t know of any buildbots
or users using that configuration.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If you want to support some sort of lockless mode in MLIR, I think that burden should be carried as part of MLIR, instead of infecting the entire LLVM codebase.</p></div></div></div></blockquote><div><br></div><div>I agree here. It is going to be much easier, and likely saner, to have the MLIR bits controlled by a flag in the MLIR context. Trying to stop/start threading bits in utilities doesn't seem reliable given all of the different factors, e.g. ThreadPool /llvm::parallel_for/etc. functionality. It also provides a much more controlled interface/contract.</div><div><br></div><div>-- River</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4229286402721459753WordSection1"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal">-Eli <u></u><u></u></p>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>