<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 2/28/20 12:56 AM, Chris Lattner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3D74A06E-88F5-4D5D-A41D-192302C2EDC6@nondot.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
On Feb 27, 2020, at 9:44 PM, Nicholas Krause <<a
href="mailto:xerofoify@gmail.com" class=""
moz-do-not-send="true">xerofoify@gmail.com</a>> wrote:
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">On 2/28/20 12:19 AM, Chris Lattner wrote:<br
class="">
<blockquote type="cite" class="">Hi Nicholas,<br class="">
<br class="">
You might want to check out MLIR: its pass manager is
already automatically and implicitly multithreaded.<br
class="">
<br class="">
-Chris<br class="">
</blockquote>
Chris,<br class="">
<br class="">
I was aware that LLVM was moving to MLIR at some point due
to this. I've curious as<br class="">
to how MLIR deals with IPO as that's the problem I was
running into. Even if you have<br class="">
pipelines what guarantees do we have about IPO or are
there any. For example if an<br class="">
analysis pass runs after a loop pass for heuristics to get
good data, does MLIR ensure<br class="">
that? The problem isn't getting a pipeline as much as
IPO issues in terms of rescheduling<br class="">
in a pipeline or incorrectly splitting up into pipelines.
I yet to find a good solution on the<br class="">
GCC side as well and it seems that there will be issues
with this no matter what, not<br class="">
sure of what trade offs the LLVM side is willing to make.<br
class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Hi Nicholas,</div>
<div><br class="">
</div>
<div>It is very difficult to mix things like loop passes and IPO
passes in any system, unless one is prepared to preserve the
analysis results that the other depend on. One nice thing
about MLIR is that it defines this away, by allowing explicit
representation of loops in the IR. This means that it isn’t
an analysis pass that gets “invalidated” like the existing
LLVM LoopInfo analysis pass. It is just structurally
impossible for this to happen. I don’t think that all of the
AnalysisPass’s in LLVM have been super successful.</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">The other issues is that graph data structures
to my knowledge do not allow insertion<br class="">
of multiple nodes at the same time or how to scale the
graphs for callers or SSA. Not<br class="">
sure if you guys have encapsulated the operators and data
structures in a series of<br class="">
classes as that would be the first part. The other part is
figuring out how to link and<br class="">
interact with build systems to launch threads from make -j
or other similar things.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Yeah, MLIR handles that by factoring global use-def chains
on symbols (e.g. functions) as being different than local
use-def chains. This makes it much more efficient. You can
find more information on <a
href="https://mlir.llvm.org/docs/SymbolsAndSymbolTables/"
class="" moz-do-not-send="true">MLIR symbols here</a>.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">Thanks for the notice about MLIR through maybe
my IPO is not really there<br class="">
but after reading parts of it seems to be a issue through
a little smaller still<br class="">
and thanks for the prompt response,<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Sure, happy to help. It would be great to see a GIMPLE
dialect in MLIR someday :-)</div>
<div><br class="">
</div>
<div>-Chris</div>
</div>
</blockquote>
Chris,<br>
<br>
I asked the GCC what they want to do about MLIR and am waiting for a
reply. Anyhow what is the status and <br>
what parts are we planning to move to MLIR in LLVM/Clang. I've not
seen any discussion on that other than <br>
starting to plan for it. Perhaps we should start a wiki page for
that as I don't think all parts need to be MLIR.<br>
I don't have access to writing for the wiki so unfortunately I can't
start writing it up unless I get access. <br>
<br>
Regards and this is one reason you do your research before writing a
multi-threading program a lot of the <br>
research or work has been done at this point,<br>
Nick<br>
<blockquote type="cite"
cite="mid:3D74A06E-88F5-4D5D-A41D-192302C2EDC6@nondot.org">
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
Nick<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">On Feb 27, 2020, at
7:05 PM, Nicholas Krause via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" class=""
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br class="">
<br class="">
Greetings All,<br class="">
<br class="">
For the last few months since the GCC Cauldron I've
been researching/helping out<br class="">
plan for multi-threading GCC. I've posted my GCC ideas
here:<br class="">
<a
href="https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit"
class="" moz-do-not-send="true">https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit</a><br
class="">
<br class="">
as I've heard there is interest on the LLVM side as
well. I've talked to some of the IBM folks from<br
class="">
the Toronto area about it face to face due to them
having more middle end and back end knowledge<br
class="">
then me.<br class="">
<br class="">
Not sure if anyone is interested in my ideas or wants
me to extend my help on the LLVM side,<br class="">
<br class="">
Nick<br class="">
_______________________________________________<br
class="">
LLVM Developers mailing list<br class="">
<a class="moz-txt-link-abbreviated"
href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br
class="">
<a class="moz-txt-link-freetext"
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br
class="">
</blockquote>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<br>
</body>
</html>