[llvm-dev] Loop Opt WG - using MLIR

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 14 15:31:08 PDT 2019

> On Aug 13, 2019, at 10:58 AM, Gary Elsesser via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> MLIR  is sufficiently expressive to capture general multidimensional 
> array references without lose of information.  Fortran pointers
> may require speicial handling, as non-contiguous memory may be
> described - forward or backward in each dimension.
>     p => A(I1:I2:-3, J1:j2, K1:k2:K3)
> Fortran also permits empty arrays: call S(A(1:0)).
> The BIG design chooses include:
>   1. Augment LLVM IR to provide a more general GEP; continue loop restructuring
>       work in LLVM; MLIR may be used for additional high-level optimization.
> OR
>    2. Create a middle-LLVM that works on MLIR; do all loop restructuring here;
>        phase out existing LLVM loop restructuring .
> OR
>    3. adopt MLIR in LLVM ... (a bridge too far).

My 2c:

I think that path 3 is a bridge too far, and not worth considering in the immediate term.

#1 can definitely provide some value, but it isn’t clear that it provides a lot of utility and will take us to where we really need to go.

#2 is a promising direction if the “loop optimizer” is an optional component that (e.g.) clang would turn on and off monolithically with a flag.  This path is structurally similar to the “enable poly” sort of design, with more flexibility on how the loop optimizer is implemented, and different compile time characteristics.

I think that path #2 is very interesting to scope out, and path #1 is interesting if there are very specific objectives that need to be reached for some purpose.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190814/2697e899/attachment.html>

More information about the llvm-dev mailing list