Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
E77790.pdf
Скачиваний:
2
Добавлен:
16.05.2024
Размер:
1.29 Mб
Скачать

3.4 Options Reference

needed, because data stored there by the compiler cannot be restored except by recompilation.

Example [1]: if object files for one or more programs are compiled with -xprofile=tcov:/test/profdata, a directory named /test/

profdata.profile will be created by the compiler and used to store data describing the profiled object files. The same directory will also be used at execution time to store execution data associated with the profiled object files.

Example [2]: if a program named myprog is compiled with - xprofile=tcov and executed in the directory /home/joe, the directory /home/joe/myprog.profile will be created at run time and used to store runtime profile data.

3.4.172 –xprofile_ircache[=path]

(SPARC) Save and reuse compilation data between collect and use profile phases.

Use with -xprofile=collect|use to improve compilation time during the use phase by reusing compilation data saved from the collect phase.

If specified, path will override the location where the cached files are saved. By default, these files will be saved in the same directory as the object file. Specifying a path is useful when the collect and use phases happen in two different places.

A typical sequence of commands might be:

demo% f95 -xO5 -xprofile=collect -xprofile_ircache t1.c t2.c demo% a.out collects feedback data

demo% f95 -xO5 -xprofile=use -xprofile_ircache t1.c t2.c

With large programs, compilation time in the use phase can improve significantly by saving the intermediate data in this manner. But this will be at the expense of disk space, which could increase considerably.

3.4.173 –xprofile_pathmap=collect_prefix:use_prefix

(SPARC) Set path mapping for profile data files.

Use the -xprofile_pathmap option with the -xprofile=use option.

154 Oracle Developer Studio 12.6: Fortran User's Guide • July 2017

3.4 Options Reference

Use -xprofile_pathmap when the compiler is unable to find profile data for an object file that is compiled with -xprofile=use, and:

You are compiling with -xprofile=use into a directory that is not the directory used when previously compiling with -xprofile=collect.

Your object files share a common basename in the profile but are distinguished from each other by their location in different directories.

The collect-prefix is the prefix of the UNIX pathname of a directory tree in which object files were compiled using -xprofile=collect.

The use-prefix is the prefix of the UNIX pathname of a directory tree in which object files are to be compiled using -xprofile=use.

If you specify multiple instances of -xprofile_pathmap, the compiler processes them in the order of their occurrence. Each use-prefix specified by an instance of -xprofile_pathmap is compared with the object file pathname until either a matching use-prefix is identified or the last specified use-prefix is found not to match the object file pathname.

3.4.174 –xrecursive

Allow routines without RECURSIVE attribute call themselves recursively.

Normally, only subprograms defined with the RECURSIVE attribute can call themselves recursively.

Compiling with -xrecursive enables subprograms to call themselves, even if they are not defined with the RECURSIVE attribute. But, unlike subroutines defined RECURSIVE, use of this flag does not cause local variables to be allocated on the stack by default. For local variables to have separate values in each recursive invocation of the subprogram, compile also with - stackvar to put local variables on the stack.

Indirect recursion (routine A calls routine B which then calls routine A) can give inconsistent results at optimization levels greater than -xO2. Compiling with the -xrecursive flag guarantees correctness with indirect recursion, even at higher optimization levels.

Compiling with -xrecursive can cause performance degradations.

3.4.175 –xreduction

Synonym for -reduction.

Chapter 3 • Fortran Compiler Options

155

3.4 Options Reference

3.4.176 –xregs=r

Specifies the usage of registers for the generated code.

r is a comma-separated list that consists of one or more of the following sub-options: appl, float,frameptr.

Prefixing a sub-option with no% disables that sub-option.

Note that —xregs sub-options are restricted to specific hardware platforms.

Example: -xregs=appl,no%float

TABLE 22

The -xregs Sub-options

 

 

 

Value

 

Meaning

 

 

 

appl

 

(SPARC) Allow the compiler to generate code using the application registers as scratch

 

 

registers. The application registers are:

 

 

g2, g3, g4 (on 32–bit platforms)

 

 

g2, g3 (on 64–bit platforms)

 

 

It is strongly recommended that all system software and libraries be compiled using

 

 

-xregs=no%appl. System software (including shared libraries) must preserve these

 

 

registers’ values for the application. Their use is intended to be controlled by the

 

 

compilation system and must be consistent throughout the application.

 

 

In the SPARC ABI, these registers are described as application registers. Using these

 

 

registers can improve performance because fewer load and store instructions are needed.

 

 

However, such use can conflict with some old library programs written in assembly code.

 

 

 

float

 

(SPARC) Allow the compiler to generate code by using the floating-point registers as

 

 

scratch registers for integer values. Use of floating-point values may use these registers

 

 

regardless of this option. If you want your code to be free of all references to floating

 

 

point registers, you need to use -xregs=no%float and also make sure your code does not

 

 

in any way use floating point types.

 

 

 

frameptr

 

(x86) Allow the compiler to use the frame-pointer register (%ebp on IA32, %rbp on

 

 

AMD64) as a general-purpose register.

 

 

The default is -xregs=no%frameptr

 

 

With -xregs=framptr the compiler is free to use the frame-pointer register to improve

 

 

program performance. However, some features of the debugger and performance

 

 

measurement tools may be limited as a result. Stack tracing, debuggers, and performance

 

 

analyzers cannot report on functions compiled with —xregs=frameptr

 

 

Mixed C, Fortran, and C++ code should not be compiled with —xregs=frameptr if a

 

 

C++ function, called directly or indirectly from a C or Fortran function, can throw an

 

 

exception. If compiling such mixed source code with —fast, add —xregs=no%frameptr

 

 

after the —fast option on the command line.

156 Oracle Developer Studio 12.6: Fortran User's Guide • July 2017

3.4 Options Reference

Value

Meaning

 

 

 

With more available registers on 64–bit platforms, compiling with —xregs=frameptr has

 

a better chance of improving 32–bit code performance than 64–bit code.

 

The compiler ignores -xregs=frameptr and issues a warning if you also specify -pg.

 

Also, -xkeepframe overrides -xregs=frameptr.

 

 

The SPARC default is -xregs=appl,float.

The x86 default is -xregs=no%frameptr. -xregs=frameptr in included in the expansion of - fast.

It is strongly recommended that you compile code intended for shared libraries that will link with applications, with -xregs=no%appl,float. At the very least, the shared library should explicitly document how it uses the application registers so that applications linking with those libraries are aware of these register assignments.

For example, an application using the registers in some global sense (such as using a register to point to some critical data structure) would need to know exactly how a library with code compiled without -xregs=no%appl is using the application registers in order to safely link with that library.

On x86 systems, -pg is incompatible with -xregs=frameptr, and these two options should not be used together. Note also that -xregs=frameptr is included in -fast.

3.4.177 -xs[={yes|no}]

(Oracle Solaris) Link debug information from object files into executable.

-xs is the same as -xs=yes.

The default is -xs=yes.

This option controls the trade-off of executable size versus the need to retain object files in order to debug. For dwarf, use -xs=no to keep the executable small but depend on the object files. This option has almost no effect on dbx performance or the runtime per formance of the program.

When the compile command forces linking (that is, -c is not specified) there will be no object file(s) and the debug information must be placed in the executable. In this case, -xs=no (implicit or explicit) will be ignored.

The feature is implemented by having the compiler adjust the section flags and/or section names in the object file that it emits, which then tells the linker what to do for that object file's

Chapter 3 • Fortran Compiler Options

157

Соседние файлы в предмете Информационные и сетевые технологии