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/20200319/bd764a8a/attachment.html>