[PATCH] D94163: [RISCV] Set dependency on floating point CSRs, 1/3

[Serge Pavlov via Phabricator via llvm-commits]

sepavloff added a comment.

In D94163#2603738 <https://reviews.llvm.org/D94163#2603738>, @asb wrote:

> We discussed this briefly in the RISC-V call as I noted this patchset has been sat open for some time. One thing that might be helpful is whether you could say a little bit more about the goal for this patchset.

Most floating point instructions set accrued exception bits in `fflags` register. If an instruction is specified with dynamic rounding mode, it also depends on the content of `frm` register. So in the following code:

  csrwi  frm, a1
  fadd.d ft2, ft2, ft3

changing the order of instruction is not allowed, because `fadd.d` depends on the content of `frm`, which is changed by the previous instruction. Similarly, the code:

  fadd.d ft2, ft2, ft3
  csrrs t0, fflags, zero

does not allow to change the order of the instructions, as `crsrs` reads content of `fflags`, which is set by the first instruction.

Now nothing prevents the compiler from changing the order of instructions in these examples. Existing instruction definitions are unable to express these dependencies. It does not allow to write programs that use non-default floating point environment, for example, dynamic rounding mode.

The goal of this patchset is to establish means to express such dependencies.

> Once this lands, what's the next step?

This is the first and necessary step toward full-fledged implementation of floating point support. In particular it would allow progress in D91242 <https://reviews.llvm.org/D91242> and D90854 <https://reviews.llvm.org/D90854>. Actually this work was undertaken because the lack of dependencies prevents implementation of `llvm.set.rounding` (https://reviews.llvm.org/D91242#2400476). The next steps, of course, include support of constrained intrinsics for RSCV.

> Is there some relevant RFC,

If RFC can facilitate review of this patchset, I will prepare it.

> or equivalent changes being made to other in-tree architectures?

Targets that support full-fledged floating point operations add implicit uses and definitions of FP state and control register(s). For example:
	• X86: https://github.com/llvm/llvm-project/blob/bc172e532a89754d47fef1306064a26a4dc0a76b/llvm/lib/Target/X86/X86InstrFPStack.td#L728 (see `let Defs = [FPSW]` and `let Uses = [FPCW]`),
	• PowerPC: https://github.com/llvm/llvm-project/blob/e7361c8eccb7663146096622549dc03240414157/llvm/lib/Target/PowerPC/PPCInstrInfo.td#L3169 (see `Uses = [RM]`),
	• SystemZ: https://github.com/llvm/llvm-project/blob/9e28b89827a3be4ab602b40c263839665af06b4a/llvm/lib/Target/SystemZ/SystemZInstrFP.td#L434 (see `let Uses = [FPC]`)

> We're also still unclear about the advantage of changing codegen to default to a static rounding mode (which might be a surprising change, as all software compiled to date on both GCC and LLVM has used used the dynamic rounding mode by default).

Instructions in assembler without explicit rounding mode specification get dynamic rounding mode as now. Lowering of FP operations like `fadd` uses static rounding mode RNE, because these operations  assume default floating point environment (https://llvm.org/docs/LangRef.html#floating-point-environment). Using static rounding mode  has some advantages over assuming `frm` to have particular value. The code that requires default rounding mode does not require setting `rfm` in a program where some pieces uses non-default rounding mode. Such code works as designed even if it is called from a region where other rounding mode is set. Such implementation simplifies implementation of things like `#pragma STDC FENV_ROUND` and make programs more robust.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94163