Path: utzoo!mnetor!uunet!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: noalias and vectors
Message-ID: <531@cresswell.quintus.UUCP>
Date: 14 Jan 88 03:07:55 GMT
References: <2942@hall.cray.com>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 58
Keywords: noalias, auto-vectorizing
Summary: not an argument for 'noalias'

In article <2942@hall.cray.com>, rig@hall.cray.com (Richard Gisselquist)
gives the following example:

> void sub1( a, b, c, i )
>     int *a, *b, *c;
>     int i;
>     {
>        int j;
>        for (j = 0; j < i; j++) *a++ = *b++ + *c++;
>     }
and points out that for the CRAY you would really like to vectorise this.
His statement that a "safe" vectorising compiler currently finds exactly
three safe places in "all the system software" is the kind of evidence I
was asking for that noalias would be useful.  Except that

(a) it would be rather surprising if system code DID contain a lot of
    vectorisable code.  Compilers, for example, often spend a lot of
    time walking around trees, which doesn't vectorise.  So before we can
    evaluate this evidence, we need to know how much better the compiler
    could do if noalias were used, and how many noalias declarations were
    needed.

(b) if anything, this is evidence that aliasing should be the exception,
    with noalias the default.  Why?  Because most programmers would find
    it hard to say what the example actually does.  Gisselquist says
>	sub1(a+1, a+1, a, N) will sum a vector into its last element.
    Yes, but what *else* does it do?  You have 59 seconds left...

(c) Each of the combinations a==b, b==c, c==a, and a==b==c makes sense
    and should be vectorisable.  In fact, what we need for this to work
    is
	assert((a+i >= b || b >= a));
	assert((a+i >= c || c >= a));
    That is, if b or c overlaps a, it is above a.  If I want to add a
    vector c to a vector a, I don't see why I shouldn't call
	sub1(a, a, c, n);
    But that violates 'noalias'.  assert() seems to me to be a far
    better mechanism, because it makes clear to the human reader WHY
    the transformation is safe.  Maintaining code that relies on
    'noalias' is going to be a nightmare.  (Remember maintenance?)

(d) If the assertions above are true, *this* loop can be vectorised,
    whatever *other* aliasing may be done to these arrays.

I've finally realised why I dislike 'noalias'.  Maintenance.
The original programmer may well understand his algorithm well enough
to know where a 'noalias' is safe and where it isn't.  But the
maintainer may not.  It is very easy to make barely noticeable changes
to a program which violate the *unstated* assumptions which justify
'noalias'.  So, professional C programmers who use 'noalias' declarations
will always include in the code clear and explicit statements saying why
the 'noalias' is used and when it is actually valid.  The best of them
will use 'assert' for as much of this as they can.  But in the presence
of 'assert', 'noalias' is redundant.  Indeed, 'assert' can handle
index aliasing, which 'noalias' can't.

Is there any reason why C compilers should not be allowed to assume the
truth of assertions even in the presence of NDEBUG?