aes: Performance regressions from aes-0.8.x to 0.9.1 presumably due to differences in inlining on x86_64

[ephemeralriggs]

We have recently started to migrate Fuchsia to aes 0.9.1 and see some performance regression with it compared to aes 0.8.4 on x86_64.

Most regressions we observe are in the range of 3% to 8%, although a few outliers are significantly larger than that (two-digit percentages). Disassembly shows that there are differences in the inlining between the different versions.

It seems there is no open issue referencing this problem, but it is unlikely that this is a Fuchsia-specific problem.

[erickt]

It does look like the regression goes away if we compile with rustc ... -Ctarget-feature=+aes .... Maybe aes-0.8.4 was doing runtime detection for the AES instructions, which stopped in 0.9.1?

[newpavlov]

What crates are you using aes together with (ctr, aes-gcm, etc.)? Are you using the same compiler version? Have you tried the lto option?

[erickt]

Here's our patch to update aes to 0.9.1.

We're using a number of the RustCypto libraries in fuchsia, like aes-gcm, aes-gcm-siv, ctr and etc. The full dependencies can be seen in third_party/rust_crates/Cargo.lock. Note though we're not directly using cargo in our build system, and instead use cargo-gnaw to convert the build to GN, which produces third_party/rust_crates/BUILD.gn. There you can see the full feature flags.

So for aes-0.8.4, we've got:

rustc_library("aes-v0_8_4") {
  crate_name = "aes"
  source_root = "//third_party/rust_crates/vendor/aes-0.8.4/src/lib.rs"
  output_name = "aes-9f84688850b96a05"
  edition = "2021"
  disable_clippy = true
  enforce_source_listing = false
  configs -= [ "//build/config/rust:2018_idioms" ]

  deps = []
  deps += [ ":cfg-if-v1_0_4" ]
  deps += [ ":cipher-v0_4_4" ]
  if (current_cpu == "arm64" || current_cpu == "x64" || false) {
    deps += [ ":cpufeatures-v0_2_17" ]
  }

  rustenv = []

  rustflags = [
    "--cap-lints=allow",
    "-Cmetadata=9f84688850b96a05",
    "-Cextra-filename=-9f84688850b96a05",
    "--cfg=aes_armv8",
  ]

  visibility = [ ":*" ]

  applicable_licenses = [ ":aes-v0_8_4.license" ]
}

For aes-0.9.1, we've got:

rustc_library("aes-v0_9_1") {
  crate_name = "aes"
  source_root = "//third_party/rust_crates/vendor/aes-0.9.1/src/lib.rs"
  output_name = "aes-994e7717cce9cfe1"
  edition = "2024"
  disable_clippy = true
  enforce_source_listing = false
  configs -= [ "//build/config/rust:2018_idioms" ]

  deps = []
  deps += [ ":cipher-v0_5_2" ]
  deps += [ ":cpubits-v0_1_1" ]
  if (current_cpu == "arm64" || current_cpu == "x64" || false) {
    deps += [ ":cpufeatures-v0_3_0" ]
  }

  rustenv = []

  rustflags = [
    "--cap-lints=allow",
    "-Cmetadata=994e7717cce9cfe1",
    "-Cextra-filename=-994e7717cce9cfe1",
  ]

  visibility = [ ":*" ]

  applicable_licenses = [ ":aes-v0_9_1.license" ]
}

We should be using the same compiler version. We do use LTO in some configurations, but I'm not sure if the numbers @ephemeralriggs got was with LTO.

[tarcieri]

If -Ctarget-feature=+aes fixes it, it makes me wonder if we're missing a #[target_feature(enable = "aes")] somewhere which is preventing inlining