🚀 go-pugleaf

In article <46kuem$j45@manuel.anu.edu.au>, keagchon@mehta.anu.edu.au (Geoff Keating 9205156) writes:
> Hmmm. Suppose you claim that X[20][20] and Y[20] are not aliases of
> each other. What's wrong with:
> 
> assert(&Y[20] <= &X[0][0] && X[20][20] >= Y[0]);
> 
> (apart from the obvious fact that it's not portable)?

The fact that it's not portable. :-)

Seriously, this check is far too simplistic for most vectorizing and
parallelizing compilers.  Most vectorizing compilers can easily deal with
arrays that overlap, as long as the compiler *knows* what the overlap
characteristics are.  For example, if X[0] maps to Y[4], X[1] to Y[5], and
so on, then the compiler may be able to perform parallel operations in
4-element groups with no problem.

> In fact, couldn't a compiler take some loop:
> 
> for (...)
>   for (...)
>     X[...] = Y[..] * X[...];
> 
> and turn it into:
> 
> if (X and Y are aliased)
>   for (...)
>     for (...)
>       X[...] = Y[..] * X[...];
> else
>   some_neat_vectorop(X,Y);

The whole problem is how to implement that if statement.

This discussion seems to me somewhat moot anyway.  The main reason that
Fortran 90 added lots of array manipulation syntax and intrinsic functions
is to substantially reduce the necessity for compilers to figure out what
array operation is being done by a loop.  Unless and until C or C++ add
such higher-level array operations, Fortran 90 is probably always going to
give better performance than C/C++ in the realm of array manipulation,
regardless of the aliasing issues.

-- 
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
I feel like I've been sent for and couldn't go, and weren't needed after I
got there.
------------------------------------------------------------------------------

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]