<div dir="ltr">Hi all,<br><br>Since it seems like all of the feedback here is positive, what would be the next steps (migrate Enzyme mailing list to LLVM, create discord/discourse, etc)?<br><br>@Renato<br><br>The split support sounds like a good solution to me.<br><br>Regarding Enzyme/MLIR, the idea there isn't necessarily to use Enzyme to differentiate MLIR directly, but lowering MLIR to LLVM then running Enzyme could be an interesting (though not necessarily ideal) way to provide differentiable programming in MLIR. We're also considering extending Enzyme to work directly on MLIR as well and while indeed many parts of the analysis are specific to LLVM instructions, other differentiation specific analyses likely will have components which can be shared (e.g. Activity Analysis which determines whether there exists a path through the program that enables differentiable information to flow from input to output).<br><br>Cheers,<br>Billy</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 15, 2021 at 12:54 PM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.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"><div>Hi William,</div><div><br></div><div>I think this is a really cool project and worthy of being in LLVM. For now it's a plugin pass, which goes well with incubator projects, but it could very well be a standard IR pass that is enabled by flags, etc. We have similar examples for OpenCL, OpenMP, etc. which need integration on both Clang and LLVM. Shouldn't be too messy.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Jan 2021 at 22:14, William Moses via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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"><div dir="ltr">Obviously integration into the monorepo itself would fix this for subsequent versions so it's somewhat of a chicken-and-the egg issue. I'd love to hear any thoughts from folks on how something like this might be eventually handled. I'd also like to see upstream users (for example to differentiate MLIR -- ideally with nice integration for reductions, see comment below regarding parallelism).<br></div></blockquote><div><br></div><div>I think long term you should split support for older versions with the trunk version. Once (and if) it gets merged into the monorepo, we can keep the incubation repo with the previous versions only, and only to official versions, mostly static and for historical value. People should be encouraged to use the newer versions that have native support.</div><div><br></div><div>Differentiating MLIR would probably be a separate infrastructure, not sure using the same libraries? I haven't dug too much, but I expect some of the analysis to be tailored to LLVM's operations and types, which have fixed semantics and are very different from MLIR, with custom dialects, operations and types. But it would be really nice if we had that at the MLIR level, at least for the standard upstream dialects, as it would be a major boost for ML compilers to start using MLIR more aggressively.</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "Enzyme AD" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:enzyme-dev+unsubscribe@googlegroups.com" target="_blank">enzyme-dev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/enzyme-dev/CAPH-gfeYP1ix4qa4jbGCSMoqY19cce_CV-q-NkjwiuEw2aMpCA%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/enzyme-dev/CAPH-gfeYP1ix4qa4jbGCSMoqY19cce_CV-q-NkjwiuEw2aMpCA%40mail.gmail.com</a>.<br>
</blockquote></div>