Expand `arith.minf` and `arith.maxf` expand ops for non-`f32` types

[rsuderman]

x86 compilation fails with minf and maxf reduction operations.

This is the ir for the corresponding failing test:

 func.func @main(%arg0 : tensor<2x1x4xf16>, %arg1 : tensor<f16>) -> tensor<2x1xf16> {
  %0 = stablehlo.reduce(%arg0 init: %arg1) applies stablehlo.minimum across dimensions = [2] : (tensor<2x1x4xf16>, tensor<f16>) -> tensor<2x1xf16>
  return %0 : tensor<2x1xf16>
}

[jmintb]

Can I have a go at this?

[jvstokes]

Please first validate that this is still an issue (a fix may already be in,) but if it's still an issue then go ahead :)

[dcaballe]

I would expect this to be working already. We have made significant changes to the max/min representation and support. See: https://discourse.llvm.org/t/rfc-fix-floating-point-max-and-min-operations-in-mlir/72671

[rsuderman]

Validated that this is still failing.

[dcaballe]

What is the compilation command?

[rsuderman]

You need to execute it on an x86 machine, then just iree-compiler --iree-hal-target-backends=llvm-cpu <file> should yield the following error:

suderman@build[]: iree-compile /tmp//test.mlir  --iree-hal-target-backends=llvm-cpu
lld: error: undefined symbol: fminf
>>> referenced by -:2
>>>               /tmp/main_dispatch_0-867483.o:(main_dispatch_0_generic_2x4_f16)
>>> referenced by -:2
>>>               /tmp/main_dispatch_0-867483.o:(main_dispatch_0_generic_2x4_f16)
>>> referenced by -:2
>>>               /tmp/main_dispatch_0-867483.o:(main_dispatch_0_generic_2x4_f16)
>>> referenced 3 more times
Linking failed; escaped command line returned exit code 256:

LLD_VERSION=IREE /usr/local/google/home/suderman/Repos/iree/build/llvm-project/bin/lld -flavor gnu -o /tmp/main_dispatch_0-867483.so --build-id=none -nostdlib -static -shared --no-undefined --no-allow-shlib-undefined --allow-multiple-definition --gc-sections -z now -z relro --discard-all --icf=all --ignore-data-address-equality --ignore-function-address-equality --hash-style=sysv /tmp/main_dispatch_0-867483.o

/tmp//test.mlir:2:24: error: failed to link executable and generate target dylib (check above for more specific error messages)
  %0 = stablehlo.reduce(%arg0 init: %arg1) applies stablehlo.minimum across dimensions = [2] : (tensor<2x1x4xf16>, tensor<f16>) -> tensor<2x1xf16>
                       ^
/tmp//test.mlir:1:2: note: called from
 func.func @main(%arg0 : tensor<2x1x4xf16>, %arg1 : tensor<f16>) -> tensor<2x1xf16> {

[dcaballe]

It works for me with --iree-llvmcpu-target-triple=x86_64-unknown-linux-gnu --iree-llvmcpu-link-embedded=false

[rsuderman]

You are right, apparently just with --iree-llvmcpu-link-embedded=false it builds correctly. Happy to close but I would be curious why the flag changes the success.

[benvanik]

when that flag is false libc can be used - we don't want libc to be used - we should never be emitting scalar calls to libc to do min/max even if libc is available