[RISCV] Mark FSIN and other math functions as Expand for scalable vectors.

[craig.topper]

Summary

This prevents them from being assumed legal by the cost model.

This matches what is done for AArch64 SVE.

[liaolucy]

I would like to ask a question:

What are the benefits of illegal costs? Is there a problem that illegal costs are trying to solve?

[craig.topper]

In D123799#3457909, @liaolucy wrote:

I would like to ask a question:

What are the benefits of illegal costs? Is there a problem that illegal costs are trying to solve?

It prevents the vectorizer from creating llvm.sin, etc. with scalable vector types since they will crash in the backend.

[craig.topper]

Add rint and nearbyint

[frasercrmck]

I agree they should probably be invalid, conceptually, but in reality I don't like that we have users of cost models crash when encountering invalid costs, with the rationale that the IR shouldn't contain anything with an invalid cost. I don't see how those two models are compatible.

[craig.topper]

In D123799#3461104, @frasercrmck wrote:

I agree they should probably be invalid, conceptually, but in reality I don't like that we have users of cost models crash when encountering invalid costs, with the rationale that the IR shouldn't contain anything with an invalid cost. I don't see how those two models are compatible.

Invalid cost is a recent concept. Did the project fail to update some code to comprehend the possibility of invalid costs?

[frasercrmck]

In D123799#3461124, @craig.topper wrote:

In D123799#3461104, @frasercrmck wrote:

I agree they should probably be invalid, conceptually, but in reality I don't like that we have users of cost models crash when encountering invalid costs, with the rationale that the IR shouldn't contain anything with an invalid cost. I don't see how those two models are compatible.

Invalid cost is a recent concept. Did the project fail to update some code to comprehend the possibility of invalid costs?

To be honest, I don't have a good idea about the broader community view on invalid costs so I can't say for sure. I'm sure I've seen it argued in a review that invalid costs are a symptom of invalid IR which should have been legalized before reaching whichever part of code crashed. I can't find where I thought I saw that, though. I might have dreamed it.

CodeMetrics is one that definitely hard-crashes on invalid costs, and that's used by several optimizations that form the standard pipeline.

It's doubly hard for scalable-vector targets because many of the base TTIs assume fixed-length vectors and I've seen it argued in D119529 (maybe where @liaolucy is coming from) that that's acceptable. We can't assume anything other than invalid costs for scalable vectors in base TTI functions. But then, in my opinion, forcing targets to fully cost everything before things stop crashing is asking too much.

On reflection, it's the combination of these two issues that's making life hard. We have to fully cost everything scalable but we also can't return invalid costs to get there without making assumptions.

[liaolucy]

In D123799#3457920, @craig.topper wrote:

In D123799#3457909, @liaolucy wrote:

I would like to ask a question:

What are the benefits of illegal costs? Is there a problem that illegal costs are trying to solve?

It prevents the vectorizer from creating llvm.sin, etc. with scalable vector types since they will crash in the backend.

Thank Craig , I get the crash today.

This patch fix tsvc s451 crash.

fatal error: error in backend: Cannot select: t12: nxv2f32 = fsin nnan ninf nsz arcp contract afn reassoc t7
  t7: nxv2f32,ch = load<(load unknown-size from %ir.uglygep51, align 16, !tbaa !4)> t0, t4, undef:i64
    t4: i64 = add t3, t81
      t3: i64,ch = CopyFromReg t0, Register:i64 %12
        t2: i64 = Register %12
      t81: i64 = ADDI t80, TargetGlobalAddress:i64<ptr @b> 0 [TF=3]
        t80: i64 = LUI TargetGlobalAddress:i64<ptr @b> 0 [TF=4]
          t78: i64 = TargetGlobalAddress<ptr @b> 0 [TF=4]
        t79: i64 = TargetGlobalAddress<ptr @b> 0 [TF=3]
    t6: i64 = undef
In function: s451

[reames]

LGTM

For context, I've been landing patches to remove the "crash on invalid cost" issue that got discussed earlier in this review. As of now, there are no cases that I'm aware of where an invalid cost can lead to a crash. We'll probably find a couple more as time goes by, but the major changes are in, and these are just bugs we should fix.

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

const auto SetCommonVFPActions = [&](MVT VT) {
 
       setOperationAction({ISD::FTRUNC, ISD::FCEIL, ISD::FFLOOR, ISD::FROUND},
                          VT, Custom);
 
       setOperationAction({ISD::VECREDUCE_FADD, ISD::VECREDUCE_SEQ_FADD,
                           ISD::VECREDUCE_FMIN, ISD::VECREDUCE_FMAX},
                          VT, Custom);
 
+      // Expand FP operations that need libcalls.
+      setOperationAction(ISD::FREM, VT, Expand);
+      setOperationAction(ISD::FPOW, VT, Expand);
+      setOperationAction(ISD::FCOS, VT, Expand);
+      setOperationAction(ISD::FSIN, VT, Expand);
+      setOperationAction(ISD::FSINCOS, VT, Expand);
+      setOperationAction(ISD::FEXP, VT, Expand);
+      setOperationAction(ISD::FEXP2, VT, Expand);
+      setOperationAction(ISD::FLOG, VT, Expand);
+      setOperationAction(ISD::FLOG2, VT, Expand);
+      setOperationAction(ISD::FLOG10, VT, Expand);
+      setOperationAction(ISD::FRINT, VT, Expand);
+      setOperationAction(ISD::FNEARBYINT, VT, Expand);
+
+      setOperationAction(ISD::VECREDUCE_FADD, VT, Custom);
+      setOperationAction(ISD::VECREDUCE_SEQ_FADD, VT, Custom);
+      setOperationAction(ISD::VECREDUCE_FMIN, VT, Custom);
+      setOperationAction(ISD::VECREDUCE_FMAX, VT, Custom);
+
       setOperationAction(ISD::FCOPYSIGN, VT, Legal);
 
       setOperationAction({ISD::LOAD, ISD::STORE}, VT, Custom);
 
       setOperationAction({ISD::MLOAD, ISD::MSTORE, ISD::MGATHER, ISD::MSCATTER},
                          VT, Custom);
 
       setOperationAction(

llvm/test/Analysis/CostModel/RISCV/rvv-intrinsics.ll

+; NOTE: Assertions have been autogenerated by utils/update_analyze_test_checks.py
+; RUN: opt < %s -passes='print<cost-model>' 2>&1 -disable-output -S -mtriple=riscv64 -mattr=+v | FileCheck %s
+
+define void @unsupported_fp_ops(<vscale x 4 x float> %vec) {
+; CHECK-LABEL: 'unsupported_fp_ops'
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %sin = call <vscale x 4 x float> @llvm.sin.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %cos = call <vscale x 4 x float> @llvm.cos.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %pow = call <vscale x 4 x float> @llvm.pow.nxv4f32(<vscale x 4 x float> %vec, <vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %powi = call <vscale x 4 x float> @llvm.powi.nxv4f32.i32(<vscale x 4 x float> %vec, i32 42)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %exp = call <vscale x 4 x float> @llvm.exp.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %exp2 = call <vscale x 4 x float> @llvm.exp2.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %log = call <vscale x 4 x float> @llvm.log.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %log2 = call <vscale x 4 x float> @llvm.log2.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %log10 = call <vscale x 4 x float> @llvm.log10.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %rint = call <vscale x 4 x float> @llvm.rint.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Invalid cost for instruction: %nearbyint = call <vscale x 4 x float> @llvm.nearbyint.nxv4f32(<vscale x 4 x float> %vec)
+; CHECK-NEXT:  Cost Model: Found an estimated cost of 1 for instruction: ret void
+;
+
+  %sin = call <vscale x 4 x float> @llvm.sin.nxv4f32(<vscale x 4 x float> %vec)
+  %cos = call <vscale x 4 x float> @llvm.cos.nxv4f32(<vscale x 4 x float> %vec)
+  %pow = call <vscale x 4 x float> @llvm.pow.nxv4f32(<vscale x 4 x float> %vec, <vscale x 4 x float> %vec)
+  %powi = call <vscale x 4 x float> @llvm.powi.nxv4f32.i32(<vscale x 4 x float> %vec, i32 42)
+  %exp = call <vscale x 4 x float> @llvm.exp.nxv4f32(<vscale x 4 x float> %vec)
+  %exp2 = call <vscale x 4 x float> @llvm.exp2.nxv4f32(<vscale x 4 x float> %vec)
+  %log = call <vscale x 4 x float> @llvm.log.nxv4f32(<vscale x 4 x float> %vec)
+  %log2 = call <vscale x 4 x float> @llvm.log2.nxv4f32(<vscale x 4 x float> %vec)
+  %log10 = call <vscale x 4 x float> @llvm.log10.nxv4f32(<vscale x 4 x float> %vec)
+  %rint = call <vscale x 4 x float> @llvm.rint.nxv4f32(<vscale x 4 x float> %vec)
+  %nearbyint = call <vscale x 4 x float> @llvm.nearbyint.nxv4f32(<vscale x 4 x float> %vec)
+  ret void
+}
+
+declare <vscale x 4 x float> @llvm.sin.nxv4f32(<vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.cos.nxv4f32(<vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.pow.nxv4f32(<vscale x 4 x float>, <vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.powi.nxv4f32.i32(<vscale x 4 x float>, i32)
+declare <vscale x 4 x float> @llvm.exp.nxv4f32(<vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.exp2.nxv4f32(<vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.log.nxv4f32(<vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.log2.nxv4f32(<vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.log10.nxv4f32(<vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.rint.nxv4f32(<vscale x 4 x float>)
+declare <vscale x 4 x float> @llvm.nearbyint.nxv4f32(<vscale x 4 x float>)