<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 13, 2019, at 10:58 AM, Gary Elsesser via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">MLIR is sufficiently expressive to capture general multidimensional<span class="Apple-converted-space"> </span><br class="">array references without lose of information. Fortran pointers<br class="">may require speicial handling, as non-contiguous memory may be<br class="">described - forward or backward in each dimension.<br class=""> p => A(I1:I2:-3, J1:j2, K1:k2:K3)<br class="">Fortran also permits empty arrays: call S(A(1:0)).<br class=""><br class="">The BIG design chooses include:<br class=""> 1. Augment LLVM IR to provide a more general GEP; continue loop restructuring<br class=""> work in LLVM; MLIR may be used for additional high-level optimization.<br class="">OR<br class=""> 2. Create a middle-LLVM that works on MLIR; do all loop restructuring here;<br class=""> phase out existing LLVM loop restructuring .<br class="">OR<br class=""> 3. adopt MLIR in LLVM ... (a bridge too far).<br class=""></div></div></blockquote></div><div class=""><br class=""></div>My 2c:<div class=""><br class=""><div class="">I think that path 3 is a bridge too far, and not worth considering in the immediate term.</div><div class=""><br class=""></div><div class="">#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.</div><div class=""><br class=""></div><div class="">#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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></body></html>