A.2.168 –xregs=r[,r...]
Controls scratch register usage.
The compiler can generate faster code if it has more registers available
for temporary storage (scratch registers). This option makes available additional
scratch registers that might not always be appropriate.
A.2.168.1 Values
r must be one of the following values. The
meaning of each value depends upon the -m32|-m64 setting.
Table A–46 The
-xregs Values
Values
|
Meaning
|
[no%]appl
|
(SPARC) [Does not] 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 increase performance because fewer load and store instructions are needed. However, such use can conflict with
programs that use the registers for other purposes.
|
[no%]float
|
(SPARC) [Does not] 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
use floating point types in any way.
|
[no%]frameptr
|
(x86) [Does not] Allow the compiler to use the
frame-pointer register (%ebp on IA32, %rbp on AMD64) as an unallocated callee-saves
register.
Using this register as an unallocated callee-saves register may improve
program run time. However, it also reduces the capacity of some tools to inspect
and follow the stack. This stack inspection capability is important for system
performance measurement and tuning. Therefor, using this optimization may improve local program
performance at the expense of global system performance.
-
Tools, such as the Performance Analyzer, that dump the stack
for postmortem diagnosis will not work.
-
Debuggers (adb, mdb, dbx)
will not be able to dump the stack or directly pop stack frames.
-
The dtrace performance analysis facility
will be unable to collect information on any frames on the stack before the
most recent frame missing the frame pointer.
-
Posix pthread_cancel will fail trying to
find cleanup handlers.
-
C++ exceptions cannot propagate through C functions.
The failures in C++ exceptions occur when a C function that has lost
its frame pointer calls a C++ function that throws an exception through the
C function. Such calls typically occur when a function accepts a function
pointer (for example, qsort) or when a global function,
such as malloc, is interposed upon.
The last
two affects listed above may impact the correct operation of applications.
Most application code will not encounter these problems. Libraries that are
developed by using -xO4, however, need documentation that
details the restrictions of their usage by their clients.
-
Note –
The compiler ignores -xregs=framptr and issues
a warning if you also specify -xpg. Also, the compiler ignores
this option for 32–bit x86 compilation unless exceptions are disabled
with -noex option.
|
Defaults
The SPARC default is -xregs=appl,float.
The x86 default is -xregs=no%frameptr -xregs=frameptr in included in the expansion of -fast.
Examples
To compile an application program using all available scratch registers,
use -xregs=appl,float.
To compile non-floating-point code that is sensitive to context switch,
use -xregs=no%appl,no%float.
See also
SPARC V8 and SPARC V9 ABI