Poorly optimized assembly generation around Ipv4Addr, Ipv6Addr

[TyPR124]

I tried this code:

pub fn ipv4_bitand_mask(ipv4: Ipv4Addr, mask: u32) -> Ipv4Addr {
    let ipv4_u32 = u32::from_ne_bytes(ipv4.octets());
    Ipv4Addr::from((ipv4_u32 & mask).to_ne_bytes())
}

I expected to see this happen: assembly generated should be equivalent to:

pub fn ipv4_bitand_mask_unsafe(ipv4: Ipv4Addr, mask: u32) -> Ipv4Addr {
    let ipv4_u32: u32 = unsafe { std::mem::transmute(ipv4) };
    unsafe { std::mem::transmute(ipv4_u32 & mask) }
}

Instead, this happened: the generated assembly retains calls to Ipv4::octets and Ipv4::from, leaving the assembly poorly optimized

I've played with different ways of implementing the safe version, but cannot find anyway get it to optimize further.

Good assembly:

example::ipv4_bitand_mask_unsafe:
        mov     eax, edi
        and     eax, esi
        ret

Bad assembly:

example::ipv4_bitand_mask:
        push    rbx
        sub     rsp, 16
        mov     ebx, esi
        mov     dword ptr [rsp + 8], edi
        lea     rdi, [rsp + 8]
        call    qword ptr [rip + std::net::ip::Ipv4Addr::octets@GOTPCREL]
        and     eax, ebx
        mov     edi, eax
        call    qword ptr [rip + <std::net::ip::Ipv4Addr as core::convert::From<[u8; 4]>>::from@GOTPCREL]
        add     rsp, 16
        pop     rbx
        ret

Playground and GodBolt (both include an IPv6 example as well)

Adding '-Z mir-opt-level=2' (or higher) does optimize away the call to octets, but not the call to from.

I get the same optimization behavior when building a binary, at least on my own platfom (x86-64 Windows MSVC)

Meta

rustc --version --verbose:

rustc 1.49.0-nightly (beb5ae474 2020-10-04)
binary: rustc
commit-hash: beb5ae474d2835962ebdf7416bd1c9ad864fe101
commit-date: 2020-10-04
host: x86_64-pc-windows-msvc
release: 1.49.0-nightly
LLVM version: 11.0

[jonas-schievink]

Maybe it's just missing #[inline]s?

[TyPR124]

I will try to test with adding #[inline] in the appropriate places in std

[scottmcm]

This is a trivial method on a concrete type, so yeah, probably just needs #[inline]. Or you want to turn on LTO.

(If it were generic it wouldn't be necessary, but for concrete things the bodies aren't in the meta.)

[TyPR124]

So I found when a crate exports a function with #[inline], it does get optimized where called (though I'm . On the other hand, the same logic inside function will not be inlined: this basic program, for instance, retains assembly calls to octets() and from():

fn main() {
    let ip: Ipv4Addr = std::env::args().nth(1).unwrap().parse().unwrap();
    let ipbeu32 = u32::from_be_bytes(ip.octets());
    let net = Ipv4Addr::from((ipbeu32 & 0xffffff00u32.to_be()).to_ne_bytes());
    println!("{}", net);
}

Edit: copy the right "basic program" this time...

With #[inline] on the methods in libstd, the two calls are optimized away.

Is this worth a PR to add #[inline] to libstd? If so, is there anything that shouldn't have #[inline] in the API? Seems to me like nearly everything would be better inlined, at least for IPv4, but I'm far from an expert.

[LeSeulArtichaut]

Feel free to open a PR I guess, your reviewer will decide whether it should be merged or not.

[mati865]

Ping @TyPR124, do you want to work on fixing this issue?