Re: dealing with strict aliasing rules
On Wed, 16 Jun 1999 21:03:58 PDT, Kyle Jones <kyle_jones(a)wonderworks.com> said:
My memory says that somebody (Valdis?) reported crashes with the
AIX compiler at high optimization because it started assuming
that pointers were not aliased. The optimization (I guess) is
that a value does not ever have to hit memory if the compiler can
determine that no pointer could ever reference it. The value can
live entirely in a register, which is a win.
Yes, it was me. However, that was originally against 20.mumble, in
the pre-gung-ho days.
The actual optimization (at least as performed by IBM with -qansialias)
is to check that if we have a pointer 'struct foobar *fooptr', and another
pointer 'struct baz *bazptr', if code does the following:
x = fooptr->field1;
bazptr->somefield = mumble;
y = fooptr->field2;
then -qansialias tells the compiler that it's free to assume that
no load/store via bazptr will conflict with a load/store through
fooptr. Not only does this mean it may be able to optimize out a
store, but it also has implications for code migration (for instance,
if field1 and field2 are 2 adjacent fields, it can scoot the
assignmnet to Y up above mumble, use a register already contianing fooptr,
etc. I haven't been able to coerce XLC to use a 'load multiple'
to load both x and y in the same opcode, but it's conceivable ;)
If I remember correctly, the aliasing problems cropped up in alloc.c.
I was in the process of rebuilding to test, but I just realized that
(a) it's 2:30Am, and (b) as a result, I compiled with '-O3 -qstrict'
where 'strict' tells the optimizer to not get into massive code
optimizations that may have an impact on program logic (which probably
inhibits most optimizations that ansialias would allow).
/Valdis