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

John McCall via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 17 11:26:43 PST 2020


On 17 Feb 2020, at 13:27, Hal Finkel 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.

Is the goal for this to be an out-of-tree proof of concept, or is the 
goal to eventually integrate this into LLVM and have Clang compile by 
emitting MLIR as an intermediate stage?  The latter would be a huge 
project with a lot of uncertain trade-offs, but I think it would be very 
interesting; whereas I’m afraid the former is not something I can 
spare any time to think about.

John.

>
> 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 
>> <mailto: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 list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory




More information about the llvm-dev mailing list