[VMVX] Missing support for arith.maxnumf and arith.minnumf

[Max191]

The VMVX backend does not support the arith.maxnumf op, which causes compiler failures for softmax. https://github.com/llvm/llvm-project/commit/fa0666876cdf11162af341911b99311a56be2274 changes the softmax decomposition to produce this op, which we are carrying a revert for in https://github.com/iree-org/iree/pull/17770.

An VM op needs to be implemented for arith.maxnumf, and arith.minnumf, similar to what was done for the minimum and maximum ops: https://github.com/iree-org/iree/commit/459f5ffad7b33e3bebd2947df8efa9cccea67b75

[ScottTodd]

https://mlir.llvm.org/docs/Dialects/ArithOps/#arithmaximumf-arithmaximumfop

arith.maximumf:

Returns the maximum of the two arguments, treating -0.0 as less than +0.0. If one of the arguments is NaN, then the result is also NaN.

arith.maxnumf:

Returns the maximum of the two arguments. If the arguments are -0.0 and +0.0, then the result is either of them. If one of the arguments is NaN, then the result is the other argument.

... do we care about the distinction? Looks like we currently just lower to a ternary operator for each data type, e.g.

static inline float vm_max_f32(float lhs, float rhs) {
  return lhs < rhs ? rhs : lhs;
}

[benvanik]

good q - IMO we only need one, and the more sane behavior (maxnumf/minnumf) seems ideal