[LLVMdev] Multi-dimensional array accesses in LLVM-IR | Thoughts

[Renato Golin]

On 12 September 2012 09:38, Tobias Grosser <tobias at grosser.es> wrote:
> I personally would first have a look at approach '2'.

While I normally argue to leave the IR as it is (since it's a compiler
IR, not a magical one), I can see some trends going on that should not
be ignored.

This is one example, where the front-end bends its knees to generate
IR that LLVM understands, so that you can revert it to what should
have been in the first place (to analyse parallelism) and convert it
back again to "correct" IR. As you mentioned, there will be cases that
the analysis won't work, ex. when receiving an array from a function,
it could look like an opaque pointer in some architectures.

Last month, in the Cambridge LLVM Social, David Chisnall asked me
about a builder that would validate procedure call standards depending
on the target, so that the front-end could use that to build the
horrible messes we end up doing in that scenario. Another idea is to
create a pass that will convert from high-level function declaration
to low-level target-dependent declaration during the validation phase,
so the front-end produces "good-looking" calls (with types as-is) and
the pass makes them target-valid.

This technique could also apply to your case. If the front-end
supports multi-dimensional access and produces code conforming to
that, your pass can analyse and vectorize. If not, no worries, you
just ignore them. Which means not all front-ends must change at the
same time to accommodate your analysis.

Later on, a validation pass would transform all multi- to
single-dimensional array access and produce IR that the back-ends can
consume.

It might not be the easiest route, but would avoid some dead-ends down
the road...


-- 
cheers,
--renato

http://systemcall.org/