A.2.105 -xalias_level[=n]

(SPARC) The C++ compiler can perform type-based alias-analysis and optimizations when you specify the following command:

• -xalias_level[=n]

  where n is any, simple, or compatible.

• -xalias_level=any

  At this level of analysis, the compiler assumes that any type may alias any other type. However, despite this assumption, some optimization is possible.

• -xalias_level=simple

  The compiler assumes that simple types are not aliased. Specifically, a storage object with a dynamic type that is one of the following simple types:

is only accessed through lvalues of the following types:

• The dynamic type of the object

  • A constant or volatile qualified version of the dynamic type of the object, a type that is the signed or unsigned type corresponding to the dynamic type of the object

  • A type that is the signed or unsigned type corresponding to a constant or volatile qualified version of the dynamic type of the object

  • An aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union)

  • A char or unsigned char type

  -xalias_level=compatible

  The compiler assumes that layout-incompatible types are not aliased. A storage object is only accessed through lvalues of the following types:

  • The dynamic type of the object

  • A constant or volatile qualified version of the dynamic type of the object, a type that is the signed or unsigned type which corresponds to the dynamic type of the object

  • A type that is the signed or unsigned type which corresponds to the constant or volatile qualified version of the dynamic type of the object

  • An aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union)

  • A type that is (possibly constant or volatile qualified) base class type of the dynamic type of the object

  • A char or unsigned char type.

    The compiler assumes that the types of all references are layout compatible with the dynamic type of the corresponding storage object. Two types are layout-compatible under the following conditions:

  • If two types are the same type, then they are layout-compatible types.

  • If two types differ only in constant or volatile qualification, then they are layout-compatible types.

  • For each of the signed integer types, there exists a corresponding (but different) unsigned integer type. These corresponding types are layout compatible.

  • Two enumeration types are layout-compatible if they have the same underlying type.

  • Two Plain Old Data (POD) struct types are layout compatible if they have the same number of members, and corresponding members (in order) have layout compatible types.

  • Two POD union types are layout compatible if they have the same number of members, and corresponding members (in any order) have layout compatible types.

    References may be non-layout-compatible with the dynamic type of the storage object under limited circumstances:

  • If a POD union contains two or more POD structs that share a common initial sequence, and if the POD union object currently contains one of those POD structs, it is permitted to inspect the common initial part of any of them. Two POD structs share a common initial sequence if corresponding members have layout compatible types and, as applicable to bit fields, the same widths, for a sequence of one or more initial members.

  • A pointer to a POD struct object, suitably converted using a reinterpret_cast, points to its initial member, or if that member is a bit field, to the unit in which it resides.

A.2.105.1 Defaults

If you do not specify -xalias_level, the compiler sets the option to -xalias_level=any. If you specify -xalias_level but do not provide a value, the compiler sets the option to -xalias_level=compatible.

Interactions

The compiler does not perform type-based alias analysis at optimization level -xO2 and below.

Warning

If you are using reinterpret_cast or an equivalent old-style cast, the program may violate the assumptions of the analysis. Also, union type punning, as shown in the following example, violates the assumptions of the analysis.

union bitbucket{
  int i;
  float f;
};

int bitsof(float f){
bitbucket var;
var.f=3.6;
return var.i;
}