[llvm] [SelectionDAG][RISCV] Operations with static rounding (PR #100999)

[Matt Arsenault via llvm-commits]

================
@@ -8131,15 +8131,73 @@ void SelectionDAGBuilder::visitIntrinsicCall(const CallInst &I,
 void SelectionDAGBuilder::visitConstrainedFPIntrinsic(
     const ConstrainedFPIntrinsic &FPI) {
   SDLoc sdl = getCurSDLoc();
+  const TargetLowering &TLI = DAG.getTargetLoweringInfo();
+  EVT VT = TLI.getValueType(DAG.getDataLayout(), FPI.getType());
+  fp::ExceptionBehavior EB = *FPI.getExceptionBehavior();
+  std::optional<RoundingMode> RM = FPI.getRoundingMode();
+
+  SDNodeFlags Flags;
+  if (EB == fp::ExceptionBehavior::ebIgnore)
+    Flags.setNoFPExcept(true);
+
+  if (auto *FPOp = dyn_cast<FPMathOperator>(&FPI))
+    Flags.copyFMF(*FPOp);
+
+  bool UseStaticRounding = EB == fp::ExceptionBehavior::ebIgnore && RM &&
+                           *RM != RoundingMode::Dynamic &&
----------------
arsenm wrote:

> What is wrong with using constrained intrinsic for operations with static rounding?

It's not really what they are for. This isn't wrong, but why would using the fixed mode instructions be better than using instructions that do read the mode? The constrained argument only tells you the dynamic mode will be a certain value. Using fixed mode instructions does not change the expected behavior. Is there some reason using the fixed mode instructions is an optimization (I'd assume not)?

> Constrained intrinsics are used here as per their desigs, no?

Not really. What you're describing is more like https://llvm.org/docs/LangRef.html#llvm-fptrunc-round-intrinsic, where the rounding mode argument provides the behavior to use. The backend must manage mode switches as necessary, or use fixed rounding mode instructions like these ones you are defining. 



https://github.com/llvm/llvm-project/pull/100999