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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200216/f5e508e6/attachment.html>
+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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200216/c86a118e/attachment.html>
Hi Prashanth, On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev <llvm-dev at lists.llvm.org> 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.\That's a rather vague statement, considering the flexibility of MLIR. Could you explain your plans in more detail, and what specifically you hope to achieve with them? Cheers, Nicolai>> >> 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 > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.
Can you elaborate what your approach is? Do you intent to fork clang for MLIR at a specific version, keep up-to-date with master and/or try to upstream this? Do you think MLIR has all the semantics required, such as for representing exceptions? Michael Am So., 16. Feb. 2020 um 03:16 Uhr schrieb Prashanth N R via flang-dev <flang-dev at lists.llvm.org>:> > 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 > _______________________________________________ > flang-dev mailing list > flang-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
Hi Michael- 1. We intent to fork clang for MLIR at a particular release and develop. We will mostly merge with the master as soon as we reach a good milestones. Most of the development is expected to happen in github or some such version control system. 2. MLIR is extensible and we are hoping that constructs like exceptions can be represented in MLIR. As we dive deep into design we might be able to answer the question in detail. thanks, -Prashanth On Mon, Feb 17, 2020 at 2:11 AM Michael Kruse <llvm at meinersbur.de> wrote:> Can you elaborate what your approach is? Do you intent to fork clang > for MLIR at a specific version, keep up-to-date with master and/or try > to upstream this? > > Do you think MLIR has all the semantics required, such as for > representing exceptions? > > Michael > > Am So., 16. Feb. 2020 um 03:16 Uhr schrieb Prashanth N R via flang-dev > <flang-dev at lists.llvm.org>: > > > > 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 > > _______________________________________________ > > flang-dev mailing list > > flang-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200217/805a6dad/attachment.html>
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 > <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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200217/a86c87b7/attachment-0001.html>
> On Feb 16, 2020, at 1:16 AM, Prashanth N R via llvm-dev <llvm-dev at lists.llvm.org> 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.Hi Prashanth, I’d love to see this. In terms of staging this in over time, have you considered starting by tackling the Clang “CFG” representation first? It is used for source level analysis (-Wunreachable, clang static analyzer) and would be much better as a “CIL” implemented in MLIR. From there, you could port Clang’s CodeGen/IRGen to be based on that IR instead of the AST. From there, you could factor other parts of IRGen out into their own independent MLIR lowering phases (e.g. ABI lowering etc). The advantage of starting with the CFG representation is that the bar to getting it accepted into the tree is lower (Clang CFG isn’t complete) and swapping out one IR with another should not create a compile time regression - adding another phase could. -Chris