From 17cefcdd423a9572fa7be0747093f89da23464b9 Mon Sep 17 00:00:00 2001 From: Christopher Haster Date: Wed, 16 Jul 2025 13:59:00 -0500 Subject: [PATCH] Dropped LFS3_FORCEINLINE from lfs3_data_slice This use to save code/stack, but apparently not anymore: code stack ctx before: 36960 2392 652 after: 36936 (-0.1%) 2384 (-0.3%) 652 (+0.0%) code stack ctx ckdatacksumreads before: 38368 2720 660 ckdatacksumreads after: 38024 (-0.9%) 2624 (-3.5%) 660 (+0.0%) The stack hot-path has changed significantly since then, with many functions adopting LFS3_NOINLINE to get off the stack hot-path. Not sure if that's related. I'm also starting to think LFS3_FORCEINLINE is a symptom of over-optimization. We shouldn't be doing the compilers job, if it can't figure out the best inlining strategy so be it. --- lfs3.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lfs3.c b/lfs3.c index 7b0c329c..8e0cfe20 100644 --- a/lfs3.c +++ b/lfs3.c @@ -1641,7 +1641,6 @@ static inline uint32_t lfs3_data_cksum(lfs3_data_t data) { #endif // data slicing -LFS3_FORCEINLINE static inline lfs3_data_t lfs3_data_slice(lfs3_data_t data, lfs3_ssize_t off, lfs3_ssize_t size) { // limit our off/size to data range, note the use of unsigned casts