"square can be computed more efficiently" is wrong

[RReverser]

Lint name:
suboptimal_flops

I tried this code:

#![warn(clippy::suboptimal_flops)]

pub fn sample_sqr(x: f64) -> f64 {
    x.powi(2)
}

I expected to see this happen: it should pass.

Instead, this happened: it says "square can be computed more efficiently" and suggests to use x * x instead.

This is incorrect, because, unlike powf, powi produces exactly same native code as x * x, and is more natural to read (IMO). If anything, due to usage of intrinsic, it might be optimised even more than bare expression, although they're unlikely to be different on practice.

Meta

• cargo clippy -V: clippy 0.1.53 (2e495d2 2021-04-08)
• rustc -Vv:

      rustc 1.53.0-nightly (2e495d2e8 2021-04-08)
      binary: rustc
      commit-hash: 2e495d2e845cf27740e3665f718acfd3aa17253e
      commit-date: 2021-04-08
      host: x86_64-unknown-linux-gnu
      release: 1.53.0-nightly
      LLVM version: 12.0.0
  

[camsteffen]

@clarfonthey or @thiagoarrais do you have any input?

[clarfonthey]

I believe that this may be a new optimisation -- does it really always generate the same code now?

[thiagoarrais]

For reference: this lint was introduced in #5443. It may indeed have been obsoleted by some new optimization since the original issue (#2040).

[RReverser]

I actually checked with Godbolt and x.powi(2) was generating code equivalent to x * x in every version starting from Rust 1.0.

In fact, even powf(2.0) seems to have always generated equivalent code in optimised mode, although it's less readable and I don't have any opinion on that one.

[camsteffen]

Could it be architecture-dependant?

[RReverser]

Not sure - it's certainly possible, but I haven't found one where this wouldn't hold on any mainstream arch. Plus, as noted above, it uses a compiler intrinsic under the hood, which I'd assume to always be implemented whatever's most efficient on each supported platform.

[camsteffen]

Seems like we have sufficient info to not lint this case.

[mucinoab]

@rustbot claim