<div dir="ltr">Albert, please loop me in too in your discussions (haha..), I'll be out the whole of next week though.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 10, 2020 at 10:50 AM Albert Cohen <<a href="mailto:albertcohen@google.com">albertcohen@google.com</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 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><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" target="_blank">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><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">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">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>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">N</div></div>