test

Sun Studio 12: C User's Guide

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: