let Neon builtin function accept a const variable

[scout-zeng]

FORCE_INLINE __m128i _mm_sll_epi64(__m128i a, __m128i count) { long long c = count.vect_s64[0]; const int mc = c; __m128i result_m128i; if (likely(c >= 0 && c < 64)) { result_m128i.vect_s64 = vshlq_n_s64(a.vect_s64, mc); } else { result_m128i.vect_s64 = vdupq_n_s64(0); } return result_m128i; }
vshlq_n_s64 is an Neon intrinsics, 2nd parameter of this function needs a const int, however it failed in current CLANG Latest version. This patch used to support this feature which make Neon intrinsics can receive a const int variable instead of literal.

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-clang

Author: None (scout-zeng)

Changes

FORCE_INLINE __m128i _mm_sll_epi64(__m128i a, __m128i count) { long long c = count.vect_s64[0]; const int mc = c; __m128i result_m128i; if (likely(c >= 0 && c < 64)) { result_m128i.vect_s64 = vshlq_n_s64(a.vect_s64, mc); } else { result_m128i.vect_s64 = vdupq_n_s64(0); } return result_m128i; }
vshlq_n_s64 is an Neon intrinsics, 2nd parameter of this function needs a const int, however it failed in current CLANG Latest version. This patch used to support this feature which make Neon intrinsics can receive a const int variable instead of literal.

---

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

1 Files Affected:

• (modified) clang/lib/Sema/SemaChecking.cpp (+4-3)

diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 69276ce418fa6..f9fc0ff536254 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -5666,11 +5666,12 @@ bool Sema::BuiltinConstantArg(CallExpr *TheCall, int ArgNum,
 
   if (Arg->isTypeDependent() || Arg->isValueDependent()) return false;
 
-  std::optional<llvm::APSInt> R;
-  if (!(R = Arg->getIntegerConstantExpr(Context)))
+  Expr::EvalResult evalRes;
+  if (!Arg->EvaluateAsInt(evalRes, Context)) {
     return Diag(TheCall->getBeginLoc(), diag::err_constant_integer_arg_type)
            << FDecl->getDeclName() << Arg->getSourceRange();
-  Result = *R;
+  }
+  Result = evalRes.Val.getInt();
   return false;
 }
 

[scout-zeng]

@efriedma-quic Hi Eli, if there is any problem, please let me know.

[efriedma-quic]

Needs regression tests (in clang/test/Sema/). For NEON intrinsics, and whatever other classes of intrinsics are affected by this.

Please add a reference to the issue in the commit message, like "fixes #139033" (the initial comment on the pull request will become the commit message when it's merged).

#139033 (comment) suggested we want to warn when we do non-standard folding like this.

[scout-zeng]

fixes #139033

[scout-zeng]

Hi @efriedma-quic , I do not think this workaround can fix this issue. Because the clang compiler still gives me an error like 'argument to xxx must be a constant integer", which means the if condition in line 5670 is not true. I am confused about that. Can you give me some suggestions ?

[efriedma-quic]

I think something like your patch solves the original testcase from #139033. (Actually, it crashes in codegen, but that's an easy fix.) And I thought you wanted specifically that...?

Your new testcase will never work; the NEON intrinsic is specifically specified to only allow operands which produce an immediate encoding. For a shift with a variable amount, you want something like vshlq_s64(a.vect_s64, vdupq_n_s64(mc));.

[scout-zeng]

I think something like your patch solves the original testcase from #139033. (Actually, it crashes in codegen, but that's an easy fix.) And I thought you wanted specifically that...?

Your new testcase will never work; the NEON intrinsic is specifically specified to only allow operands which produce an immediate encoding. For a shift with a variable amount, you want something like vshlq_s64(a.vect_s64, vdupq_n_s64(mc));.

Actually, I agree #139033 can be solved by this patch.
Just as you mentioned, Neon Intrinsic is only allowed immediate code. What can I do if I want to allow operands like variables?
Could you help evaluate the magnitude of this workload and whether it is feasible, from the perspective of the Clang compiler?

[efriedma-quic]

The NEON intrinsics specification (https://developer.arm.com/architectures/instruction-sets/intrinsics/vshl_n_s64) specifically says the argument must be an immediate in the specified range. That's because it's supposed to map to an instruction which encodes the shift amount into the instruction itself. We aren't allowed to accept anything else.

As I mentioned, there are other ways to write constructs with equivalent semantics.