Cannot select `fmaximum`/`fminimum`

[dcaballe]

Any plans to add support for fmaximum/fminimum and their respective reductions to the RISC-V backend? We would like to target them from MLIR since the main fmax/fmin semantics in MLIR matches these instructions. This is currently blocking: https://reviews.llvm.org/D155877

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

[llvmbot]

@llvm/issue-subscribers-bug

[unterumarmung]

It looks like the RISC-V backend supports llvm.maximum and llvm.minimum intrinsics, but it's missing support for llvm.vector.reduce.fminimum and @llvm.vector.reduce.fmaximum. This caused an infinite loop when I ran trunk llc in Godbolt: https://godbolt.org/z/GfxMj41fx

I want to make changes to add support for llvm.vector.reduce.fminimum and llvm.vector.reduce.fmaximum in the RISC-V backend, but I'm new to backend development. So, I could really use some guidance on where to make the code changes and what the expected results should be for these intrinsics. I'll try to look at commits from other backends that added support for these intrinsics, but any help or tips you can give me would be super appreciated! Thanks!

P.S. Isn't there supposed to be some kind of fallback code generation for intrinsics that are not supported by a backend?

[topperc]

@unterumarmung using an assertions build triggers an llvm_unreachable. https://godbolt.org/z/5nY98v53Y I'm going to commit a patch to turn that llvm_unreachable into a fatal error.

[dcaballe]

I'm actually getting and error for llvm.fmaximum, not the reduction one:

LLVM ERROR: Cannot select: t21: f32 = fmaximum t105, t268
  t105: f32 = fmaximum t208, t212
    t208: f32 = extract_vector_elt t214, Constant:i32<0>
      t214: nxv2f32,ch = llvm.riscv.vle<(load (s64) from %ir.5, align 64)> t0, TargetConstant:i32<8507>, undef:nxv2f32, t14, Constant:i32<2>
        t213: i32 = TargetConstant<8507>
        t106: nxv2f32 = undef
        t14: i32 = add t12, Constant:i32<64>
          t12: i32,ch = load<(load (s32) from %ir..unpack21, align 8)> t0, t11, undef:i32
            t11: i32,ch = load<(load (s32) from %ir..elt20)> t0, t8, undef:i32
              t8: i32 = add nuw t4, Constant:i32<28>
                t4: i32,ch = CopyFromReg t0, Register:i32 %1
                  t3: i32 = Register %1
                t7: i32 = Constant<28>
              t10: i32 = undef
            t10: i32 = undef
          t13: i32 = Constant<64>
        t109: i32 = Constant<2>
      t9: i32 = Constant<0>
    t212: f32 = extract_vector_elt t211, Constant:i32<0>
      t211: nxv2f32 = RISCVISD::VSLIDEDOWN_VL undef:nxv2f32, t214, Constant:i32<1>, t209, Constant:i32<1>, TargetConstant:i32<3>
        t106: nxv2f32 = undef
        t214: nxv2f32,ch = llvm.riscv.vle<(load (s64) from %ir.5, align 64)> t0, TargetConstant:i32<8507>, undef:nxv2f32, t14, Constant:i32<2>
          t213: i32 = TargetConstant<8507>
          t106: nxv2f32 = undef
          t14: i32 = add t12, Constant:i32<64>
            t12: i32,ch = load<(load (s32) from %ir..unpack21, align 8)> t0, t11, undef:i32
              t11: i32,ch = load<(load (s32) from %ir..elt20)> t0, t8, undef:i32
                t8: i32 = add nuw t4, Constant:i32<28>
                  t4: i32,ch = CopyFromReg t0, Register:i32 %1

                  t7: i32 = Constant<28>
                t10: i32 = undef
              t10: i32 = undef
            t13: i32 = Constant<64>
          t109: i32 = Constant<2>
        t103: i32 = Constant<1>
        t209: nxv2i1 = RISCVISD::VMSET_VL Constant:i32<1>
          t103: i32 = Constant<1>
        t103: i32 = Constant<1>
        t210: i32 = TargetConstant<3>
      t9: i32 = Constant<0>
  t268: f32,ch = load<(load (s32) from constant-pool)> t0, t270, undef:i32
    t270: i32 = RISCVISD::LLA TargetConstantPool:i32<float 0xC6293E5940000000> 0
      t269: i32 = TargetConstantPool<float 0xC6293E5940000000> 0
    t10: i32 = undef

If llvm.fmaximum is supported on f32, please, let me know and I'll try to get a repro. You can see the full log report from our testing here: https://github.com/openxla/iree/actions/runs/5626828153/job/15248556223?pr=14472#logs

[topperc]

I fixed llvm.fmaximum for scalar f32 when the F extension is enabled earlier today.

[dcaballe]

Thanks a lot, Craig! What is the state or planning for the reduction ones?

[topperc]

Need to figure out a good lowering for reductions. We don't have a hardware reduction instruction that does this. So we need to do something like vredmax, and vfclass to find all the nans, and vcpop to count if there are any nans. If there are any nans replace the vredmax result with nan. This is not going to be efficient.

[dcaballe]

That should be fine. We would like to remove some hacks and fix some issues related to this in MLIR and for that we need at least the basic functionality to be implemented on x86, ARM and RISC-V. It looks like RISC-V is the only one missing.

[topperc]

After my scalar fix, the reductions no longer crash. They just generate terrible code https://godbolt.org/z/YfzYv4o8G

[dcaballe]

Awesome! Let me integrate and run more extensive benchmarks.