[PATCH] D125234: [AArch64] Remove redundant f{min,max}nm intrinsics.

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a subscriber: scanon.
fhahn added a comment.

In D125234#3502984 <https://reviews.llvm.org/D125234#3502984>, @dmgreen wrote:

> Sounds good to me.
>
> Do we need aarch64_neon_fmaxnm? Or is it equivalent to llvm.fmaxnum? We convert it late in the backend, maybe we should be doing that in the frontend instead, and removing the need for aarch64_neon_fmaxnm entirely. It would allow a lot more optimizations like this without the need to implement them all specifically.

I *think* they behave differently with respect to signaling NaNs. IIUC `llvm.maxnum` always returns quite NaNs:

  ‘llvm.maxnum.*’ Intrinsic¶
  
  Follows the IEEE-754 semantics for maxNum except for the handling of signaling NaNs. This matches the behavior of libm’s fmax.
  
  If either operand is a NaN, returns the other non-NaN operand. Returns NaN only if both operands are NaN. The returned NaN is always quiet. If the operands compare equal, returns a value that compares equal to both operands. This means that fmax(+/-0.0, +/-0.0) could return either -0.0 or 0.0.

AArch64's `FMAXNM`'s says `NaNs are handled according to the IEEE 754-2008 standard.`, so it seems like it would handle signaling NaNs, but I may be wrong. Perhaps @scanon  knows more.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125234/new/

https://reviews.llvm.org/D125234