[llvm] [LV][doc] Update and extend the docs on floating-point reduction vectorization (PR #172809)

[Tibor Győri via llvm-commits]

https://github.com/TiborGY updated https://github.com/llvm/llvm-project/pull/172809

>From 6eb45feae557776a711551efaa35568cd334d23f Mon Sep 17 00:00:00 2001
From: GYT <tiborgyri at gmail.com>
Date: Wed, 17 Dec 2025 06:41:00 +0100
Subject: [PATCH 1/5] Update and elaborate the status of floating point
 reduction vectorization

---
 llvm/docs/Vectorizers.rst | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/llvm/docs/Vectorizers.rst b/llvm/docs/Vectorizers.rst
index 0dfa33753cdd0..964164522c987 100644
--- a/llvm/docs/Vectorizers.rst
+++ b/llvm/docs/Vectorizers.rst
@@ -200,7 +200,22 @@ reduction operations, such as addition, multiplication, XOR, AND and OR.
     return sum;
   }
 
-We support floating point reduction operations when `-ffast-math` is used.
+The full vectorization of reductions inherently involves reordering operations,
+which is problematic for floating-point reductions. Since floating-point
+operations are not associative, the result may depend on the order of operations.
+Therefore, vectorizing floating-point reductions is implicitly prohibited by
+the C and C++ standards, unless the compiler can ensure that the result does
+not change.
+
+For this reason, on most targets we support floating point reduction operations
+only when `-ffast-math` (or at least the `-fassociative-math -fno-signed-zeros 
+-fno-trapping-math` subset of `-ffast-math`) is used. On select targets such as
+AArch64 and RISC-V we support generating ordered reductions which preserve the
+exact result, allowing a limited form of vectorization to take place while
+remaining standards-compliant. However, ordered reductions are typically less
+efficient than traditionally vectorized reductions, therefore enabling floating-
+point reordering may still result in more performant reductions on these
+targets.
 
 Inductions
 ^^^^^^^^^^

>From e0c057426dfadb3b709e37b808791c8d0819e77f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tibor=20Gy=C5=91ri?= <tibor.gyori at chem.u-szeged.hu>
Date: Fri, 2 Jan 2026 17:09:33 +0100
Subject: [PATCH 2/5] Suggestion 1

Co-authored-by: Florian Hahn <flo at fhahn.com>
---
 llvm/docs/Vectorizers.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/llvm/docs/Vectorizers.rst b/llvm/docs/Vectorizers.rst
index 964164522c987..1d60e5892c498 100644
--- a/llvm/docs/Vectorizers.rst
+++ b/llvm/docs/Vectorizers.rst
@@ -200,7 +200,7 @@ reduction operations, such as addition, multiplication, XOR, AND and OR.
     return sum;
   }
 
-The full vectorization of reductions inherently involves reordering operations,
+The full vectorization of reductions requires reordering operations,
 which is problematic for floating-point reductions. Since floating-point
 operations are not associative, the result may depend on the order of operations.
 Therefore, vectorizing floating-point reductions is implicitly prohibited by

>From 5129b2203b8ef171dbe38da5ff1fa1d9316aa8bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tibor=20Gy=C5=91ri?= <tibor.gyori at chem.u-szeged.hu>
Date: Fri, 2 Jan 2026 17:10:34 +0100
Subject: [PATCH 3/5] Suggestion 3

Co-authored-by: Florian Hahn <flo at fhahn.com>
---
 llvm/docs/Vectorizers.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/llvm/docs/Vectorizers.rst b/llvm/docs/Vectorizers.rst
index 1d60e5892c498..b8515afb2b76a 100644
--- a/llvm/docs/Vectorizers.rst
+++ b/llvm/docs/Vectorizers.rst
@@ -210,7 +210,7 @@ not change.
 For this reason, on most targets we support floating point reduction operations
 only when `-ffast-math` (or at least the `-fassociative-math -fno-signed-zeros 
 -fno-trapping-math` subset of `-ffast-math`) is used. On select targets such as
-AArch64 and RISC-V we support generating ordered reductions which preserve the
+AArch64 and RISC-V LLVM supports generating ordered reductions which preserve the
 exact result, allowing a limited form of vectorization to take place while
 remaining standards-compliant. However, ordered reductions are typically less
 efficient than traditionally vectorized reductions, therefore enabling floating-

>From 9f31b59b9dbc87ed6ac377b1caa449ff4a6aa14c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tibor=20Gy=C5=91ri?= <tibor.gyori at chem.u-szeged.hu>
Date: Fri, 2 Jan 2026 17:24:28 +0100
Subject: [PATCH 4/5] Suggestion 2

Co-authored-by: Florian Hahn <flo at fhahn.com>
---
 llvm/docs/Vectorizers.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/llvm/docs/Vectorizers.rst b/llvm/docs/Vectorizers.rst
index b8515afb2b76a..27c6c2be6c68e 100644
--- a/llvm/docs/Vectorizers.rst
+++ b/llvm/docs/Vectorizers.rst
@@ -207,9 +207,9 @@ Therefore, vectorizing floating-point reductions is implicitly prohibited by
 the C and C++ standards, unless the compiler can ensure that the result does
 not change.
 
-For this reason, on most targets we support floating point reduction operations
-only when `-ffast-math` (or at least the `-fassociative-math -fno-signed-zeros 
--fno-trapping-math` subset of `-ffast-math`) is used. On select targets such as
+Therefore LLVM supports vectorizing floating point reductions
+only when at least the `-fassociative-math -fno-signed-zeros 
+-fno-trapping-math` subset of `-ffast-math` is used on most targets. On select targets such as
 AArch64 and RISC-V LLVM supports generating ordered reductions which preserve the
 exact result, allowing a limited form of vectorization to take place while
 remaining standards-compliant. However, ordered reductions are typically less

>From 55306996e0e76a59225c730e85feef8b61c48c4f Mon Sep 17 00:00:00 2001
From: GYT <tiborgyri at gmail.com>
Date: Fri, 2 Jan 2026 17:33:44 +0100
Subject: [PATCH 5/5] implement suggestion 4

---
 llvm/docs/Vectorizers.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/llvm/docs/Vectorizers.rst b/llvm/docs/Vectorizers.rst
index 27c6c2be6c68e..1c151bbfa3a73 100644
--- a/llvm/docs/Vectorizers.rst
+++ b/llvm/docs/Vectorizers.rst
@@ -203,11 +203,9 @@ reduction operations, such as addition, multiplication, XOR, AND and OR.
 The full vectorization of reductions requires reordering operations,
 which is problematic for floating-point reductions. Since floating-point
 operations are not associative, the result may depend on the order of operations.
-Therefore, vectorizing floating-point reductions is implicitly prohibited by
-the C and C++ standards, unless the compiler can ensure that the result does
-not change.
 
-Therefore LLVM supports vectorizing floating point reductions
+Changing floating-point results is implicitly prohibited by the C and C++ standards,
+therefore LLVM supports vectorizing floating point reductions
 only when at least the `-fassociative-math -fno-signed-zeros 
 -fno-trapping-math` subset of `-ffast-math` is used on most targets. On select targets such as
 AArch64 and RISC-V LLVM supports generating ordered reductions which preserve the