[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