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

Prashanth N R via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 18 07:55:40 PST 2020


Hal-

Thanks for the critical  issues to ponder over. We will get back to you
once we  have more clarity of the task.

thanks,
-Prashanth

On Mon, Feb 17, 2020 at 11:57 PM Hal Finkel <hfinkel at anl.gov> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200218/229656c8/attachment.html>


More information about the llvm-dev mailing list