[LLVMdev] Multi-dimensional array accesses in LLVM-IR | Thoughts
hfinkel at anl.gov
Wed Sep 12 15:27:33 PDT 2012
On Wed, 12 Sep 2012 15:56:25 +0100
Renato Golin <rengolin at systemcall.org> wrote:
> 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.
I agree that this seems suboptimal: information known to the frontend
is lost, and then must be guessed by the backend. This might also be a
case where metadata is helpful.
I also think that it is important to keep in mind that this particular
case is one in which guessing is important. This is because there is a
lot of existing C/C++ code which does manual indexing of
multidimensional arrays, and we should try to support iteration-space
transformations involving those arrays as well.
> 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
Do you mean that there is some kind of canonical form that all of the
frontends will use, and that LLVM provides some kind of utility for
generating this canonical form?
> 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
> It might not be the easiest route, but would avoid some dead-ends down
> the road...
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev