[clang] constexpr built-in reduce add function.

[c8ef]

Part of #51787.

This patch adds constexpr support for the built-in reduce add function. If this is the right way to go, I will add support for other reduce functions in later patches.

[llvmbot]

@llvm/pr-subscribers-clang

Author: None (c8ef)

Changes

Part of #51787.

This patch adds constexpr support for the built-in reduce add function. If this is the right way to go, I will add support for other reduce functions in later patches.

---

Full diff: https://github.com/llvm/llvm-project/pull/116243.diff

4 Files Affected:

• (modified) clang/docs/ReleaseNotes.rst (+2)
• (modified) clang/include/clang/Basic/Builtins.td (+1-1)
• (modified) clang/lib/AST/ExprConstant.cpp (+14)
• (modified) clang/test/Sema/constant_builtins_vector.cpp (+6)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 78ba70c624d18c..2bc2bda663168e 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -353,6 +353,8 @@ Non-comprehensive list of changes in this release
   The flexible array member (FAM) can now be accessed immediately without causing
   issues with the sanitizer because the counter is automatically set.
 
+- ``__builtin_reduce_add`` function can now be used in constant expressions.
+
 New Compiler Flags
 ------------------
 
diff --git a/clang/include/clang/Basic/Builtins.td b/clang/include/clang/Basic/Builtins.td
index e866605ac05c09..a17e1353b2e1b4 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -1504,7 +1504,7 @@ def ReduceAnd : Builtin {
 
 def ReduceAdd : Builtin {
   let Spellings = ["__builtin_reduce_add"];
-  let Attributes = [NoThrow, Const, CustomTypeChecking];
+  let Attributes = [NoThrow, Const, CustomTypeChecking, Constexpr];
   let Prototype = "void(...)";
 }
 
diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index d664c503655ba6..e9fb3b4b00d164 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -13528,6 +13528,20 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const CallExpr *E,
     return Success(DidOverflow, E);
   }
 
+  case Builtin::BI__builtin_reduce_add: {
+    APValue Source;
+    if (!EvaluateAsRValue(Info, E->getArg(0), Source))
+      return false;
+
+    auto SourceLen = Source.getVectorLength();
+    APSInt Reduced = Source.getVectorElt(0).getInt();
+    for (unsigned EltNum = 1; EltNum < SourceLen; ++EltNum) {
+      Reduced += Source.getVectorElt(EltNum).getInt();
+    }
+
+    return Success(Reduced, E);
+  }
+
   case clang::X86::BI__builtin_ia32_addcarryx_u32:
   case clang::X86::BI__builtin_ia32_addcarryx_u64:
   case clang::X86::BI__builtin_ia32_subborrow_u32:
diff --git a/clang/test/Sema/constant_builtins_vector.cpp b/clang/test/Sema/constant_builtins_vector.cpp
index c6b1b37cef28b4..6d2db6e5111eff 100644
--- a/clang/test/Sema/constant_builtins_vector.cpp
+++ b/clang/test/Sema/constant_builtins_vector.cpp
@@ -723,3 +723,9 @@ not within the bounds of the input vectors; index of -1 found at position 0 is n
 permitted in a constexpr context}}
         vector4charConst1,
         vector4charConst2, -1, -1, -1, -1);
+
+static_assert(__builtin_reduce_add((vector4char){}) == 0);
+static_assert(__builtin_reduce_add((vector4char){1, 2, 3, 4}) == 10);
+static_assert(__builtin_reduce_add((vector4short){10, 20, 30, 40}) == 100);
+static_assert(__builtin_reduce_add((vector4int){100, 200, 300, 400}) == 1000);
+static_assert(__builtin_reduce_add((vector4long){1000, 2000, 3000, 4000}) == 10000);

[RKSimon]

This seems reasonable to me - I'd recommend you take a look at the min/max reductions to see if signed/unsigned can be correctly handled with this approach.

[RKSimon]

(style) Avoid auto

[c8ef]

Done.

[RKSimon]

How is this handled? I'd have expected Source.getVectorElt(0).getInt() to have failed?

[c8ef]

I believe this is similar to zero initializing a vector with 4 char elements.

[c8ef]

This seems reasonable to me - I'd recommend you take a look at the min/max reductions to see if signed/unsigned can be correctly handled with this approach.

Thank you for your suggestions! Signed integer overflow in C++ is undefined behavior and cannot occur in a constexpr context. I have addressed the issue in the latest revision.

[Fznamznon]

LGTM, thanks!

[RKSimon]

Thanks @c8ef - are you OK to add the remaining integer reduction cases next? Also, please can you also update the LanguageExtensions docs page to mention that they are constexpr legal?

[c8ef]

Thanks @c8ef - are you OK to add the remaining integer reduction cases next? Also, please can you also update the LanguageExtensions docs page to mention that they are constexpr legal?

Will do.