Repository navigation
-C linker-plugin-lto prevents vectorization of mem::swap at -C opt-level=3 #124234
Description
I tried this code (godbolt):
pub type T = [u64; 4];
#[no_mangle]
pub fn swap_32(a: &mut T, b: &mut T) {
std::mem::swap(a, b);
unsafe {
// std::ptr::swap(a, b);
// std::ptr::swap_nonoverlapping(a, b, 1);
}
}I expected to see this happen: code optimizes to a few <_ x i64> (target-cpu-dependent) loads and stores on -C opt-level=3.
Instead, this happened: the code is not vectorized when -C linker-plugin-lto is also passed to the compiler (this is passed together with -Clto=... but that has no effect here)
Note that this only happens with mem::swap/ptr::swap_nonoverlapping, not ptr::swap.
Meta
rustc --version --verbose:
rustc 1.79.0-nightly (f9b161492 2024-04-19)
binary: rustc
commit-hash: f9b16149208c8a8a349c32813312716f6603eb6f
commit-date: 2024-04-19
host: x86_64-unknown-linux-gnu
release: 1.79.0-nightly
LLVM version: 18.1.4
This happens since at least 1.61, but I could not find a way to bisect this, so I opted not to mark this a regression.
@rustbot modify labels: +A-LLVM +A-LTO +I-slow
Activity
[-]`-C linker-plugin-lto` prevents vectorization of `ptr::swap_nonoverlapping` at `-C opt-level=3`[/-][+]`-C linker-plugin-lto` prevents vectorization of `mem::swap` at `-C opt-level=3`[/+]DaniPopes commentedon Apr 21, 2024
4b043fa...d3ad51b
Probably #94212 cc @scottmcm
scottmcm commentedon Apr 23, 2024
We used to basically be forcing this, but stopped doing that in #123185
I know nothing about what
linker-plugin-ltodoes or why it would be relevant.But yeah, in assembly it swaps via
ymms in v3 https://rust.godbolt.org/z/Mqc64zYxW without the flag, but does individualqwords with it 🤷nikic commentedon Apr 23, 2024
I'm not sure whether
-C linker-plugin-ltois compatible with--emit=llvm-ir(or--emit=asm). I'd guess it prints the pre-LTO IR in that case?DaniPopes commentedon Apr 23, 2024
My workflow is getting the
--releaseassembly withcargo-show-asm. LTO is enabled in the release profile overrides in the manifest.It's unfortunate that this does not return the fully optimized assembly, but it also makes sense since linking doesn't actually happen. I thought this issue initially was a regression because couldn't find any info on this.
I confirmed that it gets vectorized in the final assembly with
objdump+grepin a new crate, so I'll close this issue.scottmcm commentedon Apr 23, 2024
Glad to hear it's working! (and that I didn't break everything *phew*)
TBH, this has been confusing me too as I work on stuff. Thus tests like https://github.com/rust-lang/rust/blob/master/tests/assembly/x86_64-typed-swap.rs as it seems that looking in LLVM IR keeps not telling the full story :(
pacak commentedon Apr 24, 2024
FWIW I just released
cargo-show-asm0.2.33 and now it can actually disassemble your binary (pass--disasmin addition to usual flags and make sure symbols are not stripped bycargo) so output should be similar to what you can get fromobjdump, but with less manual interactions. For now it's locked behind "disasm" feature (cargo install cargo-show-asm --features disasm), if something doesn't work - please make a ticket :)