[llvm-dev] MLIR project, GSoC 2020.

Sun Mar 29 14:18:52 PDT 2020

Hi Alex,

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 backends
<https://llvm.org/docs/TableGen/index.html>, 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!

I know you already involved with binding
<https://llvm.discourse.group/t/study-route-of-mlir-python-bindings/322/1>
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:

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 debate
<https://llvm.org/docs/TableGen/index.html#tablegen-deficiencies>.

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?

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?

BR Abhi

On Thu, Mar 19, 2020 at 3:37 PM Alex Zinenko <zinenko at google.com> wrote:

> Hi Abhi,
>
> 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.
>
> 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 https://mlir.llvm.org/docs/Rationale 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.
>
> 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 -
> https://llvm.discourse.group/t/study-route-of-mlir-python-bindings/322/1 -
> but we did not move forward with a proposal so far.
>
> 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 +River Riddle
> <riverriddle at google.com> and +Lei Zhang <antiagainst at google.com>.
>
> Best,
> Alex
>
> On Mon, Mar 16, 2020 at 3:02 AM Stefanos Baziotis <
> stefanos.baziotis at gmail.com> wrote:
>
>> Hi Abhi,
>>
>> I CC'd the mentors of one of the projects.
>>
>> Best,
>> Stefanos
>>
>> Στις Κυρ, 15 Μαρ 2020 στις 11:52 μ.μ., ο/η ABHIMANYU RAWAT via llvm-dev <
>> llvm-dev at lists.llvm.org> έγραψε:
>>
>>> Hi there,
>>>
>>> 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.
>>>
>>> From MLIR open projects page I find two of the following projects
>>> interesting:
>>>
>>> 1. Rework the MLIR python bindings, add a C APIs for core concepts
>>>
>>> 2. Automatic formatter for TableGen (similar to clang-format for C/C++)
>>>
>>> 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.
>>>
>>> Overall I am very excited to work on the project, with the
>>> community and improving my skills by actively contributing to the
>>> project(in the long run also).
>>>
>>> BR Abhi
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>
> --
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200330/4c265f32/attachment-0001.html>