On Fri, Dec 08, 2023 at 09:08:47AM -0800, Nick Desaulniers wrote: > On Fri, Dec 8, 2023 at 8:19 AM Miguel Ojeda > <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > > > On Fri, Dec 8, 2023 at 6:28 AM comex <comexk@xxxxxxxxx> wrote: > > > > > > Regarding the issue of wrappers not being inlined, it's possible to get LLVM to optimize C and Rust code together into an object file, with the help of a compatible Clang and LLD: > > > > > > @ rustc -O --emit llvm-bc a.rs > > > @ clang --target=x86_64-unknown-linux-gnu -O2 -c -emit-llvm -o b.bc b.c > > > @ ld.lld -r -o c.o a.bc b.bc > > > > > > Basically LTO but within the scope of a single object file. This would be redundant in cases where kernel-wide LTO is enabled. > > > > > > Using this approach might slow down compilation a bit due to needing to pass the LLVM bitcode between multiple commands, but probably not very much. > > > > > > Just chiming in as someone not involved in Rust for Linux but familiar with these tools. Perhaps this has been considered before and rejected for some reason; I wouldn’t know. > > > > Thanks comex for chiming in, much appreciated. > > > > Yeah, this is what we have been calling the "local-LTO hack" and it > > was one of the possibilities we were considering for non-LTO kernel > > builds for performance reasons originally. I don't recall who > > originally suggested it in one of our meetings (Gary or Björn > > perhaps). > > > > If LLVM folks think LLVM-wise nothing will break, then we are happy to > > On paper, nothing comes to mind. No promises though. > > From a build system perspective, I'd rather just point users towards > LTO if they have this concern. We support full and thin lto. This > proposal would add a third variant for just rust drivers. Each > variation on LTO has a maintenance cost and each have had their own > distinct fun bugs in the past. Not sure an additional variant is > worth the maintenance cost, even if it's technically feasible. > Actually, the "LTO" in "local-LTO" may be misleading ;-) The problem we want to resolve here is letting Rust code call small C functions (or macros) without exporting the symbols. To me, it's really just "static linking" a library (right now it's rust/helpers.o) contains small C functions and macros used by Rust into a Rust driver kmodule, the "LTO" part can be optional: let the linker make the call. Regards, Boqun > > go ahead with that (since it also solves the performance side), but it > > would be nice to know if it will always be OK to build like that, i.e. > > I think Andreas actually tried it and it seemed to work and boot, but > > the worry is whether there is something subtle that could have bad > > codegen in the future. > > > > (We will also need to worry about GCC.) > > > > Cheers, > > Miguel > > > > -- > Thanks, > ~Nick Desaulniers
