RFC: What is the real behavior for the minnum/maxnum intrinsics?

Project Infrastructure LLVM Dev List Archives
1

Hi,

The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear right now to usefully optimize. There are two problems. First the expected behavior for signaling NaNs needs to be clarified. Second, whether the returned value is expected to be canonicalized (as if by llvm.canonicalize).

Currently according to the LangRef:

Follows the IEEE-754 semantics for minNum, which also match for libm’s
fmin.

If either operand is a NaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN. If the operands compare equal,
returns a value that compares equal to both operands. This means that
fmin(+/-0.0, +/-0.0) could return either -0.0 or 0.0.

This first line is a lie. This isn’t true for the case of signaling NaNs. The IEEE rule is if either input is a signaling nan, it returns a quieted NaN, not the other operand. The C standard definition for fmin/fmax do not make this distinction, and just return the other operand.

The constant folding for these currently match the libm behavior, returning the non-NaN operand and will never quiet. The default lowering for these operations also just directly calls the system’s fmin/fmax.

Additionally, the IEEE standard specifies that minNum/maxNum return the “canonicalized” value. If the returned value is a NaN, my understanding of this is that the payload bits of the NaN are all 0 even if this was not the case for the input NaNs. This also contradicts just returning the raw value of the other operand if one is a NaN as will happen in the implemented constant folding and libm lowering.

On AMDGPU we select these to instructions that have either behavior, depending on a flag that can be considered part of the global floating point mode. We default to enabling the IEEE behavior, returning a quieted nan. In order to match the expected behavior of fmin/fmax in the OpenCL builtin library, we use llvm.canonicalize to quiet the incoming NaNs to the minnum/maxnum intrinsics. This is approximately tripling the number of instructions inside the inner loops of an important kernel, where min/max are feeding into each other. My goal is to eliminate the canonicalizes, since the output of min/max is supposed to be canonical. I don’t necessarily care about getting correct FP exception behavior, but I do need these to return the correct value for signaling nans loaded from memory.

Since these intrinsics do have the IEEE name, I think they should probably be change to match the IEEE behavior. This would mean that optimizing
llvm.canonicalize(llvm.minnum(x, y)) → llvm.minnum(x, y) is a correct transformation. Target lowering would then be expected to insert quieting canonicalizes for the inputs to the libm fmin call. Do we need another pair of intrinsics matching the fmin/fmax behavior?

TLDR:

  1. What do these do for signaling NaNs?
  2. If the target expects something to happen during llvm.canonicalize (e.g. flush denormals), can this be assumed to have been done by the implementation of llvm.minnum/maxnum?

-Matt

2

Sadly I can't seem to find an actual copy of the draft of the IEEE
754-201x standard, but I understand that it introduces new min/max
functions that better match the min/max actually implemented by
hardware and used in languages
<https://github.com/WebAssembly/design/issues/214&gt;\. I agree, the first
sentence you quote doesn't seem correct. Perhaps someone more familiar
with the IEEE 754 development can give more insight.

Best,

Alex

3

It’s a bit more subtle.

The minNum, maxNum, minNumMag, and maxNumMag operations have been removed from the normative clauses of IEEE 754 201x entirely, and replaced with a set of non-normative recommended operations. This is not a great situation, because it doesn’t provide much clarity for complier writers or CPU architects, but it at least removes the existing operations which were known to be critically flawed, due to them not being associative.

The new non-normative operations of interest are defined in clause 9.6:

  1. minimum / maximum: returns NaN if any input is NaN.
  2. minimumNumber / maximumNumber: return NaN only if every input is NaN, even if signaling NaNs are present.

Otherwise returns the numerical min / max ordering –0 before +0. The behavior of ordering zeros is a critical distinction from the behavior of the old operations, possibly more critical than the signaling NaN behavior.

I can’t in good faith recommend jumping to implement these semantics, because they are non-normative. They make sense, but there are other definitions that make sense as well, so there’s no guarantee that IEEE 754 won’t tweak them before adopting them in a normative clause in the next revision. I can’t really argue against adopting them either, because they do make perfect sense.

Some notes on how these definitions align with existing architectures of interest:

ARMv8:

  1. FMIN / FMAX implement the new minimum / maximum exactly.
  2. FMINNM / FMAXNM implement minimumNumber / maximumNumber if we can prove no sNaNs are present. If sNaN may be present, we need to canonicalize each argument first.

X86:

  1. AFAIK there’s no trivial instruction for minimum / maximum, because MINxx / MAXxx return the second argument if either is NaN. So this will look like a compare + min/max + select, I think.
  2. The new AVX-512 VRANGExx can be used to implement minimumNumber / maximumNumber if we can prove no sNaNs are present. If sNaN may be present, we need to canonicalize each argument first. Pre-AVX-512, this is also compare + min/max + select.

Someone else will need to provide details for other arches.
– Steve

4

The AMDGPU instructions in the default mode for compute match #2 here. They also do seem to preserve the new signed 0 behavior.

If we can settle on stating explicitly the in the LangRef that de-facto current behavior where the signalingness of a NaN is ignored here, that would allow solving my immediate problems. The required lowering code would be clear and optimizable. This isn’t ideal but at as far as the current standard is concerned, this fits with sNaN being generally broken in LLVM (e.g. constant folding for every operation doesn’t bother quieting them)

This is the only part that I immediately care about. When the new standard is finalized, we can re-visit the other details such as the signed 0 question. Are there any targets that don’t already treat -0.0 as < 0.0?

-Matt

5

[V]MINxx and [V]MAXxx on x86 return the second argument if the arguments compare equal (but they also don’t handle NaNs “correctly” — they’re really intended to pattern match (a < b ? a : b) instead of the fmin / fmax libm functions.

The newer AVX-512 VRANGExx functions get the sign of zero right.

– Steve

6

Given that I believe we don’t generally support SNaN currently, this seems consistent to me. -Hal

7

We have to raise this problem again, since glibc changed the behavior of fmin(3)/fmax(3) since 2021.

If both arguments are NaN, or either is a signaling NaN, NaN is returned.
8

And source like

double fmin(double, double);

double f(double a, double b) {
        return fmin(a, b);
}

is compiler to

fminnm  d0, d0, d1

on aarch64, which may be not true for C23.