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?