<div dir="auto">+1<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Converting openmp and known library calls into memref and affine for would be super cool. </div><div dir="auto"><br></div><div dir="auto">Cheers, </div><div dir="auto">Renato </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Feb 2020, 18:27 Hal Finkel via llvm-dev, <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>Hi, Prashanth,</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Thanks again,</p>
<p>Hal<br>
</p>
<div>On 2/16/20 3:21 AM, Prashanth N R via
cfe-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">+cfe-dev<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Feb 16, 2020 at 2:46
PM Prashanth N R <<a href="mailto:prashanth.nr@gmail.com" target="_blank" rel="noreferrer">prashanth.nr@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"> 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.
<div><br>
</div>
<div> 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.</div>
<div><br>
</div>
<div> Please ping me for any queries or concerns. </div>
<div><br>
</div>
<div>Regards,</div>
<div>-Prashanth</div>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
cfe-dev mailing list
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" rel="noreferrer">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<pre cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>