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.
> So
> presumably you mean permitted the alias analysis to distinguish loads
> and stores using int* and float*, but not struct s* and struct t*. I
> don't think that would be particularly useful.
No, that wasn't what I meant .. it seems that the existing
switch already does what I want!
> > BTW: one of the hacks is aliasing pairs like these:
> >
> > struct X { T x; X(T a) : x(x) {} };
> > struct Y { T x[1]; };
> >
> > in C++, so a constructor can initialise an array
> > of known length efficiently. (in C++ assignment
> > of default initialised value can cost more than
> > initialisation, and may even be impossible if
> > there is no default constructor).
>
> C (I don't know about C++) provides an out to the aliasing rules for
> unions.
Due to stupidity on the part of WG21, this won't work for the above
code because X above has a constructor, and unions may not
contain constructable types. [Excuse my annoyance -- I vetoed this
as an NB representative, but the current rule was passed next
meeting which I could afford to attend]
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
