Optimizer Pragmas

By default, the optimizer assumes that all functions might modify global variables. To some degree, this assumption limits the extent of optimizations it can perform on global variables. The NO_SIDE_EFFECTS pragma provides a way to override this assumption. If you know for certain that some functions do not modify global variables, you can gain further optimization of code containing calls to these functions by specifying the function names in this pragma.

NO_SIDE_EFFECTS has the following form:

#pragma NO_SIDE_EFFECTS functionname(1), ..., functionname(n)

All functions in functionname are the names of functions that do not modify the values of global variables. Global variable references can be optimized to a greater extent in the presence of calls to the listed functions. Note that you need the NO_SIDE_EFFECTS pragma in the files where the calls are made, not where the function is defined. This pragma takes effect from the line it first occurs on to the end of the file.

The ALLOCS_NEW_MEMORY pragma states that the function functionname returns a pointer to new memory that it either allocates or a routine that it calls allocates. ALLOCS_NEW_MEMORY has the following form:

#pragma ALLOCS_NEW_MEMORY functionname(1), ..., functionname(n)

The new memory must be memory that was either newly allocated or was previously freed and is now reallocated. For example, the standard routines malloc() and calloc() satisfy this requirement.

Large applications might have routines that are layered above malloc() and calloc(). These interface routines make the calls to malloc() and calloc(), initialize the memory, and return the pointer that malloc() or calloc() returns. For example, in the program below:

struct_type *get_new_record(void)
   {
   struct_type *p;
 
   if ((p=malloc(sizeof(*p))) == NULL) {
        printf("get_new_record():out of memory\n");
        abort();
        }
   else {
        /* initialize the struct */
        .
        .
        .
        return p;
        }

the routine get_new_record falls under this category, and can be included in the ALLOCS_NEW_MEMORY pragma.

Informs the compiler that the function(s) may enable floating-point trap handling. When the compiler is so informed, it will not perform loop invariant code motion (LICM) on floating-point operations in the function(s) named in the pragma. This pragma is required for proper code generation when floating-point traps are enabled.

#pragma FLOAT_TRAPS_ON { functionname,...functionname }
#pragma FLOAT_TRAPS_ON { _ALL }

For example:

#pragma FLOAT_TRAPS_ON xyz,abc

informs the compiler and optimizer that xyz and abc have floating-point traps turned on and therefore LICM optimization should not be performed.

The PTRS_STRONGLY_TYPED pragma allows you to specify when a subset of types are type-safe. This provides a finer lever of control than +O[no]ptrs_strongly_typed.

#pragma PTRS_STRONGLY_TYPED BEGIN
 
#pragma PTRS_STRONGLY_TYPED END
 
#pragma NOPTRS_STRONGLY_TYPED BEGIN
 
#pragma NOPTRS_STRONGLY_TYPED END

Any types that are defined between the begin-end pair are taken to apply type-safe assumptions. These pragmas are not allowed to nest. For each BEGIN an associated END must be defined in the compilation unit.

The pragma will take precedence over the command-line option. Although, sometimes both are required (see example 2).

Example 1

double *d;
#pragma PTRS_STRONGLY_TYPED BEGIN
int *i;
float *f;
#pragma PTRS_STRONGLY_TYPED END
main(){
  .  .  .
}

In this example only two types, pointer-to-int and pointer-to-float will be assumed to be type-safe.

Example 2

cc +Optrs_strongly_typed foo.c
 
/*source for Ex.2 */
double *d;
  ...
#pragma NOPTRS_STRONGLY_TYPED BEGIN
int *i;
float *f;
#pragma NOPTRS_STRONGLY_TYPED END
  ...
main(){
  ...
}

In this example all types are assumed to be type-safe except the types bracketed by pragma NOPTRS_STRONGLY_TYPED. The command-line option is required because the default option is +Onoptrs_strongly_typed.