rustc 1.34.0-nightly (da6ab956e 2019-01-27) and later make encoding_rs with packed_simd go from one .s to 31 .rcgu.s files

[hsivonen]

Steps to reproduce

1. Clone https://github.com/hsivonen/encoding_rs
2. cd encoding_rs
3. git checkout simd
4. rustup default rustup default 1.32.0
5. rustup target add armv7-unknown-linux-gnueabihf
6. RUSTC_BOOTSTRAP=1 RUSTFLAGS='-C target_feature=+neon,+thumb-mode,+thumb2' cargo rustc --target armv7-unknown-linux-gnueabihf --features simd-accel --release -- --emit asm
7. find target | grep -c '\.s$'
8. rm -rf target
9. git checkout packed_simd
10. rustup default nightly
11. rustup target add thumbv7neon-unknown-linux-gnueabihf
12. cargo rustc --target thumbv7neon-unknown-linux-gnueabihf --features simd-accel --release -- --emit asm
13. find target | grep -c '\.s$'

Actual results

In the simd + Rust 1.32 case, there is one .s file. In the packed_simd + Rust 1.34 case, encoding_rs is split across 31 .s files. These are all .rcgu.s files. Examining these files suggests lesser inlining within encoding_rs, although code from packed_simd and core::arch appears to have gotten inlined.

Expected result

Expected one .s file with the same level of inlining in the packed_simd + Rust 1.34 case as with the simd + Rust 1.32 case.

Additional info

When building an actual binary from a different top-level crate (encoding_bench), the packed_simd + Rust 1.34 case regresses performance relative to the simd + Rust 1.32 on Exynos 5.

[hsivonen]

RUSTFLAGS='-C codegen-units=1' cargo rustc --target thumbv7neon-unknown-linux-gnueabihf --features simd-accel --release -- --emit asm does not change things.

[gnzlbg]

@hsivonen do you have a cargo/.config or custom profiles when building the simd crate that might be fixing the number of codegen-units or whether incremental compilation is enabled/disabled when using the simd crate ?

[hsivonen]

do you have a cargo/.config or custom profiles

I don't have a cargo directory under encoding_rs. I don't have .config or config under ~/.cargo. I'm not aware of having custom profiles.

[hsivonen]

In the case of x86_64-unknown-linux-gnu, the same target exists on both 1.32 and 1.34, so I was able to try packed_simd with both. This is not a simd vs. packed_simd issue: packed_simd with Rust 1.32 produces one .s targeting x86_64 and 31 .rcgu.s files with 1.34.

[hsivonen]

One .s with 1.33.0-beta.4. Must be a very recent change.

[hsivonen]

First nightly with 31 .s files: rustc 1.34.0-nightly (da6ab95 2019-01-27)
Last nightly with one .s file: rustc 1.33.0-nightly (20c2cba 2019-01-26)

[hsivonen]

GitHub comparison of the two.

[hsivonen]

The most suspicious commit in that range seems to be the new cargo version. Maybe the compiler didn't change but the way cargo invokes it did.

[hsivonen]

Well, in that range cargo turned on incremental compilation by default.

[hsivonen]

Link to the PR for turning on incremental compilation.

[hsivonen]

Indeed, incremental = false under [profile.release] in Cargo.toml returns the behavior to a single .s.

[hsivonen]

Adding incremental = false under [profile.bench] in the Cargo.toml did not fix the regression relative to the simd crate on the Thumb2 on ARMv7 CPU case. How should I verify that incremental = false is taking effect in a cargo bench scenario?

[hsivonen]

rustc 1.34.0-nightly (da6ab95 2019-01-27) vs. rustc 1.33.0-nightly (20c2cba 2019-01-26) does not show a benchmarking difference on x86_64 (tested on a Haswell desktop i7).