<div dir="ltr"><div dir="ltr"><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020 at 6:07 AM Alex Zinenko <<a href="mailto:zinenko@google.com" target="_blank">zinenko@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"><div>Hi Abhi,</div><div><br></div><div>thanks for your interest in MLIR projects. Nicolas (CCed) and I are both mentors for the Python and C bindings project. There is no long form description for most MLIR projects as we basically collected ideas for the things we would like to have, but had not yet had time to implement (or describe). While we did experiment with C and pybind11 bindings some time ago, this code was never clean enough for upstreaming. The main challenge that we saw was handling MLIR's extensibility at various levels: this is mostly transparent and easy in C++, but non-trivial in Python without "stringly" typing.</div><div><br></div><div>Since bindings are likely there to stay and their quality will have impact on multiple users, we would like to first explore various options: binding C++ APIs directly to Python, providing a C layer and binding that to Python instead, using different libraries. As a first step, it would be great to be able to write a motivated rationale for choosing one or another approach that we could fit into <a href="https://mlir.llvm.org/docs/Rationale/" target="_blank">https://mlir.llvm.org/docs/Rationale</a> format. Depending on the results, we could then proceed writing Python bindings or C bindings, or both. Initially, I would consider looking at generic abstractions that let one inspect the IR, such as mlir::Operation, mlir::Type and mlir::Attribute. When it's ready, we can look into making it more type-safe by defining specific subclasses of those classes and relying on LLVM's casting mechanism. At the same time, we would look into making this extensible, ideally in an automated way, to new operations, types and attributes, including out-of-tree ones. Finally, we could look into the IR construction and rewriting infrastructure that relies on C++ templates quite a bit.</div><div><br></div><div>I am open to discuss and help write a more tailored proposal around this topic. Please also be advised that another person was interested in the project - <a href="https://llvm.discourse.group/t/study-route-of-mlir-python-bindings/322/1" target="_blank">https://llvm.discourse.group/t/study-route-of-mlir-python-bindings/322/1</a> - but we did not move forward with a proposal so far.</div><div><br></div><div>As for the Tablegen formatter part, I might have been the author of that idea as well, although there were more people interested. MLIR relies on Tablegen much more than LLVM does and having a formatter would improve code health. This project is a bit exploratory, and I don't know if there were attempts to implement something similar for LLVM needs. Ideally, we would like to have an equivalent of clang-format, but I am not convinced that it makes sense to share the code between the two (at least, there is no point for a tablegen formatter to depend on clang). This would require looking into the tablegen parser and providing a pretty printer. This will also involve some amount of community discussion and writing to establish the code style for tabelgen that the formatter would follow. Other people who might be interested in this project are <a class="gmail_plusreply" id="m_-1140473560977633555gmail-m_8239952358757600069plusReplyChip-3" href="mailto:riverriddle@google.com" target="_blank">+River Riddle</a> and <a class="gmail_plusreply" id="m_-1140473560977633555gmail-m_8239952358757600069plusReplyChip-4" href="mailto:antiagainst@google.com" target="_blank">+Lei Zhang</a>.</div></div></blockquote><div><br></div>Thanks Alex for forwarding! For the TableGen formater project, I might not have the bandwidth to mentor this time given there is already another project I'd like to: <a href="https://llvm.discourse.group/t/spir-v-module-combiner/729/" target="_blank">https://llvm.discourse.group/t/spir-v-module-combiner/729/</a>. But others might be happy to there! :)<div></div><div> </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><br></div><div>Best,</div><div>Alex</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 3:02 AM Stefanos Baziotis <<a href="mailto:stefanos.baziotis@gmail.com" target="_blank">stefanos.baziotis@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">Hi Abhi,<br><br>I CC'd the mentors of one of the projects.<br><br>Best,<br>Stefanos</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Στις Κυρ, 15 Μαρ 2020 στις 11:52 μ.μ., ο/η ABHIMANYU RAWAT via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> έγραψε:<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">Hi there,<div><br></div><div>I am Abhimanyu Rawat, 1st-year graduate student and researcher from Paris, I hail from a pure computer science background on both Bachelors's and Masters's level. I find MLIR projects quite interesting. I have experience writing C code for EMC^2 as a protocols engineer for 2 years, I use python for convenience tasks. From a programming language perspective(thanks to Dan Grossman) I find compilers very daunting and fun. I am familiar with LLVM and have used it, looking at the projects I find MLIR having a good technical depth which may also support my research.</div><div><br></div><div>From MLIR open projects page I find two of the following projects interesting: </div><div><br></div><div>1. Rework the MLIR python bindings, add a C APIs for core concepts</div><div><br></div><div>2. Automatic formatter for TableGen (similar to clang-format for C/C++)</div><div><br></div><div>I wish to know more about the project description, current work, deliverables etc. just elaborative description same as with other LLVM open projects for GSoC. Additionally, please point me to any outstanding bugs or completed bugs or the literature you think one must go through in order to address the aforementioned projects. I have some rough idea about both the projects; maybe with your help, I could write a project description which is empty at the moment and add it to the page.</div><div><br></div><div><div><span style="font-size:12.8px">Overall</span><span style="color:rgb(0,0,0)"> </span><span style="color:rgb(0,0,0)">I am very excited to work on the project</span><span style="font-size:12.8px">, with the community and improving my skills by actively contributing to the project(in the long run also). </span></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">BR Abhi</span></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div>Alex</div></div></div></div></div>
</blockquote></div></div>