| Name | Description |
|---|---|
| #pragma disjoint | Lists identifiers that do not share the same physical storage, which provides more opportunities for optimizations. |
| #pragma execution_frequency (C++ only) | Marks program source code that you expect will be either very frequently or very infrequently executed. |
| #pragma export | Selectively exports functions or variables from a DLL module. The EXPORTALL compiler option exports all functions or variables, which often results in larger modules and significantly increased WSA requirements. |
| #pragma inline (C only) | Together with the INLINE compiler option, ensures that frequently used functions are inlined. This directive is only supported in C; however, you can use the inline keyword in C++. |
| #pragma isolated_call | Lists functions that have no side effects (that do not modify global storage). This directive can improve the runtime performance of variables and storage by allowing the compiler to make fewer assumptions about whether external and static variables could be updated. |
| #pragma leaves | Specifies that a function never returns to the instruction following a call to that function. This directive provides information to the compiler that enables it to explore additional opportunities for optimization. |
| #pragma noinline | This directive can improve pipeline usage and allow more of the used routines to be inlined. |
| #pragma option_override | Allows
you to specify optimization options on a per-routine basis rather
than on only a per-compilation basis. It enables you to specify which
functions you do not want to optimize while compiling the rest of
the program optimized. This directive helps you to isolate which function
is causing problems under optimization. The option_override pragma
can be also used to change the spill size for a function. If the compiler
requests that you to increase the spill size for a specific function,
you should use the option_override pragma instead
of the SPILL compiler option, which increases the spill size for all
functions in the compile unit and can have a negative performance
impact on the generated code.
Note: The spill size should not be
increased unless requested by a compiler message.
|
| #pragma reachable | Declares that the point in the program after the specified function can be the target of a branch from some unknown location. That is, you can reach the instruction after the specified function from a point in your program other than the return statement in the named function. This directive provides information to the compiler that enables it to explore additional opportunities for optimization. |
| #pragma strings | Indicates if strings should be placed in read-only memory or read/write memory. You can reduce the memory requirements for DLLs by specifying #pragma strings(readonly), so that string literals are not placed in the writable static area. Alternatively, you can also use the ROSTRING compiler option (the default), which informs the compiler that string literals are read-only. |
| #pragma unroll | Informs the compiler how to perform loop unrolling on the loop body that immediately follows it. The directive works in conjunction with the UNROLL compiler option to provide you with some control over the application of this optimization techique. The pragma directive overrides the UNROLL or NOUNROLL compiler option in effect for the designated loop. |
| #pragma variable | Indicates if a named external object is used in
reentrant or non-reentrant fashion. If an object is qualified as RENT,
its references or its definition will be in the writable static area,
which is in modifiable storage. If an object is qualified as NORENT,
its references or its definition will be in the code area. You can reduce the memory requirements for DLLs by specifying #pragma variable(var_name,NORENT), so that constant variables are not placed in the writable static area. Alternatively, you can use the ROCONST compiler option to inform the compiler that constant variables are not to be placed in the writable static area. |