RE: [pooma-dev] Brick engine and pointer aliasing

[James Crotinger]

I don't know where the code base ended up, but it used to be that we did a dependency analysis and if we detected the same block in use on the RHS that would be assigned to on the LHS, we allocated a new array, assigned results into it, and then copied the results back into the original target array. A lot of that sort of analysis got removed in the push to get 2.3 out before we left, though, so it may be gone, in which case certain statements that used to be well-defined would now be undefined.

With respect to restrict, we tried this at various times and found it not to help. With KCC, it wasn't properly propagated to the generated C code - they were not able to carry out the analysis carefully enough to label the ultimate temporary pointer that was used in the inner loop as a restricted pointer. Also, it's nonstandard, so if it is put in, make it so that it can be configured away.

        Jim

-----Original Message-----
From: Richard Guenther [mailto:address@hidden]
Sent: Wednesday, May 28, 2003 7:59 AM
To: address@hidden
Subject: [pooma-dev] Brick engine and pointer aliasing

Hi!

Currently the data members of the Brick and BrickView engines are
_not_ marked restrict, i.e. they're T *data_m. While strictly
speaking this is correct it harms performance on vector computers
quite a lot.

For dataparallel statements in POOMA the result is undefined, if
iterations depend on each other, which is equivalent to that the
compiler may assume restrictness of all data_m pointers, here?
[note the question mark]

For non-dataparallel statements, the situation is more complicated.
While under the restrict assumption a loop like

for (i=0; i<4; ++i)
  A(i) = A(i-1);

is the same as non-restricted(?), if we have two views to the same
Array, things get messed up, as in

  for (i=0; i<4; ++i)
    A(Interval1)(i) = A(Interval2)(i-1);

as now the iterations can be executed in parallel if BrickViews
have restricted data members.

The question now is, do we actually "support" such non-dataparallel
statements involving different views of the same Brick engine? Can
we specify such uses as undefined behavior? Can we mark Brick and
BrickView engine data_m members restrict?

Any thoughts on these issues?

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/