[PATCH] D75729: [RISCV] Select +0.0 immediate using fcvt.{d, s}.{x, w} fN, x0

Luís Marques via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 11 14:07:35 PDT 2020


luismarques added a comment.

In D75729#1917843 <https://reviews.llvm.org/D75729#1917843>, @jrtc27 wrote:

> > Unless you fast-path register zero (or the value itself being zero), a naive implementation is going to have to do a full integer->float conversion, which is more likely to be a multi-cycle operation, regardless of rounding mode. Contrast that with an `fmv`, which is a special case of `fsgnj`, but the generic case is still just bit selection and concatenation, so it should always be single-cycle. Having said that, the Rocket schedule (and reading the code) indicates that both are 2-cycle operations, and for the Bluespec Piccolo/Flute cores both are 1-cycle operations, but the GCC schedule for the 7 series SiFive cores claims that `fmv` will be in the A pipe (address, i.e. loads/stores, but also any FP<->int given that already needs to be present on the load/store paths), and `fcvt` will be in the B pipe (branches, but also mul/div and and any other FP ops).
>
> Actually I got confused, `fmv.x.?`and `fmv.?.x` aren't special cases of `fsgnj` (that's only true for the FP<->FP `fmv`'s), but their own instructions outright. The rest of what I said still applies though.


Thanks for the detailed info James. So the GCC table is the ideal implementation, and probably what we should adopt, it seems?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75729/new/

https://reviews.llvm.org/D75729





More information about the llvm-commits mailing list