<div dir="ltr"><div>+Chandler & Alina for new pass manager context<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 27, 2020 at 9:45 PM Nicholas Krause 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"><br>
<br>
On 2/28/20 12:19 AM, Chris Lattner wrote:<br>
> Hi Nicholas,<br>
><br>
> You might want to check out MLIR: its pass manager is already automatically and implicitly multithreaded.<br>
><br>
> -Chris<br>
Chris,<br>
<br>
I was aware that LLVM was moving to MLIR at some point due to this.</blockquote><div><br>FWIW: I don't /tihnk/ that's quite an accurate representation of the situation. MLIR is now part of the LLVM project, but so far I haven't seen any discussions of moving the core LLVM project itself to MLIR (admittedly I'm not super clear on the details of MLIR or what that'd look like - I would've guessed that LLVM would itself be a lower level that a given MLIR stack might lower to, etc). There's been some discussion of folks interested in experimenting with using MLIR in Clang, though that's not a project goal right now.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I've <br>
curious as<br>
to how MLIR deals with IPO as that's the problem I was running into. <br></blockquote><div><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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Even if you have<br>
pipelines what guarantees do we have about IPO or are there any. For <br>
example if an<br>
analysis pass runs after a loop pass for heuristics to get good data,  <br>
does MLIR ensure<br>
that?   The problem isn't getting a pipeline as much as IPO issues in <br>
terms of rescheduling<br>
in a pipeline or incorrectly splitting up into pipelines. I yet to find <br>
a good solution on the<br>
GCC side as well and it seems that there will be issues with this no <br>
matter what, not<br>
sure of what trade offs the LLVM side is willing to make.<br>
<br>
The other issues is that graph data structures to my knowledge do not <br>
allow insertion<br>
of multiple nodes at the same time or how to scale the graphs for <br>
callers or SSA. Not<br>
sure if you guys have encapsulated the operators and data structures in <br>
a series of<br>
classes as that would be the first part. The other part is figuring out <br>
how to link and<br>
interact with build systems to launch threads from make -j or other <br>
similar things.<br>
<br>
<br>
Thanks for the notice about MLIR through maybe my IPO is not really there<br>
but after reading parts of it seems to be a issue through a little <br>
smaller still<br>
and thanks for the  prompt response,<br>
<br>
Nick<br>
>> On Feb 27, 2020, at 7:05 PM, Nicholas Krause via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Greetings All,<br>
>><br>
>> For the last few months since the GCC Cauldron I've been researching/helping out<br>
>> plan for multi-threading GCC. I've posted my GCC ideas here:<br>
>> <a href="https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit</a><br>
>><br>
>> as I've heard there is interest on the LLVM side as well. I've talked to some of the IBM folks from<br>
>> the Toronto area about it face to face due to them having more middle end and back end knowledge<br>
>> then me.<br>
>><br>
>> Not sure if anyone is interested in my ideas or wants me to extend my help on the LLVM side,<br>
>><br>
>> Nick<br>
>> _______________________________________________<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>
<br>
_______________________________________________<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>