 RealView Compiler User's Guide | |
| Home Products Events Support | |
On-Line Manuals
RealView Compiler User's Guide
Preface Introduction Getting started with the ARM Compiler Compiler Features Coding Practices Optimizing code
Optimizing for size versus speed Optimization levels and the debug view Selecting the target device Optimizing loops Using volatile Code metrics Measuring code and data sizes Measuring stack use Reducing debug information in objects and librarie Functions Minimizing parameter passing overhead __value_in_regs __pure Placing ARM function qualifiers Inlining How the compiler decides to inline When is it practical for the compiler to inline? Managing inlining Inlining functions across multiple files Debugging data and the --[no]_inline keyword Marking functions as static Setting breakpoints on inlined functions in ROM im Aligning data About data alignment The __packed qualifier and unaligned accesses to d __packed structures versus individually __packed f Using floating-point arithmetic Support for floating-point operations VFP architectures The --fpu option Floating-point linkage The --fpmode option Using the --fpu option VFP support Trapping and identifying division-by-zero errors Integer division (Software) Floating point division Support for ARM architecture v6 Instruction generation Alignment support Endian support Diagnostic Messages Using the Inline and Embedded Assemblers SemihostingMarking functions as static
  | |||
  |  | ||
| |||
| Home > Coding Practices > Inlining > Marking functions as static | |||
At the optimization levels -O2 and -O3, the compiler is able to automatically inline a function if it is sensible to do so, even when the function is not declared as __inline or inline.
Note
To control the automatic inlining of functions at higher optimization levels, use the --[no_]autoinline command-line option.
Unless a function is explicitly declared as static (or __inline), the compiler has to retain the out-of-line version of it in the object file in case it is called from some other module. The linker is unable to remove unused out-of-line functions from an object, unless unused out‑of‑line functions are placed into their own sections using linker feedback.
If you fail to declare functions that are never called from outside a module as static, your code can be adversely affected. In particular, you might have:
A larger code size, because out-of-line versions of functions are retained in the image.
When a function is inlined, both the in-line version and an out-of-line version of the function might end up in the final image, unless the function is declared as static. This might possibly increase code size.
An unnecessarily complicated debug view, because there are both inline versions and out-of-line versions of functions to display.
Retaining both inline and out-of-line copies of a function in code can sometimes be confusing when setting breakpoints or single-stepping in a debug view. The debugger has to display both in-line and out-of-line versions in its interleaved source view, so that you can see what is happening when stepping through either the in-line or out-of-line version.
Because of these problems, declare functions as static when you are sure that they can never be called from another module.
| Copyright © 2007 ARM Limited. All rights reserved. | ARM DUI 0375A |
 PDF version | |
| Home > Coding Practices > Inlining > Marking functions as static | |
| |
| Contact Site Map Press Privacy | Copyright © 2008 Keil™, An ARM® Company. All rights reserved. |
