[llvm-dev] [cfe-dev] MLIR for clang

[Renato Golin via llvm-dev]

+1

This is a very big, long and complex task and if we don't take it as a
community project, the off tree project will bit rot before it can be
merged. It has happened so many times before and will certainly happen
again if we're not careful.

Converting openmp and known library calls into memref and affine for would
be super cool.

Cheers,
Renato

On Mon, 17 Feb 2020, 18:27 Hal Finkel via llvm-dev, <llvm-dev at lists.llvm.org>
wrote:

> Hi, Prashanth,
>
> I definitely recommend that we have a discussion first on design goals for
> this. You've mentioned modeling of multidimensional arrays, and I know
> you've also been thinking about OpenMP, and it would be good to lay out the
> desired end state.
>
> Part of the reason I say this is because there are significant design
> decisions that I suspect will appear up front. Handling of multidimensional
> arrays is a good example. C/C++ certainly do have multidimensional arrays
> of static extent, but these are largely irrelevant for a significant
> fraction of production C++ use cases. This is because, in many cases, the
> array bounds are not known statically, or at least they're not all known
> statically, and so programmers make use of C++ wrapper libraries which
> provide the interface of multidimensional arrays implemented on top of
> one-dimensional heap-allocated data. If we create an infrastructure that
> works well for static multidimensional arrays but does not contain any
> provision for recognizing appropriate loop nests and also treating them
> using the multidimensional-array optimization infrastructure, we won't
> really improve the compiler in practice for many, if not most, relevant
> production users.
>
> It's also going to be important what we optimize loops that only look like
> loops after coroutines are analyzed and inlined. Regardless, there
> certainly are areas in which we could do a better job optimizing
> constructs  (e.g., more devirtualization, optimization of exception
> handling and uses of RTTI), and it would be good to put everything out on
> the table so that decisions can be made based on use cases as opposed to
> being driven by the desire to use a particular tool.
>
> Thanks again,
>
> Hal
> On 2/16/20 3:21 AM, Prashanth N R via cfe-dev wrote:
>
> +cfe-dev
>
> On Sun, Feb 16, 2020 at 2:46 PM Prashanth N R <prashanth.nr at gmail.com>
> wrote:
>
>>   Starting from May-June, we at "Compiler Tree" would  start porting
>> clang compiler to use MLIR as middle end target. If someone has already
>> started a similar effort we would love to collaborate with them. If someone
>> would like to work with us, we are ready to form a group and collaborate.
>> If there are sharing opportunities from Fortran side, we would like to
>> consider the same.
>>
>>    We are in the early phase of design for "C" part of the work. From our
>> experience with (FC+MLIR) compiler, we are estimating that we would have an
>> early cut of the compiler working with non-trivial workload within a
>> quarter of starting of work.
>>
>>   Please ping me for any queries or concerns.
>>
>> Regards,
>> -Prashanth
>>
>
> _______________________________________________
> cfe-dev mailing listcfe-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200221/9117249d/attachment.html>