[llvm-dev] RFC: What is the real behavior for the minnum/maxnum intrinsics?

[Arsenault, Matthew via llvm-dev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180723/0e4aa0d4/attachment-0001.html>