[llvm-dev] [RFC] A new multidimensional array indexing intrinsic

[Michael Kruse via llvm-dev]

Am Fr., 2. Aug. 2019 um 13:47 Uhr schrieb Chris Lattner <clattner at nondot.org>:
> > However, I think loop transformations are something we can do
> > reasonably (as Polly shows), if necessary guarded by runtime-condition
> > to e.g. rule out aliasing, out-of-bounds accesses and integer
> > overflow. The required lowering of multi-dimensional accesses on
> > dynamically-sized arrays to one-dimensional ones for GEP loses crucial
> > information. At the moment we have ScalarEvolution::delinearize which
> > tries to recover this information, but unfortunately is not very
> > robust. Carrying this information from the front-end into the IR is a
> > much more reliable way, especially if the source language already has
> > the semantics.
>
> Are you interested in the C family, or another language (e.g. fortran) that has multidimensional arrays as a first class concept?  I can see how this is useful for the later case, but in the former case you’d just be changing where you do the pattern matching, right?

Both. Transformations on LLVM-IR have the advantage to be applicable
on all languages that have an LLVM-IR codegen. The motivating case
here is Chapel. For Fortran we could do the transformations on MLIR,
but I do not see that it is a lot easier on LLVM (modulo allocatable
arrays) if the front-end does not emit affine.for. For C/C++ we could
add a language extension (builtin, attribute, ...) that allows
conveying this information to the mid-end. Even if not, we do want to
optimize applications that are written in C/C++.


> > The other feedback in this thread was mostly against using an
> > intrinsic. Would you prefer starting with an intrinsic or would the
> > other suggested approaches be fine as well?
>
> Which other approach are you referring to?  I’d pretty strong prefer *not* to add an instruction for this.  It is generally better to start things out as experimental intrinsics, get experience with them, then if they make sense to promote them to instructions.

This was already my argument in this thread.

Suggestions I found in this thread:
 * Use llvm.assume to compare a GEP result ptr with the multidimensional one
 * Extending GEP with more arguments
 * Extend GEP in another unspecified way
 * Add metadata (such as operand bundles) to GEP that can be dropped
(like MDNode)
 * Add metadata to memory accesses
 * Add a dynamically sized array type

Michael