[all-commits] [llvm/llvm-project] 29a484: [Hexagon] Lower vreduce(min|max)((imum)?) (#211898)

[Fateme Hosseini via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 29a48499738db1829f9a6b71a38bc4461867a3c4
      https://github.com/llvm/llvm-project/commit/29a48499738db1829f9a6b71a38bc4461867a3c4
  Author: Fateme Hosseini <Fhossein at qti.qualcomm.com>
  Date:   2026-09-10 (Thu, 10 Sep 2026)

  Changed paths:
    M llvm/lib/Target/Hexagon/HexagonISelLowering.h
    M llvm/lib/Target/Hexagon/HexagonISelLoweringHVX.cpp
    M llvm/lib/Target/Hexagon/HexagonPatternsHVX.td
    A llvm/test/CodeGen/Hexagon/vreduce-fminmax-nan-fixup.ll
    A llvm/test/CodeGen/Hexagon/vreduce-max-lowering.ll
    A llvm/test/CodeGen/Hexagon/vreduce-min-lowering.ll

  Log Message:
  -----------
  [Hexagon] Lower vreduce(min|max)((imum)?) (#211898)

Add custom lowering for VECREDUCE_FMIN/FMAX/FMINIMUM/FMAXIMUM on HVX
float vector types. The target-independent default expansion reduces
these pairwise using the hardware min/max instruction directly, which
does not implement IEEE-754 NaN-propagation semantics: a NaN in the
input can silently corrupt the reduction result, and an all-NaN input
produces a non-NaN value instead of NaN.

The custom lowering strips NaN elements to the appropriate neutral value
(+/-Inf) before the pairwise tree reduction so a NaN can't corrupt other
lanes, then fixes up the scalar result to NaN if every input element was
NaN.

FMINNUM/FMAXNUM on HVX vector types get the same treatment: NaN operands
are replaced with the neutral value before delegating to the hardware
min/max, with a fixup to restore NaN when both operands were NaN (per
llvm.minnum/maxnum semantics).

Co-authored-by: Kaushik Kulkarni <kauskulk at qti.qualcomm.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications