[llvm-commits] dependence analysis (of multi dimensional arrays)

[Preston Briggs]

I think we should do two things:

   1. We should write code to automatically delinearize where ever
   possible, and
   2. We should change the IR (extend the GEP instruction) so that Clang
   doesn't have to linearize all multi-dimensional array references.

I think we need (1) because much existing code is already linearized. I
think we need (2) because delinearization isn't able to handle all
subscripts and we'll lose information. In particular, delinearization can't
handle couple subscripts (I believe), things like:

*  for (i = 0; i < m; i++) {*
*    for (j = 0; j < n; j++) {*
*      A[i][j] = ...*
*      ... = A[j][i];*
*    }*
*  }*

Of course, we can begin with delinearization, extending the GEP later. My
thought would be to build delinearization into the dependence analyzer,
using it to attack MIV subscripts only.

I'll reread Maslov (Wolfe's book also discusses the topic in Section 7.2.4)
and see if I can get back up to speed.

To extend the GEP, it seems like we need to provide 2 fields for every
dimension: size and subscript, where size is loop invariant.

Preston




On Mon, Sep 24, 2012 at 2:15 PM, Sebastian Pop <spop at codeaurora.org> wrote:
> Hi Preston,
>
> +// In addition, the implementation depends on the GEP instruction to
> +// differentiate subscripts. Unfortunately, since Clang linearizes
subscripts
> +// for most arrays, this will be inadequate. We trust that the GEP
instruction
> +// will eventually be extended.
> +//
> +// In the meantime, we should explore Maslov's ideas about
delinearization.
>
> I haven't had the chance to discuss with you about the linearized
> multi-dimensional
> array problem, and Tobias Grosser was also interested to know your point
of view
> on reconstructing the higher level representation based on the linear
form.
>
> Could you please provide more details on what should be done to address
this
> problem in LLVM or Clang?
>
> Thanks,
> Sebastian
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120924/4a7b1eec/attachment.html>