On Mon, 2007-11-05 at 10:15 -0800, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2007-11-05 at 09:56 -0800, Ian Lance Taylor wrote:
> > > skaller <[EMAIL PROTECTED]> writes:
> > >
> > > > Can someone tell me what optimisations might be enabled/disabled
> > > > by strict aliasing rules?
> >
> > > Strict aliasing only refers to loads and stores using pointers.
> >
> > Ah, I see. So turning it off isn't really all that bad
> > for optimisation.
>
> It depends on the processor. For an in-order processor with a deep
> pipeline (e.g., Itanium, but there are others), the ability to reorder
> loads and stores is very important to permit scheduling flexibility.
> Strict aliasing reportedly makes a difference for x86, but I don't
> think it makes a huge difference.
Well, I have been compiling with strict-aliasing enabled and
haven't encountered any errors that I'm aware of: the code seems
to run on x86, x86_64 and PPC32. I do get a couple of warnings.
In the example case, the code looks like:
reinterpret<Y>(X(1,2,3))
where re-interpret is:
template<typename T, typename U>
T &reinterpret(U const &x) {
return reinterpret_cast<T&>(const_cast<U&>(x));
}
This is pretty nasty, but is necessary to work around
design faults in C++.
It's essential here that the X struct be initialised before
any loads via the Y struct (any reordering would be a disaster).
g++ seems to generate the right code here, but the warning
does worry me. There are some other breaches -- essential with
a custom memory manager (Felix has a garbage collector),
however I think they're no problem due to enough subroutine
boundaries getting in the way :)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
