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

[James Clarke via Phabricator via llvm-commits]

jrtc27 added a comment.

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

> In D75729#1916662 <https://reviews.llvm.org/D75729#1916662>, @luismarques wrote:
>
> > In D75729#1912792 <https://reviews.llvm.org/D75729#1912792>, @rogfer01 wrote:
> >
> > > Perhaps these are slightly better than just `fcvt` everywhere because they avoid the rounding mode required by  `fcvt.s.w` / `fcvt.s.l`  / `fcvt.d.l`?
> >
> >
> > With the rounding mode being stateless (it's per instruction), I'm don't know what the issue would be with that.
>
>
> 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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75729