HPlogo HP C/HP-UX Programmer's Guide: Workstations and Servers > Chapter 4 Optimizing HP C Programs

Aliasing Options

» 

Technical documentation

Complete book in PDF

 » Table of Contents

 » Index

To be conservative, the optimizer assumes that a pointer can point to any object in the entire application. Instead, if the optimizer can be educated on the application's pointer usage, then the optimizer can generate more efficient code, due to the elimination of some false assumptions. Such behavior can be communicated to the optimizer by using the following options:

  • +O[no]ptrs_strongly_typed

  • +O[no]ptrs_to_globals[=list]

  • +O[no]global_ptrs_unique[=list]

  • +O[no]ptrs_ansi

where list is a comma-separated list of global variable names.

Here are the type-inferred aliasing rules:

  • Type-aliasing optimizations are based on the assumption that pointer dereferences obey their declared types.

  • A C variable is considered address-exposed if and only if the address of that variable is assigned to another variable or passed to a function as an actual parameter. In general, address-exposed objects are collected into a separate group based on their declared type. Global variables and static variables are considered address-exposed by default. Local variables and actual parameters are considered address-exposed only if their address has been computed using the address operator .

  • Dereferences of pointers to a certain type will be assumed to only alias with the corresponding equivalent group. An equivalent group includes all the address exposed objects of the same type. The dereferences of pointers are also assumed to alias with other pointer dereferences associated with the same equivalent group.

    In the example

    int *p, *q;

    *p and *q are assumed to alias with any objects of type int. Also *p and *q are assumed to alias with each other.

  • Signed/Unsigned type distinctions are ignored in grouping objects into an equivalent group. Likewise, long and int types are considered to map to the same equivalent group. However, the volatile type qualifier is considered significant in grouping objects into equivalent groups (e.g., a pointer to int will not be considered to alias with a volatile int object).

  • If two type names reduce to the same type, they are considered synonymous.

    In the following example, both types type_old and type_new will reduce to the same type, struct foo.

    typedef struct foo_st type_old;
    typedef type_old type_new;
  • Each field of a structure type is placed in a separate equivalent group which is distinct from the equivalent group of the field's base type. (The assumption here is that a pointer to int will not be assigned the address of a structure field whose type is int). The actual type name of a structure type is not considered significant in constructing equivalent groups (e.g., dereferences of a struct foo pointer and a struct bar pointer will be assumed to alias with each other even if struct foo and struct bar have identical field declarations).

  • All fields of a union type are placed in the same equivalent group, which is distinct from the equivalent group of any of the field's base types. (Thus, all dereferences of pointers to a particular union type will be assumed to alias with each other, regardless of which union field is being accessed.)

  • Address-exposed array variables are grouped into the equivalent group of the array element type.

  • Explicit pointer typecasts applied to expression values will be honored in that it would alter the equivalent group associated with an ensuing use of the typecast expression value. For example, an int pointer that is first typecast into a float pointer and then dereferenced will be assumed to potentially access objects in the float equivalent group — and not the int equivalent group. However, type-incompatible assignments to pointer variables will not alter the aliasing assumptions on subsequent references of such pointer variables.

    In general, type incompatible assignments can potentially invalidate some of the type-safe assumptions, and such constructs may elicit compiler warning messages.

    NOTE: Variables declared to be of type void * need to be typecast into a pointer to a specific type before they can be dereferenced.
© Hewlett-Packard Development Company, L.P.