Thanks for bringing this up! I think part of the problem is that when we introduced the arith.minf and arith.maxf ops it wasn’t clear what behavior we wanted to model in MLIR regarding NaN, ±0.0 and friends. I think we just propagated the documentation from LLVM. In addition to the NaN misalignment, for example, I don’t think we ever honored the treating -0.0 as less than +0.0 behavior.
IMO, the first step to disentangle this would be to make a call on the variants we want to represent in MLIR, which is not easy at all.
In addition to the variants above we should also consider the variants from the ML frameworks, which may or may not fall into any of the above. IIRC, there were some subtleties and description gaps in some of the framework specs about the handling of the special floating-point numbers that make this problem even more challenging.
We should also take into account that whatever we decide about standalone fp min and max ops should be propagated to the reduction ops in some MLIR dialects (e.g., vector).
Perhaps aligning MLIR with the variants represented in LLVM would be a good way to go. I’m not familiar with the SPIRV ones. Are they significantly different?