Hacking vs Feature Request to Compiler

Posted Oct 11, 2024 19:03 UTC (Fri) by rywang014 (subscriber, #167182)
Parent article: FFI type mismatches in Rust for Linux

Sounds like this "LTO only for C called in Rust" is totally doable on LLVM end, but nobody had that need before so there isn't a feature for it. Instead of hacking around LLVM bytecode, IR manipulation and flags, why don't we make a feature request to LLVM (and later GCC) to do it for R4L?

Something I can think of: mark the helpers.o symbols as "inline only". When linking: any objects referencing those symbols are force-LTO'ed; and after all linkings, delete those text and symbols.

Hacking vs Feature Request to Compiler

Posted Oct 12, 2024 2:20 UTC (Sat) by garyguo (subscriber, #173367) [Link] (1 responses)

> Something I can think of: mark the helpers.o symbols as "inline only". When linking: any objects referencing those symbols are force-LTO'ed; and after all linkings, delete those text and symbols.

From LLVM IR level, inlinehint + linkonce_odr is essentially what you have described. It gets inlined during LTO, and unused functions get deleted without codegen functions get discarded without codegen. If LLVM heurstics decides not to inline something, the function gets emitted with weak linkage (if one doesn't want the heurstics, then replace inlinehint with alwaysinline).

It's just you cannot tweak clang to generate this combination. It was attempted previously: https://reviews.llvm.org/D18095, but it was rejected and the advice is keep post-processing IR.

Hacking vs Feature Request to Compiler

Posted Oct 13, 2024 4:10 UTC (Sun) by rywang014 (subscriber, #167182) [Link]

Now that we have a concrete use case can we pursue for a native LLVM support again?