test

Sun Studio 12: C User's Guide

Chapter 5 Type-Based Alias Analysis

This document explains how to use the -xalias_level option and several pragmas to enable the compiler to perform type-based alias analysis and optimizations. You use these extensions to express type-based information about the way pointers are used in your C program. The C compiler uses this information, in turn, to do a significantly better job of alias disambiguation for pointer-based memory references in your program.

See B.2.67 -xalias_level[=l] for a detailed explanation of this command’s syntax. Also, see 4.3.38 -Xalias_level[=l] for an explanation of the lint program’s type-based alias-analysis capabilities.

5.1 Introduction to Type-Based Analysis

You can use the -xalias_level option to specify one of seven alias levels. Each level specifies a certain set of properties about the way you use pointers in your C program.

As you compile with higher levels of the -xalias_level option, the compiler makes increasingly extensive assumptions about the pointers in your code. You have greater programming freedom when the compiler makes fewer assumptions. However, the optimizations that result from these narrow assumptions may not result in significant runtime performance improvement. If you code in accordance with the compiler assumptions of the more advanced levels of the -xalias_level option, there is a greater chance that the resulting optimizations will enhance runtime performance.

The -xalias_level option specifies which alias level applies to each translation unit. For cases where more detail is beneficial, you can use new pragmas to override whatever alias levels are in effect so that you can explicitly specify the aliasing relationships between individual types or pointer variables in the translation unit. These pragmas are most useful when the pointer usage in a translation unit is covered by one of the available alias levels, but a few specific pointer variables are used in an irregular way that is not allowed by one of the available levels.

5.2 Using Pragmas for Finer Control

For cases in which type-based analysis can benefit from more detail, you can use the following pragmas to override the alias level in effect and specify the aliasing relationships between individual types or pointer variables in the translation unit. These pragmas provide the most benefit when the use of pointers in a translation unit is consistent with one of the available alias levels, but a few specific pointer variables are used in an irregular way not allowed by one of the available levels.

Note –

You must declare the named type or variable prior to the pragma or a warning message is issued and the pragma is ignored. The results of the program are undefined if the pragma appears after the first memory reference to which its meaning applies.

The following terms are used in the pragma definitions.

Term  

Meaning  

level

Any of the alias levels listed under B.2.67 -xalias_level[=l].

type

Any of the following: 

  • char, short, int, long, long long, float, double, long double

  • void, which denotes all pointer types

  • typedef name, which is the name of a defined type from a typedef declaration

  • struct name, which is the keyword struct followed by a struct tag name

  • union, which is the keyword union followed by a union tag name

pointer_name

The name of any variable of pointer type in the translation unit. 

5.2.1 #pragma alias_level level (list)

Replace level with one of the seven alias levels: any, basic, weak, layout, strict, std, or strong. You can replace list with either a single type or a comma-delimited list of types, or you can replace list with either a single pointer or a comma-delimited list of pointers. For example, you can issue #pragma alias_level as follows:

This pragma specifies that the indicated alias level applies either to all of the memory references of the translation unit for the listed types, or to all of the dereferences of the translation unit where any of the named pointer variables are being dereferenced.

If you specify more than one alias level to be applied to a particular dereference, the level that is applied by the pointer name, if any, has precedence over all other levels. The level applied by the type name, if any, has precedence over the level applied by the option. In the following example, the std level applies to p if the program is compiled with #pragma alias_level set higher than any.


typedef int * int_ptr;
int_ptr p;
#pragma alias_level strong (int_ptr)
#pragma alias_level std (p)

5.2.1.1 #pragma alias (type, type [, type]…)

This pragma specifies that all the listed types alias each other. In the following example, the compiler assumes that the indirect access *pt aliases the indirect access *pf.


#pragma alias (int, float)
int *pt;
float *pf;

5.2.1.2 #pragma alias (pointer, pointer [, pointer]…)

This pragma specifies that at the point of any dereference of any of the named pointer variables, the pointer value being dereferenced can point to the same object as any of the other named pointer variables. However, the pointer is not limited to only the objects contained in the named variables and can point to objects that are not included in the list. This pragma overrides the aliasing assumptions of any applied alias levels. In the following example, any indirect accesses of p and q after the pragma are considered to alias regardless of their type.


#pragma alias(p, q)

5.2.1.3 #pragma may_point_to (pointer, variable [, variable]…)

This pragma specifies that at the point of any dereference of the named pointer variable, the pointer value being dereferenced can point to the objects that are contained in any of the named variables. However, the pointer is not limited to only the objects contained in the named variables and can point to objects that are not included in the list. This pragma overrides the aliasing assumptions of any applied alias levels. In the following example, the compiler assumes that any indirect access of *p, aliases any direct accesses a, b, and c.


#pragma alias may_point_to(p, a, b, c)

5.2.1.4 #pragma noalias (type, type [, type]…)

This pragma specifies that the listed types do not alias each other. In the following example, the compiler assumes that any indirect access of *p does not alias the indirect access *ps.


struct S {
   float f;
   ...} *ps;

#pragma noalias(int, struct S)
int *p;

5.2.1.5 #pragma noalias (pointer, pointer [, pointer]…)

This pragma specifies that at the point of any dereference of any of the named pointer variables, the pointer value being dereferenced does not point to the same object as any of the other named pointer variables. This pragma overrides all other applied alias levels. In the following example, the compiler assumes that any indirect access of *p does not alias the indirect access *q regardless of the types of the two pointers.


#pragma noalias(p, q)

5.2.1.6 #pragma may_not_point_to (pointer, variable [, variable]…)

This pragma specifies that at the point of any dereference of the named pointer variable, the pointer value being dereferenced does not point to the objects that are contained in any of the named variables. This pragma overrides all other applied alias levels. In the following example, the compiler assumes that any indirect access of *p does not alias the direct accesses a, b, or c.


#pragma may_not_point_to(p, a, b, c)

5.3 Checking With lint

The lint program recognizes the same levels of type-based alias-disambiguation as the compiler’s -xalias_level command. The lint program also recognizes the pragmas related to type-based alias-disambiguation documented in this chapter. For a detailed explanation of the lint -Xalias_level command, see 4.3.38 -Xalias_level[=l].

There are four situations that lint detects and for which it generates warnings:

5.3.1 Struct Pointer Cast of Scalar Pointer

In the following example, the pointer p of type integer is cast as a pointer of type struct foo. With lint -Xalias_level=weak (or higher), this generates an error.


struct foo {
    int a;
    int b;
  };

struct foo *f;
int *p;

void main()
{
    f = (struct foo *)p; /* struct pointer cast of scalar pointer error */
}

5.3.2 Struct Pointer Cast of Void Pointer

In the following example, the void pointer vp, is cast as a struct pointer. With lint -Xalias_level=weak (or higher), this generates a warning.


struct foo {
    int a;
    int b;
  };

struct foo *f;
void *vp;

void main()
{
    f = (struct foo *)vp; /* struct pointer cast of void pointer error */
}

5.3.3 Cast of Struct Field to Structure Pointer

In the following example, the address of structure member foo.b is being cast as a struct pointer and then assigned to p. With lint -Xalias_level=weak (or higher), this generates a warning.


struct foo p{
    int a;
    int b;
  };

struct foo *f1;
struct foo *f2;

void main()
{
    f2 = (struct foo *)&f1->b; /* cast of a scalar pointer to struct pointer error*/
}

5.3.4 Explicit Aliasing Required

In the following example, the pointer f1 of type struct fooa is being cast as a pointer of type struct foob. With lint -Xalias_level=strict (or higher) such a cast requires explicit aliasing, unless the struct types are identical (the same number of fields of the same type). In addition, at alias levels standard and strong, the assumptions is that the tags must match for aliasing to occur. Use #pragma alias (struct fooa, struct foob) before the assignment to f1 and lint stops generating the warning.


struct fooa {
    int a;
};

struct foob {
    int b;
};

struct fooa *f1;
struct foob *f2;

void main()
{
    f1 = (struct fooa *)f2; /* explicit aliasing required warning */
}

5.4 Examples of Memory Reference Constraints

This section provides examples of code that are likely to appear in your source files. Each example is followed by a discussion of the compiler’s assumptions about the code as dictated by the applied level of type-based analysis.

Consider the following code. It can be compiled with different levels of aliasing to demonstrate the aliasing relationship of the shown types.

struct foo {
    int f1;
    short f2;
    short f3;
    int f4;
} *fp;

struct bar {
    int b1;
    int b2;
    int b3;
} *bp;

int *ip;
short *sp;

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=any option, the compiler considers the following indirect accesses as aliases to each other:

*ip, *sp, *fp, *bp, fp->f1, fp->f2, fp->f3, fp->f4, bp->b1, bp->b2, bp->b3

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=basic option, the compiler considers the following indirect accesses as aliases to each other:

*ip, *bp, fp->f1, fp->f4, bp->b1, bp->b2, bp->b3

Additionally, *sp, fp->f2, and fp->f3 can alias each other, and *sp and *fp can alias each other.

However, under -xalias_level=basic, the compiler assumes the following:

The compiler makes these assumptions because the access types of the two indirect accesses are different basic types.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=weak option, the compiler assumes the following alias information:

The compiler assumes that fp->fp1 does not alias bp->b2 because f1 is a field with offset 0 in a structure, whereas b2 is a field with a 4-byte offset in a structure. Similarly, the compiler assumes that fp->f1 does not alias bp->b3, and fp->f4 does not alias either bp->b1 or bp->b2.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=layout option, the compiler assumes the following information:

fp->f4 does not alias bp->b3 because f4 and b3 are not corresponding fields in the common initial sequence of foo and bar.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=strict option, the compiler assumes the following alias information:

With -xalias_level=strict, the compiler assumes that *fp, *bp, fp->f1, fp->f2, fp->f3, fp->f4, bp->b1, bp->b2, and bp->b3 do not alias each other because foo and bar are not the same when field names are ignored. However, fp aliases fp->f1 and bp aliases bp->b1.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=std option, the compiler assumes the following alias information:

However, fp->f1 does not alias bp->b1, bp->b2, or bp->b3 because foo and bar are not the same when field names are considered.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=strong option, the compiler assumes the following alias information:

Consider the following example source code. It demonstrates the aliasing relationship of the shown types when compiled with different levels of aliasing.

struct foo {
    int f1;
    int f2;
    int f3;
} *fp;

struct bar {
    int b1;
    int b2;
    int b3;
} *bp;

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=any option, the compiler assumes the following alias information:

*fp, *bp, fp->f1, fp->f2, fp->f3, bp->b1, bp->b2 and bp->b3 all can alias each other because any two memory accesses alias each other at the level of -xalias_level=any.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=basic option, the compiler assumes the following alias information:

*fp, *bp, fp->f1, fp->f2, fp->f3, bp->b1, bp->b2 and bp->b3 all can alias each other. Any two field accesses using pointers *fp and *bp can alias each other in this example because all the structure fields are the same basic type.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=weak option, the compiler assumes the following alias information:

However, -xalias_level=weak imposes the following restrictions:

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=layout options, the compiler assumes the following alias information:

However, -xalias_level=layout imposes the following restrictions:

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=strict option, the compiler assumes the following alias information:

However, -xalias_level=strict imposes the following restrictions:

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=std option, the compiler assumes the following alias information:

fp->f1, fp->f2, fp->f3, bp->b1, bp->b2, and bp->b3 do not alias each other.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=strong option, the compiler assumes the following alias information:

fp->f1, fp->f2, fp->f3, bp->b1, bp->b2, and bp->b3 do not alias each other.

Consider the following example source code that demonstrates that certain levels of aliasing cannot handle interior pointers. For a definition of interior pointers see Table B–11.

struct foo {
        int f1;
        struct bar *f2;
        struct bar *f3;
        int f4;
        int f5;
        struct bar fb[10];
} *fp;

struct bar
        struct bar *b2;
        struct bar *b3;
        int b4;
} *bp;

bp=(struct bar*)(&fp->f2);

The dereference in 5.4 Examples of Memory Reference Constraints is not supported by weak, layout, strict, or std. After the pointer assignment bp=(struct bar*)(&fp->f2), the following pair of memory accesses touches the same memory locations:

However, under options weak, layout, strict, and std, the compiler assumes that fp->f2 and bp->b2 do not alias. The compiler makes this assumption because b2 has an offset of zero, which is different from the offset of f2 (four bytes), and foo and bar do not have a common initial sequence. Similarly, the compiler also assumes that bp->b3 does not alias fp->f3, and bp->b4 does not alias fp->f4.

Thus, the pointer assignment bp=(struct bar*)(&fp->f2)creates a situation in which the compiler’s assumptions about alias information are incorrect. This may lead to incorrect optimization.

Try compiling after you make the modifications shown in the following example.


struct foo {
        int f1;
        struct bar fb;   /* Modified line */
#define f2 fb.b2         /* Modified line */
#define f3 fb.b3         /* Modified line */
#define f4 fb.b4         /* Modified line */
        int f5;
        struct bar fb[10];
} *fp;

struct bar
        struct bar *b2;
        struct bar *b3;
        int b4;
} *bp;

bp=(struct bar*)(&fp->f2);

After the pointer assignment bp=(struct bar*)(&fp->f2), the following pair of memory accesses touches the same memory locations:

By examining the changes shown in the preceding code example, you can see that the expression fp->f2 is another form of the expression fp->fb.b2. Because fp->fb is of type bar, fp->f2 accesses the b2 field of bar. Furthermore, bp->b2 also accesses the b2 field of bar. Therefore, the compiler assumes that fp->f2 aliases bp->b2. Similarly, the compiler assumes that fp->f3 aliases bp->b3, and fp->f4 aliases bp->b4. As a result, the aliasing assumed by the compiler matches the actual aliases caused by the pointer assignment.

Consider the following example source code.

struct foo {
        int f1;
        int f2;
} *fp;

struct bar {
        int b1;
        int b2;
} *bp;

struct cat {
        int c1;
        struct foo cf;
        int c2;
        int c3;
} *cp;

struct dog {
        int d1;
        int d2;
        struct bar db;
        int d3;
} *dp;

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=weak option, the compiler assumes the following alias information:

fp->f2 can alias cp->c2 because *dp can alias *cp and *fp can alias dp->db.

cp->cf.f1 does not alias dp->db.b1.

cp->c2 does not alias dp->db.b1 and cp->c2 does not alias dp->d3.

With respect to offsets, cp->c2 can alias db->db.b1 only if *dp aliases cp->cf. However, if *dp aliases cp->cf, then dp->db.b1 must alias beyond the end of foo cf, which is prohibited by object restrictions. Therefore, the compiler assumes that cp->c2 cannot alias db->db.b1.

cp->c3 can alias dp->d3.

Notice that cp->c3 does not alias dp->db.b2. These memory references do not alias because the offsets of the fields of the types involved in the dereferences differ and do not overlap. Based on this, the compiler assumes they cannot alias.

Notice that dp->d3 does not alias cp->cf.f2. These memory references do not alias because the offsets of the fields of the types involved in the dereferences differ and do not overlap. Based on this, the compiler assumes they cannot alias.

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=layout option, the compiler assumes only the following alias information:

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=strict option, the compiler assumes only the following alias information:

If 5.4 Examples of Memory Reference Constraints is compiled with the -xalias_level=std option, the compiler assumes only the following alias information:

Consider the following example source code.

struct foo {
        short f1;
        short f2;
        int   f3;
} *fp;

struct bar {
        int b1;
        int b2;
} *bp;

union moo {
        struct foo u_f;
        struct bar u_b;
} u;

Here are the compiler’s assumptions based on the following alias levels:

Consider the following example source code.

struct bar;

struct foo {
        struct foo *ffp;
        struct bar *fbp;
} *fp;

struct bar {
        struct bar *bbp;
        long        b2;
} *bp;

Here are the compiler’s assumptions based on the following alias levels:

Consider the following example source code:

struct foo;
struct bar;
#pragma alias (struct foo, struct bar)

struct foo {
        int f1;
        int f2;
} *fp;

struct bar {
        short b1;
        short b2;
        int   b3;
} *bp;

The pragma in this example tells the compiler that foo and bar are allowed to alias each other. The compiler makes the following assumptions about alias information: