[pooma-dev] Brick engine and pointer aliasing

[Jeffrey D. Oldham]

Richard Guenther wrote:
> 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?

I assume that the rule is that, for a data-parallel assignment, the code 
is only correct if the iterations can occur in any order without any 
change in the result.  Thus, I assume that restrict is acceptable.

Jeffrey D. Oldham
oldham at codesourcery.com