[clang] [clang][Interp] Zero-init remaining string literal elements (PR #66862)

2023-09-27 Thread Timm Baeder via cfe-commits

tbaederr wrote:

Ping

https://github.com/llvm/llvm-project/pull/66862
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread Fangrui Song via cfe-commits

https://github.com/MaskRay approved this pull request.


https://github.com/llvm/llvm-project/pull/67515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread Fangrui Song via cfe-commits

https://github.com/MaskRay edited 
https://github.com/llvm/llvm-project/pull/67515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread Fangrui Song via cfe-commits


@@ -401,6 +401,30 @@
 // CHECK338-NOT: "--end-group"
 // CHECK338: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/fini.o"
 
+// RUN: %clangxx -### -target hexagon-unknown-elf \
+// RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
+// RUN:   -mcpu=hexagonv60 \
+// RUN:   -nolibc \
+// RUN:   %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-NOLIBC %s
+// CHECK-NOLIBC: "-cc1"
+// CHECK-NOLIBC: {{hexagon-link|ld}}
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0_standalone.o"
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0.o"
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/init.o"
+// CHECK-NOLIBC: 
"-L{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60"
+// CHECK-NOLIBC: "-L{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib"
+// CHECK-NOLIBC: "{{[^"]+}}.o"
+// CHECK-NOLIBC: "-lstdc++"
+// CHECK-NOLIBC: "-lm"

MaskRay wrote:

The pattern `{{hexagon-link|ld}}` is too broad. The `ld` part may match `clang 
-cc1 .../build/` if someone's build directory is called `build` (`ld` is a 
substring!).

With `-fuse-ld=lld`, we can ensure that the linker is not affected by 
`CLANG_DEFAULT_LINKER` and `"{{.*}}ld.lld"` will occur...

https://github.com/llvm/llvm-project/pull/67515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libunwind] [libc++][lit] Allow overriding the executor for tests (PR #66545)

2023-09-27 Thread Vladimir Vereschaka via cfe-commits

vvereschaka wrote:

[executorfix.diff.txt](https://github.com/llvm/llvm-project/files/12745676/executorfix.diff.txt)

@arichardson ,

here is few updates for your fix (please see attached file):
* added an escaping of quotes for the serialized lit parameter. There could be 
an executor string something like that `"C:/Python310/python.exe" 
"C:/buildbot/temp/llvm-project/libcxx/utils/ssh.py" 
--host=ubu...@jetson6.lab.llvm.org`. We need to replace `"` with `\"` because 
it goes into the python's string.
* the test parameters are processing as a cmake list. We need to properly 
prepare `xxx_LIBxxx_TEST_PARAMS` variables in the cmake cache file.

The `libunwind` and `libc++abi` tests are passed successfully with these 
changes. I have started the `libc++` tests. It will take about 1 hour, but they 
already started successfully. These changes are working properly on the win 
cross toolchain builders.

https://github.com/llvm/llvm-project/pull/66545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [libc++][lit] Allow overriding the executor for tests (PR #66545)

2023-09-27 Thread Vladimir Vereschaka via cfe-commits

vvereschaka wrote:

[executorfix.diff.txt](https://github.com/llvm/llvm-project/files/12745676/executorfix.diff.txt)

@arichardson ,

here is few updates for your fix (please see attached file):
* added an escaping of quotes for the serialized lit parameter. There could be 
an executor string something like that `"C:/Python310/python.exe" 
"C:/buildbot/temp/llvm-project/libcxx/utils/ssh.py" 
--host=ubu...@jetson6.lab.llvm.org`. We need to replace `"` with `\"` because 
it goes into the python's string.
* the test parameters are processing as a cmake list. We need to properly 
prepare `xxx_LIBxxx_TEST_PARAMS` variables in the cmake cache file.

The `libunwind` and `libc++abi` tests are passed successfully with these 
changes. I have started the `libc++` tests. It will take about 1 hour, but they 
already started successfully. These changes are working properly on the win 
cross toolchain builders.

https://github.com/llvm/llvm-project/pull/66545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread via cfe-commits


@@ -401,6 +401,30 @@
 // CHECK338-NOT: "--end-group"
 // CHECK338: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/fini.o"
 
+// RUN: %clangxx -### -target hexagon-unknown-elf \
+// RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
+// RUN:   -mcpu=hexagonv60 \
+// RUN:   -nolibc \
+// RUN:   %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-NOLIBC %s
+// CHECK-NOLIBC: "-cc1"
+// CHECK-NOLIBC: {{hexagon-link|ld}}
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0_standalone.o"
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0.o"
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/init.o"
+// CHECK-NOLIBC: 
"-L{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60"
+// CHECK-NOLIBC: "-L{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib"
+// CHECK-NOLIBC: "{{[^"]+}}.o"
+// CHECK-NOLIBC: "-lstdc++"
+// CHECK-NOLIBC: "-lm"

androm3da wrote:

I may have done `-SAME` to excess. This test passes locally but fails on some 
of the bots because `hexagon-link` isn't on the same line as the subsequent 
`... crt0_standalone.o`.  Wouldn't have thought that behavior would be 
system-dependent but perhaps we can be less strict about this test.

https://github.com/llvm/llvm-project/pull/67515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 53a87b4 - [clang-repl] Disable LSan in clang-repl.

2023-09-27 Thread Lang Hames via cfe-commits

Author: Lang Hames
Date: 2023-09-27T21:39:48-07:00
New Revision: 53a87b4a6903c0c47337ca18697bb6355cc087d4

URL: 
https://github.com/llvm/llvm-project/commit/53a87b4a6903c0c47337ca18697bb6355cc087d4
DIFF: 
https://github.com/llvm/llvm-project/commit/53a87b4a6903c0c47337ca18697bb6355cc087d4.diff

LOG: [clang-repl] Disable LSan in clang-repl.

https://llvm.org/github.com/llvm/llvm-project/issues/67586.

Added: 


Modified: 
clang/tools/clang-repl/ClangRepl.cpp

Removed: 




diff  --git a/clang/tools/clang-repl/ClangRepl.cpp 
b/clang/tools/clang-repl/ClangRepl.cpp
index a29a2ebac434ab5..5663c2c5a6c9285 100644
--- a/clang/tools/clang-repl/ClangRepl.cpp
+++ b/clang/tools/clang-repl/ClangRepl.cpp
@@ -24,6 +24,14 @@
 #include "llvm/Support/TargetSelect.h"
 #include 
 
+// Disable LSan for this test.
+// FIXME: Re-enable once we can assume GCC 13.2 or higher.
+// https://llvm.org/github.com/llvm/llvm-project/issues/67586.
+#if LLVM_ADDRESS_SANITIZER_BUILD || LLVM_HWADDRESS_SANITIZER_BUILD
+#include 
+LLVM_ATTRIBUTE_USED int __lsan_is_turned_off() { return 1; }
+#endif
+
 static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
 static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
 static llvm::cl::opt OffloadArch("offload-arch", 
llvm::cl::Hidden);



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 0d8b864 - CGBuiltin: emit llvm.abs.* instead of neg+icmp+select for abs

2023-09-27 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2023-09-27T21:29:56-07:00
New Revision: 0d8b864829073cf6f0a40f1b257d6631fc4145d0

URL: 
https://github.com/llvm/llvm-project/commit/0d8b864829073cf6f0a40f1b257d6631fc4145d0
DIFF: 
https://github.com/llvm/llvm-project/commit/0d8b864829073cf6f0a40f1b257d6631fc4145d0.diff

LOG: CGBuiltin: emit llvm.abs.* instead of neg+icmp+select for abs

instcombine will combine neg+icmp+select to llvm.abs.*. Let's just emit
llvm.abs.* in the first place.

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
clang/test/CodeGen/abs-overflow.c
clang/test/CodeGen/builtin-abs.c
clang/test/CodeGenCXX/builtins.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 04c0325c7fd038b..b0fd38408806566 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -1769,12 +1769,9 @@ Value *CodeGenFunction::EmitCheckedArgForBuiltin(const 
Expr *E,
 }
 
 static Value *EmitAbs(CodeGenFunction , Value *ArgValue, bool HasNSW) {
-  // X < 0 ? -X : X
-  // TODO: Use phi-node (for better SimplifyCFGPass)
-  Value *NegOp = CGF.Builder.CreateNeg(ArgValue, "neg", false, HasNSW);
-  Constant *Zero = llvm::Constant::getNullValue(ArgValue->getType());
-  Value *CmpResult = CGF.Builder.CreateICmpSLT(ArgValue, Zero, "abscond");
-  return CGF.Builder.CreateSelect(CmpResult, NegOp, ArgValue, "abs");
+  return CGF.Builder.CreateBinaryIntrinsic(
+  Intrinsic::abs, ArgValue,
+  ConstantInt::get(CGF.Builder.getInt1Ty(), HasNSW));
 }
 
 static Value *EmitOverflowCheckedAbs(CodeGenFunction , const CallExpr *E,

diff  --git a/clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c 
b/clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
index 64bd6e3ed41e8bb..2ef4c28a5e999a4 100644
--- a/clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
+++ b/clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
@@ -17,9 +17,7 @@ typedef __SIZE_TYPE__ size_t;
 // BOTH-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
 // BOTH-NEXT:store i32 [[A:%.*]], ptr [[A_ADDR]], align 4
 // BOTH-NEXT:[[TMP0:%.*]] = load i32, ptr [[A_ADDR]], align 4
-// BOTH-NEXT:[[NEG:%.*]] = sub nsw i32 0, [[TMP0]]
-// BOTH-NEXT:[[ABSCOND:%.*]] = icmp slt i32 [[TMP0]], 0
-// BOTH-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i32 [[NEG]], i32 [[TMP0]]
+// BOTH-NEXT:[[ABS:%.*]] = call i32 @llvm.abs.i32(i32 %0, i1 true)
 // BOTH-NEXT:ret i32 [[ABS]]
 signed int testabs(signed int a) {
   return __abs(a);
@@ -30,9 +28,7 @@ signed int testabs(signed int a) {
 // 64BIT-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
 // 64BIT-NEXT:store i64 [[A:%.*]], ptr [[A_ADDR]], align 8
 // 64BIT-NEXT:[[TMP0:%.*]] = load i64, ptr [[A_ADDR]], align 8
-// 64BIT-NEXT:[[NEG:%.*]] = sub nsw i64 0, [[TMP0]]
-// 64BIT-NEXT:[[ABSCOND:%.*]] = icmp slt i64 [[TMP0]], 0
-// 64BIT-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i64 [[NEG]], i64 
[[TMP0]]
+// 64BIT-NEXT:[[ABS:%.*]] = call i64 @llvm.abs.i64(i64 [[TMP0]], i1 true)
 // 64BIT-NEXT:ret i64 [[ABS]]
 //
 // 32BIT-LABEL: @testlabs(
@@ -40,9 +36,7 @@ signed int testabs(signed int a) {
 // 32BIT-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
 // 32BIT-NEXT:store i32 [[A:%.*]], ptr [[A_ADDR]], align 4
 // 32BIT-NEXT:[[TMP0:%.*]] = load i32, ptr [[A_ADDR]], align 4
-// 32BIT-NEXT:[[NEG:%.*]] = sub nsw i32 0, [[TMP0]]
-// 32BIT-NEXT:[[ABSCOND:%.*]] = icmp slt i32 [[TMP0]], 0
-// 32BIT-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i32 [[NEG]], i32 
[[TMP0]]
+// 32BIT-NEXT:[[ABS:%.*]] = call i32 @llvm.abs.i32(i32 [[TMP0]], i1 true)
 // 32BIT-NEXT:ret i32 [[ABS]]
 //
 signed long testlabs(signed long a) {
@@ -54,9 +48,7 @@ signed long testlabs(signed long a) {
 // 64BIT-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
 // 64BIT-NEXT:store i64 [[A:%.*]], ptr [[A_ADDR]], align 8
 // 64BIT-NEXT:[[TMP0:%.*]] = load i64, ptr [[A_ADDR]], align 8
-// 64BIT-NEXT:[[NEG:%.*]] = sub nsw i64 0, [[TMP0]]
-// 64BIT-NEXT:[[ABSCOND:%.*]] = icmp slt i64 [[TMP0]], 0
-// 64BIT-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i64 [[NEG]], i64 
[[TMP0]]
+// 64BIT-NEXT:[[ABS:%.*]] = call i64 @llvm.abs.i64(i64 [[TMP0]], i1 true)
 // 64BIT-NEXT:ret i64 [[ABS]]
 //
 // 32BIT-LABEL: @testllabs(
@@ -64,9 +56,7 @@ signed long testlabs(signed long a) {
 // 32BIT-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
 // 32BIT-NEXT:store i64 [[A:%.*]], ptr [[A_ADDR]], align 8
 // 32BIT-NEXT:[[TMP0:%.*]] = load i64, ptr [[A_ADDR]], align 8
-// 32BIT-NEXT:[[NEG:%.*]] = sub nsw i64 0, [[TMP0]]
-// 32BIT-NEXT:[[ABSCOND:%.*]] = icmp slt i64 [[TMP0]], 0
-// 32BIT-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i64 [[NEG]], i64 
[[TMP0]]
+// 32BIT-NEXT:[[ABS:%.*]] = call i64 @llvm.abs.i64(i64 [[TMP0]], i1 true)
 // 32BIT-NEXT:ret i64 

[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread via cfe-commits


@@ -401,6 +401,30 @@
 // CHECK338-NOT: "--end-group"
 // CHECK338: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/fini.o"
 
+// RUN: %clangxx -### -target hexagon-unknown-elf \
+// RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
+// RUN:   -mcpu=hexagonv60 \
+// RUN:   -nolibc \
+// RUN:   %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-NOLIBC %s
+// CHECK-NOLIBC: "-cc1"
+// CHECK-NOLIBC: {{hexagon-link|ld}}
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0_standalone.o"
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0.o"
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/init.o"
+// CHECK-NOLIBC: 
"-L{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60"
+// CHECK-NOLIBC: "-L{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib"
+// CHECK-NOLIBC: "{{[^"]+}}.o"
+// CHECK-NOLIBC: "-lstdc++"
+// CHECK-NOLIBC: "-lm"

androm3da wrote:

> I'll tidy this test a bit first...

Oh whoops I didn't see this.  I'll rebase.

https://github.com/llvm/llvm-project/pull/67515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread via cfe-commits

https://github.com/androm3da updated 
https://github.com/llvm/llvm-project/pull/67515

>From 87db8df7385b87f92f3bba2f80041e79039de78e Mon Sep 17 00:00:00 2001
From: Brian Cain 
Date: Wed, 27 Sep 2023 21:07:05 -0700
Subject: [PATCH 1/2] [clang][hexagon] Change driver tests to "--target="

`-target` has been deprecated, we can switch the tests to using `--target`
instead.
---
 clang/test/Driver/hexagon-hvx-ieee-fp.c |   6 +-
 clang/test/Driver/hexagon-hvx-qfloat.c  |   6 +-
 clang/test/Driver/hexagon-hvx.c | 174 ++--
 clang/test/Driver/hexagon-long-calls.c  |   6 +-
 clang/test/Driver/hexagon-memops.c  |   4 +-
 clang/test/Driver/hexagon-nvj.c |   4 +-
 clang/test/Driver/hexagon-nvs.c |   4 +-
 clang/test/Driver/hexagon-packets.c |   4 +-
 clang/test/Driver/hexagon-toolchain-elf.c   |  86 +-
 clang/test/Driver/hexagon-toolchain-linux.c |  20 +--
 clang/test/Driver/hexagon-vectorize.c   |   8 +-
 11 files changed, 161 insertions(+), 161 deletions(-)

diff --git a/clang/test/Driver/hexagon-hvx-ieee-fp.c 
b/clang/test/Driver/hexagon-hvx-ieee-fp.c
index 4166d640b6faa51..0e502941d62a999 100644
--- a/clang/test/Driver/hexagon-hvx-ieee-fp.c
+++ b/clang/test/Driver/hexagon-hvx-ieee-fp.c
@@ -2,13 +2,13 @@
 // Tests for the hvx ieee fp feature and errors.
 // 
-
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv68 -mhvx 
-mhvx-ieee-fp \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx 
-mhvx-ieee-fp \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-IEEEFP %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv66 -mhvx=v68 
-mhvx-ieee-fp \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv66 -mhvx=v68 
-mhvx-ieee-fp \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-IEEEFP %s
 // CHECK-IEEEFP: "-target-feature" "+hvx-ieee-fp"
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv68 -mhvx 
-mhvx-ieee-fp \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx 
-mhvx-ieee-fp \
 // RUN:  -mno-hvx-ieee-fp 2>&1 | FileCheck -check-prefix=CHECK-NO-IEEEFP %s
 // CHECK-NO-IEEEFP: "-target-feature" "-hvx-ieee-fp"
 
diff --git a/clang/test/Driver/hexagon-hvx-qfloat.c 
b/clang/test/Driver/hexagon-hvx-qfloat.c
index ac3de8ded16ebd6..f3662da040a8fcf 100644
--- a/clang/test/Driver/hexagon-hvx-qfloat.c
+++ b/clang/test/Driver/hexagon-hvx-qfloat.c
@@ -2,13 +2,13 @@
 // Tests for the hvx qfloat feature and errors.
 // 
-
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv68 -mhvx -mhvx-qfloat 
\
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx 
-mhvx-qfloat \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-QFLOAT %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv66 -mhvx=v68 
-mhvx-qfloat \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv66 -mhvx=v68 
-mhvx-qfloat \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-QFLOAT %s
 // CHECK-QFLOAT: "-target-feature" "+hvx-qfloat"
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv68 -mhvx -mhvx-qfloat 
\
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx 
-mhvx-qfloat \
 // RUN:  -mno-hvx-qfloat 2>&1 | FileCheck -check-prefix=CHECK-NO-QFLOAT %s
 // CHECK-NO-QFLOAT: "-target-feature" "-hvx-qfloat"
 
diff --git a/clang/test/Driver/hexagon-hvx.c b/clang/test/Driver/hexagon-hvx.c
index b57cc22515c2979..d21d88701ba5eff 100644
--- a/clang/test/Driver/hexagon-hvx.c
+++ b/clang/test/Driver/hexagon-hvx.c
@@ -8,31 +8,31 @@
 // CHECK-HVX-ON-NOT:  "-target-feature" "-hvx
 // CHECK-HVX-OFF-NOT: "-target-feature" "+hvx
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv5 \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv5 \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-HVX-OFF %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv55 \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv55 \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-HVX-OFF %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv60 \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv60 \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-HVX-OFF %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv62 \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv62 \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-HVX-OFF %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv65 \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv65 \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-HVX-OFF %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv66 \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv66 \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-HVX-OFF %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv67 \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv67 \
 // 

[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -757,6 +772,17 @@ getTOCEntryTypeForMO(const MachineOperand ) {
 llvm_unreachable("Unexpected operand type to get TOC type.");
   }
 }
+
+// FIXME: find alternative approach to get rid of this hack.
+// On AIX, TLS-local-dynamic requires that the symbol for the module handle 
must
+// have the name "_$TLSML". This symbol is used as one TOC symbol reference
+// itself with an ML relocation type, thus it has "[TC]" attached to its name.

amy-kwan wrote:

```suggestion
// FIXME: find an alternative approach to get rid of this hack.
// On AIX, TLS-local-dynamic requires that the symbol for the module handle must
// have the name "_$TLSML". This symbol is used as one TOC symbol reference
// with an @ml relocation specifier, thus it has "[TC]" attached to its name.
```
Maybe this makes a bit more sense?

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -370,11 +370,23 @@ namespace llvm {
 /// G8RC = TLSGD_AIX, TOC_ENTRY, TOC_ENTRY
 /// Op that combines two register copies of TOC entries
 /// (region handle into R3 and variable offset into R4) followed by a
-/// GET_TLS_ADDR node which will be expanded to a call to __get_tls_addr.
+/// GET_TLS_ADDR node which will be expanded to a call to .__tls_get_addr.
 /// This node is used in 64-bit mode as well (in which case the result is
 /// G8RC and inputs are X3/X4).
 TLSGD_AIX,
 
+/// %x3 = GET_TLS_MOD_AIX _$TLSML - For the AIX local-dynamic TLS model,
+/// produces a call to .__tls_get_mod(_$TLSML\@ml).
+GET_TLS_MOD_AIX,
+
+/// [GP|G8]RC = TLSLD_AIX, TOC_ENTRY(variable offset)
+/// Op that internally creates a TOC entry for the "_$TLSML" symbol, and
+/// generates a GET_TLS_MOD_AIX node which will be expanded into a call to
+/// .__tls_get_mod, and then adds the variable offset with the result from
+/// the call. This node is used in both 32-bit and 64-bit modes. The only
+/// difference is register class.

amy-kwan wrote:

```suggestion
/// difference is the register class.
```

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -145,9 +163,88 @@ namespace {
   .addImm(0);
 
 if (IsAIX) {
-  // The variable offset and region handle are copied in r4 and r3. The
-  // copies are followed by GETtlsADDR32AIX/GETtlsADDR64AIX.
-  if (!IsTLSTPRelMI) {
+  if (IsTLSLDAIXMI) {
+// It is better to put TLSLDAIX node before LoadOffsetToc node,
+// because LoadOffsetToc node can use clobbers r4/r5. Search for 
the
+// first paired LoadOffsetToc node within the same BB.
+unsigned LDTocOp =
+Is64Bit ? (IsLargeModel ? PPC::LDtocL : PPC::LDtoc)
+: (IsLargeModel ? PPC::LWZtocL : PPC::LWZtoc);
+MachineBasicBlock::iterator Anchor = I;
+if (!RegInfo.use_empty(OutReg)) {
+  std::set Uses;
+  // Collect all instructions that use OutReg
+  for (MachineOperand  : RegInfo.use_operands(OutReg)) {
+if (Uses.count(MO.getParent()))

amy-kwan wrote:

Pull out the `MO.getParent()` calls, and end the comment on 176 with a period.

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -145,9 +163,88 @@ namespace {
   .addImm(0);
 
 if (IsAIX) {
-  // The variable offset and region handle are copied in r4 and r3. The
-  // copies are followed by GETtlsADDR32AIX/GETtlsADDR64AIX.
-  if (!IsTLSTPRelMI) {
+  if (IsTLSLDAIXMI) {
+// It is better to put TLSLDAIX node before LoadOffsetToc node,

amy-kwan wrote:

```suggestion
// It is better to put the TLSLDAIX/TLSLDAIX8 nodes before the node 
that loads from the TOC (LoadOffsetToc),
```
Maybe it may be good to elaborate just a bit more on the node (something along 
these lines?)

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -3412,13 +3416,23 @@ SDValue 
PPCTargetLowering::LowerGlobalTLSAddressAIX(SDValue Op,
 return DAG.getNode(PPCISD::ADD_TLS, dl, PtrVT, TLSReg, VariableOffset);
   }
 
-  // Only Local-Exec, Initial-Exec and General-Dynamic TLS models are currently
-  // supported models. If Local- or Initial-exec are not possible or specified,
-  // all GlobalTLSAddress nodes are lowered using the general-dynamic model.
-  // We need to generate two TOC entries, one for the variable offset, one for
-  // the region handle. The global address for the TOC entry of the region
-  // handle is created with the MO_TLSGDM_FLAG flag and the global address
-  // for the TOC entry of the variable offset is created with MO_TLSGD_FLAG.
+  if (Model == TLSModel::LocalDynamic) {
+// For local-dynamic on AIX, we need to generate two TOC entries, one for
+// the variable offset, the other for the module handle. The module handle
+// is encapsulated inside the TLSLD_AIX pseudo node, and will be expanded 
by
+// PPCTLSDynamicCall.
+SDValue VariableOffsetTGA =
+DAG.getTargetGlobalAddress(GV, dl, PtrVT, 0, PPCII::MO_TLSLD_FLAG);
+SDValue VariableOffset = getTOCEntry(DAG, dl, VariableOffsetTGA);

amy-kwan wrote:

We discussed this a bit offline, and we should add a FIXME (thanks for adding 
it!).

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -145,9 +163,88 @@ namespace {
   .addImm(0);
 
 if (IsAIX) {
-  // The variable offset and region handle are copied in r4 and r3. The
-  // copies are followed by GETtlsADDR32AIX/GETtlsADDR64AIX.
-  if (!IsTLSTPRelMI) {
+  if (IsTLSLDAIXMI) {
+// It is better to put TLSLDAIX node before LoadOffsetToc node,
+// because LoadOffsetToc node can use clobbers r4/r5. Search for 
the
+// first paired LoadOffsetToc node within the same BB.
+unsigned LDTocOp =
+Is64Bit ? (IsLargeModel ? PPC::LDtocL : PPC::LDtoc)
+: (IsLargeModel ? PPC::LWZtocL : PPC::LWZtoc);
+MachineBasicBlock::iterator Anchor = I;
+if (!RegInfo.use_empty(OutReg)) {
+  std::set Uses;
+  // Collect all instructions that use OutReg
+  for (MachineOperand  : RegInfo.use_operands(OutReg)) {
+if (Uses.count(MO.getParent()))
+  continue;
+Uses.insert(MO.getParent());
+  }
+  // Find the first Add within current BB.

amy-kwan wrote:

```suggestion
  // Find the first Add within the current BB.
```

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -1622,6 +1629,9 @@ def TLSGDAIX8 :
  "#TLSGDAIX8",
  [(set i64:$rD,
(PPCTlsgdAIX i64:$offset, i64:$handle))]>;
+// This pseudo is expanded to load module-handle in X3, and the call to 
GETtlsMOD64AIX.

amy-kwan wrote:

```suggestion
// This pseudo is expanded to load the module-handle in X3, and the call to 
GETtlsMOD64AIX.
```

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -145,9 +163,88 @@ namespace {
   .addImm(0);
 
 if (IsAIX) {
-  // The variable offset and region handle are copied in r4 and r3. The
-  // copies are followed by GETtlsADDR32AIX/GETtlsADDR64AIX.
-  if (!IsTLSTPRelMI) {
+  if (IsTLSLDAIXMI) {
+// It is better to put TLSLDAIX node before LoadOffsetToc node,
+// because LoadOffsetToc node can use clobbers r4/r5. Search for 
the
+// first paired LoadOffsetToc node within the same BB.
+unsigned LDTocOp =
+Is64Bit ? (IsLargeModel ? PPC::LDtocL : PPC::LDtoc)
+: (IsLargeModel ? PPC::LWZtocL : PPC::LWZtoc);
+MachineBasicBlock::iterator Anchor = I;
+if (!RegInfo.use_empty(OutReg)) {
+  std::set Uses;
+  // Collect all instructions that use OutReg
+  for (MachineOperand  : RegInfo.use_operands(OutReg)) {
+if (Uses.count(MO.getParent()))
+  continue;
+Uses.insert(MO.getParent());
+  }
+  // Find the first Add within current BB.
+  MachineBasicBlock::iterator UseIter = MBB.begin();
+  for (MachineBasicBlock::iterator AE = MBB.end(); UseIter != AE;
+   ++UseIter)
+if (Uses.count(&*UseIter))
+  break;
+
+  if (UseIter != MBB.end()) {
+// Get the instruction that defines the other used register
+// operand of UseIter. The match pattern is that: UseIter has
+// exactly one used-operand defined by LDTocOp
+// (LDtocL/LDtoc/LWZtocL/LWZtoc).
+MachineInstr *LoadOffsetToc = nullptr;
+int MatchCount = 0;
+for (MachineOperand  : UseIter->operands()) {
+  if (MO.isReg() && MO.isUse()) {
+Register OffsetReg = MO.getReg();
+if (RegInfo.hasOneDef(OffsetReg)) {
+  if (RegInfo.getOneDef(OffsetReg)
+  ->getParent()
+  ->getOpcode() == LDTocOp) {
+LoadOffsetToc =
+RegInfo.getOneDef(OffsetReg)->getParent();
+++MatchCount;
+  }
+} else {
+  // FIXME: analyze this scenario if there is one.
+  MatchCount = 0;
+  break;
+}
+  }
+}
+// Get the iterator.
+if (MatchCount == 1 && LoadOffsetToc) {
+  Anchor = MBB.begin();
+  for (MachineBasicBlock::iterator AE = MBB.end(); Anchor != 
AE;
+   ++Anchor)
+if (&*Anchor == LoadOffsetToc)
+  break;
+
+  if (Anchor == MBB.end())
+Anchor = I;
+}
+  }
+}
+
+// Generate instructions to load module-handle.

amy-kwan wrote:

```suggestion
// Generate instructions to load the module-handle.
```

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -6,6 +6,6 @@
 #endif
 
 static __thread int y __attribute((tls_model("global-dynamic"))); // no-warning
-static __thread int y __attribute((tls_model("local-dynamic"))); // 
expected-error {{TLS model 'local-dynamic' is not yet supported on AIX}}
+static __thread int y __attribute((tls_model("local-dynamic"))); // 
expected-no-diagnostics

amy-kwan wrote:

Thanks! I think this is expected as noted in 
https://clang.llvm.org/doxygen/VerifyDiagnosticConsumer_8h_source.html#l00178:
> /// VerifyDiagnosticConsumer expects at least one expected-* directive to
/// be found inside the source code.  If no diagnostics are expected the
/// following directive can be used to indicate this:
///
/// \code
///   // expected-no-diagnostics
/// \endcode

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [PowerPC] Support local-dynamic TLS relocation on AIX (PR #66316)

2023-09-27 Thread Amy Kwan via cfe-commits


@@ -145,9 +163,88 @@ namespace {
   .addImm(0);
 
 if (IsAIX) {
-  // The variable offset and region handle are copied in r4 and r3. The
-  // copies are followed by GETtlsADDR32AIX/GETtlsADDR64AIX.
-  if (!IsTLSTPRelMI) {
+  if (IsTLSLDAIXMI) {
+// It is better to put TLSLDAIX node before LoadOffsetToc node,
+// because LoadOffsetToc node can use clobbers r4/r5. Search for 
the

amy-kwan wrote:

```suggestion
// because the LoadOffsetToc node can use clobbers r4/r5. Search 
for the
```

https://github.com/llvm/llvm-project/pull/66316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV][NFC] Move some common class/multiclass from riscv_vector.td to riscv_vector_common.td (PR #67587)

2023-09-27 Thread Brandon Wu via cfe-commits

https://github.com/4vtomat closed 
https://github.com/llvm/llvm-project/pull/67587
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 11819a1 - [RISCV][NFC] Move some common class/multiclass from riscv_vector.td to riscv_vector_common.td (#67587)

2023-09-27 Thread via cfe-commits

Author: Brandon Wu
Date: 2023-09-28T11:25:53+08:00
New Revision: 11819a1031fc67ef216de380a918dc5f33646fc4

URL: 
https://github.com/llvm/llvm-project/commit/11819a1031fc67ef216de380a918dc5f33646fc4
DIFF: 
https://github.com/llvm/llvm-project/commit/11819a1031fc67ef216de380a918dc5f33646fc4.diff

LOG: [RISCV][NFC] Move some common class/multiclass from riscv_vector.td to 
riscv_vector_common.td (#67587)

Since there are more vendor extensions that needs to implement
custom intrinsics, it's useful to move some common usages to
riscv_vector_common.td.

Added: 


Modified: 
clang/include/clang/Basic/riscv_vector.td
clang/include/clang/Basic/riscv_vector_common.td

Removed: 




diff  --git a/clang/include/clang/Basic/riscv_vector.td 
b/clang/include/clang/Basic/riscv_vector.td
index 60a1a2b2be6fb40..c685f3ef6087d81 100644
--- a/clang/include/clang/Basic/riscv_vector.td
+++ b/clang/include/clang/Basic/riscv_vector.td
@@ -14,466 +14,6 @@
 
 include "riscv_vector_common.td"
 
-//===--===//
-// Basic classes with automatic codegen.
-//===--===//
-
-class RVVOutBuiltin
-: RVVBuiltin {
-  let IntrinsicTypes = [-1];
-}
-
-class RVVOp0Builtin
-: RVVBuiltin {
-  let IntrinsicTypes = [0];
-}
-
-class RVVOutOp1Builtin
-: RVVBuiltin {
-  let IntrinsicTypes = [-1, 1];
-}
-
-class RVVOutOp0Op1Builtin
-: RVVBuiltin {
-  let IntrinsicTypes = [-1, 0, 1];
-}
-
-multiclass RVVBuiltinSet> suffixes_prototypes,
- list intrinsic_types> {
-  let IRName = intrinsic_name, MaskedIRName = intrinsic_name # "_mask",
-  IntrinsicTypes = intrinsic_types in {
-foreach s_p = suffixes_prototypes in {
-  let Name = NAME # "_" # s_p[0] in {
-defvar suffix = s_p[1];
-defvar prototype = s_p[2];
-def : RVVBuiltin;
-  }
-}
-  }
-}
-
-// IntrinsicTypes is output, op0, op1 [-1, 0, 1]
-multiclass RVVOutOp0Op1BuiltinSet> suffixes_prototypes>
-: RVVBuiltinSet;
-
-multiclass RVVOutBuiltinSet> suffixes_prototypes>
-: RVVBuiltinSet;
-
-multiclass RVVOp0BuiltinSet> suffixes_prototypes>
-: RVVBuiltinSet;
-
-// IntrinsicTypes is output, op1 [-1, 0]
-multiclass RVVOutOp0BuiltinSet> suffixes_prototypes>
-: RVVBuiltinSet;
-
-// IntrinsicTypes is output, op1 [-1, 1]
-multiclass RVVOutOp1BuiltinSet> suffixes_prototypes>
-: RVVBuiltinSet;
-
-multiclass RVVOp0Op1BuiltinSet> suffixes_prototypes>
-: RVVBuiltinSet;
-
-multiclass RVVOutOp1Op2BuiltinSet> suffixes_prototypes>
-: RVVBuiltinSet;
-
-// IntrinsicTypes is output, op2 [-1, 2]
-multiclass RVVOutOp2BuiltinSet> suffixes_prototypes>
-: RVVBuiltinSet;
-
-multiclass RVVSignedBinBuiltinSet
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVSignedBinBuiltinSetRoundingMode
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVUnsignedBinBuiltinSet
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVUnsignedBinBuiltinSetRoundingMode
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVIntBinBuiltinSet
-: RVVSignedBinBuiltinSet,
-  RVVUnsignedBinBuiltinSet;
-
-multiclass RVVInt64BinBuiltinSet
-: RVVOutOp1BuiltinSet,
-  RVVOutOp1BuiltinSet;
-
-multiclass RVVSlideOneBuiltinSet
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVSignedShiftBuiltinSet
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVSignedShiftBuiltinSetRoundingMode
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVUnsignedShiftBuiltinSet
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVUnsignedShiftBuiltinSetRoundingMode
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVShiftBuiltinSet
-: RVVSignedShiftBuiltinSet,
-  RVVUnsignedShiftBuiltinSet;
-
-let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
-  multiclass RVVSignedNShiftBuiltinSet
-  : RVVOutOp0Op1BuiltinSet;
-
-  multiclass RVVSignedNShiftBuiltinSetRoundingMode
-  : RVVOutOp0Op1BuiltinSet;
-
-  multiclass RVVUnsignedNShiftBuiltinSet
-  : RVVOutOp0Op1BuiltinSet;
-
-  multiclass RVVUnsignedNShiftBuiltinSetRoundingMode
-  : RVVOutOp0Op1BuiltinSet;
-
-}
-
-multiclass RVVCarryinBuiltinSet
-: RVVOutOp1BuiltinSet;
-
-multiclass RVVCarryOutInBuiltinSet
-: RVVOp0Op1BuiltinSet;
-
-multiclass RVVSignedMaskOutBuiltinSet
-: RVVOp0Op1BuiltinSet;
-
-multiclass RVVUnsignedMaskOutBuiltinSet
-: RVVOp0Op1BuiltinSet;
-
-multiclass RVVIntMaskOutBuiltinSet
-: RVVSignedMaskOutBuiltinSet,
-  RVVUnsignedMaskOutBuiltinSet;
-
-class RVVIntExt
-: RVVBuiltin {
-  let IRName = intrinsic_name;
-  let MaskedIRName = intrinsic_name # "_mask";
-  let OverloadedName = NAME;
-  let IntrinsicTypes = [-1, 0];
-}
-
-let HasMaskedOffOperand = false in {
-  multiclass RVVIntTerBuiltinSet {
-defm "" : RVVOutOp1BuiltinSet;
-  }
-  multiclass RVVFloatingTerBuiltinSet {
-defm "" : RVVOutOp1BuiltinSet;
-  }
-  multiclass RVVFloatingTerBuiltinSetRoundingMode {
-defm "" : RVVOutOp1BuiltinSet;

[PATCH] D152206: [Basic] Support 64-bit x86 target for UEFI

2023-09-27 Thread Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG315a407086b0: [Basic] Support 64-bit x86 target for UEFI 
(authored by prabhukr prabh...@google.com).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152206/new/

https://reviews.llvm.org/D152206

Files:
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/TargetParser/Triple.cpp
  llvm/unittests/IR/DataLayoutTest.cpp
  llvm/unittests/TargetParser/TripleTest.cpp


Index: llvm/unittests/TargetParser/TripleTest.cpp
===
--- llvm/unittests/TargetParser/TripleTest.cpp
+++ llvm/unittests/TargetParser/TripleTest.cpp
@@ -462,6 +462,7 @@
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UEFI, T.getOS());
   EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
+  EXPECT_EQ(Triple::COFF, T.getObjectFormat());
 
   T = Triple("wasm32-unknown-unknown");
   EXPECT_EQ(Triple::wasm32, T.getArch());
Index: llvm/unittests/IR/DataLayoutTest.cpp
===
--- llvm/unittests/IR/DataLayoutTest.cpp
+++ llvm/unittests/IR/DataLayoutTest.cpp
@@ -11,6 +11,7 @@
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include "llvm/IR/Type.h"
+#include "llvm/TargetParser/Triple.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gtest/gtest.h"
 
@@ -104,4 +105,11 @@
   EXPECT_EQ(Align(4 * 8), DL->getPrefTypeAlign(V8F32Ty));
 }
 
+TEST(DataLayoutTest, UEFI) {
+  Triple TT = Triple("x86_64-unknown-uefi");
+
+  // Test UEFI X86_64 Mangling Component.
+  EXPECT_STREQ(DataLayout::getManglingComponent(TT), "-m:w");
+}
+
 } // anonymous namespace
Index: llvm/lib/TargetParser/Triple.cpp
===
--- llvm/lib/TargetParser/Triple.cpp
+++ llvm/lib/TargetParser/Triple.cpp
@@ -799,6 +799,8 @@
   case Triple::x86_64:
 if (T.isOSWindows())
   return Triple::COFF;
+else if (T.isUEFI())
+  return Triple::COFF;
 return Triple::ELF;
 
   case Triple::aarch64_be:
Index: llvm/lib/IR/DataLayout.cpp
===
--- llvm/lib/IR/DataLayout.cpp
+++ llvm/lib/IR/DataLayout.cpp
@@ -171,7 +171,7 @@
 return "-m:l";
   if (T.isOSBinFormatMachO())
 return "-m:o";
-  if (T.isOSWindows() && T.isOSBinFormatCOFF())
+  if ((T.isOSWindows() || T.isUEFI()) && T.isOSBinFormatCOFF())
 return T.getArch() == Triple::x86 ? "-m:x" : "-m:w";
   if (T.isOSBinFormatXCOFF())
 return "-m:a";


Index: llvm/unittests/TargetParser/TripleTest.cpp
===
--- llvm/unittests/TargetParser/TripleTest.cpp
+++ llvm/unittests/TargetParser/TripleTest.cpp
@@ -462,6 +462,7 @@
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UEFI, T.getOS());
   EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
+  EXPECT_EQ(Triple::COFF, T.getObjectFormat());
 
   T = Triple("wasm32-unknown-unknown");
   EXPECT_EQ(Triple::wasm32, T.getArch());
Index: llvm/unittests/IR/DataLayoutTest.cpp
===
--- llvm/unittests/IR/DataLayoutTest.cpp
+++ llvm/unittests/IR/DataLayoutTest.cpp
@@ -11,6 +11,7 @@
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include "llvm/IR/Type.h"
+#include "llvm/TargetParser/Triple.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gtest/gtest.h"
 
@@ -104,4 +105,11 @@
   EXPECT_EQ(Align(4 * 8), DL->getPrefTypeAlign(V8F32Ty));
 }
 
+TEST(DataLayoutTest, UEFI) {
+  Triple TT = Triple("x86_64-unknown-uefi");
+
+  // Test UEFI X86_64 Mangling Component.
+  EXPECT_STREQ(DataLayout::getManglingComponent(TT), "-m:w");
+}
+
 } // anonymous namespace
Index: llvm/lib/TargetParser/Triple.cpp
===
--- llvm/lib/TargetParser/Triple.cpp
+++ llvm/lib/TargetParser/Triple.cpp
@@ -799,6 +799,8 @@
   case Triple::x86_64:
 if (T.isOSWindows())
   return Triple::COFF;
+else if (T.isUEFI())
+  return Triple::COFF;
 return Triple::ELF;
 
   case Triple::aarch64_be:
Index: llvm/lib/IR/DataLayout.cpp
===
--- llvm/lib/IR/DataLayout.cpp
+++ llvm/lib/IR/DataLayout.cpp
@@ -171,7 +171,7 @@
 return "-m:l";
   if (T.isOSBinFormatMachO())
 return "-m:o";
-  if (T.isOSWindows() && T.isOSBinFormatCOFF())
+  if ((T.isOSWindows() || T.isUEFI()) && T.isOSBinFormatCOFF())
 return T.getArch() == Triple::x86 ? "-m:x" : "-m:w";
   if (T.isOSBinFormatXCOFF())
 return "-m:a";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Driver] Fix detection of libc++ with empty sysroot. (PR #66947)

2023-09-27 Thread Vladimir Vereschaka via cfe-commits

vvereschaka wrote:

>edit: hopefully good after 
>https://github.com/llvm/llvm-project/commit/5aa3338930d15a59dd6ddbd36fc09ffa6610ca72

the test has been passed locally on the builder with this commit. Thank you for 
the fix.

https://github.com/llvm/llvm-project/pull/66947
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [InstCombine] Add combines/simplifications for `llvm.ptrmask` (PR #67166)

2023-09-27 Thread via cfe-commits

https://github.com/goldsteinn edited 
https://github.com/llvm/llvm-project/pull/67166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [InstCombine] Add combines/simplifications for `llvm.ptrmask` (PR #67166)

2023-09-27 Thread via cfe-commits

goldsteinn wrote:

Okay, rebased ontop of your vec support patches + added vec support/tests.

https://github.com/llvm/llvm-project/pull/67166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [ValueTracking] Simplify uaddo pattern (PR #65910)

2023-09-27 Thread via cfe-commits

goldsteinn wrote:

Okay, rebased ontop of your vec support patches + added vec support/tests.

https://github.com/llvm/llvm-project/pull/65910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] f9558c6 - [C++20] [Modules] Handle import decl before module declaration without being in GMF

2023-09-27 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2023-09-28T10:24:50+08:00
New Revision: f9558c691128cbc1660f69bd3b5f547be90ed18b

URL: 
https://github.com/llvm/llvm-project/commit/f9558c691128cbc1660f69bd3b5f547be90ed18b
DIFF: 
https://github.com/llvm/llvm-project/commit/f9558c691128cbc1660f69bd3b5f547be90ed18b.diff

LOG: [C++20] [Modules] Handle import decl before module declaration without 
being in GMF

Close https://github.com/llvm/llvm-project/issues/67627

In a module unit, all the declaration before the modoule declaration
should live in the GMF.

Added: 
clang/test/Modules/pr67627.cppm

Modified: 
clang/lib/Parse/Parser.cpp

Removed: 




diff  --git a/clang/lib/Parse/Parser.cpp b/clang/lib/Parse/Parser.cpp
index dda1dbaa0c21aa9..9d2c2fd9a5fa5d6 100644
--- a/clang/lib/Parse/Parser.cpp
+++ b/clang/lib/Parse/Parser.cpp
@@ -2564,6 +2564,10 @@ Decl *Parser::ParseModuleImport(SourceLocation AtLoc,
 SeenError = false;
 break;
   case Sema::ModuleImportState::FirstDecl:
+// If we found an import decl as the first declaration, we must be not in
+// a C++20 module unit or we are in an invalid state.
+ImportState = Sema::ModuleImportState::NotACXX20Module;
+[[fallthrough]];
   case Sema::ModuleImportState::NotACXX20Module:
 // We can only import a partition within a module purview.
 if (IsPartition)

diff  --git a/clang/test/Modules/pr67627.cppm b/clang/test/Modules/pr67627.cppm
new file mode 100644
index 000..3d4410229080a98
--- /dev/null
+++ b/clang/test/Modules/pr67627.cppm
@@ -0,0 +1,13 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/A.cppm -emit-module-interface -o %t/A.pcm
+// RUN: %clang_cc1 -std=c++20 %t/B.cppm -fmodule-file=A=%t/A.pcm -fsyntax-only 
-verify
+
+//--- A.cppm
+export module A;
+
+//--- B.cppm
+import A; // expected-note {{add 'module;' to the start of the file to 
introduce a global module fragment}}
+export module B; // expected-error {{module declaration must occur at the 
start of the translation unit}}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Fix crash when visting a fold expression in a default argument (PR #67514)

2023-09-27 Thread Shafik Yaghmour via cfe-commits

https://github.com/shafik updated 
https://github.com/llvm/llvm-project/pull/67514

>From e2e0e10e13748ba9369b73c7547c035ee75dfffa Mon Sep 17 00:00:00 2001
From: Shafik Yaghmour 
Date: Tue, 26 Sep 2023 18:55:44 -0700
Subject: [PATCH] [Clang] Fix crash when visting a fold expression in a default
 argument

CheckDefaultArgumentVisitor::Visit(...) assumes that the children of Expr will
not be NULL. This is not a valid assumption and when we have a CXXFoldExpr
the children can be NULL and this causes a crash.

Fixes: https://github.com/llvm/llvm-project/issues/67395
---
 clang/docs/ReleaseNotes.rst| 4 
 clang/lib/Sema/SemaDeclCXX.cpp | 3 ++-
 clang/test/SemaTemplate/cxx1z-fold-expressions.cpp | 8 
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 8a136aae5489a8c..3a65e40b7274f5f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -357,6 +357,10 @@ Bug Fixes to C++ Support
   reference. Fixes:
   (`#64162 `_)
 
+- Fix crash when fold expression was used in the initialization of default
+  argument. Fixes:
+  (`#67395 `_)
+
 Bug Fixes to AST Handling
 ^
 - Fixed an import failure of recursive friend class template.
diff --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 0091e0ecf6f3986..302e944d5d74f1c 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -86,7 +86,8 @@ class CheckDefaultArgumentVisitor
 bool CheckDefaultArgumentVisitor::VisitExpr(const Expr *Node) {
   bool IsInvalid = false;
   for (const Stmt *SubStmt : Node->children())
-IsInvalid |= Visit(SubStmt);
+if (SubStmt)
+  IsInvalid |= Visit(SubStmt);
   return IsInvalid;
 }
 
diff --git a/clang/test/SemaTemplate/cxx1z-fold-expressions.cpp 
b/clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
index 518eaf0e05239e0..47a252eb335f6e5 100644
--- a/clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
+++ b/clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
@@ -124,3 +124,11 @@ namespace PR30738 {
   int test_h3 = h(1, 2, 3);
   N::S test_h4 = h(N::S(), N::S(), N::S()); // expected-note 
{{instantiation of}}
 }
+
+namespace GH67395 {
+template 
+bool f();
+
+template 
+void g(bool = (f() || ...));
+}

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Driver] Support -fsanitize=cfi-icall on loongarch64 (PR #67310)

2023-09-27 Thread Fangrui Song via cfe-commits

https://github.com/MaskRay approved this pull request.


https://github.com/llvm/llvm-project/pull/67310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Driver] Support -fsanitize=cfi-icall on loongarch64 (PR #67310)

2023-09-27 Thread via cfe-commits

Ami-zhang wrote:

@MaskRay @xen0n Could you please review this PR and provide your feedback? 
Thank you!

https://github.com/llvm/llvm-project/pull/67310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [CodeGenPrepare] Transform ldexp into target supported intrinsics (PR #67552)

2023-09-27 Thread via cfe-commits

huhu233 wrote:

> Why does this need special handling in CGP instead of being a normal custom 
> lowering for FLDEXP?

@nikic , thanks for your suggestion, I'll update the patch as soon!

https://github.com/llvm/llvm-project/pull/67552
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D154869: [Flang] [FlangRT] Introduce FlangRT project as solution to Flang's runtime LLVM integration

2023-09-27 Thread H. Vetinari via Phabricator via cfe-commits
h-vetinari added a comment.

Any update on this patchset? With the migration away from phabricator, it'd be 
good to get this in soonish (otherwise it'll need to be moved to github).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154869/new/

https://reviews.llvm.org/D154869

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [CodeGenPrepare] Transform ldexp into target supported intrinsics (PR #67552)

2023-09-27 Thread via cfe-commits

huhu233 wrote:

> I agree and custom lowering also gives a straight forward way to support 
> vectors types as well.

You are right, I'll update the patch as soon, thanks!

https://github.com/llvm/llvm-project/pull/67552
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Driver] Fix detection of libc++ with empty sysroot. (PR #66947)

2023-09-27 Thread Anton Korobeynikov via cfe-commits

asl wrote:

@sam-mccall As far as I can see, the bot was green before this change: 
https://lab.llvm.org/buildbot/#/builders/119/builds/15229

Have you not received email from the buildbot?

https://github.com/llvm/llvm-project/pull/66947
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits

https://github.com/zygoloid edited 
https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits


@@ -7304,6 +7382,21 @@ class BufferToAPValueConverter {
 return ArrayValue;
   }
 
+  std::optional visit(const VectorType *Ty, CharUnits Offset) {
+SmallVector Bytes;
+if (!Buffer.readObject(Offset, Info.Ctx.getTypeSizeInChars(Ty), Bytes))
+  return std::nullopt;

zygoloid wrote:

At least, assuming that there is padding in the same places in both. Maybe the 
vector doesn't actually have padding, but the struct does, so the round-trip 
*should* fail?

https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits

https://github.com/zygoloid edited 
https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits


@@ -2732,6 +2732,92 @@ static bool truncateBitfieldValue(EvalInfo , const 
Expr *E,
   return true;
 }
 
+static bool BitcastAPIntToVector(EvalInfo , const VectorType *VTy,
+ const llvm::APInt ,
+ SmallVectorImpl ) {
+  QualType EltTy = VTy->getElementType();
+  unsigned NElts = VTy->getNumElements();
+  unsigned EltSize =
+  VTy->isExtVectorBoolType() ? 1 : Info.Ctx.getTypeSize(EltTy);
+
+  if ((NElts * EltSize) % Info.Ctx.getCharWidth() != 0) {
+// The vector's size in bits is not a multiple of the target's byte size,
+// so its layout is unspecified. For now, we'll simply treat these cases as
+// unsupported (this should only be possible with OpenCL bool vectors whose
+// element count isn't a multiple of the byte size).
+return false;
+  }
+
+  Elts.reserve(NElts);
+  bool BigEndian = Info.Ctx.getTargetInfo().isBigEndian();
+  if (EltTy->isRealFloatingType()) {
+const llvm::fltSemantics  = Info.Ctx.getFloatTypeSemantics(EltTy);
+unsigned FloatEltSize = EltSize;
+if ( == ::x87DoubleExtended())
+  FloatEltSize = 80;
+for (unsigned i = 0; i < NElts; i++) {
+  llvm::APInt Elt;
+  if (BigEndian)
+Elt = SValInt.rotl(i * EltSize + FloatEltSize).trunc(FloatEltSize);
+  else
+Elt = SValInt.rotr(i * EltSize).trunc(FloatEltSize);

zygoloid wrote:

```suggestion
  llvm::APInt Elt = SValInt.extractBits(FloatEltSize, BigEndian ? (NElts - 
i) * EltSize - FloatEltSize : i * EltSize);
```
Extracting the bits in one go will avoid a heap allocation if the vector is 
larger than 64 bits but its elements are not.

https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits


@@ -2732,6 +2732,92 @@ static bool truncateBitfieldValue(EvalInfo , const 
Expr *E,
   return true;
 }
 
+static bool BitcastAPIntToVector(EvalInfo , const VectorType *VTy,
+ const llvm::APInt ,
+ SmallVectorImpl ) {
+  QualType EltTy = VTy->getElementType();
+  unsigned NElts = VTy->getNumElements();
+  unsigned EltSize =
+  VTy->isExtVectorBoolType() ? 1 : Info.Ctx.getTypeSize(EltTy);
+
+  if ((NElts * EltSize) % Info.Ctx.getCharWidth() != 0) {
+// The vector's size in bits is not a multiple of the target's byte size,
+// so its layout is unspecified. For now, we'll simply treat these cases as
+// unsupported (this should only be possible with OpenCL bool vectors whose
+// element count isn't a multiple of the byte size).
+return false;
+  }
+
+  Elts.reserve(NElts);
+  bool BigEndian = Info.Ctx.getTargetInfo().isBigEndian();
+  if (EltTy->isRealFloatingType()) {
+const llvm::fltSemantics  = Info.Ctx.getFloatTypeSemantics(EltTy);
+unsigned FloatEltSize = EltSize;
+if ( == ::x87DoubleExtended())
+  FloatEltSize = 80;
+for (unsigned i = 0; i < NElts; i++) {
+  llvm::APInt Elt;
+  if (BigEndian)
+Elt = SValInt.rotl(i * EltSize + FloatEltSize).trunc(FloatEltSize);
+  else
+Elt = SValInt.rotr(i * EltSize).trunc(FloatEltSize);
+  Elts.push_back(APValue(APFloat(Sem, Elt)));
+}
+  } else if (EltTy->isIntegerType()) {
+for (unsigned i = 0; i < NElts; i++) {
+  llvm::APInt Elt;
+  if (BigEndian)
+Elt = SValInt.rotl(i * EltSize + EltSize).zextOrTrunc(EltSize);
+  else
+Elt = SValInt.rotr(i * EltSize).zextOrTrunc(EltSize);
+  Elts.push_back(APValue(APSInt(Elt, !EltTy->isSignedIntegerType(;
+}
+  } else {
+return false;
+  }
+  return true;
+}
+
+static bool BitcastVectorToAPInt(EvalInfo , const VectorType *VTy,
+ const APValue , llvm::APInt ) {
+  QualType EltTy = VTy->getElementType();
+  unsigned NElts = VTy->getNumElements();
+  unsigned EltSize =
+  VTy->isExtVectorBoolType() ? 1 : Info.Ctx.getTypeSize(EltTy);
+  unsigned VecSize = Info.Ctx.getTypeSize(VTy);
+
+  if ((NElts * EltSize) % Info.Ctx.getCharWidth() != 0) {
+// The vector's size in bits is not a multiple of the target's byte size,
+// so its layout is unspecified. For now, we'll simply treat these cases as
+// unsupported (this should only be possible with OpenCL bool vectors whose
+// element count isn't a multiple of the byte size).
+return false;
+  }
+
+  bool BigEndian = Info.Ctx.getTargetInfo().isBigEndian();
+  Res = llvm::APInt::getZero(VecSize);
+  for (unsigned i = 0; i < SVal.getVectorLength(); i++) {
+const APValue  = SVal.getVectorElt(i);
+llvm::APInt EltAsInt;

zygoloid wrote:

Move this out of the loop so that we only allocate storage for it once. (It 
typically won't fit in 64 bits, so this will perform a heap allocation.)

https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits


@@ -7095,6 +7157,22 @@ class APValueToBufferConverter {
 return true;
   }
 
+  bool visitVector(const APValue , QualType Ty, CharUnits Offset) {
+const VectorType *VTy = Ty->castAs();
+
+APInt Bits;
+if (!BitcastVectorToAPInt(Info, VTy, Val, Bits))
+  return false;
+
+assert(Bits.getBitWidth() == Info.Ctx.getTypeSize(Ty));
+
+unsigned Width = Bits.getBitWidth();
+SmallVector Bytes(Width / 8);
+llvm::StoreIntToMemory(Bits, &*Bytes.begin(), Width / 8);
+Buffer.writeObject(Offset, Bytes);

zygoloid wrote:

Are the padding bits of an x86 fp80 vector defined? If not, we'll need to avoid 
marking them as initialized here...

https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits


@@ -2732,6 +2732,92 @@ static bool truncateBitfieldValue(EvalInfo , const 
Expr *E,
   return true;
 }
 
+static bool BitcastAPIntToVector(EvalInfo , const VectorType *VTy,
+ const llvm::APInt ,
+ SmallVectorImpl ) {
+  QualType EltTy = VTy->getElementType();
+  unsigned NElts = VTy->getNumElements();
+  unsigned EltSize =
+  VTy->isExtVectorBoolType() ? 1 : Info.Ctx.getTypeSize(EltTy);
+
+  if ((NElts * EltSize) % Info.Ctx.getCharWidth() != 0) {
+// The vector's size in bits is not a multiple of the target's byte size,
+// so its layout is unspecified. For now, we'll simply treat these cases as
+// unsupported (this should only be possible with OpenCL bool vectors whose
+// element count isn't a multiple of the byte size).
+return false;
+  }
+
+  Elts.reserve(NElts);
+  bool BigEndian = Info.Ctx.getTargetInfo().isBigEndian();
+  if (EltTy->isRealFloatingType()) {
+const llvm::fltSemantics  = Info.Ctx.getFloatTypeSemantics(EltTy);
+unsigned FloatEltSize = EltSize;
+if ( == ::x87DoubleExtended())
+  FloatEltSize = 80;
+for (unsigned i = 0; i < NElts; i++) {
+  llvm::APInt Elt;
+  if (BigEndian)
+Elt = SValInt.rotl(i * EltSize + FloatEltSize).trunc(FloatEltSize);
+  else
+Elt = SValInt.rotr(i * EltSize).trunc(FloatEltSize);
+  Elts.push_back(APValue(APFloat(Sem, Elt)));
+}
+  } else if (EltTy->isIntegerType()) {
+for (unsigned i = 0; i < NElts; i++) {
+  llvm::APInt Elt;
+  if (BigEndian)
+Elt = SValInt.rotl(i * EltSize + EltSize).zextOrTrunc(EltSize);
+  else
+Elt = SValInt.rotr(i * EltSize).zextOrTrunc(EltSize);
+  Elts.push_back(APValue(APSInt(Elt, !EltTy->isSignedIntegerType(;
+}
+  } else {
+return false;
+  }
+  return true;
+}
+
+static bool BitcastVectorToAPInt(EvalInfo , const VectorType *VTy,
+ const APValue , llvm::APInt ) {
+  QualType EltTy = VTy->getElementType();
+  unsigned NElts = VTy->getNumElements();
+  unsigned EltSize =
+  VTy->isExtVectorBoolType() ? 1 : Info.Ctx.getTypeSize(EltTy);
+  unsigned VecSize = Info.Ctx.getTypeSize(VTy);
+
+  if ((NElts * EltSize) % Info.Ctx.getCharWidth() != 0) {
+// The vector's size in bits is not a multiple of the target's byte size,
+// so its layout is unspecified. For now, we'll simply treat these cases as
+// unsupported (this should only be possible with OpenCL bool vectors whose
+// element count isn't a multiple of the byte size).
+return false;
+  }
+
+  bool BigEndian = Info.Ctx.getTargetInfo().isBigEndian();
+  Res = llvm::APInt::getZero(VecSize);
+  for (unsigned i = 0; i < SVal.getVectorLength(); i++) {
+const APValue  = SVal.getVectorElt(i);
+llvm::APInt EltAsInt;
+if (Elt.isInt()) {
+  EltAsInt = Elt.getInt();
+} else if (Elt.isFloat()) {
+  EltAsInt = Elt.getFloat().bitcastToAPInt();
+} else {
+  // Don't try to handle vectors of anything other than int or float
+  // (not sure if it's possible to hit this case).
+  return false;
+}
+unsigned BaseEltSize = EltAsInt.getBitWidth();
+if (BigEndian)
+  Res |= EltAsInt.zextOrTrunc(VecSize).rotr(i * EltSize + BaseEltSize);
+else
+  Res |= EltAsInt.zextOrTrunc(VecSize).rotl(i * EltSize);

zygoloid wrote:

```suggestion
Res.insertBits(EltAsInt, BigEndian ? (NElts - i) * EltSize - BaseEltSize : 
i * EltSize);
```
Avoid another heap allocation.

https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits


@@ -7304,6 +7382,21 @@ class BufferToAPValueConverter {
 return ArrayValue;
   }
 
+  std::optional visit(const VectorType *Ty, CharUnits Offset) {
+SmallVector Bytes;
+if (!Buffer.readObject(Offset, Info.Ctx.getTypeSizeInChars(Ty), Bytes))
+  return std::nullopt;

zygoloid wrote:

... and here we'll need to not reject if the padding bits are uninitialized.

As a testcase, we should ensure that (for example) this:
```c++
struct A {
  long double a, b, c, d;
};
```
can round-trip through a vector of 4 `long double`s.

https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits


@@ -2732,6 +2732,92 @@ static bool truncateBitfieldValue(EvalInfo , const 
Expr *E,
   return true;
 }
 
+static bool BitcastAPIntToVector(EvalInfo , const VectorType *VTy,
+ const llvm::APInt ,
+ SmallVectorImpl ) {
+  QualType EltTy = VTy->getElementType();
+  unsigned NElts = VTy->getNumElements();
+  unsigned EltSize =
+  VTy->isExtVectorBoolType() ? 1 : Info.Ctx.getTypeSize(EltTy);
+
+  if ((NElts * EltSize) % Info.Ctx.getCharWidth() != 0) {
+// The vector's size in bits is not a multiple of the target's byte size,
+// so its layout is unspecified. For now, we'll simply treat these cases as
+// unsupported (this should only be possible with OpenCL bool vectors whose
+// element count isn't a multiple of the byte size).
+return false;
+  }
+
+  Elts.reserve(NElts);
+  bool BigEndian = Info.Ctx.getTargetInfo().isBigEndian();
+  if (EltTy->isRealFloatingType()) {
+const llvm::fltSemantics  = Info.Ctx.getFloatTypeSemantics(EltTy);
+unsigned FloatEltSize = EltSize;
+if ( == ::x87DoubleExtended())
+  FloatEltSize = 80;
+for (unsigned i = 0; i < NElts; i++) {
+  llvm::APInt Elt;
+  if (BigEndian)
+Elt = SValInt.rotl(i * EltSize + FloatEltSize).trunc(FloatEltSize);
+  else
+Elt = SValInt.rotr(i * EltSize).trunc(FloatEltSize);
+  Elts.push_back(APValue(APFloat(Sem, Elt)));
+}
+  } else if (EltTy->isIntegerType()) {
+for (unsigned i = 0; i < NElts; i++) {
+  llvm::APInt Elt;
+  if (BigEndian)
+Elt = SValInt.rotl(i * EltSize + EltSize).zextOrTrunc(EltSize);
+  else
+Elt = SValInt.rotr(i * EltSize).zextOrTrunc(EltSize);
+  Elts.push_back(APValue(APSInt(Elt, !EltTy->isSignedIntegerType(;

zygoloid wrote:

```suggestion
  llvm::APInt Elt = SValInt.extractBits(FloatEltSize, (BigEndian ? NElts - 
i - 1 : i) * EltSize));
  Elts.push_back(APValue(APSInt(std::move(Elt), 
!EltTy->isSignedIntegerType(;
```
As above, but also `std::move` the `APInt` into the `APSInt` to avoid another 
heap allocation if the element size is > 64 bits.

https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits

https://github.com/zygoloid commented:

Thanks, I like the code reuse! There are some minor optimization and 
simplification opportunities in the code you're reusing that might be worth 
addressing now.

I'm worried that vectors with padding (which I think is only vectors of x86 
`long double`) aren't being treated properly by `bit_cast` here. It's probably 
a bit awkward to fix, given the new approach, but maybe we can handle the 
padding separately from the conversion of the vector to/from `APInt`.

https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

2023-09-27 Thread Richard Smith via cfe-commits

https://github.com/zygoloid edited 
https://github.com/llvm/llvm-project/pull/66894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 22433cc - [Driver][test] Fix hexagon-toolchain-elf.c

2023-09-27 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2023-09-27T16:55:58-07:00
New Revision: 22433cc541ff706d9e845774ef1c8c959dc67799

URL: 
https://github.com/llvm/llvm-project/commit/22433cc541ff706d9e845774ef1c8c959dc67799
DIFF: 
https://github.com/llvm/llvm-project/commit/22433cc541ff706d9e845774ef1c8c959dc67799.diff

LOG: [Driver][test] Fix hexagon-toolchain-elf.c

"ld" may match a build direcory path, making the `-SAME:` pattern fail.

Added: 


Modified: 
clang/test/Driver/hexagon-toolchain-elf.c

Removed: 




diff  --git a/clang/test/Driver/hexagon-toolchain-elf.c 
b/clang/test/Driver/hexagon-toolchain-elf.c
index b868024d41b9bab..b840de28fd92089 100644
--- a/clang/test/Driver/hexagon-toolchain-elf.c
+++ b/clang/test/Driver/hexagon-toolchain-elf.c
@@ -384,10 +384,10 @@
 // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
-
 // RUN: %clangxx -### --target=hexagon-unknown-elf \
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
-// RUN:   -mcpu=hexagonv60 \
+// RUN:   -mcpu=hexagonv60 -fuse-ld=lld \
 // RUN:   -s -t -e start_here -uFoo -undefined Bar %s 2>&1 | FileCheck 
-check-prefix=CHECK33B %s
 // CHECK33B:  "-cc1"
-// CHECK33B:  {{hexagon-link|ld}}
+// CHECK33B:  ld.lld
 // CHECK33B-SAME: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0_standalone.o"
 // CHECK33B-SAME: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0.o"
 // CHECK33B-SAME: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/init.o"



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] Ensure NoTrapAfterNoreturn is false for the wasm backend (PR #65876)

2023-09-27 Thread Matt Harding via cfe-commits

https://github.com/majaha edited https://github.com/llvm/llvm-project/pull/65876
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] Ensure NoTrapAfterNoreturn is false for the wasm backend (PR #65876)

2023-09-27 Thread Matt Harding via cfe-commits


@@ -1,33 +1,133 @@
-; RUN: llc < %s -asm-verbose=false -verify-machineinstrs | FileCheck %s
-; RUN: llc < %s -asm-verbose=false -fast-isel -fast-isel-abort=1 
-verify-machineinstrs | FileCheck %s
-
-; Test that LLVM unreachable instruction and trap intrinsic are lowered to
-; wasm unreachable
+; RUN: llc < %s -verify-machineinstrs | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs | 
FileCheck %s
+; RUN: llc < %s -verify-machineinstrs --trap-unreachable | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs 
--trap-unreachable | FileCheck %s
+; RUN: llc < %s -verify-machineinstrs --trap-unreachable 
--no-trap-after-noreturn | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs 
--trap-unreachable --no-trap-after-noreturn | FileCheck %s
 
 target triple = "wasm32-unknown-unknown"
 
-declare void @llvm.trap()
-declare void @llvm.debugtrap()
-declare void @abort()
 
-; CHECK-LABEL: f1:
-; CHECK: call abort{{$}}
-; CHECK: unreachable
-define i32 @f1() {
-  call void @abort()
-  unreachable
-}
+; Test that the LLVM trap and debug trap intrinsics are lowered to
+; wasm unreachable.
+
+declare void @llvm.trap() cold noreturn nounwind
+declare void @llvm.debugtrap() nounwind
 
-; CHECK-LABEL: f2:
-; CHECK: unreachable
-define void @f2() {
+define void @trap_ret_void() {
+; CHECK-LABEL: trap_ret_void:
+; CHECK: .functype trap_ret_void () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:# fallthrough-return
+; CHECK-NEXT:end_function
   call void @llvm.trap()
   ret void
 }
 
-; CHECK-LABEL: f3:
-; CHECK: unreachable
-define void @f3() {
+define void @dtrap_ret_void() {
+; CHECK-LABEL: dtrap_ret_void:
+; CHECK: .functype dtrap_ret_void () -> ()

majaha wrote:

 sounds good

https://github.com/llvm/llvm-project/pull/65876
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] Ensure NoTrapAfterNoreturn is false for the wasm backend (PR #65876)

2023-09-27 Thread Matt Harding via cfe-commits


@@ -1,33 +1,133 @@
-; RUN: llc < %s -asm-verbose=false -verify-machineinstrs | FileCheck %s
-; RUN: llc < %s -asm-verbose=false -fast-isel -fast-isel-abort=1 
-verify-machineinstrs | FileCheck %s
-
-; Test that LLVM unreachable instruction and trap intrinsic are lowered to
-; wasm unreachable
+; RUN: llc < %s -verify-machineinstrs | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs | 
FileCheck %s
+; RUN: llc < %s -verify-machineinstrs --trap-unreachable | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs 
--trap-unreachable | FileCheck %s
+; RUN: llc < %s -verify-machineinstrs --trap-unreachable 
--no-trap-after-noreturn | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs 
--trap-unreachable --no-trap-after-noreturn | FileCheck %s
 
 target triple = "wasm32-unknown-unknown"
 
-declare void @llvm.trap()
-declare void @llvm.debugtrap()
-declare void @abort()
 
-; CHECK-LABEL: f1:
-; CHECK: call abort{{$}}
-; CHECK: unreachable
-define i32 @f1() {
-  call void @abort()
-  unreachable
-}
+; Test that the LLVM trap and debug trap intrinsics are lowered to
+; wasm unreachable.
+
+declare void @llvm.trap() cold noreturn nounwind
+declare void @llvm.debugtrap() nounwind
 
-; CHECK-LABEL: f2:
-; CHECK: unreachable
-define void @f2() {
+define void @trap_ret_void() {
+; CHECK-LABEL: trap_ret_void:
+; CHECK: .functype trap_ret_void () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:# fallthrough-return
+; CHECK-NEXT:end_function
   call void @llvm.trap()
   ret void
 }
 
-; CHECK-LABEL: f3:
-; CHECK: unreachable
-define void @f3() {
+define void @dtrap_ret_void() {
+; CHECK-LABEL: dtrap_ret_void:
+; CHECK: .functype dtrap_ret_void () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:# fallthrough-return
+; CHECK-NEXT:end_function
   call void @llvm.debugtrap()
   ret void
 }
+
+; LLVM trap followed by LLVM unreachable could become exactly one
+; wasm unreachable, but two are emitted currently.
+define void @trap_unreach() {
+; CHECK-LABEL: trap_unreach:
+; CHECK: .functype trap_unreach () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:end_function
+  call void @llvm.trap()
+  unreachable
+}
+
+
+; Test that LLVM unreachable instruction is lowered to wasm unreachable when
+; necessary to fulfill the wasm operand stack requirements.
+
+declare void @ext_func()
+declare i32 @ext_func_i32()
+declare void @ext_never_return() noreturn
+
+; This test emits wasm unreachable to fill in for the missing i32 return value.

majaha wrote:

In the low-level specifics of the compiler, yes.

But at the higher level of what the wasm specification requires, this wasm 
`unreachable` fulfils the typing requirements of the code block, "filling in" 
for the i32 value that wasm validation expects to be at the top of the operand 
stack, by virtue of being stack polymorphic.

We could in theory emit an `i32.const 42` instruction, or anything else that 
fills in for the missing return value because reaching llvm `unreachable` is 
undefined behaviour. But wasm `unreachable` has a single byte encoding, and it 
traps as the most sensible form of UB.

https://github.com/llvm/llvm-project/pull/65876
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Ensure NoTrapAfterNoreturn is false for the wasm backend (PR #65876)

2023-09-27 Thread Heejin Ahn via cfe-commits

aheejin wrote:

> Yeah you've got it, that's the main point. It can be set via the C++ API, and 
> when I tried doing so in the Rust compiler I found it broke the WebAssembly 
> backend. Sorry if I didn't make that clear enough earlier, I'm glad we're on 
> the same page now.

The other points I tried to say in 
https://github.com/llvm/llvm-project/pull/65876#issuecomment-1737922328 stay 
the same though.

https://github.com/llvm/llvm-project/pull/65876
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Handle sema of noexcept condition in their evaluation context. (PR #67538)

2023-09-27 Thread Shafik Yaghmour via cfe-commits

shafik wrote:

I wonder does this also fix this: 
https://github.com/llvm/llvm-project/issues/67058

https://github.com/llvm/llvm-project/pull/67538
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [mlir][sparse] Change tests to use new syntax for ELL and slice (PR #67569)

2023-09-27 Thread Yinying Li via cfe-commits

https://github.com/yinying-lisa-li closed 
https://github.com/llvm/llvm-project/pull/67569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

2023-09-27 Thread Michael Spencer via cfe-commits


@@ -0,0 +1,267 @@
+//===--- cc1modbuildd_main.cpp - Clang CC1 Module Build Daemon 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Tooling/ModuleBuildDaemon/SocketMsgSupport.h"
+#include "clang/Tooling/ModuleBuildDaemon/SocketSupport.h"
+#include "clang/Tooling/ModuleBuildDaemon/Utils.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/ThreadPool.h"
+#include "llvm/Support/Threading.h"
+#include "llvm/Support/YAMLParser.h"
+#include "llvm/Support/YAMLTraits.h"
+
+// TODO: Make portable
+#if LLVM_ON_UNIX
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+using namespace llvm;
+using namespace clang;
+using namespace cc1modbuildd;
+
+// Create unbuffered STDOUT stream so that any logging done by module build
+// daemon can be viewed without having to terminate the process
+static raw_fd_ostream _outs() {
+  static raw_fd_ostream S(STDOUT_FILENO, false, true);
+  return S;
+}
+
+namespace {
+
+class ModuleBuildDaemonServer {
+public:
+  SmallString<128> BasePath;
+  SmallString<128> SocketPath;
+  SmallString<128> PidPath;
+
+  ModuleBuildDaemonServer(SmallString<128> Path, ArrayRef Argv)
+  : BasePath(Path), SocketPath(Path) {
+llvm::sys::path::append(SocketPath, SOCKET_FILE_NAME);
+  }
+
+  ~ModuleBuildDaemonServer() { shutdownDaemon(SIGTERM); }
+
+  int forkDaemon();
+  int launchDaemon();
+  int listenForClients();
+
+  static void handleClient(int Client);
+
+  void shutdownDaemon(int signal) {
+unlink(SocketPath.c_str());
+shutdown(ListenSocketFD, SHUT_RD);
+close(ListenSocketFD);
+exit(EXIT_SUCCESS);
+  }
+
+private:
+  // Initializes and returns DiagnosticsEngine
+  pid_t Pid = -1;
+  int ListenSocketFD = -1;
+};
+
+// Required to handle SIGTERM by calling Shutdown
+ModuleBuildDaemonServer *DaemonPtr = nullptr;
+void handleSignal(int Signal) {
+  if (DaemonPtr != nullptr) {
+DaemonPtr->shutdownDaemon(Signal);

Bigcheese wrote:

I did some more checking on this. `DaemonPtr` is fine as the signal handler is 
installed after this is set. As for `shutdownDaemon`, all the functions it 
currently calls are signal safe according to POSIX, but `ListenSocketFD` also 
needs to be atomic as it is written after the signal handler is installed.

Basically you need to treat the signal handler as running in another thread 
that starts and synchronizes with when the signal handler gets installed.

https://github.com/llvm/llvm-project/pull/67562
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Ensure NoTrapAfterNoreturn is false for the wasm backend (PR #65876)

2023-09-27 Thread Matt Harding via cfe-commits


@@ -1,33 +1,133 @@
-; RUN: llc < %s -asm-verbose=false -verify-machineinstrs | FileCheck %s
-; RUN: llc < %s -asm-verbose=false -fast-isel -fast-isel-abort=1 
-verify-machineinstrs | FileCheck %s
-
-; Test that LLVM unreachable instruction and trap intrinsic are lowered to
-; wasm unreachable
+; RUN: llc < %s -verify-machineinstrs | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs | 
FileCheck %s
+; RUN: llc < %s -verify-machineinstrs --trap-unreachable | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs 
--trap-unreachable | FileCheck %s
+; RUN: llc < %s -verify-machineinstrs --trap-unreachable 
--no-trap-after-noreturn | FileCheck %s
+; RUN: llc < %s -fast-isel -fast-isel-abort=1 -verify-machineinstrs 
--trap-unreachable --no-trap-after-noreturn | FileCheck %s
 
 target triple = "wasm32-unknown-unknown"
 
-declare void @llvm.trap()
-declare void @llvm.debugtrap()
-declare void @abort()
 
-; CHECK-LABEL: f1:
-; CHECK: call abort{{$}}
-; CHECK: unreachable
-define i32 @f1() {
-  call void @abort()
-  unreachable
-}
+; Test that the LLVM trap and debug trap intrinsics are lowered to
+; wasm unreachable.
+
+declare void @llvm.trap() cold noreturn nounwind
+declare void @llvm.debugtrap() nounwind
 
-; CHECK-LABEL: f2:
-; CHECK: unreachable
-define void @f2() {
+define void @trap_ret_void() {
+; CHECK-LABEL: trap_ret_void:
+; CHECK: .functype trap_ret_void () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:# fallthrough-return
+; CHECK-NEXT:end_function
   call void @llvm.trap()
   ret void
 }
 
-; CHECK-LABEL: f3:
-; CHECK: unreachable
-define void @f3() {
+define void @dtrap_ret_void() {
+; CHECK-LABEL: dtrap_ret_void:
+; CHECK: .functype dtrap_ret_void () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:# fallthrough-return
+; CHECK-NEXT:end_function
   call void @llvm.debugtrap()
   ret void
 }
+
+; LLVM trap followed by LLVM unreachable could become exactly one
+; wasm unreachable, but two are emitted currently.
+define void @trap_unreach() {
+; CHECK-LABEL: trap_unreach:
+; CHECK: .functype trap_unreach () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:end_function
+  call void @llvm.trap()
+  unreachable
+}
+
+
+; Test that LLVM unreachable instruction is lowered to wasm unreachable when
+; necessary to fulfill the wasm operand stack requirements.
+
+declare void @ext_func()
+declare i32 @ext_func_i32()
+declare void @ext_never_return() noreturn
+
+; This test emits wasm unreachable to fill in for the missing i32 return value.
+define i32 @missing_ret_unreach() {
+; CHECK-LABEL: missing_ret_unreach:
+; CHECK: .functype missing_ret_unreach () -> (i32)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:call ext_func
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:end_function
+  call void @ext_func()
+  unreachable
+}
+
+; This is similar to the above test, but ensures wasm unreachable is emitted
+; even after a noreturn call.
+define i32 @missing_ret_noreturn_unreach() {
+; CHECK-LABEL: missing_ret_noreturn_unreach:
+; CHECK: .functype missing_ret_noreturn_unreach () -> (i32)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:call ext_never_return
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:end_function
+  call void @ext_never_return()
+  unreachable
+}
+
+; We could emit no instructions at all for the llvm unreachables in these next
+; three tests, as the signatures match and reaching llvm unreachable is
+; undefined behaviour. But wasm unreachable is emitted for the time being.
+
+define void @void_sig_match_unreach() {
+; CHECK-LABEL: void_sig_match_unreach:
+; CHECK: .functype void_sig_match_unreach () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:call ext_func
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:end_function
+  call void @ext_func()
+  unreachable
+}
+
+define i32 @i32_sig_match_unreach() {
+; CHECK-LABEL: i32_sig_match_unreach:
+; CHECK: .functype i32_sig_match_unreach () -> (i32)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:call ext_func_i32
+; CHECK-NEXT:drop
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:end_function
+  call i32 @ext_func_i32()
+  unreachable
+}
+
+define void @void_sig_match_noreturn_unreach() {
+; CHECK-LABEL: void_sig_match_noreturn_unreach:
+; CHECK: .functype void_sig_match_noreturn_unreach () -> ()
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:call ext_never_return
+; CHECK-NEXT:unreachable
+; CHECK-NEXT:end_function
+  call void @ext_never_return()
+  unreachable
+}
+
+; This function currently doesn't emit unreachable.

majaha wrote:

I intended the last four test functions to be in more of a declarative style, 
describing the current state of affairs for a few examples of interest, and 
showing where there's room for improvement. They can be updated as the codegen 

[clang] [clang-format] Don't align ctors and dtors with other functions (PR #67618)

2023-09-27 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang-format


Changes

Fixed #67604.

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


2 Files Affected:

- (modified) clang/lib/Format/WhitespaceManager.cpp (+5-1) 
- (modified) clang/unittests/Format/FormatTest.cpp (+12) 


``diff
diff --git a/clang/lib/Format/WhitespaceManager.cpp 
b/clang/lib/Format/WhitespaceManager.cpp
index 1790a9df42b5d14..762729d1c4166a5 100644
--- a/clang/lib/Format/WhitespaceManager.cpp
+++ b/clang/lib/Format/WhitespaceManager.cpp
@@ -974,7 +974,11 @@ void WhitespaceManager::alignConsecutiveDeclarations() {
   AlignTokens(
   Style,
   [](Change const ) {
-if (C.Tok->isOneOf(TT_FunctionDeclarationName, TT_FunctionTypeLParen))
+if (C.Tok->is(TT_FunctionDeclarationName) && C.Tok->Previous &&
+C.Tok->Previous->isNot(tok::tilde)) {
+  return true;
+}
+if (C.Tok->is(TT_FunctionTypeLParen))
   return true;
 if (C.Tok->isNot(TT_StartOfName))
   return false;
diff --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 0d0fbdb84e3271b..713d908d130c2db 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -18677,6 +18677,12 @@ TEST_F(FormatTest, AlignConsecutiveDeclarations) {
   verifyFormat("inta(int x);\n"
"double b();",
Alignment);
+  verifyFormat("struct Test {\n"
+   "  Test(const Test &) = default;\n"
+   "  ~Test() = default;\n"
+   "  Test =(const Test &) = default;\n"
+   "};",
+   Alignment);
   unsigned OldColumnLimit = Alignment.ColumnLimit;
   // We need to set ColumnLimit to zero, in order to stress nested alignments,
   // otherwise the function parameters will be re-flowed onto a single line.
@@ -18713,6 +18719,12 @@ TEST_F(FormatTest, AlignConsecutiveDeclarations) {
"double b();",
Alignment);
   Alignment.AlignConsecutiveAssignments.Enabled = true;
+  verifyFormat("struct Test {\n"
+   "  Test(const Test &)= default;\n"
+   "  ~Test()   = default;\n"
+   "  Test =(const Test &) = default;\n"
+   "};",
+   Alignment);
   // Ensure recursive alignment is broken by function braces, so that the
   // "a = 1" does not align with subsequent assignments inside the function
   // body.

``




https://github.com/llvm/llvm-project/pull/67618
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-format] Don't align ctors and dtors with other functions (PR #67618)

2023-09-27 Thread Owen Pan via cfe-commits

https://github.com/owenca created 
https://github.com/llvm/llvm-project/pull/67618

Fixed #67604.

>From dfa92b41b74e554157467ea51f5db9dfcec4fcce Mon Sep 17 00:00:00 2001
From: Owen Pan 
Date: Wed, 27 Sep 2023 16:06:48 -0700
Subject: [PATCH] [clang-format] Don't align ctors and dtors with other
 functions

Fixed #67604.
---
 clang/lib/Format/WhitespaceManager.cpp |  6 +-
 clang/unittests/Format/FormatTest.cpp  | 12 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/clang/lib/Format/WhitespaceManager.cpp 
b/clang/lib/Format/WhitespaceManager.cpp
index 1790a9df42b5d14..762729d1c4166a5 100644
--- a/clang/lib/Format/WhitespaceManager.cpp
+++ b/clang/lib/Format/WhitespaceManager.cpp
@@ -974,7 +974,11 @@ void WhitespaceManager::alignConsecutiveDeclarations() {
   AlignTokens(
   Style,
   [](Change const ) {
-if (C.Tok->isOneOf(TT_FunctionDeclarationName, TT_FunctionTypeLParen))
+if (C.Tok->is(TT_FunctionDeclarationName) && C.Tok->Previous &&
+C.Tok->Previous->isNot(tok::tilde)) {
+  return true;
+}
+if (C.Tok->is(TT_FunctionTypeLParen))
   return true;
 if (C.Tok->isNot(TT_StartOfName))
   return false;
diff --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 0d0fbdb84e3271b..713d908d130c2db 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -18677,6 +18677,12 @@ TEST_F(FormatTest, AlignConsecutiveDeclarations) {
   verifyFormat("inta(int x);\n"
"double b();",
Alignment);
+  verifyFormat("struct Test {\n"
+   "  Test(const Test &) = default;\n"
+   "  ~Test() = default;\n"
+   "  Test =(const Test &) = default;\n"
+   "};",
+   Alignment);
   unsigned OldColumnLimit = Alignment.ColumnLimit;
   // We need to set ColumnLimit to zero, in order to stress nested alignments,
   // otherwise the function parameters will be re-flowed onto a single line.
@@ -18713,6 +18719,12 @@ TEST_F(FormatTest, AlignConsecutiveDeclarations) {
"double b();",
Alignment);
   Alignment.AlignConsecutiveAssignments.Enabled = true;
+  verifyFormat("struct Test {\n"
+   "  Test(const Test &)= default;\n"
+   "  ~Test()   = default;\n"
+   "  Test =(const Test &) = default;\n"
+   "};",
+   Alignment);
   // Ensure recursive alignment is broken by function braces, so that the
   // "a = 1" does not align with subsequent assignments inside the function
   // body.

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread David Li via cfe-commits


@@ -1048,27 +1052,29 @@ class FunctionSamples {
 };
 if (isDeclaration(SymbolMap.lookup(getFuncName( {
   // Add to the import list only when it's defined out of module.
-  S.insert(getGUID(getName()));
+  S.insert(getGUID());
 }
 // Import hot CallTargets, which may not be available in IR because full
 // profile annotation cannot be done until backend compilation in ThinLTO.
 for (const auto  : BodySamples)
   for (const auto  : BS.second.getCallTargets())
-if (TS.getValue() > Threshold) {
-  const Function *Callee = SymbolMap.lookup(getFuncName(TS.getKey()));
+if (TS.second > Threshold) {
+  const Function *Callee = SymbolMap.lookup(getFuncName(TS.first));
   if (isDeclaration(Callee))
-S.insert(getGUID(TS.getKey()));
+S.insert(TS.first.getHashCode());
 }
 for (const auto  : CallsiteSamples)
   for (const auto  : CS.second)
 NameFS.second.findInlinedFunctions(S, SymbolMap, Threshold);
   }
 
   /// Set the name of the function.
-  void setName(StringRef FunctionName) { Context.setName(FunctionName); }
+  void setName(ProfileFuncRef FunctionName) {

david-xl wrote:

I suggested the ProfileFuncRef because it is no longer name/string, but a kind 
of handle to reference the function.  Keeping FuncName is fine with me too.

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread David Li via cfe-commits


@@ -1048,27 +1052,29 @@ class FunctionSamples {
 };
 if (isDeclaration(SymbolMap.lookup(getFuncName( {
   // Add to the import list only when it's defined out of module.
-  S.insert(getGUID(getName()));
+  S.insert(getGUID());
 }
 // Import hot CallTargets, which may not be available in IR because full
 // profile annotation cannot be done until backend compilation in ThinLTO.
 for (const auto  : BodySamples)
   for (const auto  : BS.second.getCallTargets())
-if (TS.getValue() > Threshold) {
-  const Function *Callee = SymbolMap.lookup(getFuncName(TS.getKey()));
+if (TS.second > Threshold) {
+  const Function *Callee = SymbolMap.lookup(getFuncName(TS.first));
   if (isDeclaration(Callee))
-S.insert(getGUID(TS.getKey()));
+S.insert(TS.first.getHashCode());
 }
 for (const auto  : CallsiteSamples)
   for (const auto  : CS.second)
 NameFS.second.findInlinedFunctions(S, SymbolMap, Threshold);
   }
 
   /// Set the name of the function.
-  void setName(StringRef FunctionName) { Context.setName(FunctionName); }
+  void setName(ProfileFuncRef FunctionName) {

david-xl wrote:

I suggested the ProfileFuncRef because it is no longer name/string, but a kind 
of handle to reference the function.  Keeping FuncName is fine with me too.

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D159483: [Modules] Add a flag to control builtin headers being in system modules

2023-09-27 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added subscribers: sammccall, dblaikie.
dblaikie added a comment.

@sammccall @rsmith - figure if this does impact us, we'll use the flag to 
opt-out in the short term while we figure out longer-term solution, yeah? Is 
there any pre-emptive testing you think is worth doing?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159483/new/

https://reviews.llvm.org/D159483

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV][GISel] Select G_SELECT (PR #67614)

2023-09-27 Thread Michael Maitland via cfe-commits


@@ -239,6 +245,11 @@ bool RISCVInstructionSelector::select(MachineInstr ) {
   }
   case TargetOpcode::G_SEXT_INREG:
 return selectSExtInreg(MI, MIB);
+  case TargetOpcode::G_SELECT:
+if (!selectSelect(MI, MIB, MRI))
+  return false;
+MI.eraseFromParent();

michaelmaitland wrote:

Looks like other `select` functions (i.e. selectSExtInreg) do 
`MI.eraseFromParent();` in `selectXX`. Should we move this one into 
`selectSelect` in the `true` cases for consistency and simplification here?

https://github.com/llvm/llvm-project/pull/67614
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits

WenleiHe wrote:

> When testing on an internal large profile (> 1 GB, with more than 10 million 
> functions), the full profile load time is reduced from 28 sec to 25 sec in 
> average, and reading function offset table from 0.78s to 0.7s 

What is the E2E compile time change for the case you measured? Is there any 
memory footprint change?

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits

WenleiHe wrote:

> When testing on an internal large profile (> 1 GB, with more than 10 million 
> functions), the full profile load time is reduced from 28 sec to 25 sec in 
> average, and reading function offset table from 0.78s to 0.7s 

What is the E2E compile time change for the case you measured? Is there any 
memory footprint change?

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -1048,27 +1052,29 @@ class FunctionSamples {
 };
 if (isDeclaration(SymbolMap.lookup(getFuncName( {
   // Add to the import list only when it's defined out of module.
-  S.insert(getGUID(getName()));
+  S.insert(getGUID());
 }
 // Import hot CallTargets, which may not be available in IR because full
 // profile annotation cannot be done until backend compilation in ThinLTO.
 for (const auto  : BodySamples)
   for (const auto  : BS.second.getCallTargets())
-if (TS.getValue() > Threshold) {
-  const Function *Callee = SymbolMap.lookup(getFuncName(TS.getKey()));
+if (TS.second > Threshold) {
+  const Function *Callee = SymbolMap.lookup(getFuncName(TS.first));
   if (isDeclaration(Callee))
-S.insert(getGUID(TS.getKey()));
+S.insert(TS.first.getHashCode());
 }
 for (const auto  : CallsiteSamples)
   for (const auto  : CS.second)
 NameFS.second.findInlinedFunctions(S, SymbolMap, Threshold);
   }
 
   /// Set the name of the function.
-  void setName(StringRef FunctionName) { Context.setName(FunctionName); }
+  void setName(ProfileFuncRef FunctionName) {

WenleiHe wrote:

I think it's ProfileFuncRef that is misleading. It's really just a wrapper 
around name, not wrapper for function. It should be ProfileFuncName. 

So I think it makes sense to keep Name, instead of using Function. Same goes 
for other places. 

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -85,7 +86,7 @@ class ProfiledCallGraph {
 std::queue Queue;
 for (auto  : ContextTracker.getRootContext().getAllChildContext()) {
   ContextTrieNode *Callee = 
-  addProfiledFunction(ContextTracker.getFuncNameFor(Callee));
+  addProfiledFunction(Callee->getFuncName());

WenleiHe wrote:

ProfiledCallGraph needs to build graph with actual function name. This is 
because it is used to build up processing order for 
SampleProfileLoader::SymbolMap, which is keyed on string name. 

This change would break it as it changes ProfiledCallGraph to also use MD5. 
Same for similar changes below.   

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)

WenleiHe wrote:

Is it necessary for this to be explicit? Allow implicit conversion and remove 
some of the changes later. 

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;

WenleiHe wrote:

Currently the indicator for string vs hash is implicit: Data == null means it's 
hash. This isn't good for readability. 

Can we represent them with union and an explicit flag? 

```
union {
StringRef Name;
uint64_t Hash;
};
bool UseStringName;
```

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -1048,27 +1052,29 @@ class FunctionSamples {
 };
 if (isDeclaration(SymbolMap.lookup(getFuncName( {
   // Add to the import list only when it's defined out of module.
-  S.insert(getGUID(getName()));
+  S.insert(getGUID());
 }
 // Import hot CallTargets, which may not be available in IR because full
 // profile annotation cannot be done until backend compilation in ThinLTO.
 for (const auto  : BodySamples)
   for (const auto  : BS.second.getCallTargets())
-if (TS.getValue() > Threshold) {
-  const Function *Callee = SymbolMap.lookup(getFuncName(TS.getKey()));
+if (TS.second > Threshold) {
+  const Function *Callee = SymbolMap.lookup(getFuncName(TS.first));
   if (isDeclaration(Callee))
-S.insert(getGUID(TS.getKey()));
+S.insert(TS.first.getHashCode());
 }
 for (const auto  : CallsiteSamples)
   for (const auto  : CS.second)
 NameFS.second.findInlinedFunctions(S, SymbolMap, Threshold);
   }
 
   /// Set the name of the function.
-  void setName(StringRef FunctionName) { Context.setName(FunctionName); }
+  void setName(ProfileFuncRef FunctionName) {

WenleiHe wrote:

I think it's ProfileFuncRef that is misleading. It's really just a wrapper 
around name, not wrapper for function. It should be ProfileFuncName. 

So I think it makes sense to keep Name, instead of using Function. Same goes 
for other places. 

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+// Only need to check for base 10 digits, fail faster if otherwise.
+if (Str.size() > 0 && isdigit(Str[0]) &&

WenleiHe wrote:

I don't think `Str.size() > 0 && isdigit(Str[0])` is going to speed up things 
meaningfully. They are the first two things that `getAsInteger` checks anyways. 
Suggest remove them and just do `getAsInteger` for simplicity and readability. 

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -836,7 +840,7 @@ std::error_code SampleProfileWriterBinary::writeBody(const 
FunctionSamples ) {
 encodeULEB128(Sample.getSamples(), OS);
 encodeULEB128(Sample.getCallTargets().size(), OS);
 for (const auto  : Sample.getSortedCallTargets()) {
-  StringRef Callee = J.first;
+  auto Callee = J.first;

WenleiHe wrote:

nit: auto->ProfileFuncRef for readability. See 
https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {

WenleiHe wrote:

This name ProfileFuncRef can be misleading. It's not a reference to profile 
function which should include the actual profile. 

Maybe something like ProfileFuncName.

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;

WenleiHe wrote:

Currently the indicator for string vs hash is implicit: Data == null means it's 
hash. This isn't good for readability. 

Can we represent them with union and an explicit flag? 

```
union {
StringRef Name;
uint64_t Hash;
};
bool UseStringName;
```

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)

WenleiHe wrote:

Is it necessary for this to be explicit? Allow implicit conversion and remove 
some of the changes later. 

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+// Only need to check for base 10 digits, fail faster if otherwise.
+if (Str.size() > 0 && isdigit(Str[0]) &&

WenleiHe wrote:

I don't think `Str.size() > 0 && isdigit(Str[0])` is going to speed up things 
meaningfully. They are the first two things that `getAsInteger` checks anyways. 
Suggest remove them and just do `getAsInteger` for simplicity and readability. 

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-09-27 Thread via cfe-commits


@@ -305,6 +304,10 @@ struct LineLocation {
 return LineOffset != O.LineOffset || Discriminator != O.Discriminator;
   }
 
+  uint64_t getHashCode() const {

WenleiHe wrote:

LineLocationHash should reuse getHashCode to avoid future divergence. 

https://github.com/llvm/llvm-project/pull/66164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Recommit "Implement [[msvc::no_unique_address]] (#65675)" (PR #67199)

2023-09-27 Thread Amy Huang via cfe-commits

https://github.com/amykhuang edited 
https://github.com/llvm/llvm-project/pull/67199
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Recommit "Implement [[msvc::no_unique_address]] (#65675)" (PR #67199)

2023-09-27 Thread Amy Huang via cfe-commits

amykhuang wrote:

Added a section for target specific spellings in 
`GenerateHasAttrSpellingStringSwitch`, and a check for "existsInTarget" in 
`ParseCXX11AttributeArgs`, and looks like all tests are passing now.

https://github.com/llvm/llvm-project/pull/67199
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [libc++][lit] Allow overriding the executor for tests (PR #66545)

2023-09-27 Thread Alexander Richardson via cfe-commits

arichardson wrote:

> @arichardson
> 
> here is a problem with your changes when building the libraries on the 
> windows cross toolchain builders
> 
> * https://lab.llvm.org/buildbot/#/builders/60/builds/14086
> * https://lab.llvm.org/buildbot/#/builders/119/builds/15283
> 
> https://lab.llvm.org/buildbot/#/builders/60/builds/14086/steps/12/logs/stdio
> 
> ```
> llvm-lit.py: 
> C:\buildbot\as-builder-1\x-armv7l\llvm-project\llvm\utils\lit\lit\TestingConfig.py:151:
>  fatal: unable to parse config file 
> 'C:/buildbot/as-builder-1/x-armv7l/build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins/libunwind/test/cmake-bridge.cfg',
>  traceback: Traceback (most recent call last):
>   File 
> "C:\buildbot\as-builder-1\x-armv7l\llvm-project\llvm\utils\lit\lit\TestingConfig.py",
>  line 139, in load_from_path
> exec(compile(data, path, "exec"), cfg_globals, None)
>   File 
> "C:/buildbot/as-builder-1/x-armv7l/build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins/libunwind/test/cmake-bridge.cfg",
>  line 7
> config. 'executor="C:/Python310/python.exe" 
> "C:/buildbot/as-builder-1/x-armv7l/llvm-project/libcxx/utils/ssh.py" --host = 
> "ubu...@jetson6.lab.llvm.org'"
>   
>  ^
> SyntaxError: unterminated string literal (detected at line 7)
> ```
> 
> would you take care of it?
> 
> UPDATE: Just let me know if you will need to check you changes before commit. 
> I will test them on the builder locally.

@vvereschaka Could you try the following patch? It works in my local testing 
but I don't have the right setup for you toolchain. The problem appears to be 
that cmake always uses greedy regexes, so I've changed the split logic to 
instead find the first =.

```
diff --git a/libcxx/test/CMakeLists.txt b/libcxx/test/CMakeLists.txt
index fd194a36a28f..1416a8343df7 100644
--- a/libcxx/test/CMakeLists.txt
+++ b/libcxx/test/CMakeLists.txt
@@ -39,8 +39,10 @@ if (LLVM_USE_SANITIZER)
 endif()
 
 foreach(param IN LISTS LIBCXX_TEST_PARAMS)
-  string(REGEX REPLACE "(.+)=(.+)" "\\1" name "${param}")
-  string(REGEX REPLACE "(.+)=(.+)" "\\2" value "${param}")
+  string(FIND "${param}" "=" _eq_index)
+  string(SUBSTRING "${param}" 0 ${_eq_index} name)
+  string(SUBSTRING "${param}" ${_eq_index} -1 value)
+  string(SUBSTRING "${value}" 1 -1 value) # strip the leading =
   serialize_lit_param("${name}" "\"${value}\"")
 endforeach()
 
diff --git a/libcxxabi/test/CMakeLists.txt b/libcxxabi/test/CMakeLists.txt
index b65ac3a9d164..1baddf9ab305 100644
--- a/libcxxabi/test/CMakeLists.txt
+++ b/libcxxabi/test/CMakeLists.txt
@@ -53,8 +53,10 @@ else()
 endif()
 
 foreach(param IN LISTS LIBCXXABI_TEST_PARAMS)
-  string(REGEX REPLACE "(.+)=(.+)" "\\1" name "${param}")
-  string(REGEX REPLACE "(.+)=(.+)" "\\2" value "${param}")
+  string(FIND "${param}" "=" _eq_index)
+  string(SUBSTRING "${param}" 0 ${_eq_index} name)
+  string(SUBSTRING "${param}" ${_eq_index} -1 value)
+  string(SUBSTRING "${value}" 1 -1 value) # strip the leading =
   serialize_lit_param("${name}" "\"${value}\"")
 endforeach()
 
diff --git a/libunwind/test/CMakeLists.txt b/libunwind/test/CMakeLists.txt
index 084da0ab8f35..9d128720968c 100644
--- a/libunwind/test/CMakeLists.txt
+++ b/libunwind/test/CMakeLists.txt
@@ -36,8 +36,10 @@ else()
 endif()
 
 foreach(param IN LISTS LIBUNWIND_TEST_PARAMS)
-  string(REGEX REPLACE "(.+)=(.+)" "\\1" name "${param}")
-  string(REGEX REPLACE "(.+)=(.+)" "\\2" value "${param}")
+  string(FIND "${param}" "=" _eq_index)
+  string(SUBSTRING "${param}" 0 ${_eq_index} name)
+  string(SUBSTRING "${param}" ${_eq_index} -1 value)
+  string(SUBSTRING "${value}" 1 -1 value) # strip the leading =
   serialize_lit_param("${name}" "\"${value}\"")
 endforeach()

```

https://github.com/llvm/llvm-project/pull/66545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Recommit "Implement [[msvc::no_unique_address]] (#65675)" (PR #67199)

2023-09-27 Thread Amy Huang via cfe-commits

https://github.com/amykhuang updated 
https://github.com/llvm/llvm-project/pull/67199

>From b1f0feeaed93edfdd692858e9d63ab6bbb94c0a5 Mon Sep 17 00:00:00 2001
From: Amy Huang 
Date: Fri, 22 Sep 2023 14:40:14 -0700
Subject: [PATCH 1/3] Recommit "Implement [[msvc::no_unique_address]] (#65675)"

Change the attribute docs so that there is a separate one for the MSVC
attribute.

This reverts commit 71f9e7695b87298f9855d8890f0e6a3b89381eb5.
---
 clang/include/clang/Basic/Attr.td |  19 +-
 clang/include/clang/Basic/AttrDocs.td |   9 +
 clang/lib/AST/Decl.cpp|  11 +-
 clang/lib/AST/RecordLayoutBuilder.cpp |  53 ++-
 clang/lib/Parse/ParseDeclCXX.cpp  |   3 +-
 clang/lib/Sema/SemaDeclAttr.cpp   |  10 +
 clang/test/Layout/ms-no-unique-address.cpp| 381 ++
 clang/test/Preprocessor/has_attribute.cpp |   5 +-
 .../SemaCXX/cxx2a-ms-no-unique-address.cpp|  19 +
 9 files changed, 494 insertions(+), 16 deletions(-)
 create mode 100644 clang/test/Layout/ms-no-unique-address.cpp
 create mode 100644 clang/test/SemaCXX/cxx2a-ms-no-unique-address.cpp

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 21a3b5226623cf2..3da91d25ec97347 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -1798,11 +1798,24 @@ def ArmMveStrictPolymorphism : TypeAttr, 
TargetSpecificAttr {
   let Documentation = [ArmMveStrictPolymorphismDocs];
 }
 
-def NoUniqueAddress : InheritableAttr, TargetSpecificAttr 
{
-  let Spellings = [CXX11<"", "no_unique_address", 201803>];
+def NoUniqueAddress : InheritableAttr {
+  let Subjects = SubjectList<[NonBitField], ErrorDiag>;
+  // No spellings because instances of this attribute are created by
+  // MSNoUniqueAddress and ItaniumNoUniqueAddress
+  let Spellings = [];
+  let Documentation = [InternalOnly];
+}
+
+def MSNoUniqueAddress : InheritableAttr, 
TargetSpecificAttr {
   let Subjects = SubjectList<[NonBitField], ErrorDiag>;
+  let Spellings = [CXX11<"msvc", "no_unique_address", 201803>];
+  let Documentation = [MSNoUniqueAddressDocs];
+}
+
+def ItaniumNoUniqueAddress : InheritableAttr, 
TargetSpecificAttr {
+  let Subjects = SubjectList<[NonBitField], ErrorDiag>;
+  let Spellings = [CXX11<"", "no_unique_address", 201803>];
   let Documentation = [NoUniqueAddressDocs];
-  let SimpleHandler = 1;
 }
 
 def ReturnsTwice : InheritableAttr {
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index b13baa46754cfd4..d16ce23c067982d 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -1408,6 +1408,15 @@ in C++11 onwards.
   }];
 }
 
+def MSNoUniqueAddressDocs : Documentation {
+  let Category = DocCatField;
+  let Content = [{
+On MSVC targets, ``[[no_unique_address]]`` is ignored; use
+``[[msvc::no_unique_address]]`` instead. Currently there is no guarantee of ABI
+compatibility or stability with MSVC.
+  }];
+}
+
 def ObjCRequiresSuperDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 08ae2087cfe70eb..07aee0d87c835a8 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -4507,9 +4507,14 @@ bool FieldDecl::isZeroSize(const ASTContext ) const {
 
   // Otherwise, [...] the circumstances under which the object has zero size
   // are implementation-defined.
-  // FIXME: This might be Itanium ABI specific; we don't yet know what the MS
-  // ABI will do.
-  return true;
+  if (!Ctx.getTargetInfo().getCXXABI().isMicrosoft())
+return true;
+
+  // MS ABI: has nonzero size if it is a class type with class type fields,
+  // whether or not they have nonzero size
+  return !llvm::any_of(CXXRD->fields(), [](const FieldDecl *Field) {
+return Field->getType()->getAs();
+  });
 }
 
 bool FieldDecl::isPotentiallyOverlapping() const {
diff --git a/clang/lib/AST/RecordLayoutBuilder.cpp 
b/clang/lib/AST/RecordLayoutBuilder.cpp
index 8afd88ae7be27b3..f1f2275da44dcad 100644
--- a/clang/lib/AST/RecordLayoutBuilder.cpp
+++ b/clang/lib/AST/RecordLayoutBuilder.cpp
@@ -2545,7 +2545,10 @@ struct MicrosoftRecordLayoutBuilder {
 CharUnits Alignment;
   };
   typedef llvm::DenseMap BaseOffsetsMapTy;
-  MicrosoftRecordLayoutBuilder(const ASTContext ) : Context(Context) {}
+  MicrosoftRecordLayoutBuilder(const ASTContext ,
+   EmptySubobjectMap *EmptySubobjects)
+  : Context(Context), EmptySubobjects(EmptySubobjects) {}
+
 private:
   MicrosoftRecordLayoutBuilder(const MicrosoftRecordLayoutBuilder &) = delete;
   void operator=(const MicrosoftRecordLayoutBuilder &) = delete;
@@ -2595,6 +2598,8 @@ struct MicrosoftRecordLayoutBuilder {
   llvm::SmallPtrSetImpl ,
   const CXXRecordDecl *RD) const;
   const ASTContext 
+  EmptySubobjectMap *EmptySubobjects;
+
   /// The size of the record being laid out.
   CharUnits Size;
   

[clang] [clang-format] Fix requires misannotation with comma (PR #65908)

2023-09-27 Thread Emilia Kond via cfe-commits

https://github.com/rymiel closed https://github.com/llvm/llvm-project/pull/65908
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 3e87829 - [clang-format] Fix requires misannotation with comma (#65908)

2023-09-27 Thread via cfe-commits

Author: Emilia Kond
Date: 2023-09-28T01:34:30+03:00
New Revision: 3e87829a8a9ab6a5f62078c590eec09f5024f95f

URL: 
https://github.com/llvm/llvm-project/commit/3e87829a8a9ab6a5f62078c590eec09f5024f95f
DIFF: 
https://github.com/llvm/llvm-project/commit/3e87829a8a9ab6a5f62078c590eec09f5024f95f.diff

LOG: [clang-format] Fix requires misannotation with comma (#65908)

clang-format uses a heuristic to determine if a requires() is either a
requires clause or requires expression, based on what is in the
parentheses. Part of this heuristic assumed that a requires clause can
never contain a comma, however this is not the case if said comma is in
the template argument of a type.

This patch allows commas to appear in a requires clause if an angle
bracket `<` has been opened.

Fixes https://github.com/llvm/llvm-project/issues/65904

Added: 


Modified: 
clang/lib/Format/UnwrappedLineParser.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index 53310d44c709af5..9fbdfb91e21dec9 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -3362,9 +3362,12 @@ bool clang::format::UnwrappedLineParser::parseRequires() 
{
 case tok::kw_volatile:
 case tok::kw_const:
 case tok::comma:
-  FormatTok = Tokens->setPosition(StoredPosition);
-  parseRequiresExpression(RequiresToken);
-  return false;
+  if (OpenAngles == 0) {
+FormatTok = Tokens->setPosition(StoredPosition);
+parseRequiresExpression(RequiresToken);
+return false;
+  }
+  break;
 case tok::r_paren:
 case tok::pipepipe:
   FormatTok = Tokens->setPosition(StoredPosition);

diff  --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index 98b63d44b78c7c9..d3437bffeba2d35 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -1032,6 +1032,16 @@ TEST_F(TokenAnnotatorTest, 
UnderstandsRequiresClausesAndConcepts) {
   ASSERT_EQ(Tokens.size(), 22u) << Tokens;
   EXPECT_TOKEN(Tokens[4], tok::kw_requires, TT_RequiresClause);
   EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_PointerOrReference);
+
+  Tokens = annotate("void f() & requires(true) {}");
+  EXPECT_EQ(Tokens.size(), 12u) << Tokens;
+  EXPECT_TOKEN(Tokens[4], tok::amp, TT_PointerOrReference);
+  EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
+
+  Tokens = annotate("void f() & requires(C) {}");
+  EXPECT_EQ(Tokens.size(), 17u) << Tokens;
+  EXPECT_TOKEN(Tokens[4], tok::amp, TT_PointerOrReference);
+  EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsRequiresExpressions) {
@@ -1151,6 +1161,14 @@ TEST_F(TokenAnnotatorTest, 
UnderstandsRequiresExpressions) {
   EXPECT_TOKEN(Tokens[3], tok::kw_requires, TT_RequiresExpression);
   EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_RequiresExpressionLParen);
   EXPECT_TOKEN(Tokens[14], tok::l_brace, TT_RequiresExpressionLBrace);
+
+  Tokens = annotate("bool foo = requires(C c) {\n"
+"  { c.foo(); }\n"
+"};");
+  ASSERT_EQ(Tokens.size(), 25u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::kw_requires, TT_RequiresExpression);
+  EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_RequiresExpressionLParen);
+  EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_RequiresExpressionLBrace);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsPragmaRegion) {



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-format] Fix requires misannotation with comma (PR #65908)

2023-09-27 Thread via cfe-commits

https://github.com/mydeveloperday approved this pull request.


https://github.com/llvm/llvm-project/pull/65908
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-format] Disable OuterScope lambda indentation behaviour for constructor initializers (PR #66755)

2023-09-27 Thread via cfe-commits

https://github.com/mydeveloperday approved this pull request.


https://github.com/llvm/llvm-project/pull/66755
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-format] Disable OuterScope lambda indentation behaviour for constructor initializers (PR #66755)

2023-09-27 Thread via cfe-commits

https://github.com/mydeveloperday resolved 
https://github.com/llvm/llvm-project/pull/66755
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-format] Disable OuterScope lambda indentation behaviour for constructor initializers (PR #66755)

2023-09-27 Thread via cfe-commits

https://github.com/mydeveloperday approved this pull request.


https://github.com/llvm/llvm-project/pull/66755
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Support target names with dots in more utilities (PR #65812)

2023-09-27 Thread via cfe-commits


@@ -1696,6 +1696,40 @@ TEST(Support, ReplacePathPrefix) {
   EXPECT_EQ(Path, "C:\\old/foo\\bar");
 }
 
+TEST(Support, FindProgramName) {
+  StringRef WindowsProgName =
+  path::program_name("C:\\Test\\foo.exe", path::Style::windows);
+  EXPECT_EQ(WindowsProgName, "foo");
+
+  StringRef WindowsProgNameManyDots = path::program_name(
+  "C:\\Test.7\\x86_64-freebsd14.0-clang.exe", path::Style::windows);
+  EXPECT_EQ(WindowsProgNameManyDots, "x86_64-freebsd14.0-clang");
+
+  StringRef PosixProgName =
+  path::program_name("/var/empty/clang.exe", path::Style::posix);
+  EXPECT_EQ(PosixProgName, "clang");
+
+  StringRef PosixProgNameManyDotsExe = path::program_name(
+  "/llvm-test16.4/x86_64-portbld-freebsd13.2-llvm-ar.exe",
+  path::Style::posix);
+  EXPECT_EQ(PosixProgNameManyDotsExe, "x86_64-portbld-freebsd13.2-llvm-ar");
+
+  StringRef PosixProgNameManyDots = path::program_name(
+  "/llvm-test16.4/x86_64-portbld-freebsd13.2-llvm-ar", path::Style::posix);
+  EXPECT_EQ(PosixProgNameManyDots, "x86_64-portbld-freebsd13.2-llvm-ar");
+
+  StringRef PosixProgNameSh =
+  
path::program_name("/llvm-test16.4/x86_64-portbld-freebsd13.2-llvm-ar.sh",
+ path::Style::posix);
+  EXPECT_EQ(PosixProgNameSh, "x86_64-portbld-freebsd13.2-llvm-ar.sh");
+
+  // TODO: determine if this is correct. What happens on windows with an 
executable
+  // named ".exe"?

dankm wrote:

Makes sense, I'll do that in a subsequent commit.. hopefully that keeps the 
review intact.. still getting used to github.

https://github.com/llvm/llvm-project/pull/65812
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-format] Handle __attribute/__declspec/AttributeMacro consistently (PR #67518)

2023-09-27 Thread via cfe-commits

https://github.com/mydeveloperday approved this pull request.


https://github.com/llvm/llvm-project/pull/67518
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 63544af - [Driver][test] Clean up hexagon-*

2023-09-27 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2023-09-27T15:24:44-07:00
New Revision: 63544af9e4197650b725dcc80152a8c2cde1cdbd

URL: 
https://github.com/llvm/llvm-project/commit/63544af9e4197650b725dcc80152a8c2cde1cdbd
DIFF: 
https://github.com/llvm/llvm-project/commit/63544af9e4197650b725dcc80152a8c2cde1cdbd.diff

LOG: [Driver][test] Clean up hexagon-*

Added: 


Modified: 
clang/test/Driver/hexagon-hvx-ieee-fp.c
clang/test/Driver/hexagon-hvx-qfloat.c
clang/test/Driver/hexagon-hvx.c
clang/test/Driver/hexagon-long-calls.c
clang/test/Driver/hexagon-memops.c
clang/test/Driver/hexagon-nvj.c
clang/test/Driver/hexagon-nvs.c
clang/test/Driver/hexagon-packets.c
clang/test/Driver/hexagon-toolchain-elf.c
clang/test/Driver/hexagon-toolchain-linux.c
clang/test/Driver/hexagon-vectorize.c

Removed: 
clang/test/Driver/Inputs/hexagon_tree/Tools/bin/readme



diff  --git a/clang/test/Driver/Inputs/hexagon_tree/Tools/bin/readme 
b/clang/test/Driver/Inputs/hexagon_tree/Tools/bin/readme
deleted file mode 100644
index 6e2cef0143f5267..000
--- a/clang/test/Driver/Inputs/hexagon_tree/Tools/bin/readme
+++ /dev/null
@@ -1,4 +0,0 @@
-Git does not record empty directories. Create a dummy file in each directory
-here. Strictly speaking, putting dummy files in leaf directories should be
-sufficient, but adding them everywhere reduces the risk of repeating the same
-problem in case new directories are added.

diff  --git a/clang/test/Driver/hexagon-hvx-ieee-fp.c 
b/clang/test/Driver/hexagon-hvx-ieee-fp.c
index 4166d640b6faa51..c42ee77cc2a9297 100644
--- a/clang/test/Driver/hexagon-hvx-ieee-fp.c
+++ b/clang/test/Driver/hexagon-hvx-ieee-fp.c
@@ -2,24 +2,24 @@
 // Tests for the hvx ieee fp feature and errors.
 // 
-
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv68 -mhvx 
-mhvx-ieee-fp \
-// RUN:  2>&1 | FileCheck -check-prefix=CHECK-IEEEFP %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv66 -mhvx=v68 
-mhvx-ieee-fp \
-// RUN:  2>&1 | FileCheck -check-prefix=CHECK-IEEEFP %s
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx 
-mhvx-ieee-fp \
+// RUN:   2>&1 | FileCheck -check-prefix=CHECK-IEEEFP %s
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv66 -mhvx=v68 
-mhvx-ieee-fp \
+// RUN:   2>&1 | FileCheck -check-prefix=CHECK-IEEEFP %s
 // CHECK-IEEEFP: "-target-feature" "+hvx-ieee-fp"
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv68 -mhvx 
-mhvx-ieee-fp \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx 
-mhvx-ieee-fp \
 // RUN:  -mno-hvx-ieee-fp 2>&1 | FileCheck -check-prefix=CHECK-NO-IEEEFP %s
 // CHECK-NO-IEEEFP: "-target-feature" "-hvx-ieee-fp"
 
 // IEEE-FP is valid only on hvxv68 and hvxv68+.
 // RUN: not %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx=v66 \
-// RUN: -mhvx-ieee-fp 2>&1 | FileCheck -check-prefix=CHECK-ERROR1 %s
+// RUN:   -mhvx-ieee-fp 2>&1 | FileCheck -check-prefix=CHECK-ERROR1 %s
 // RUN: not %clang -c %s -### --target=hexagon-unknown-elf -mv66 -mhvx 
-mhvx-ieee-fp \
-// RUN:  2>&1 | FileCheck -check-prefix=CHECK-ERROR1 %s
+// RUN:   2>&1 | FileCheck -check-prefix=CHECK-ERROR1 %s
 // CHECK-ERROR1: error: -mhvx-ieee-fp is not supported on HVX v66
 
 // IEEE-FP is valid only if HVX is enabled.
 // RUN: not %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx-ieee-fp 
\
-// RUN:  2>&1 | FileCheck -check-prefix=CHECK-ERROR2 %s
+// RUN:   2>&1 | FileCheck -check-prefix=CHECK-ERROR2 %s
 // CHECK-ERROR2: error: -mhvx-ieee-fp requires HVX, use -mhvx/-mhvx= to enable 
it

diff  --git a/clang/test/Driver/hexagon-hvx-qfloat.c 
b/clang/test/Driver/hexagon-hvx-qfloat.c
index ac3de8ded16ebd6..f3662da040a8fcf 100644
--- a/clang/test/Driver/hexagon-hvx-qfloat.c
+++ b/clang/test/Driver/hexagon-hvx-qfloat.c
@@ -2,13 +2,13 @@
 // Tests for the hvx qfloat feature and errors.
 // 
-
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv68 -mhvx -mhvx-qfloat 
\
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx 
-mhvx-qfloat \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-QFLOAT %s
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv66 -mhvx=v68 
-mhvx-qfloat \
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv66 -mhvx=v68 
-mhvx-qfloat \
 // RUN:  2>&1 | FileCheck -check-prefix=CHECK-QFLOAT %s
 // CHECK-QFLOAT: "-target-feature" "+hvx-qfloat"
 
-// RUN: %clang -c %s -### -target hexagon-unknown-elf -mv68 -mhvx -mhvx-qfloat 
\
+// RUN: %clang -c %s -### --target=hexagon-unknown-elf -mv68 -mhvx 
-mhvx-qfloat \
 // RUN:  -mno-hvx-qfloat 2>&1 | FileCheck -check-prefix=CHECK-NO-QFLOAT %s
 // CHECK-NO-QFLOAT: "-target-feature" "-hvx-qfloat"
 

diff  --git a/clang/test/Driver/hexagon-hvx.c b/clang/test/Driver/hexagon-hvx.c
index 

[clang] Make -frewrite-includes put an endif at the end of the included text (PR #67613)

2023-09-27 Thread via cfe-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 8ff77a8f04e5a385115c1790a5f03ec263a00faf 
0f63068d1085e5064d47916a86fac089c4417e57 -- 
clang/lib/Frontend/Rewrite/InclusionRewriter.cpp 
clang/test/Frontend/rewrite-includes-cli-include.c 
clang/test/Frontend/rewrite-includes-missing.c 
clang/test/Frontend/rewrite-includes.c clang/test/Modules/preprocess-module.cpp
``





View the diff from clang-format here.


``diff
diff --git a/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp 
b/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
index 6ab57adc41bf..87f048d36b84 100644
--- a/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
+++ b/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
@@ -418,8 +418,8 @@ void InclusionRewriter::Process(FileID FileId,
   case tok::pp_import: {
 SourceLocation Loc = HashToken.getLocation();
 const IncludedFile *Inc = FindIncludeAtLocation(Loc);
-CommentOutDirective(RawLex, HashToken, FromFile, LocalEOL, 
NextToWrite,
-  Line, Inc);
+CommentOutDirective(RawLex, HashToken, FromFile, LocalEOL,
+NextToWrite, Line, Inc);
 if (FileId != PP.getPredefinesFileID())
   WriteLineInfo(FileName, Line - 1, FileType, "");
 StringRef LineInfoExtra;

``




https://github.com/llvm/llvm-project/pull/67613
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV][NFC] Move some common class/multiclass from riscv_vector.td to riscv_vector_common.td (PR #67587)

2023-09-27 Thread Craig Topper via cfe-commits

https://github.com/topperc approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/67587
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Make -frewrite-includes put an endif at the end of the included text (PR #67613)

2023-09-27 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang-modules


Changes

Also add the filename to the comments it emits, to help identify where included 
text ends.

---

Patch is 25.05 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/67613.diff


5 Files Affected:

- (modified) clang/lib/Frontend/Rewrite/InclusionRewriter.cpp (+26-7) 
- (modified) clang/test/Frontend/rewrite-includes-cli-include.c (+1) 
- (modified) clang/test/Frontend/rewrite-includes-missing.c (+2-2) 
- (modified) clang/test/Frontend/rewrite-includes.c (+74-56) 
- (modified) clang/test/Modules/preprocess-module.cpp (+3-3) 


``diff
diff --git a/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp 
b/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
index d3a3db0139c6d2f..6ab57adc41bfe8b 100644
--- a/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
+++ b/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
@@ -90,8 +90,10 @@ class InclusionRewriter : public PPCallbacks {
  bool EnsureNewline);
   void CommentOutDirective(Lexer , const Token ,
const MemoryBufferRef , StringRef EOL,
-   unsigned , int );
+   unsigned , int ,
+   const IncludedFile *Inc = nullptr);
   const IncludedFile *FindIncludeAtLocation(SourceLocation Loc) const;
+  StringRef getIncludedFileName(const IncludedFile *Inc) const;
   const Module *FindModuleAtLocation(SourceLocation Loc) const;
   const Module *FindEnteredModule(SourceLocation Loc) const;
   bool IsIfAtLocationTrue(SourceLocation Loc) const;
@@ -311,6 +313,17 @@ void InclusionRewriter::OutputContentUpTo(const 
MemoryBufferRef ,
   WriteFrom = WriteTo;
 }
 
+StringRef
+InclusionRewriter::getIncludedFileName(const IncludedFile *Inc) const {
+  if (Inc) {
+auto B = SM.getBufferOrNone(Inc->Id);
+assert(B && "Attempting to process invalid inclusion");
+if (B)
+  return llvm::sys::path::filename(B->getBufferIdentifier());
+  }
+  return StringRef();
+}
+
 /// Print characters from \p FromFile starting at \p NextToWrite up until the
 /// inclusion directive at \p StartToken, then print out the inclusion
 /// inclusion directive disabled by a #if directive, updating \p NextToWrite
@@ -320,7 +333,8 @@ void InclusionRewriter::CommentOutDirective(Lexer 
,
 const Token ,
 const MemoryBufferRef ,
 StringRef LocalEOL,
-unsigned , int ) {
+unsigned , int ,
+const IncludedFile *Inc) {
   OutputContentUpTo(FromFile, NextToWrite,
 SM.getFileOffset(StartToken.getLocation()), LocalEOL, Line,
 false);
@@ -332,12 +346,14 @@ void InclusionRewriter::CommentOutDirective(Lexer 
,
 // OutputContentUpTo() would not output anything anyway.
 return;
   }
-  OS << "#if 0 /* expanded by -frewrite-includes */" << MainEOL;
+  OS << "#if 0 /* " << getIncludedFileName(Inc)
+ << " expanded by -frewrite-includes */" << MainEOL;
   OutputContentUpTo(FromFile, NextToWrite,
 SM.getFileOffset(DirectiveToken.getLocation()) +
 DirectiveToken.getLength(),
 LocalEOL, Line, true);
-  OS << "#endif /* expanded by -frewrite-includes */" << MainEOL;
+  OS << (Inc ? "#else" : "#endif") << " /* " << getIncludedFileName(Inc)
+ << " expanded by -frewrite-includes */" << MainEOL;
 }
 
 /// Find the next identifier in the pragma directive specified by \p RawToken.
@@ -400,15 +416,16 @@ void InclusionRewriter::Process(FileID FileId,
   case tok::pp_include:
   case tok::pp_include_next:
   case tok::pp_import: {
+SourceLocation Loc = HashToken.getLocation();
+const IncludedFile *Inc = FindIncludeAtLocation(Loc);
 CommentOutDirective(RawLex, HashToken, FromFile, LocalEOL, 
NextToWrite,
-  Line);
+  Line, Inc);
 if (FileId != PP.getPredefinesFileID())
   WriteLineInfo(FileName, Line - 1, FileType, "");
 StringRef LineInfoExtra;
-SourceLocation Loc = HashToken.getLocation();
 if (const Module *Mod = FindModuleAtLocation(Loc))
   WriteImplicitModuleImport(Mod);
-else if (const IncludedFile *Inc = FindIncludeAtLocation(Loc)) {
+else if (Inc) {
   const Module *Mod = FindEnteredModule(Loc);
   if (Mod)
 OS << "#pragma clang module begin "
@@ -420,6 +437,8 @@ void InclusionRewriter::Process(FileID FileId,
   if (Mod)
 OS << "#pragma clang module end /*"
<< Mod->getFullModuleName(true) << "*/\n";
+  OS << "#endif /* " << getIncludedFileName(Inc)

[clang] Make -frewrite-includes put an endif at the end of the included text (PR #67613)

2023-09-27 Thread Paul T Robinson via cfe-commits

https://github.com/pogo59 created 
https://github.com/llvm/llvm-project/pull/67613

Also add the filename to the comments it emits, to help identify where included 
text ends.

>From 0f63068d1085e5064d47916a86fac089c4417e57 Mon Sep 17 00:00:00 2001
From: Paul Robinson 
Date: Wed, 27 Sep 2023 14:54:13 -0700
Subject: [PATCH] Make -frewrite-includes put an endif at the end of the
 included text

Also add the filename to the comments it emits, to help identify
where included text ends.
---
 .../Frontend/Rewrite/InclusionRewriter.cpp|  33 -
 .../Frontend/rewrite-includes-cli-include.c   |   1 +
 .../test/Frontend/rewrite-includes-missing.c  |   4 +-
 clang/test/Frontend/rewrite-includes.c| 130 ++
 clang/test/Modules/preprocess-module.cpp  |   6 +-
 5 files changed, 106 insertions(+), 68 deletions(-)

diff --git a/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp 
b/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
index d3a3db0139c6d2f..6ab57adc41bfe8b 100644
--- a/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
+++ b/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
@@ -90,8 +90,10 @@ class InclusionRewriter : public PPCallbacks {
  bool EnsureNewline);
   void CommentOutDirective(Lexer , const Token ,
const MemoryBufferRef , StringRef EOL,
-   unsigned , int );
+   unsigned , int ,
+   const IncludedFile *Inc = nullptr);
   const IncludedFile *FindIncludeAtLocation(SourceLocation Loc) const;
+  StringRef getIncludedFileName(const IncludedFile *Inc) const;
   const Module *FindModuleAtLocation(SourceLocation Loc) const;
   const Module *FindEnteredModule(SourceLocation Loc) const;
   bool IsIfAtLocationTrue(SourceLocation Loc) const;
@@ -311,6 +313,17 @@ void InclusionRewriter::OutputContentUpTo(const 
MemoryBufferRef ,
   WriteFrom = WriteTo;
 }
 
+StringRef
+InclusionRewriter::getIncludedFileName(const IncludedFile *Inc) const {
+  if (Inc) {
+auto B = SM.getBufferOrNone(Inc->Id);
+assert(B && "Attempting to process invalid inclusion");
+if (B)
+  return llvm::sys::path::filename(B->getBufferIdentifier());
+  }
+  return StringRef();
+}
+
 /// Print characters from \p FromFile starting at \p NextToWrite up until the
 /// inclusion directive at \p StartToken, then print out the inclusion
 /// inclusion directive disabled by a #if directive, updating \p NextToWrite
@@ -320,7 +333,8 @@ void InclusionRewriter::CommentOutDirective(Lexer 
,
 const Token ,
 const MemoryBufferRef ,
 StringRef LocalEOL,
-unsigned , int ) {
+unsigned , int ,
+const IncludedFile *Inc) {
   OutputContentUpTo(FromFile, NextToWrite,
 SM.getFileOffset(StartToken.getLocation()), LocalEOL, Line,
 false);
@@ -332,12 +346,14 @@ void InclusionRewriter::CommentOutDirective(Lexer 
,
 // OutputContentUpTo() would not output anything anyway.
 return;
   }
-  OS << "#if 0 /* expanded by -frewrite-includes */" << MainEOL;
+  OS << "#if 0 /* " << getIncludedFileName(Inc)
+ << " expanded by -frewrite-includes */" << MainEOL;
   OutputContentUpTo(FromFile, NextToWrite,
 SM.getFileOffset(DirectiveToken.getLocation()) +
 DirectiveToken.getLength(),
 LocalEOL, Line, true);
-  OS << "#endif /* expanded by -frewrite-includes */" << MainEOL;
+  OS << (Inc ? "#else" : "#endif") << " /* " << getIncludedFileName(Inc)
+ << " expanded by -frewrite-includes */" << MainEOL;
 }
 
 /// Find the next identifier in the pragma directive specified by \p RawToken.
@@ -400,15 +416,16 @@ void InclusionRewriter::Process(FileID FileId,
   case tok::pp_include:
   case tok::pp_include_next:
   case tok::pp_import: {
+SourceLocation Loc = HashToken.getLocation();
+const IncludedFile *Inc = FindIncludeAtLocation(Loc);
 CommentOutDirective(RawLex, HashToken, FromFile, LocalEOL, 
NextToWrite,
-  Line);
+  Line, Inc);
 if (FileId != PP.getPredefinesFileID())
   WriteLineInfo(FileName, Line - 1, FileType, "");
 StringRef LineInfoExtra;
-SourceLocation Loc = HashToken.getLocation();
 if (const Module *Mod = FindModuleAtLocation(Loc))
   WriteImplicitModuleImport(Mod);
-else if (const IncludedFile *Inc = FindIncludeAtLocation(Loc)) {
+else if (Inc) {
   const Module *Mod = FindEnteredModule(Loc);
   if (Mod)
 OS << "#pragma clang module begin "
@@ -420,6 +437,8 @@ void InclusionRewriter::Process(FileID FileId,
   

[clang-tools-extra] [ORC] Unify symbol mapping logic to IRLayer (PR #67612)

2023-09-27 Thread Lucas Reis via cfe-commits

https://github.com/lucasreis1 created 
https://github.com/llvm/llvm-project/pull/67612

Remove the old `IRSymbolMapper` and unify symbol mapping logic to IRLayer. 
Allows clients to provide their own version of a `IRSymbolMapper` function for 
custom mappings.

This is my first contribution, so I'm sorry in advance for any problems that 
may arise.

>From ad663b28a4462ff8435ccb986b01f326ba7ed340 Mon Sep 17 00:00:00 2001
From: Lucas Reis 
Date: Wed, 27 Sep 2023 17:13:33 -0400
Subject: [PATCH] [ORC] Unify symbol mapping logic to IRLayer. Prepare for
 possible custom mapping logic for clients.

---
 .../llvm/ExecutionEngine/Orc/CompileUtils.h   |   6 +-
 .../llvm/ExecutionEngine/Orc/IRCompileLayer.h |  12 +-
 llvm/include/llvm/ExecutionEngine/Orc/Layer.h | 104 +++---
 .../llvm/ExecutionEngine/Orc/Mangling.h   |  23 +---
 .../Orc/CompileOnDemandLayer.cpp  |  94 
 llvm/lib/ExecutionEngine/Orc/CompileUtils.cpp |   5 +-
 llvm/lib/ExecutionEngine/Orc/Layer.cpp|  68 ++--
 llvm/lib/ExecutionEngine/Orc/Mangling.cpp |  53 -
 8 files changed, 210 insertions(+), 155 deletions(-)

diff --git a/llvm/include/llvm/ExecutionEngine/Orc/CompileUtils.h 
b/llvm/include/llvm/ExecutionEngine/Orc/CompileUtils.h
index a55aa3d71db2a14..843916f2f001f26 100644
--- a/llvm/include/llvm/ExecutionEngine/Orc/CompileUtils.h
+++ b/llvm/include/llvm/ExecutionEngine/Orc/CompileUtils.h
@@ -27,8 +27,7 @@ class TargetMachine;
 
 namespace orc {
 
-IRSymbolMapper::ManglingOptions
-irManglingOptionsFromTargetOptions(const TargetOptions );
+ManglingOptions irManglingOptionsFromTargetOptions(const TargetOptions );
 
 /// Simple compile functor: Takes a single IR module and returns an ObjectFile.
 /// This compiler supports a single compilation thread and LLVMContext only.
@@ -49,8 +48,7 @@ class SimpleCompiler : public IRCompileLayer::IRCompiler {
   Expected operator()(Module ) override;
 
 private:
-  IRSymbolMapper::ManglingOptions
-  manglingOptionsForTargetMachine(const TargetMachine );
+  ManglingOptions manglingOptionsForTargetMachine(const TargetMachine );
 
   CompileResult tryToLoadFromObjectCache(const Module );
   void notifyObjectCompiled(const Module , const MemoryBuffer );
diff --git a/llvm/include/llvm/ExecutionEngine/Orc/IRCompileLayer.h 
b/llvm/include/llvm/ExecutionEngine/Orc/IRCompileLayer.h
index f493d63a7c8a991..22f9c46e4ae3703 100644
--- a/llvm/include/llvm/ExecutionEngine/Orc/IRCompileLayer.h
+++ b/llvm/include/llvm/ExecutionEngine/Orc/IRCompileLayer.h
@@ -32,18 +32,16 @@ class IRCompileLayer : public IRLayer {
 public:
   class IRCompiler {
   public:
-IRCompiler(IRSymbolMapper::ManglingOptions MO) : MO(std::move(MO)) {}
+IRCompiler(ManglingOptions MO) : MO(std::move(MO)) {}
 virtual ~IRCompiler();
-const IRSymbolMapper::ManglingOptions () const {
-  return MO;
-}
+const ManglingOptions () const { return MO; }
 virtual Expected> operator()(Module ) = 0;
 
   protected:
-IRSymbolMapper::ManglingOptions () { return MO; }
+ManglingOptions () { return MO; }
 
   private:
-IRSymbolMapper::ManglingOptions MO;
+ManglingOptions MO;
   };
 
   using NotifyCompiledFunction = std::function Compile;
-  const IRSymbolMapper::ManglingOptions *ManglingOpts;
+  const ManglingOptions *ManglingOpts;
   NotifyCompiledFunction NotifyCompiled = NotifyCompiledFunction();
 };
 
diff --git a/llvm/include/llvm/ExecutionEngine/Orc/Layer.h 
b/llvm/include/llvm/ExecutionEngine/Orc/Layer.h
index cfeedc2a0bdaab7..2f0590fa2371abe 100644
--- a/llvm/include/llvm/ExecutionEngine/Orc/Layer.h
+++ b/llvm/include/llvm/ExecutionEngine/Orc/Layer.h
@@ -16,6 +16,7 @@
 #include "llvm/ExecutionEngine/Orc/Core.h"
 #include "llvm/ExecutionEngine/Orc/Mangling.h"
 #include "llvm/ExecutionEngine/Orc/ThreadSafeModule.h"
+#include "llvm/IR/Constants.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/ExtensibleRTTI.h"
@@ -34,8 +35,7 @@ class IRMaterializationUnit : public MaterializationUnit {
 
   /// Create an IRMaterializationLayer. Scans the module to build the
   /// SymbolFlags and SymbolToDefinition maps.
-  IRMaterializationUnit(ExecutionSession ,
-const IRSymbolMapper::ManglingOptions ,
+  IRMaterializationUnit(ExecutionSession , const ManglingOptions ,
 ThreadSafeModule TSM);
 
   /// Create an IRMaterializationLayer from a module, and pre-existing
@@ -52,6 +52,15 @@ class IRMaterializationUnit : public MaterializationUnit {
   /// Return a reference to the contained ThreadSafeModule.
   const ThreadSafeModule () const { return TSM; }
 
+  struct SymbolInfo {
+  public:
+SymbolInfo(MaterializationUnit::Interface I, SymbolNameToDefinitionMap 
SMap)
+: Interface(I), SymbolToDefinition(SMap) {}
+
+MaterializationUnit::Interface Interface;
+SymbolNameToDefinitionMap SymbolToDefinition;
+  };
+
 protected:
   ThreadSafeModule TSM;
   

[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread Fangrui Song via cfe-commits


@@ -401,6 +401,30 @@
 // CHECK338-NOT: "--end-group"
 // CHECK338: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/fini.o"
 
+// RUN: %clangxx -### -target hexagon-unknown-elf \
+// RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
+// RUN:   -mcpu=hexagonv60 \

MaskRay wrote:

These files wrap too quickly. Most tests pack more than one options on one line 
and don't start a new line just for `%s 2>&1`.

https://github.com/llvm/llvm-project/pull/67515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread Fangrui Song via cfe-commits


@@ -401,6 +401,30 @@
 // CHECK338-NOT: "--end-group"
 // CHECK338: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/fini.o"
 
+// RUN: %clangxx -### -target hexagon-unknown-elf \
+// RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
+// RUN:   -mcpu=hexagonv60 \
+// RUN:   -nolibc \
+// RUN:   %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-NOLIBC %s
+// CHECK-NOLIBC: "-cc1"
+// CHECK-NOLIBC: {{hexagon-link|ld}}
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0_standalone.o"
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0.o"
+// CHECK-NOLIBC: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/init.o"
+// CHECK-NOLIBC: 
"-L{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60"
+// CHECK-NOLIBC: "-L{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib"
+// CHECK-NOLIBC: "{{[^"]+}}.o"
+// CHECK-NOLIBC: "-lstdc++"
+// CHECK-NOLIBC: "-lm"

MaskRay wrote:

Use -SAME whether applicable.

I'll tidy this test a bit first...

https://github.com/llvm/llvm-project/pull/67515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][hexagon] Add support for -nolibc (PR #67515)

2023-09-27 Thread Fangrui Song via cfe-commits


@@ -401,6 +401,30 @@
 // CHECK338-NOT: "--end-group"
 // CHECK338: 
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/fini.o"
 
+// RUN: %clangxx -### -target hexagon-unknown-elf \

MaskRay wrote:

use `--target=` for new tests.
`-target ` has been deprecated since Clang 3.4

https://github.com/llvm/llvm-project/pull/67515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147844: [clang][Sema]Print diagnostic warning about precedence when integer expression is used without parentheses in an conditional operator expression

2023-09-27 Thread NagaChaitanya Vellanki via Phabricator via cfe-commits
chaitanyav updated this revision to Diff 557427.
chaitanyav added a comment.

Add parentheses to the conditional expression


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147844/new/

https://reviews.llvm.org/D147844

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Analysis/uninit-vals.c
  clang/test/Sema/integer-overflow.c
  clang/test/Sema/parentheses.c
  clang/test/Sema/parentheses.cpp
  clang/test/SemaCXX/array-bounds.cpp
  clang/test/SemaCXX/integer-overflow.cpp
  libcxx/include/__chrono/duration.h
  libcxx/include/strstream
  libcxx/test/libcxx/algorithms/nth_element_stability.pass.cpp
  libcxx/test/libcxx/algorithms/partial_sort_stability.pass.cpp
  libcxx/test/libcxx/algorithms/sort_stability.pass.cpp
  libcxx/test/std/containers/unord/unord.map/eq.different_hash.pass.cpp
  libcxx/test/std/containers/unord/unord.multimap/eq.different_hash.pass.cpp
  libcxx/test/std/containers/unord/unord.multiset/eq.different_hash.pass.cpp
  libcxx/test/std/containers/unord/unord.set/eq.different_hash.pass.cpp
  libcxxabi/src/cxa_personality.cpp

Index: libcxxabi/src/cxa_personality.cpp
===
--- libcxxabi/src/cxa_personality.cpp
+++ libcxxabi/src/cxa_personality.cpp
@@ -718,9 +718,7 @@
 if (actionEntry == 0)
 {
 // Found a cleanup
-results.reason = actions & _UA_SEARCH_PHASE
- ? _URC_CONTINUE_UNWIND
- : _URC_HANDLER_FOUND;
+results.reason = (actions & _UA_SEARCH_PHASE) ? _URC_CONTINUE_UNWIND : _URC_HANDLER_FOUND;
 return;
 }
 // Convert 1-based byte offset into
@@ -832,9 +830,8 @@
 // End of action list. If this is phase 2 and we have found
 // a cleanup (ttypeIndex=0), return _URC_HANDLER_FOUND;
 // otherwise return _URC_CONTINUE_UNWIND.
-results.reason = hasCleanup && actions & _UA_CLEANUP_PHASE
- ? _URC_HANDLER_FOUND
- : _URC_CONTINUE_UNWIND;
+results.reason =
+(hasCleanup && (actions & _UA_CLEANUP_PHASE)) ? _URC_HANDLER_FOUND : _URC_CONTINUE_UNWIND;
 return;
 }
 // Go to next action
@@ -1250,10 +1247,9 @@
 {
 const __shim_type_info* excpType =
 static_cast(new_exception_header->exceptionType);
-adjustedPtr =
-__getExceptionClass(_exception_header->unwindHeader) == kOurDependentExceptionClass ?
-((__cxa_dependent_exception*)new_exception_header)->primaryException :
-new_exception_header + 1;
+adjustedPtr = (__getExceptionClass(_exception_header->unwindHeader) == kOurDependentExceptionClass)
+  ? ((__cxa_dependent_exception*)new_exception_header)->primaryException
+  : new_exception_header + 1;
 if (!exception_spec_can_catch(ttypeIndex, classInfo, ttypeEncoding,
   excpType, adjustedPtr,
   unwind_exception, base))
Index: libcxx/test/std/containers/unord/unord.set/eq.different_hash.pass.cpp
===
--- libcxx/test/std/containers/unord/unord.set/eq.different_hash.pass.cpp
+++ libcxx/test/std/containers/unord/unord.set/eq.different_hash.pass.cpp
@@ -40,7 +40,7 @@
 }
 template 
 std::size_t hash_even(T val) {
-  return val & 1 ? 1 : 0;
+  return (val & 1) ? 1 : 0;
 }
 template 
 std::size_t hash_same(T /*val*/) {
@@ -61,7 +61,7 @@
 }
 template 
 size_t hash_even(T* val) {
-  return *val & 1 ? 1 : 0;
+  return (*val & 1) ? 1 : 0;
 }
 
 template 
Index: libcxx/test/std/containers/unord/unord.multiset/eq.different_hash.pass.cpp
===
--- libcxx/test/std/containers/unord/unord.multiset/eq.different_hash.pass.cpp
+++ libcxx/test/std/containers/unord/unord.multiset/eq.different_hash.pass.cpp
@@ -40,7 +40,7 @@
 }
 template 
 std::size_t hash_even(T val) {
-  return val & 1 ? 1 : 0;
+  return (val & 1) ? 1 : 0;
 }
 template 
 std::size_t hash_same(T /*val*/) {
@@ -61,7 +61,7 @@
 }
 template 
 std::size_t hash_even(T* val) {
-  return *val & 1 ? 1 : 0;
+  return (*val & 1) ? 1 : 0;
 }
 
 template 
Index: libcxx/test/std/containers/unord/unord.multimap/eq.different_hash.pass.cpp
===
--- libcxx/test/std/containers/unord/unord.multimap/eq.different_hash.pass.cpp
+++ libcxx/test/std/containers/unord/unord.multimap/eq.different_hash.pass.cpp
@@ -41,7 +41,7 @@
 }
 

[clang] [OpenMP] Introduce the initial support for OpenMP kernel language (PR #66844)

2023-09-27 Thread Shilei Tian via cfe-commits

shiltian wrote:

> Where is the code that prevents the init/deinit calls from being created?

It's in the early exit.

https://github.com/llvm/llvm-project/pull/66844
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenMP] Introduce the initial support for OpenMP kernel language (PR #66844)

2023-09-27 Thread Shilei Tian via cfe-commits


@@ -752,27 +751,41 @@ void CGOpenMPRuntimeGPU::emitNonSPMDKernel(const 
OMPExecutableDirective ,
   EntryFunctionState EST;
   WrapperFunctionsMap.clear();
 
+  bool IsBareKernel = D.getSingleClause();

shiltian wrote:

So `target teams` is generic mode. Since we don't emit the kernel init/deinit, 
the kernel env will not be emitted as well. At runtime we will default to SPMD 
mode.
As discussed offline, we will need an extra mode, if we want, but no kernel env 
should work perfectly fine.

https://github.com/llvm/llvm-project/pull/66844
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   3   4   5   6   >