<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2/10/20 9:50 AM, Albert Cohen via
llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAFx_MV=RXX-OxbSVc6iq-TFTkEktp-Jqi6Oska1ciE8DbyTO-Q@mail.gmail.com">
<div dir="ltr">Thanks Chris for CCing us.
<div><br>
</div>
<div>I remember Michael's presentation and suggestion to
consider Roslyn's design and experience. I'll be glad to
discuss further in April. Michael, we can also talk later this
week if you'd like. I'll send you a separate email.</div>
<div><br>
</div>
<div>Loop transformations in MLIR take many different paths.
Polyhedral affine-to-affine, generative/lowering in linalg,
and also exploring lifting lower level constructs into affine
and further into linalg and tensor compute ops. I'm all for
exchanging on the rationale, use cases, and design of these
paths, alongside with LLVM LNO. One practical option being to
compose these lifting, affine transformations and lowering
steps to build an LLVM LNO. Ideally this could be one generic
effort that would also interop with numerical libraries or
specialized hardware ops where they exist, and that can be
used to implement domain-specific code generators.</div>
<div><br>
</div>
<div>More on Roslyn: I'm not convinced yet about the added value
of red-green trees. I see them as an implementation detail at
the moment: much like sea of nodes is a convenient abstraction
for implementing SSA-based global optimization passes,
red-green trees may improve on the practice of AST/loop-nest
transformations, but I don't see much fundamental or solid
engineering benefits... yet.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Hi, Albert,</p>
<p>I definitely think that we're focused too much on the particular
data-structure choice being proposed, rather than on the
motivation for that proposal. At a high level, it seems like the
questions here are:</p>
<p> 1. When considering the optimization of a given loop nest, how
many potential transformations should be considered?</p>
<p> 2. For those potential transformations, how many of them need to
be given a concrete representation in order to generate a cost?</p>
<p>As I see it, the underlying motivation here anticipates that:</p>
<p> 1. The number of potential transformations might be large - not
that it always must be large, but that the infrastructure should
support it being large, and...</p>
<p> 2. A large number of them need a concrete representation in
order to generate a cost (because we'll need to hand off certain
aspects to backend models, etc.), given one or more potential sets
of trip-count values.</p>
<p>To start, do you have thoughts on these?</p>
<p>Thanks,</p>
<p>Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAFx_MV=RXX-OxbSVc6iq-TFTkEktp-Jqi6Oska1ciE8DbyTO-Q@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Albert</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Feb 8, 2020 at 6:11 PM
Chris Lattner <<a href="mailto:clattner@nondot.org" moz-do-not-send="true">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;"><br>
<div><br>
<blockquote type="cite">
<div>On Feb 7, 2020, at 10:16 PM, Michael Kruse <<a href="mailto:llvmdev@meinersbur.de" target="_blank" moz-do-not-send="true">llvmdev@meinersbur.de</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div dir="ltr">Am Fr., 7. Feb. 2020 um 17:03 Uhr
schrieb Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank" moz-do-not-send="true">clattner@nondot.org</a>>:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">> The
discussion here is valuable for me, helping me
to make my<br>
> presentation about it at EuroLLVM as
relevant as possible. My current<br>
> idea is to take a complex loop nest, and
compare optimizing it using<br>
> red/green DAGs and traditional pass-based
optimizers.<br>
<br>
Cool. I’d really recommend you connect with
some of the loop optimization people working on
MLIR to learn more about what they are doing,
because it is directly related to this and I’d
love for there to be more communication.<br>
<br>
I’ve cc'd Nicolas Vasilache, Uday Bondhugula,
and Albert Cohen as examples that would be great
to connect with.<br>
</blockquote>
<div><br>
</div>
<div>You may have already seen my discussion with
Uday on the mailing list. I would like to
discuss approaches with all 3 of them, at
latest at EuroLLVM (or contact be before that,
e.g. on this mailing-list thread).</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>Great! I’d be happy to join a discussion about this at
EuroLLVM too. I think it is really important to improve
the loop optimizer in LLVM, and I’m glad you’re pushing on
it!</div>
<div><br>
</div>
<div>-Chris</div>
<br>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<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>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>