[PATCH] D87391: [Intrinsics] define semantics for experimental fmax/fmin vector reductions

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 9 09:18:05 PDT 2020


spatel created this revision.
spatel added reviewers: aemerson, nikic, craig.topper, efriedma, hfinkel, RKSimon.
Herald added subscribers: steven.zhang, dmgreen, hiraditya, kristof.beyls, mcrosier.
Herald added a reviewer: jdoerfert.
Herald added a project: LLVM.
spatel requested review of this revision.

As discussed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2020-April/140729.html

This is hopefully the final remaining showstopper before we can remove the 'experimental' from the reduction intrinsics.

No behavior was specified for the FP min/max reductions, so we have a mess of different interpretations.

There are a few potential options for the semantics of these max/min ops. I think this is the simplest based on current behavior/implementation: make the reductions inherit from the existing llvm.maxnum/minnum intrinsics. These correspond to libm fmax/fmin, and those are similar to the (now deprecated?) IEEE-754 maxNum/minNum functions (NaNs are treated as missing data). So the default expansion creates calls to libm functions.

Another option would be to inherit from llvm.maximum/minimum (NaNs propagate), but most targets just crash in codegen when given those nodes because no default expansion was ever implemented AFAICT.

We could also just assume 'nnan' semantics by default (we are already assuming 'nsz' semantics in the maxnum/minnum intrinsics), but some targets (AArch64, PowerPC) support the more defined behavior, so it doesn't make much sense to not allow a tighter spec. Fast-math-flags (nnan) can be used to loosen the semantics.

(Note that D67507 <https://reviews.llvm.org/D67507> was proposed to update the LangRef to acknowledge the more recent IEEE-754 2019 standard, but that patch seems to have stalled. If we do update based on the new standard, the reduction instructions can seamlessly inherit from whatever updates are made to the max/min intrinsics.)

x86 sees a regression here on 'nnan' tests because we have underlying, longstanding bugs in FMF creation/propagation. Those need to be fixed apart from this change (for example: https://llvm.org/PR35538). The expansion sequence before this patch may not have been correct.


https://reviews.llvm.org/D87391

Files:
  llvm/docs/LangRef.rst
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/lib/CodeGen/ExpandReductions.cpp
  llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
  llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/test/CodeGen/AArch64/vecreduce-fmax-legalization-nan.ll
  llvm/test/CodeGen/Generic/expand-experimental-reductions.ll
  llvm/test/CodeGen/Thumb2/mve-vecreduce-fminmax.ll
  llvm/test/CodeGen/Thumb2/mve-vecreduce-loops.ll
  llvm/test/CodeGen/X86/vector-reduce-fmax-nnan.ll
  llvm/test/CodeGen/X86/vector-reduce-fmax.ll
  llvm/test/CodeGen/X86/vector-reduce-fmin-nnan.ll
  llvm/test/CodeGen/X86/vector-reduce-fmin.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D87391.290737.patch
Type: text/x-patch
Size: 210363 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200909/42bfabd2/attachment-0001.bin>


More information about the llvm-commits mailing list