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

[Chris Lattner via llvm-dev]

On Aug 2, 2019, at 8:57 AM, Michael Kruse <llvmdev at meinersbur.de> wrote:
>> This is why I ask whether its makes sense to add this to LLVM IR:  If you want HPC style loop transformations, I don’t think that LLVM IR itself will ever be great, even with this.  This might make some narrow set of cases slightly better, but this is far from a solution, and isn’t contiguous with getting to a real solution.
> 
> I agree that memory layout transformations are heroic to do in
> LLVM-IR. This already follows from the C/C++ linking model where the
> compiler cannot see/modify all potential accesses to a data structure.

Right.

> 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?


>> That said, this is just my opinion - I have no data to back this up.  Adding ‘experiemental’ intrinsics is cheap and easy, so if you think this direction has promise, I’d recommend starting with that, building out the optimizers that you expect to work and measure them in practice.
> 
> 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.

Was there another alternative?

-Chris