www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Aliasing, alignment

reply bearophile <bearophileHUGS lycos.com> writes:
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.

------------------

D now allocated "large" memory blocks aligned to 16 bytes, so something like
this (that can be seen in some C++ code) isn't necessary:

__attribute__ ((aligned(16)));

But this page also says that the AMD Barcelona Quad-Core:

http://en.wikipedia.org/wiki/SSE4#cite_note-2


Support was added for SSE4a for unaligned SSE load-operation instructions
(which formerly required 16-byte alignment).<


So maybe aligning a lot will not be so necessary in future.

On the other hand the next pack of instructions, named AVE, will use 256 first,
and then 512 and 1024-bit vector FPs:

http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

A PDF reference is already available:
http://softwarecommunity.intel.com/isn/downloads/intelavx/Intel-AVX-Programming-Reference-31943302.pdf

I haven't read the reference, so I don't know if they will require 32-64-128
byte alignment :-)

Such instructions don't look much complex, but they make the already really
messy X86 asm even more chaotic :-) Someday they will have to throw away lot of
old stuff, and just simulate it :-)
It's not a problem for the transistor count, because the amount of transistors
added by each of such extension packages is huge compared for example to a
80286 that is the core of the intel CPUs :-) The problem is for compilers and
the vanishing asm programmers :-)

Bye,
bearophile
Dec 18 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Dec 19, 2008 at 11:28 AM, bearophile <bearophileHUGS 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
Dec 18 2008