Closed MarkSwanson closed 8 years ago
libfringe's speed advantage comes entirely from inlining. This is literally the most core part of our implementation technique — ie this won't be merged. The LLVM assembler appears to be broken, and I'm okay with workarounds for that, but this defeats the very purpose of libfringe.
I submit to you that LLVM is smart enough to still inline - the benchmarks seem to imply this. Maybe because the Fn is small enough it meets some LLVM metric to inline anyway?
I'm hoping you're open to explaining in a bit more detail.
I'm guessing you're worried that because there is no explicit #[inline(always)] maybe LLVM won't auto-inline it after some future update? The metrics might change, Rustc might do something different...?
Thanks.
#[inline(always)]
precisely states our intentions here, so I'd rather keep it. If it still inlines without it, but the attribute causes it to behave differently, that's a rustc bug.
This seems to have fixed the relocation troubles that occur when building a dso with libfringe.