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:
Christopher Haster
2025-02-05 01:08:19 -06:00
parent 4d02e5d646
commit b551569206
2 changed files with 21 additions and 9 deletions
+10
View File
@@ -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