Re: strict aliasing

[skaller <skaller at users dot sourceforge dot net>]

On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
> Ian Lance Taylor wrote:
> > Strict aliasing only refers to loads and stores using pointers.  
> 
> skaller writes:
> > Ah, I see. So turning it off isn't really all that bad
> > for optimisation.
> 
> One example of where it hurts on just about any platform is something
> like this:
> 
> 	void allocate(int **p, unsigned len);
> 
> 	int *foo(unsigned len) {
> 		int *p;
> 		unsigned i;
> 		allocate(&p, len);
> 		for (i = 0; i < len; i++) 
> 			p[i] = 1;
> 		return p;
> 	}
> 
> Without strict aliasing being enabled, the compiler can't assume that
> that the assignment "p[i] = 1" won't change "p".  This results the value
> of p being loaded on every loop iteration, instead of just once at the
> start of the loop.  It also prevents GCC from vectorizing the loop.


Now I'm a bit confused.. Ian wrote previously:

".... Strict
aliasing refers to one component of that analysis, really a final
tie-breaker: using type information to distinguish loads and stores."

and 

"Strict aliasing only refers to loads and stores using pointers."

but the assignment here is of an int. My understanding was that
this is "non-strict" aliasing rule, so the optimisation could
still be applied: storing an int cannot change a pointer.

Had the data type been a T* for some T, then it might have
been an alias to an int*, and I would see it.

This distinction appears to matter quite a bit, particularly
in light of Joe's comment:

"for scientific codes that process both
integer and real data, strict aliasing could make a large difference
on any processor."

It's kind of messy because array names are almost but not
quite pointers. Curious how C++ references are handled?
If we change the above code to use

	int &p

then presumably p is modelled by a pointer anyhow, however
it can't be modified by aliasing because the 'pointer p' 
is a constant.

> On Itaninum CPUs speculative loads can be used instead of strict alias
> analysis to avoid this problem.

Can't you use a read prefetch instruction in a similar way
on an amd_64? [Not the same thing .. better actually since
it doesn't commit a register]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net