Alice Ryhl <[email protected]> writes: > From: Gary Guo <[email protected]> > > Because of LLVM inling checks, it's generally not possible to inline a C > helper into Rust code, even with LTO: > > * LLVM doesn't want to inline functions compiled with > `-fno-delete-null-pointer-checks` with code compiled without. The C > CGUs all have this enabled and Rust CGUs don't. Inlining is okay since > this is one of the hardening features that does not change the ABI, > and we shouldn't have null pointer dereferences in these helpers. > > * LLVM doesn't want to inline functions with different list of builtins. C > side has `-fno-builtin-wcslen`; `wcslen` is not a Rust builtin, so > they should be compatible, but LLVM does not perform inlining due to > attributes mismatch. > > * clang and Rust doesn't have the exact target string. Clang generates > `+cmov,+cx8,+fxsr` but Rust doesn't enable them (in fact, Rust will > complain if `-Ctarget-feature=+cmov,+cx8,+fxsr` is used). x86-64 > always enable these features, so they are in fact the same target > string, but LLVM doesn't understand this and so inlining is inhibited. > This can be bypassed with `--ignore-tti-inline-compatible`, but this > is a hidden option. > > To fix this, we can add __always_inline on every helper, which skips > these LLVM inlining checks. For this purpose, introduce a new > __rust_helper macro that needs to be added to every helper. > > The actual additions of __rust_helper can happen in separate patches. A > "flag day" change is not required since missing annotations do not lead > to anything worse than missing inlining. > > Signed-off-by: Gary Guo <[email protected]> > Signed-off-by: Alice Ryhl <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]> Best regards, Andreas Hindborg
