<div dir="ltr"><div dir="ltr">On Tue, 26 Jan 2021 at 22:51, William Moses <<a href="mailto:wmoses@mit.edu">wmoses@mit.edu</a>> wrote:<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"><div dir="ltr">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></div></blockquote><div><br></div><div>I wouldn't worry about merging the lists too soon (very high traffic). MLIR has a separate channel and that seems to be working for them, you could follow their path at least for now.</div><div><br></div><div>I couldn't find the code's license, but since you're working with MIT, I imagine it's compatible (and convertible) to the LLVM license. Everything else checks for me, including the migration plan towards the monorepo.</div><div><br></div><div>Mehdi, does that answer your questions?</div><div><br></div><div>Should we look for more people to have a look and comment? Alex, perhaps mentioning on the weekly again next week to see if we get more people to look at it?</div><div><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">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></div></blockquote><div><br></div><div>MLIR doesn't always goes to LLVM IR, that's why I suggested it. </div></div></div>