This directive forces the loop immediately following it to be serial, and restricts optimization by forcing all enclosing loops to also be serial. The syntax for this directive is:

#pragma serial

PCA can still optimize loops that are inside the serial loop, but not enclosing the serial loop. Consider the code:

  for (i=0; i<N; i++)
    for (j=0; j<N; j++) {
#pragma serial
      for (k=0; k<N; k++)
         x[i][j][k] = x[i][j][k] * y[i][j];
      for (k=0; k<N; k++)
         x[i][j][k] = x[i][j][k] + z[i][k];
     }

The directive forces the i and j loops, and the first k loop to be serial. PCA can still optimize the second k loop, but it does not distribute (interchange) the i or j loops to try to get an optimizable loop. PCA always honors the #pragma serial directive. This directive is in effect only for the next loop.

Use the #pragma concurrent directive to tell PCA to ignore assumed dependences in the following loop. The syntax for this directive is:

#pragma concurrent

If the loop contains definite dependencies in addition to the assumed dependencies, PCA does not convert the loop to run in parallel. In this case, the example on the previous example would be left serial, because it has a known dependence.

---

Note: PCA does not generate code that executes in parallel (concurrently) if you use the –noconcurrentize command line option.

---

This directive is in effect only for the next loop.

Use the #pragma concurrent call directive to tell PCA that the function calls in the following loop are safe to execute in parallel.

The syntax for this directive is:

#pragma concurrent call

PCA ignores all potential data dependences due to the function argument(s). This directive applies only to the immediately following loop and not to any nested or surrounding loops. Put a #pragma concurrent call directive before each concurrentizable loop with function references. Be sure that the functions called do not introduce data dependencies.

A better way to concurrentize a loop with function calls is to use either #pragma no side effects or interprocedural analysis. IPA directs PCA to determine the true data dependencies and not rely on user assessment. IPA is explained in Chapter 7, “In-lining and Interprocedural Analysis.”

These pragmas tell PCA which values to use for chunksize, numthreads, and schedtype.

The syntax for each of these directives is:

#pragma set chunksize (n)
#pragma set numthreads (n)
#pragma set schedtype (type)

For chunksize, the range of values for n is 1 to 1,000,000. For numthreads, the range of values for n is 1 to 255. If PCA sees values larger than these, it will assume the maximum and generate a warning message. If PCA sees values smaller that 1, it will generate a warning message and ignore the pragma.

The schedtype types are:

Refer to xx #pragma parallel for a complete description of num-threads, and #pragma pfor for descriptions of chunksize and schedtype.

C functions frequently produce more information than just the returned value. Changing values of arguments via pointers or arrays, changing global data, and I/O can make a function unsafe to run concurrently.

The #pragma no side effects directive tells PCA to assume that all of the named functions are safe to execute concurrently. This means that the functions perform no I/O and that they modify only local variables.

The syntax for this directive is:

#pragma no side effects ( name [,name...] )

If you pass pointers or array names to the function and use this directive, PCA assumes that the memory locations they represent are not modified. The functions named must be declared before the directive.

Use #pragma arl (address resolution level) to control the assumptions PCA makes about memory aliases. The syntax for this directive is:

#pragma arl(n)

where n is the level of control. Table 4-2 describes the levels of control.

The directive has the same meaning as the –arl command-line option. See Chapter 3, “PCA Command-Line Options” for more information on this option and the levels of control.

When this directive appears inside a function (between the outer { and } of a function definition), it applies only to that function. If the directive appears outside a function, it sets the default value to be used for all functions that follow.

The command-line option is equivalent to a pragma at the beginning of the file and is thus overridden by other #pragma arl directives in the file.

Use #pragma distinct to indicate that two objects do not overlap.

The syntax for this directive is:

#pragma distinct (expr1,expr2[,expr3,expr4...])

where

expr1, expr2... represent objects.

The form of the expressions allowed is:

All variables involved must be previously declared. For example, for pointer p and array a, you can assert:

#pragma distinct (*p, a[])

if *p never overlaps with a[i] for any i used in the program.

The range of the directive is the function where it was made and all succeeding functions. If the assertion is made about local variables or parameters, it will have no effect beyond the immediate function. These variables cannot be used outside the immediate function.

Use the inline and ipa directives to select manually which function(s) to in-line or perform interprocedural analysis on and at which call sites. The syntax is:

#pragma [no]inline [here][routine][global] [( name[,name...])]
#pragma [no]ipa [here][routine][global] [( name[,name...])]

If either of these directives appears with a name list, all occurrences of the named functions will be in-lined/analyzed, if possible, in all references within the scope of the directive. If the directive appears without a list of functions, all function references are eligible. (See Chapter 7, “In-lining and Interprocedural Analysis” for more information about these pragmas.)

The no forms turn off in-lining and IPA of the named function(s). The scope keywords are interpreted as:

You can terminate the routine and global scopes by the corresponding no directives. (Or terminate a noinline directive with an appropriate inline directive.)

These pragmas can override the –inline, –ipa, –inline_looplevel, and –ipa_looplevel command-line options. You can use #pragma inline and #pragma ipa in addition to, or in place of, command-line controlled in-lining/interprocedural analysis.

---

Note: The inline_man or ipa_man command-line option must be specified for the corresponding directive to be enabled (see Chapter 7, “In-lining and Interprocedural Analysis” for more information).

---

PCA supports two memory management directives, #pragma padding and #pragma storage order. PCA uses these output directives to pass information on data layout to the compiler or to itself (if you are using PCA to process a program interactively). If PCA processes a program more than once, it will use the information in the directives inserted in previous runs to direct its cache usage optimizations.

#pragma padding (variable1 [, variable2 …])

#pragma storage order (variable1 [, variable2 …])

   float a1[100], a2[3], a3[200]
#pragma storage order (a1,a2,a3)

   double _Kdd13[770];
   double _Kdd14[770];
#pragma padding(_Kdd14, _Kdd13)
#pragma storage order(c, _Kdd13, b, _Kdd14, a)

When dealing with elements of linked lists, PCA allows you to parallelize:

Two pragmas support these two cases: #pragma plist, and #pragma ordered.

#pragma plist unordered (list vars.; initialize shared;  initialize
local; condition; increment) for (initialize shared, initialize
local; condition; increment)
{
   ... /* loop body */
}

#pragma ordered

Syntax:

#pragma plist ordered (list vars.; initialize shared; initialize local; condition; increment) for (initialize shared, initialize local; condition; increment) { ... /* unordered loop body 1 */ #pragma ordered { ... /* ordered loop body */ } ... /* unordered loop body 2 */ }

---

Note: For both the above cases, the increment operation can be performed anywhere without any side effect other than that of modification of the loop variable.

---

The following example shows an unordered loop, which uses #pragma plist unordered, and an ordered loop, which uses #pragma ordered.

#define N 100 #define LOOP 10 #define ERROR 5 typedef struct st_1 *sptr; struct st_1 { sptr next; int data; }; sptr head; main () { sptr list = 0; double sum2; int cnt; int i, j, k, t; double sum1; double psum; int pcnt; int error = 0; head = (sptr) malloc (sizeof (struct st_1)); head->data = N; for (list = head, i = 1; i < N; i++) { list->next = (sptr) malloc (sizeof (struct st_1)); list = list->next; list->data = (N - i); } list->next = 0; sum1 = 0; for (list = head, i = 0; list; i++, list = list->next) { if (list->data != N - i) { printf ("Mismatch: i = %d, data = %d\n", i, list->data); break; } sum1 += list->data; } printf ("SUM1 = %le\n", sum1); for (i = 0; (i < LOOP) && (error < ERROR); i++) { sum2 = 0; cnt = 0; #pragma parallel shared (list, head, sum2, cnt) local (psum, pcnt, t) { #pragma plist ordered (list; list=head, sum2 = 0, cnt = 0; psum = 0, pcnt = 0; list; list = list->next;) for (list= head, sum2 = 0, cnt = 0, psum = 0, pcnt = 0; list; list = list->next) { #pragma ordered { pcnt++; psum += list->data; } } #pragma critical { sum2 += psum; cnt += pcnt; printf ("sum2 = %le, psum = %le, pcnt = %d\n", sum2, psum, pcnt); } } if (sum2 != sum1) { error++; printf ("ERROR: i = %d, count = %d, SUM2 = %le\n",i, cnt, sum2); } printf ("\n"); } }