[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.
-Chris
-------------- 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