KAP assertions enable the programmer to provide KAP with information about the program that would not normally be known at compilation time. Although many KAP users run the product without assertions, sometimes assertions can improve the optimization results. Use assertions only where speed is essential and you understand the application program well.
KAP does not guarantee that an assertion will have an effect. KAP notes the information provided by the assertion, and if that information helps, KAP uses it.
To understand the process KAP uses in interpreting assertions,
it is necessary to understand "assumed dependencies." In the
following loop, where X
is an array, n
and m
are scalars, and nothing is known about the
relationship between n
and m
, there are
two types of dependencies:
DO 10 i=1,n 10 X(i) = X(i-1) + X(m)
Between X(i)
and X(i-1)
there is a
FORWARD dependence, and the distance is known to be one. Between
X(i)
and X(m)
, KAP tries to find
a relation, but cannot, since it does not know the value of
m
in relation to n
. The second dependence
is called an ASSUMED dependence, because it is assumed but cannot be
proven to exist.
Assertions can be unsafe, because KAP cannot check the correctness
of the information provided. If you specify an incorrect assertion,
then the KAP generated code may give very different results than the
original program. If unsafe assertions are the suspected cause of
a misbehaving program, you can tell KAP to ignore all assertions
by using the -directives
command switch without
the a
value or the C*$* no assertions
directive.
As with directives, an assertion placed before any comments or
statements in the program is treated as a global assertion. That
is, it is treated as if it were repeated at the top of each program
unit in the file. Some assertions, such as C*$* assert
relation
or C*$* assert permutation
, include
variable names. If these are specified as global assertions, the
assertion is used in a program only when those variable names appear
in common blocks or are dummy argument names to the subprogram.
Global assertions cannot be used to make relational or permutation
assertions about variables that are local to a subprogram.
Many assertions, like directives, are active until the end of the program or until overridden by another assertion. Other assertions are in effect only for the DO loops before which they appear. This type of assertion would apply to the next DO loop, but not to its nested loops. Other assertions are active within a program unit, regardless of where they appear in that program unit.
You can apply assertions collectively to a series of loops by
enlosing them in a directive block. Since KAP treats the directive
block as one loop, the assertions you want to be active on the
loops inside the block must immediately precede the C*$*
beginblock
directive. Assertions immediately preceding
directive blocks override previously set directives and assertions
for the duration of the block, as follows:
Program Unit A C*$* directive | | C*$* assertion | | C*$* beginblock | | loop | | loop | | loop | | loop | ->C*$* endblock | -> End