Brick engine and pointer aliasing

[Richard Guenther]

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/