<div dir="ltr">Hi Alex,<div><br></div><div>Thanks for the elaborative response. Looks like the Python and C binding project is already shaping up by someone else. Meanwhile, Lie Zhang is also having less bandwidth. I looked into the Tablegen project and got first-hand knowledge of tablegen tool, its utils, components involved i.e. from target description files to the demo <a href="https://llvm.org/docs/TableGen/index.html">backends</a>, and especially how all the dots are connected as a whole to generate machine binary. I think this project has more to offer than what it appears, very exciting!</div><div><br></div><div>I know you already involved with <a href="https://llvm.discourse.group/t/study-route-of-mlir-python-bindings/322/1">binding</a> project but if there is little bandwidth available then I think I would be low maintenance student. If you or someone you know might be interested then I can draft the proposal real quick and we can continue polish nitty-gritty components on the fly since after submission deadline there is a gap of more than a month for you guys to finalize the projects. Moving on, I have some questions about the tablegen formatter project:</div><div><br></div><div>1. About therm tablegen formatter, do you mean that the intermediate output generated by the tablegen which is fed to a backend for Target Code Genereation should be formatted into some structure-cum-semantic and eventually improves the readability and easy to debug? if so then it's already a topic of <a href="https://llvm.org/docs/TableGen/index.html#tablegen-deficiencies">debate</a>.</div><div><br></div><div>2. You mentioned "like to have an equivalent of clang-format" this means that the diagnostic information sort of format? If so then we can always duplicate as long as the mutual format components are not huge between what clang and this project. And are there any specific use cases you have on mind or should I compile some design ideas around that?</div><div><br></div><div>3. I attended the TFRT hangout meeting on19th March 2020, in MLIR is there any difference than what LLVM offers in terms of tablegen functionally since MLIR is the middleware piece of TFRT in terms of main tasks like target code generation, diagnostics and attributes of a programming frontend? </div><div><br></div><div>BR Abhi</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020 at 3:37 PM Alex Zinenko <<a href="mailto:zinenko@google.com">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="gmail-m_1087473063265044289plusReplyChip-3" href="mailto:riverriddle@google.com" target="_blank">+River Riddle</a> and <a class="gmail_plusreply" id="gmail-m_1087473063265044289plusReplyChip-4" href="mailto:antiagainst@google.com" target="_blank">+Lei Zhang</a>.</div><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>