Zdenek Dvorak wrote: > Hello, > >>>>>> with base being either some memory object or an INDIRECT_REF of a >>>>>> pointer and be done with that tree code. >>>>> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done >>>>> any better in removing recursion :) >>>> What type the first operand would be could be a one-bit flag in the >>>> MEM_REF itself. I.e. if there's an implicit INDIRECT_REF around the >>>> first operand, or not. The important part is only that the target >>>> address of that memory reference is computable completely trivially, >>>> namely by A + i, where A is either a or &a depending on that flag. >>>> And the more important thing anyway is that alias information of this >>>> specific mem reference encoded therein. >>> Not for data dependence it's not. :) >> You mean tests based on the actual index vector, instead of the final >> offset vector? I still sometimes think that one should be able to >> recover the index vector reasonably well, when given only offsets (and >> perhaps adjusted bases). It's a tradeoff of having only one way to >> express memory accesses (which I find quite sexy) and having to do a >> bit more work when trying to get at the offsets. > > by this kind of lowering, you lose quite a lot of information. For > example, a[i][j] lowers to something like > offset = step1 * i + step2 * j; MEM(a, offset). > > 1) Recovering the index vector is not easy, as the optimizations may > change this code a lot. Even if you find an expression that looks > like MEM(a, step1 * i + step2 * j), you have no good way to know that > this was not originally a[i + 1][j - step1/step2].
In fact, IIRC, XLC and ICC spend a large amount of time trying to recover these vectors from already existing code, and concentrate on not losing the ones they have. By transforming multiple dimension array accesses into just random arithmetic, you've make subscript approaches to data dependence very hard for any real cases. If you really think you can do a good job of recovering the index vector, i highly suggest you try it before we choose this method. All of our pointer accesses currently look like the form above, even if they were originall p[i][j], where p is int **. If you are correct, you should easily be able to write something to calculate i and j. The existing data dependence infrastructure would love to have this information. Single dimension accesses are of course, just fine with this representation.
