Type-based alias analysis and lint

Type-based alias analysis and lint
----------------------------------------------

Type-based alias analysis, enabled via the -xalias_level compiler option, can significantly improve optimizations performed by the compiler. The levels of aliasing that can be specified with this option specify certain properties about the way pointers are used in a C program. These "properties" range from assuming all memory references can alias each other (alias_level=any, the default) to a set of specific properties (specified under -alias_level=strong at the highest level) that broaden the assumptions the compiler can make about data references.

While alias levels and type-based alias analysis are all very well and good, a tool to assist in determining what potential aliasing may exist in a given program would simplify their use, especially when first considering type-based alias analysis for a particular program. Fortunately, there is a tool for this purpose: lint. Recognition of certain types of aliasing was added to lint (the traditional C program verifier as enhanced by Sun) at the same type as alias analysis was added to the C compiler.

Alias levels are specified to lint via the same option that is used with the C compiler, with the exception that the initial letter of the option is a capital 'X' instead of a lower case 'x'. For example, to specify an alias level of basic while using lint, you would use '-Xalias_level=basic'.

So, what does lint do that is of any value? Currently, it can aid in the diagnosis of certain situations in which assumptions specified by a given alias level are potentially violated or where more clarification is need than that which is available within the context of the source. An appropriate warning or error is generated when these situations are detected.

There are four cases that lint detects and for which it generates either a warning or an error:

    \* Casting a scalar pointer to a struct pointer

    \* Casting a void pointer to a struct pointer

    \* Casting a structure field to a scalar pointer

    \* Casting a struct pointer to a struct pointer at the level of -Xalias_level=strict without explicit aliasing.


For example, consider the following source:

struct fooa {
    int a;
    int b;
};

struct foob {
    int a;
    float b;
};

struct fooa \*f1;
struct foob \*f2;

void main()

{
    f1 = (struct fooa \*)f2;
}

Notice that we have a struct pointer assigned to another struct pointer where the two structs are identical (i.e., the same size) except for the tags associated with the individual struct fields. At alias level strict (or higher), lint issues a warning for the assignment:

(XX) warning: cast of struct pointer to struct pointer requires explicit aliasing under alias_level=strict

Why? Because, according to the definition of alias_level strict,

"... the compiler assumes that memory references, that involve types such as structs or unions, that are the same when tags are removed, can alias each other. Conversely, the compiler assumes that memory references involving types that are not the same even after tags are removed do not alias each other."

Since the two structs involved are not the same after the tags are removed, the compiler assumes (by definition) that they do \*not\* alias. However, the explicit assignment of one pointer to the other violates this aliasing assumption, which then causes lint to generate the above warning. As a side note, since each alias level builds on the preceding level, any alias level higher than strict will generate the same warning.

To eliminate the aliasing warning, and the potential for any unexpected optimization issues related to aliasing when compiling, as the warning message states, use explicit aliasing. This is accomplished by using the aliasing pragma "alias" at some point in the source prior to the first reference to the associated structs. It would be specified as follows:

#pragma alias (f1,f2)

Remember to run lint at a level of aliasing that is no more strict (i.e., makes stronger claims about types and data \*not\* aliasing) than that which will be used for the actual compilation.

For a complete discussion of type-based alias analysis, options, and associated aliasing pragmas, see chapter 5 of the Sun C User's Guide.

Bottom line: Try using type-based alias analysis to improve your program's performance, and try out lint's ability to detect and warn about potential aliasing problems up front.
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

dpagan

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today