[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:rguenth at tat.physik.uni-tuebingen.de] 
Sent: Wednesday, May 28, 2003 7:59 AM
To: pooma-dev at pooma.codesourcery.com
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20030604/cd7ab838/attachment.html>