[flang-commits] [flang] [FIRToMemRef] Doc collectSliceInfoFrom, getMemrefIndices, canonicalizeIndex (PR #207699)

[Kareem Ergawy via flang-commits]

================
@@ -349,6 +349,69 @@ bool FIRToMemRef::materializeShapeExtents(
   return false;
 }
 
+/// Accumulate the shape/shift/slice operands carried by `op` into `info`.
+///
+/// Accepts `fir::ArrayCoorOp`, `fir::EmboxOp`, and `fir::ReboxOp`; on any
+/// other op type this is a no-op (`if constexpr` guard in the body). Fields
+/// of `info` are **appended** to, never cleared -- callers routinely invoke
+/// this twice (once for the array_coor, once for the underlying embox/rebox)
+/// so ordering matters.
+///
+/// What each shape operand contributes:
+///   - `fir.shape %e0, %e1, ...`         -> appends extents to `shapeVec`.
+///   - `fir.shape_shift %lb0, %e0, ...`  -> appends extents to `shapeVec`
+///                                          and lower bounds to `shiftVec`.
+///   - `fir.shift %lb0, %lb1, ...`       -> appends lower bounds only,
+///                                          into `shiftVec`.
+///   - no shape operand (nullptr)        -> `shapeVec`/`shiftVec` unchanged.
+///
+/// What the slice operand contributes:
+///   - `fir.slice %lb0, %ub0, %step0, ...` -> appends *all* triple SSA values
+///                                             to `sliceVec` (per-dim, in
+///                                             Fortran order).
+///   - projected slice (extra `%fields`)  -> also sets `hasProjectedSlice`
+///                                             and, when the first field is
+///                                             a compile-time constant,
+///                                             `projectedSliceStart`.
+///   - no slice operand (nullptr)          -> `sliceVec` unchanged.
+///
+/// Examples (IR shown Fortran-first; sliceVec entries listed in append
+/// order):
+///
+/// 1) `fir.array_coor %arr(%shape) [%slice] %i, %j` where
+///        %shape = fir.shape %c4, %c2                  ; parent 4x2
+///        %slice = fir.slice %c1, %c2, %c1, %c1, %c2, %c1
+///
+///    Before: info = { shapeVec=[], shiftVec=[], sliceVec=[] }
+///    After : info = { shapeVec=[%c4, %c2],
+///                     shiftVec=[],
+///                     sliceVec=[%c1, %c2, %c1,   // dim 0 triple
+///                               %c1, %c2, %c1] } // dim 1 triple
+///
+/// 2) `fir.embox %arr(%shape_shift) [%slice]` where
+///        %shape_shift = fir.shape_shift %clb0, %e0, %clb1, %e1
+///        %slice       = fir.slice %c2, %c2, %c1, %c1, %c1, %c1
+///
+///    After: info = { shapeVec=[%e0, %e1],
+///                    shiftVec=[%clb0, %clb1],
+///                    sliceVec=[%c2, %c2, %c1,   // dim 0 triple
+///                              %c1, %c1, %c1] } // dim 1 triple
+///
+/// 3) Two-slice stack -- first the array_coor, then the underlying embox:
+///    call sequence:
+///        collectSliceInfoFrom(arrayCoorOp, info);
+///        collectSliceInfoFrom(emboxOp,     info);
+///
+///    Result: `sliceVec` holds the array_coor's triples first, followed by
+///    the embox's triples. Downstream helpers (e.g. `getMemrefIndices`) only
+///    consume the leading `rank` triples, so the two contributions are
----------------
ergawy wrote:

Yes, indeed `getMemrefIndices` only computes indices from the "front" slice. 

> but that is what you are fixing here: https://github.com/llvm/llvm-project/pull/207749, right?

Yup

https://github.com/llvm/llvm-project/pull/207699