<div dir="ltr"><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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-9005755180884645565WordSection1">
<p class="MsoNormal">(reply inline)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color: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_-9005755180884645565MsoListParagraph" style="margin-right:0in;margin-left:1in;margin-bottom:0.0001pt">
<u></u><span>1.<span style="font-style:normal;font-variant-caps:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"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_-9005755180884645565MsoListParagraph" style="margin-right:0in;margin-left:1in;margin-bottom:0.0001pt">
<u></u><span>2.<span style="font-style:normal;font-variant-caps:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"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. </p></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-9005755180884645565WordSection1"><div><p class="MsoNormal">
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.</p></div></div></div></blockquote><div><br></div><div><div style="color:rgb(0,0,0)">Well: if one can measure performance / binary size, I think it is a valid configuration to have. Being able to build and embed the compiler without paying the price for what you don't need seems valuable to me.</div><div style="color:rgb(0,0,0)">Of course if we're confident that there is no use (no way to use LLVM as a library and measure a difference there), removing it seems OK to me. </div><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-9005755180884645565WordSection1"><div></div></div></div></blockquote></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-9005755180884645565WordSection1"><div><p class="MsoNormal"> 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 that we should look into improving the situation on the MLIRContext itself to reduce the cost when used outside of a multi-threaded context.</div><div>It isn't great in general to maintain a modal behavior in order to dynamically manage the thread safety aspect of an object, so this will likely require quite some thoughts.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div></div></div></div>