Question about SSE/RVd/RVf/RVq... and related processor extensions regarding floating-point conversions

So, I've got a question about SSE, RV32/64f/d/q, and such, regarding floating-point conversion.
SSE/SSE2/SSSE3/SSE4.1/SSE4.2 for x86 and RV32f/d/q/RV64f/d/q for RISC-V define various instructions for converting from and two floating-point numbers and words of differing widths. The x86 architecture has instructions like CVTDQ2PD, CVTDQ2PS, CVTPD2DQ, CVTPD2PI, CVTPD2PS, CVTPI2PD, CVTPI2PS, CVTPS2DQ, CVTPS2PD, CVTPS2PI, CVTSD2SI, and so on and RISC-V has fcvt.w.s, fcvt.wu.s, fcvt.s.w, fcvt.s.wu, etc. My question is, are these instructions emitted for converting a floating-point number in Rust to an integer and back? (I understand that SSE typically works on pairs of floats/doubles/quads, not just individual ones, but still.) If not, is there a way to force the emission of these instructions (without) inline assembly? If these aren't emitted automatically by the compiler, why not? I'm just curious why architectures like x86 or RISC-V have so many instructions for doing things like this and yet compilers usually don't emit the majority of them, if I understand correctly, preferring to fall back to far more used instructions instead.

On nightly you can use the intrinsics in std::arch::x86_64, e.g. cvtdq2pd corresponds to

https://doc.rust-lang.org/stable/core/arch/x86_64/fn._mm_cvtepi32_pd.html

It wasn't hard to let the compiler to emit CVTDQ2PS.

Currently the rustc is backed by the LLVM, a toolchain for the optimizing compilers which also powers the clang C/++ compiler. Modern compilers perform various optimizations like the autovectorization.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.