On Fri, 7 Jun 2024 07:40:45 -0700 Matthew Maurer <mmaurer@xxxxxxxxxx> wrote: > The LLVM `.ll` textual bitcode representation may change from version > to version, which makes using `sed` to edit it potentially fragile. > Would it be possible to attach similar attributes without this? (Or > other attributes that can accomplish something similar, see the second > part.) I agree that text editing is fragile and should be avoided, but I'm not aware of a way to achieve this without text editing. > Would it be possible to use a Rust-only-LTO (actual LTO) flag rather > than a `llvm-link`? It seems likely that someone that wants to use a > synced `clang` and `rustc` to allow helpers to be inlined would be > unlikely to object to thin LTO of Rust. This would avoid introducing a > new tool. There's no way for rustc to actually perform the LTO, since the crate type that we use is rlib rather than staticlibs or cdylibs, Rust does not take care of the linking. > As one possible route around editing the `.ll` file, we could consider > *not* hiding these symbols, just marking them as "good idea to inline > if possible", and then masking any symbol that ends up in the final > `.o` via `objcopy --localize-symbol=blah`. If we're doing full-kernel > LTO rather than rust-only LTO, we'd need to use `llvm-objcopy` > instead, but the same process would follow - a postprocessing step on > the final crate object that localizes the symbol, with LTO giving the > compiler the option (but not requirement) to inline these functions if > it seems like a good idea. This was one of the approach that I considered, but IIUC objcopy require you to supply it a list of exact-match symbols rather than patterns, so we have to get all helper symbols and then feed it to objcopy. I really want to avoid having a script or host program to do this step. Best, Gary
