skaller <[EMAIL PROTECTED]> writes:
> Can someone tell me what optimisations might be enabled/disabled
> by strict aliasing rules?
With no aliasing information at all, the compiler can not reorder load
and store instructions, because they might refer to the same memory
locations. The compiler does a bunch of analysis to determine whether
load and store instructions can refer to the same location. Strict
aliasing refers to one component of that analysis, really a final
tie-breaker: using type information to distinguish loads and stores.
> Is there some merit in a switch which allows coarse aliasing
> optimisations, that is, allows optimisations based on integer
> vs float vs pointer, but not on pointer vs pointer?
Strict aliasing only refers to loads and stores using pointers. 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.
> I have some code which makes aliases by pointer casting
> to layout compatible types: optimisations based on the
> type distinction would break the code. However aliasing
> on incompatible types (eg pointer to float vs int) are
> desired (rather -- I want the fastest possible code,
> without breaking my pointer cast hackery).
>
> 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. Section 6.5.2.3 of the C standard:
One special guarantee is made in order to simplify the use of
unions: if a union contains several structures that share a common
initial sequence (see below), and if the union object currently
contains one of these structures, it is permitted to inspect the
common initial part of any of them anywhere that a declaration of
the complete type of the union is visible. Two structures share a
common initial sequence if corresponding members have compatible
types (and, for bit-fields, the same widths) for a sequence of one
or more initial members.
Note that this applies anywhere that a declaration of the complete
type of the union is available. That is, it does not only apply to
accesses through pointers to the union type. This imposes some
significant restrictions on alias analysis of pointers to structs.
Ian
