|
|||
| Products Download Events Support Videos | |||
Technical Support
On-Line Manuals
Compiler User Guide
Conventions and Feedback
Overview of the Compiler
Getting Started with the Compiler
Compiler Features
Compiler Coding Practices
The compiler as an optimizing compiler
Compiler optimization for code size versus speed
Compiler optimization levels and the debug view
Selecting the target CPU at compile time
Optimization of loop termination in C code
Loop unrolling in C code
Compiler optimization and the volatile keyword
Code metrics
Code metrics for measurement of code size and data
Stack use in C and C++
Benefits of reducing debug information in objects
Methods of reducing debug information in objects a
Guarding against multiple inclusion of header file
Methods of minimizing function parameter passing o
Functions that return multiple values through regi
Functions that return the same result when called
Comparison of pure and impure functions
Recommendation of postfix syntax when qualifying f
Inline functions
Compiler decisions on function inlining
Automatic function inlining and static functions
Inline functions and removal of unused out-of-line
Automatic function inlining and multifile compilat
Restriction on overriding compiler decisions about
Compiler modes and inline functions
Inline functions in C++ and C90 mode
Inline functions in C99 mode
Inline functions and debugging
Types of data alignment
Advantages of natural data alignment
Compiler storage of data objects by natural byte a
Relevance of natural data alignment at compile tim
Unaligned data access in C and C++ code
The __packed qualifier and unaligned data access i
Unaligned fields in structures
Performance penalty associated with marking whole
Unaligned pointers in C and C++ code
Unaligned Load Register (LDR) instructions generat
Comparisons of an unpacked struct, a __packed stru
Compiler support for floating-point arithmetic
Default selection of hardware or software floating
Example of hardware and software support differenc
Vector Floating-Point (VFP) architectures
Limitations on hardware handling of floating-point
Implementation of Vector Floating-Point (VFP) supp
Compiler and library support for half-precision fl
Half-precision floating-point number format
Compiler support for floating-point computations a
Types of floating-point linkage
Compiler options for floating-point linkage and co
Floating-point linkage and computational requireme
Processors and their implicit Floating-Point Units
Integer division-by-zero errors in C code
About trapping integer division-by-zero errors wit
About trapping integer division-by-zero errors wit
Identification of integer division-by-zero errors
Examining parameters when integer division-by-zero
Software floating-point division-by-zero errors in
About trapping software floating-point division-by
Identification of software floating-point division
Software floating-point division-by-zero debugging
New language features of C99
New library features of C99
// comments in C99 and C90
Compound literals in C99
Designated initializers in C99
Hexadecimal floating-point numbers in C99
Flexible array members in C99
__func__ predefined identifier in C99
inline functions in C99
long long data type in C99 and C90
Macros with a variable number of arguments in C99
Mixed declarations and statements in C99
New block scopes for selection and iteration state
_Pragma preprocessing operator in C99
Restricted pointers in C99
Additional <math.h> library functions in C99
Complex numbers in C99
Boolean type and <stdbool.h> in C99
Extended integer types and functions in <inttyp
<fenv.h> floating-point environment access i
<stdio.h> snprintf family of functions in C9
<tgmath.h> type-generic math macros in C99
<wchar.h> wide character I/O functions in C9
How to prevent uninitialized data from being initi
Compiler Diagnostic Messages
Using the Inline and Embedded Assemblers of the AR
Compiler User Guide
Compiler decisions on function inlining
| |||
| Home > Compiler Coding Practices > Compiler decisions on function inlining | |||
When function inlining is enabled, the compiler uses a complex decision tree to decide if a function is to be inlined.
The following simplified algorithm is used:
If the function is qualified with
__forceinline, the function is inlined if it is possible to do so.If the function is qualified with
__inlineand the option--forceinlineis selected, the function is inlined if it is possible to do so.If the function is qualified with
__inlineand the option--forceinlineis not selected, the function is inlined if it is practical to do so.If the optimization level is
-O2or higher, or--autoinlineis specified, the compiler automatically inlines functions if it is practical to do so, even if you do not explicitly give a hint that function inlining is wanted.
When deciding if it is practical to inline a function, the compiler takes into account several other criteria, such as:
the size of the function, and how many times it is called
the current optimization level
whether it is optimizing for speed (
-Otime) or size (-Ospace)whether the function has external or static linkage
how many parameters the function has
whether the return value of the function is used.
Ultimately, the compiler can decide not to inline a function,
even if the function is qualified with __forceinline.
As a general rule:
smaller functions stand a better chance of being inlined
compiling with
-Otimeincreases the likelihood that a function is inlinedlarge functions are not normally inlined because this can adversely affect code density and performance.
A recursive function is inlined into itself only once, even
if __forceinline is used.
See also- Concepts
- Reference
| Copyright © 2007-2008, 2011-2012 ARM. All rights reserved. | ARM DUI 0375D |
| Non-Confidential | ID062912 |
 PDF version | |
| Home > Compiler Coding Practices > Compiler decisions on function inlining |
ProductsDevelopment Tools |
Hardware & Collateral |
Downloads |
Support |
Buy |
|
 |
|||
