<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 29, 2020 at 2:19 PM Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.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 style="overflow-wrap: break-word;">On Feb 29, 2020, at 2:08 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<div><blockquote type="cite"><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've<span> </span><br>curious as<br>to how MLIR deals with IPO as that's the problem I was running into.<span> </span><br></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br>FWIW I believe LLVM's new pass manager (NPM) was designed with parallelism and the ability to support this situation (that MLIR doesn't? Or doesn't to the degree/way in which the NPM does). I'll leave it to folks (Chandler probably has the most context here) to provide some more detail there if they can/have time.<br></div></div></blockquote></div><br><div>Historically speaking, all of the LLVM pass managers have been designed to support multithreaded compilation (check out the ancient history of the <a href="http://llvm.org/docs/WritingAnLLVMPass.html" target="_blank">WritingAnLLVMPass</a> doc if curious).</div></div></blockquote><div><br></div><div>I think the specific thing that might'v been a bit different in the NPM was to do with analysis invalidation in a way that's more parallelism friendly than the previous one - but I may be misrepresenting/misundrstanding some of it.</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 style="overflow-wrap: break-word;"><div>The problem is that LLVM has global use-def chains on constants, functions and globals, etc, so it is impractical to do this.  Every “inst->setOperand” would have to be able to take locks or use something like software transactional memory techniques in their implementation.  This would be very complicated and very slow.<br></div></div></blockquote><div><br>Oh, yeah - I recall that particular limitation being discussed/not addressed as yet.<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 style="overflow-wrap: break-word;"><div></div><div>MLIR defines this away from the beginning.  This is a result of the core IR design, not the pass manager design itself.<br></div></div></blockquote><div><br>What does MLIR do differently here/how does it define that issue away? (doesn't have use-lists built-in?)<br><br>- Dave<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 style="overflow-wrap: break-word;"><div></div><div><br></div><div>-Chris</div></div></blockquote></div></div>