[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 some old library programs written in assembly code.

[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 (for example, 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.

  The compiler ignores -xregs=frameptr and issues a warning

  if you also specify -xpg.

• ---

  Note –

  The compiler ignores -xregs=framptr and issues a warning if you also specify -xpg.

  ---