Aliasing, alignment

[Bill Baxter]

On Fri, Dec 19, 2008 at 11:28 AM, bearophile <bearophileHUGS at lycos.com> wrote:
> What's the stance of the D language regarding the "aliasing" problem?
> The last C99 has added a keyword (restrict) to manage this problem (and in GCC you can find some nonstandard extensions for C++ too).
>
> See also:
> http://www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict_keyw.html
>
> I think this keyword potentially allows C compilers to produce executables as efficient as Fortran ones.

I think 'invariant' is supposed to cover these cases.
If an array passed in is labeled "invariant" then the compiler is safe
to assume there are no aliasing problems with it.  It can't be aliased
to the output array because that would mean part of the data is, in
fact, not invariant.

To take advantage of that you're probably going to have to cast to
'invariant' a lot on the calling side.  But I think C99 doesn't
actually perform any checks as to whether your data is aliased or not.
 So you can have code that incorrectly assumes things are ok, when
they are not e.g.:
            add_vectors(C, A, B) // C = A + B
Looks fine, but it's not clear that C can't overlap A and B from
looking at that (assuming add_vectors is uisng 'restrict').
In D2 with invariant could be:
            add_vectors(C, cast(invariant)A, cast(invariant)B);  [*]
So at least the reader of the code can tell that add_vectors is making
some assumptions.
And the compiler will tell you you're making a mistake if you try to
just plain add_vectors(C,A,B).


[*] ... except I don't think cast(invariant) works right now.  Would
be nice to have I think.  and cast(const), too.

--bb