Re: ANSI-strict pointer aliasing rules

On Thu, Apr 27, 2006 at 07:34:19PM +0930, Andrew Dunstan wrote:
> Next time we have this discussion I wish someone would actually document
> the performance differences. IIRC most of what I have seen makes it at
> best marginal.

I can imagine there are cases where the performance difference is
nontrivial. Take this (somewhat contrived) example:

int *i;
char *c;
while( *i < BIG_NUMBER )
*i += *c;

With strict aliasing, the compiler need only load *c once, without it
needs to load it each time through the loop because it has to consider
the possibility that 'i' and 'c' point to the same memory location.

PostgreSQL doesn't actually have loops of this kind so it's not
something we need worry about. And you can acheive all the benefits by
explicitly loading *c into a local variable before the loop. I can
beleive that certain RISC architectures would benefit more than
something like the Intel CISC architecture.

> Personally, I think this whole mess results from a bad case of
> committee-itis.

I think the goal was noble (at least, according to the best version
I've heard so far): make it easier to compete with Fortran in numerical
processing. If you define a struct vector { double x,y,z,d; } and the
compiler can assume that values in that structure can only be changed
via a (vector*) pointer, it can do things like load an array of them
into a large parallel processing unit.

Ofcourse, this is useless for most of the programs written in C, and in
C99 they fixed it the right way using the "restrict" keyword, which is
actually far more usful for the above purpose than strict-aliasing.

Compiler writers love it because it makes it easier for them, but
actual benefits, hmm...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.