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

[Richard Guenther]

On Wed, 4 Jun 2003, James Crotinger wrote:

> 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.

Yes, I remember reading something in some manual about this fact ;)

> 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.

"restrict" is properly #defined based on a configure check. Or do you mean
specifically disable restrict for Brick and BrickView? Anyway, putting
restrict in helps the NEC C++ compiler vectorizing some loops (not all -
its bad at inlining as so many other compilers - and its #pragma inline
complete refuses to work for some unknown reason), so you get 2GFlops
instead of 50MFlops there ;)

Richard.

>       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/
>