Aliasing, alignment

[bearophile]

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