Adopted LFS_FORCEINLINE
May revisit this in the future, but this is the best solution I can think of right now, that doesn't run into duplicate macro-argument side-effect issues... Statement expressions would be another solution, but that's even less portable! At the moment this is only used for functions that implement LFSR_DATA_* and LFSR_RAT_* macros. These _need_ to be inlined to avoid a large code-size explosion, and GCC seems to have issues with this. For most of the other inlinable functions, relying on C99's inline + compiler heuristics seems to be fine. Code changes: before: 36304 2576 640 no-forceinline: 36460 (+0.4%) 2664 (+3.4%) 640 (+0.0%) yes-forceinline: 36300 (-0.0%) 2576 (+0.0%) 640 (+0.0%)
This commit is contained in:
+10
@@ -229,6 +229,16 @@ extern "C"
|
||||
#endif
|
||||
|
||||
|
||||
// Some function attributes, no way around these
|
||||
|
||||
// Force a function to be inlined
|
||||
#if !defined(LFS_NO_BUILTINS) && defined(__GNUC__)
|
||||
#define LFS_FORCEINLINE __attribute__((always_inline))
|
||||
#else
|
||||
#define LFS_FORCEINLINE
|
||||
#endif
|
||||
|
||||
|
||||
// Builtin functions, these may be replaced by more efficient
|
||||
// toolchain-specific implementations. LFS_NO_BUILTINS falls back to a more
|
||||
// expensive basic C implementation for debugging purposes
|
||||
|
||||
Reference in New Issue
Block a user