dialects: (riscv_snitch) add fastmath flags in vector ops

[superlopuh]

It feels like fastmath is still appropriate on the vector ops, also it will make the lowering a little less tedious, by making the vector and scalar arithmetic ops a little more uniform.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.90%. Comparing base (22b8564) to head (877571d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2913   +/-   ##
=======================================
  Coverage   89.90%   89.90%           
=======================================
  Files         403      403           
  Lines       50424    50424           
  Branches     7788     7788           
=======================================
  Hits        45334    45334           
  Misses       3862     3862           
  Partials     1228     1228           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zero9178]

Why do RISC-V operations have fast math actually? I'd have thought that fast math would be gone past instruction selection (aka arith to riscv lowering).

Does this enable anything that cannot be done on arith?

[superlopuh]

fmadd

[zero9178]

fmadd

I'd have expected this to be implemented within arith-to-riscv as a simple DAG match. Having fastmath feels wrong to me because suddenly the semantics of instructions that have fast math do not match exactly the ones of the RISC-V ISA anymore which feels a bit odd.

Shouldn't be a correctness issue though I guess, so if this is the state of the world then so be it.

[superlopuh]

My understanding is that this follows the behaviour of LLVM, although we might want to diverge from it. Also, isn't that the definition of fastmath, to diverge from the semantics?

[tobiasgrosser]

My understanding is that this follows the behaviour of LLVM, although we might want to diverge from it. Also, isn't that the definition of fastmath, to diverge from the semantics?

Can you clarify how this 'follows the behaviour of LLVM'. I am not sure what you are precisely referring to. It might indeed be interesting to investigate how LLVM implements fastmath. Typically fastmath flags are at the LLVM-IR level, but I am unsure if it also maintains them in the backend. It may or may not, and I would find it useful to understand what LLVM does. In general, we should follow LLVM except if there good reasons to do sth different.

[superlopuh]

What I mean is that LLVM did emit fmadd instructions in our flow without the fastmath flags. I think @compor initially added the flags to our experimental setup and set up the corresponding infrastructure in xDSL to make sure that we also emit fmadd instructions when explicitly specified by the user.
https://discourse.llvm.org/t/risc-v-multiply-add-instructions-fmadd-etc-bit-exactness-and-correctness-of-optimizations/64194
In this discussion, the reference is the C standard. I don't know what the specification of arith on floats is but it seems to mostly follow the C standard/clang/llvm approach of only change the fp operations when the relevant flags are set, and not by default.

[tobiasgrosser]

Are you saying for C-code that was compiled with clang, fmadds were created. Or that LLVM-IR that you generated without fastmath flags was fused by LLVM (or later in its backend). The link you posted suggests that only the former is legal.

On the other hand, @nazavode's research seems to suggest that LLVM indeed maintains fastmath flags up until the very end.

[superlopuh]

What I'm saying is with the flags, fmadds were created by the backend, and without they were not.