| C User's Guide Supplement |
Type-Based Alias Analysis
This document explains how you can use a new Sun WorkShop Compilers C option and several new 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.
This document contains the following sections:
Introduction
You can use the new
-xalias_leveloption 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_leveloption, 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_leveloption, there is a greater chance that the resulting optimizations will enhance runtime performance.The
-xalias_leveloption 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.The
-xalias_levelOptionThe compiler uses the
-xalias_leveloption to determine what assumptions it can make in order to perform optimizations using type-based alias analysis. This option places the indicated alias level into effect for the translation units being compiled. The first default is-xalias_level=any, which means there is no type-based alias analysis. If you specify-xalias_levelwithout a value, the default is-xalias_level=layout.Remember that if you issue the
-xalias_leveloption but you fail to adhere to all of the assumptions and restrictions about aliasing described for any of the alias levels, the behavior of your program is undefined.
-xalias_level=listReplace list with one of the terms in the following table.
Pragmas
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.
level Any of the alias levels listed under The -xalias_level Option. type Any of the following: char,short,int,long,longlong,float,double,longdoublevoid, which denotes all pointer typestypedefname, which is the name of a defined type from atypedefdeclarationstructname, which is the keywordstructfollowed by a struct tag nameunion, which is the keywordunionfollowed by a union tag namepointer_name The name of any variable of pointer type in the translation unit.
#pragmaalias_levellevellistReplace level with one of the seven alias levels:
any,basic,weak,layout,strict,std, orstrong. 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#pragmaalias_levelas follows:
#pragmaalias_levellevel(type [,type])#pragmaalias_levellevel(pointer [, pointer])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
stdlevel applies to p if the program is compiled with#pragmaalias_levelset higher thanany.
typedef int*int_ptr;int_ptr p;#pragma alias_level strong (int_ptr)#pragma alias_level std (p)
#pragmaalias (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
*ptaliases the indirect access*pf.
#pragma alias (int, float)int*pt;float*pf;
#pragmaalias(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. This pragma overrides the aliasing assumptions of any applied alias levels. In the following example, the compiler assumes that the indirect access
*paliases the indirect access*qregardless of the types of the two pointers.
#pragma alias(p, q)
#pragmamay_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. This pragma overrides the aliasing assumptions of any applied alias levels. In the following example, the compiler assumes that the indirect access
*paliases the direct accessesa,b, andc.
#pragma alias may_point_to(p, a, b, c)
#pragmanoalias (type,type [, type]...)This pragma specifies that the listed types do not alias each other. In the following example, the compiler assumes that the indirect access
*pdoes not alias the indirect access*ps.
struct S {float f;...} *ps;#pragma noalias(int, struct S)int*p;
#pragmanoalias (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 the indirect access
*pdoes not alias the indirect access*qregardless of the types of the two pointers.
#pragma noalias(p, q)
#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 the indirect access
*pdoes not alias the direct accessesa,b, orc.
#pragma may_not_point_to(p, a, b, c)Examples
This section provides examples of how memory references are constrained in your program when you use the
-xalias_leveloption.Example 1
Consider the following code example that can compile 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 Example 1 is compiled with the
-xalias_level=anyoption, 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->b3If Example 1 is compiled with the
-xalias_level=basicoption, the compiler considers the following indirect accesses as aliases to each other:
*ip,*bp,fp->f1,fp->f4,bp->b1,bp->b2,bp->b3Additionally,
*sp,fp->f2, andfp->f3can alias each other, and*spand*fpcan alias each other.However, under
-xalias_level=basic, the compiler assumes the following:
*ipdoes not alias*sp.*ipdoes not aliasfp->f2andfp->f3.*spdoes not aliasfp->f1,fp->f4,bp->b1,bp->b2, andbp->b3.The compiler makes these assumptions because the access types of the two indirect accesses are different basic types.
If Example 1 is compiled with the
-xalias_level=weakoption, the compiler assumes the following alias information:
*ipcan alias*fp,fp->f1,fp->f4,*bp,bp->b1,bp->b2, andbp->b3.*spcan alias*fp,fp->f2andfp->f3.fp->f1can aliasbp->b1.fp->f4can aliasbp->b3.The compiler assumes that
fp->fp1does not aliasbp->b2becausef1is a field with offset 0 in a structure, whereasb2is a field with a 4-byte offset in a structure. Similarly, the compiler assumes thatfp->f1does not aliasbp->b3, andfp->f4does not alias eitherbp->b1orbp->b2.If Example 1 is compiled with the
-xalias_level=layoutoption, the compiler assumes the following information:
*ipcan alias*fp,*bp,fp->f1,fp->f4,bp->b1,bp->b2, andbp->b3.*spcan alias*fp,fp->f2, andfp->f3.fp->f1can aliasbp->b1and*bp.*fpand*bpcan alias each other.
fp->f4does not aliasbp->b3becausef4andb3are not corresponding fields in the common initial sequence offooandbar.If Example 1 is compiled with the
-xalias_level=strictoption, the compiler assumes the following alias information:
*ipcan alias*fp,fp->f1,fp->f4,*bp,bp->b1,bp->b2, andbp->b3.*spcan alias*fp,fp->f2, andfp->f3.With
-xalias_level=strict, the compiler assumes that*fp,*bp,fp->f1,fp->f2,fp->f3,fp->f4,bp->b1,bp->b2, andbp->b3do not alias each other becausefooandbarare not the same when field names are ignored. However,fpaliasesfp->f1andbpaliasesbp->b1.If Example 1 is compiled with the
-xalias_level=stdoption, the compiler assumes the following alias information:
*ipcan alias*fp,fp->f1,fp->f4,*bp,bp->b1,bp->b2, andbp->b3.*spcan alias*fp,fp->f2, andfp->f3.However,
fp->f1does not aliasbp->b1,bp->b2, orbp->b3becausefooandbarare not the same when field names are considered.If Example 1 is compiled with the
-xalias_level=strongoption, the compiler assumes the following alias information:
*ipdoes not aliasfp->f1,fp->f4,bp->b1,bp->b2, andbp->b3because a pointer, such as*ip, should not point to the interior of a structure.- Similarly,
*spdoes not aliasfp->f1orfp->f3.*ipdoes not alias*fp,*bp, and*spdue to differing types.*spdoes not alias*fp,*bp, and*ipdue to differing types.Example 2
Consider the following example source code that can compile with different levels of aliasing to demonstrate the aliasing relationship of the shown types.
struct foo {int f1;int f2;int f3;}*fp;struct bar {int b1;int b2;int b3;}*bp;If Example 2 is compiled with the
-xalias_level=anyoption, the compiler assumes the following alias information:
*fp,*bp,fp->f1,fp->f2,fp->f3,bp->b1,bp->b2andbp->b3all can alias each other because any two memory accesses alias each other at the level of-xalias_level=any.If Example 2 is compiled with the
-xalias_level=basicoption, the compiler assumes the following alias information:
*fp,*bp,fp->f1,fp->f2,fp->f3,bp->b1,bp->b2andbp->b3all can alias each other. Any two field accesses using pointers*fpand*bpcan alias each other in this example because all the structure fields are the same basic type.If Example 2 is compiled with the
-xalias_level=weakoption, the compiler assumes the following alias information:
*fpand*fpcan alias each other.fp->f1can aliasbp->b1,*bpand*fp.fp->f2can aliasbp->b2,*bpand*fp.fp->f3can aliasbp->b3,*bpand*fp.However,
-xalias_level=weakimposes the following restrictions:
fp->f1does not aliasbp->b2orbp->b3becausef1has an offset of zero, which is different from that ofb2(four bytes) andb3(eight bytes).fp->f2does not aliasbp->b1orbp->b3becausef2has an offset of four bytes, which is different fromb1(zero bytes) andb3(eight bytes).fp->f3does not aliasbp->b1orbp->b2becausef3has an offset of eight bytes, which is different fromb1(zero bytes) andb2(four bytes).If Example 2 is compiled with the
-xalias_level=layoutoptions, the compiler assumes the following alias information:
*fpand*bpcan alias each other.fp->f1can aliasbp->b1,*bp, and*fp.fp->f2can aliasbp->b2,*bp, and*fp.fp->f3can aliasbp->b3,*bp, and*fp.However,
-xalias_level=layoutimposes the following restrictions:
fp->f1does not aliasbp->b2orbp->b3because fieldf1corresponds to fieldb1in the common initial sequence offooandbar.fp->f2does not aliasbp->b1orbp->b3becausef2corresponds to fieldb2in the common initial sequence offooandbar.fp->f3does not aliasbp->b1orbp->b2becausef3corresponds to fieldb3in the common initial sequence offooandbar.If Example 2 is compiled with the
-xalias_level=strictoption, the compiler assumes the following alias information:
*fpand*bpcan alias each other.fp->f1can aliasbp->b1,*bp, and*fp.fp->f2can aliasbp->b2,*bp, and*fp.fp->f3can aliasbp->b3,*bp, and*fp.However,
-xalias_level=strictimposes the following restrictions:
fp->f1does not aliasbp->b2orbp->b3because fieldf1corresponds to fieldb1in the common initial sequence offooandbar.fp->f2does not aliasbp->b1orbp->b3becausef2corresponds to fieldb2in the common initial sequence offooandbar.fp->f3does not aliasbp->b1orbp->b2becausef3corresponds to fieldb3in the common initial sequence offooandbar.If Example 2 is compiled with the
-xalias_level=stdoption, the compiler assumes the following alias information:
fp->f1,fp->f2,fp->f3,bp->b1,bp->b2, andbp->b3do not alias each other.If Example 2 is compiled with the
-xalias_level=strongoption, the compiler assumes the following alias information:
fp->f1,fp->f2,fp->f3,bp->b1,bp->b2, andbp->b3do not alias each other.Example 3
Consider the following example source code that demonstrates that certain levels of aliasing cannot handle interior pointers. For a definition of interior pointers see strong.
struct foo {int f1;struct bar *f2;struct bar *f3;int f4;int f5;struct bar fb[10];} *fp;struct barstruct bar *b2;struct bar *b3;int b4;} *bp;bp=(struct bar*)(&fp->f2);The dereference in Example 3 is not supported by
weak,layout,strict, orstd. After the pointer assignmentbp=(struct bar*)(&fp->f2), the following pair of memory accesses touches the same memory locations:
fp->f2andbp->b2access the same memory locationfp->f3andbp->b3access the same memory locationfp->f4andbp->b4access the same memory locationHowever, under options
weak,layout,strict, andstd, the compiler assumes thatfp->f2andbp->b2do not alias. The compiler makes this assumption becauseb2has an offset of zero, which is different from the offset off2(four bytes), andfooandbardo not have a common initial sequence. Similarly, the compiler also assumes thatbp->b3does not aliasfp->f3, andbp->b4does not aliasfp->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.
After the pointer assignment
bp=(struct bar*)(&fp->f2), the following pair of memory accesses touches the same memory locations:
fp->f2andbp->b2fp->f3andbp->b3fp->f4andbp->b4By examining the changes shown in the preceding code example, you can see that the expression
fp->f2is another form of the expressionfp->fb.b2. Becausefp->fbis of typebar,fp->f2accesses theb2field ofbar. Furthermore,bp->b2also accesses theb2field ofbar. Therefore, the compiler assumes thatfp->f2aliasesbp->b2. Similarly, the compiler assumes thatfp->f3aliasesbp->b3, andfp->f4aliasesbp->b4. As a result, the aliasing assumed by the compiler matches the actual aliases caused by the pointer assignment.Example 4
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 Example 4 is compiled with the
-xalias_level=weakoption, the compiler assumes the following alias information:
fp->f1can aliasbp->b1,cp->c1,dp->d1,cp->cf.f1, anddf->db.b1.fp->f2can aliasbp->b2,cp->cf.f1,dp->d2,cp->cf.f2,df->db.b2,cp->c2.bp->b1can aliasfp->f1,cp->c1,dp->d1,cp->cf.f1, anddf->db.b1.bp->b2can aliasfp->f2,cp->cf.f1,dp->d2,cp->cf.f1, anddf->db.b2.
fp->f2can aliascp->c2because*dpcan alias*cpand*fpcan aliasdp->db.
cp->c1can aliasfp->f1,bp->b1,dp->d1, anddp->db.b1.cp->cf.f1can aliasfp->f1,fp->f2,bp->b1,bp->b2,dp->d2, anddp->d1.
cp->cf.f1does not aliasdp->db.b1.
cp->cf.f2can aliasfp->f2,bp->b2,dp->db.b1, anddp->d2.cp->c2can aliasdp->db.b2.
cp->c2does not aliasdp->db.b1andcp->c2does not aliasdp->d3.With respect to offsets,
cp->c2can aliasdb->db.b1only if*dpaliasescp->cf. However, if*dpaliasescp->cf, thendp->db.b1must alias beyond the end offoocf, which is prohibited by object restrictions. Therefore, the compiler assumes thatcp->c2cannot aliasdb->db.b1.Notice that
cp->c3does not aliasdp->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.
dp->d1can aliasfp->f1,bp->b1, andcp->c1.dp->d2can aliasfp->f2,bp->b2, andcp->cf.f1.dp->db.b1can aliasfp->f1,bp->b1, andcp->c1.dp->db.b2can aliasfp->f2,bp->b2,cp->c2, andcp->cf.f1.dp->d3can aliascp->c3.Notice that
dp->d3does not aliascp->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 Example 4 is compiled with the
-xalias_level=layoutoption, the compiler assumes only the following alias information:
fp->f1,bp->b1,cp->c1anddp->d1all can alias each other.fp->f2,bp->b2anddp->d2all can alias each other.fp->f1can aliascp->cf.f1anddp->db.b1.bp->b1can aliascp->cf.f1anddp->db.b1.fp->f2can aliascp->cf.f2anddp->db.b2.bp->b2can aliascp->cf.f2anddp->db.b2.If Example 4 is compiled with the
-xalias_level=strictoption, the compiler assumes only the following alias information:
fp->f1andbp->b1can alias each other.fp->f2andbp->b2can alias each other.fp->f1can aliascp->cf.f1anddp->db.b1.bp->b1can aliascp->cf.f1anddp->db.b1.fp->f2can aliascp->cf.f2anddp->db.b2.bp->b2can aliascp->cf.f2anddp->db.b2.If Example 4 is compiled with the
-xalias_level=stdoption, the compiler assumes only the following alias information:
fp->f1can aliascp->cf.f1.bp->b1can aliasdp->db.b1.fp->f2can aliascp->cf.f2.bp->b2can aliasdp->db.b2.Example 5
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:
- If Example 5 is compiled with the
-xalias_level=weakoption,fp->f3andbp->b2can alias each other.- If Example 5 is compiled with the
-xalias_level=layoutoption, no fields can alias each other.- If Example 5 is compiled with the
-xalias_level=strictoption,fp->f3andbp->b2can alias each other.- If Example 5 is compiled with the
-xalias_level=stdoption, no fields can alias each other.Example 6
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:
- If Example 6 is compiled with the
-xalias_level=weakoption, onlyfp->ffpandbp->bbpcan alias each other.- If Example 6 is compiled with the
-xalias_level=layoutoption, onlyfp->ffpandbp->bbpcan alias each other.- If Example 6 is compiled with the
-xalias_level=strictoption, no fields can alias because the two struct types are still different even after their tags are removed.- If Example 6 is compiled with the
-xalias_level=stdoption, no fields can alias because the two types and the tags are not the same.Example 7
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
fooandbarare allowed to alias each other. The compiler makes the following assumptions about alias information:
fp->f1can alias withbp->b1,bp->b2, andbp->b3fp->f2can alias withbp->b1,bp->b2, andbp->b3
|
Sun Microsystems, Inc. Copyright information. All rights reserved. Feedback |
Library | Contents | Previous | Next | Index |