[PATCH] D151547: [RISCV] Remove experimental for zihintntl.

2023-07-19 Thread Piyou Chen via Phabricator via cfe-commits
BeMg added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151547

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


[PATCH] D155145: [X86] Add AVX-VNNI-INT16 instructions.

2023-07-19 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei accepted this revision.
pengfei added a comment.
This revision is now accepted and ready to land.

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155145

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


[PATCH] D155148: [X86] Add SM4 instructions.

2023-07-19 Thread Freddy, Ye via 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 rG049d6a3f428e: [X86] Add SM4 instructions. (authored by 
FreddyYe).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155148

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/immintrin.h
  clang/lib/Headers/sm4intrin.h
  clang/test/CodeGen/X86/sm4-builtins.c
  clang/test/CodeGen/attr-target-x86.c
  clang/test/Driver/x86-target-features.c
  clang/test/Preprocessor/x86_target_features.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/include/llvm/TargetParser/X86TargetParser.def
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/lib/TargetParser/Host.cpp
  llvm/lib/TargetParser/X86TargetParser.cpp
  llvm/test/CodeGen/X86/sm4-intrinsics.ll
  llvm/test/MC/Disassembler/X86/sm4-32.txt
  llvm/test/MC/Disassembler/X86/sm4-64.txt
  llvm/test/MC/X86/sm4-32-att.s
  llvm/test/MC/X86/sm4-32-intel.s
  llvm/test/MC/X86/sm4-64-att.s
  llvm/test/MC/X86/sm4-64-intel.s
  llvm/test/TableGen/x86-fold-tables.inc

Index: llvm/test/TableGen/x86-fold-tables.inc
===
--- llvm/test/TableGen/x86-fold-tables.inc
+++ llvm/test/TableGen/x86-fold-tables.inc
@@ -3169,6 +3169,10 @@
   {X86::VSHUFPSZ256rri, X86::VSHUFPSZ256rmi, 0},
   {X86::VSHUFPSZrri, X86::VSHUFPSZrmi, 0},
   {X86::VSHUFPSrri, X86::VSHUFPSrmi, 0},
+  {X86::VSM4KEY4Yrr, X86::VSM4KEY4Yrm, 0},
+  {X86::VSM4KEY4rr, X86::VSM4KEY4rm, 0},
+  {X86::VSM4RNDS4Yrr, X86::VSM4RNDS4Yrm, 0},
+  {X86::VSM4RNDS4rr, X86::VSM4RNDS4rm, 0},
   {X86::VSQRTPDZ128rkz, X86::VSQRTPDZ128mkz, 0},
   {X86::VSQRTPDZ256rkz, X86::VSQRTPDZ256mkz, 0},
   {X86::VSQRTPDZrkz, X86::VSQRTPDZmkz, 0},
Index: llvm/test/MC/X86/sm4-64-intel.s
===
--- /dev/null
+++ llvm/test/MC/X86/sm4-64-intel.s
@@ -0,0 +1,114 @@
+// RUN: llvm-mc -triple x86_64 -x86-asm-syntax=intel -output-asm-variant=1 --show-encoding %s | FileCheck %s
+
+// CHECK: vsm4key4 ymm12, ymm13, ymm4
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0xe4]
+  vsm4key4 ymm12, ymm13, ymm4
+
+// CHECK: vsm4key4 xmm12, xmm13, xmm4
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0xe4]
+  vsm4key4 xmm12, xmm13, xmm4
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [rbp + 8*r14 + 268435456]
+// CHECK: encoding: [0xc4,0x22,0x16,0xda,0xa4,0xf5,0x00,0x00,0x00,0x10]
+  vsm4key4 ymm12, ymm13, ymmword ptr [rbp + 8*r14 + 268435456]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [r8 + 4*rax + 291]
+// CHECK: encoding: [0xc4,0x42,0x16,0xda,0xa4,0x80,0x23,0x01,0x00,0x00]
+  vsm4key4 ymm12, ymm13, ymmword ptr [r8 + 4*rax + 291]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [rip]
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0x25,0x00,0x00,0x00,0x00]
+  vsm4key4 ymm12, ymm13, ymmword ptr [rip]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [2*rbp - 1024]
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0x24,0x6d,0x00,0xfc,0xff,0xff]
+  vsm4key4 ymm12, ymm13, ymmword ptr [2*rbp - 1024]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [rcx + 4064]
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0xa1,0xe0,0x0f,0x00,0x00]
+  vsm4key4 ymm12, ymm13, ymmword ptr [rcx + 4064]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [rdx - 4096]
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0xa2,0x00,0xf0,0xff,0xff]
+  vsm4key4 ymm12, ymm13, ymmword ptr [rdx - 4096]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+// CHECK: encoding: [0xc4,0x22,0x12,0xda,0xa4,0xf5,0x00,0x00,0x00,0x10]
+  vsm4key4 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+// CHECK: encoding: [0xc4,0x42,0x12,0xda,0xa4,0x80,0x23,0x01,0x00,0x00]
+  vsm4key4 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [rip]
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0x25,0x00,0x00,0x00,0x00]
+  vsm4key4 xmm12, xmm13, xmmword ptr [rip]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0x24,0x6d,0x00,0xfe,0xff,0xff]
+  vsm4key4 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [rcx + 2032]
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0xa1,0xf0,0x07,0x00,0x00]
+  vsm4key4 xmm12, xmm13, xmmword ptr [rcx + 2032]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [rdx - 2048]
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0xa2,0x00,0xf8,0xff,0xff]
+  vsm4key4 xmm12, xmm13, xmmword ptr [rdx - 2048]
+
+// CHECK: 

[clang] 049d6a3 - [X86] Add SM4 instructions.

2023-07-19 Thread Freddy Ye via cfe-commits

Author: Freddy Ye
Date: 2023-07-20T13:35:15+08:00
New Revision: 049d6a3f428efeb1a22f62e55b808f60b0bf27cc

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

LOG: [X86] Add SM4 instructions.

For more details about these instructions, please refer to the latest ISE 
document: 
https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: pengfei, skan

Differential Revision: https://reviews.llvm.org/D155148

Added: 
clang/lib/Headers/sm4intrin.h
clang/test/CodeGen/X86/sm4-builtins.c
llvm/test/CodeGen/X86/sm4-intrinsics.ll
llvm/test/MC/Disassembler/X86/sm4-32.txt
llvm/test/MC/Disassembler/X86/sm4-64.txt
llvm/test/MC/X86/sm4-32-att.s
llvm/test/MC/X86/sm4-32-intel.s
llvm/test/MC/X86/sm4-64-att.s
llvm/test/MC/X86/sm4-64-intel.s

Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/BuiltinsX86.def
clang/include/clang/Driver/Options.td
clang/lib/Basic/Targets/X86.cpp
clang/lib/Basic/Targets/X86.h
clang/lib/Headers/CMakeLists.txt
clang/lib/Headers/immintrin.h
clang/test/CodeGen/attr-target-x86.c
clang/test/Driver/x86-target-features.c
clang/test/Preprocessor/x86_target_features.c
llvm/docs/ReleaseNotes.rst
llvm/include/llvm/IR/IntrinsicsX86.td
llvm/include/llvm/TargetParser/X86TargetParser.def
llvm/lib/Target/X86/X86.td
llvm/lib/Target/X86/X86InstrInfo.td
llvm/lib/Target/X86/X86InstrSSE.td
llvm/lib/TargetParser/Host.cpp
llvm/lib/TargetParser/X86TargetParser.cpp
llvm/test/TableGen/x86-fold-tables.inc

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f87507530ff9f1..2982810b67fa0c 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -821,6 +821,9 @@ X86 Support
   * Support intrinsic of ``_mm_sm3msg1_epi32``.
   * Support intrinsic of ``_mm_sm3msg2_epi32``.
   * Support intrinsic of ``_mm_sm3rnds2_epi32``.
+- Support ISA of ``SM4``.
+  * Support intrinsic of ``_mm(256)_sm4key4_epi32``.
+  * Support intrinsic of ``_mm(256)_sm4rnds4_epi32``.
 
 Arm and AArch64 Support
 ^^^

diff  --git a/clang/include/clang/Basic/BuiltinsX86.def 
b/clang/include/clang/Basic/BuiltinsX86.def
index 7fe19d86a256bd..48dd9cbb1ab7a4 100644
--- a/clang/include/clang/Basic/BuiltinsX86.def
+++ b/clang/include/clang/Basic/BuiltinsX86.def
@@ -2151,6 +2151,12 @@ TARGET_BUILTIN(__builtin_ia32_vsm3msg1, 
"V4UiV4UiV4UiV4Ui", "nV:128:", "sm3")
 TARGET_BUILTIN(__builtin_ia32_vsm3msg2, "V4UiV4UiV4UiV4Ui", "nV:128:", "sm3")
 TARGET_BUILTIN(__builtin_ia32_vsm3rnds2, "V4UiV4UiV4UiV4UiIUi", "nV:128:", 
"sm3")
 
+// SM4
+TARGET_BUILTIN(__builtin_ia32_vsm4key4128, "V4UiV4UiV4Ui", "nV:128:", "sm4")
+TARGET_BUILTIN(__builtin_ia32_vsm4key4256, "V8UiV8UiV8Ui", "nV:256:", "sm4")
+TARGET_BUILTIN(__builtin_ia32_vsm4rnds4128, "V4UiV4UiV4Ui", "nV:128:", "sm4")
+TARGET_BUILTIN(__builtin_ia32_vsm4rnds4256, "V8UiV8UiV8Ui", "nV:256:", "sm4")
+
 #undef BUILTIN
 #undef TARGET_BUILTIN
 #undef TARGET_HEADER_BUILTIN

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 0aede381ec6dc8..0578bc0cba1214 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5060,6 +5060,8 @@ def msha512 : Flag<["-"], "msha512">, 
Group;
 def mno_sha512 : Flag<["-"], "mno-sha512">, Group;
 def msm3 : Flag<["-"], "msm3">, Group;
 def mno_sm3 : Flag<["-"], "mno-sm3">, Group;
+def msm4 : Flag<["-"], "msm4">, Group;
+def mno_sm4 : Flag<["-"], "mno-sm4">, Group;
 def mtbm : Flag<["-"], "mtbm">, Group;
 def mno_tbm : Flag<["-"], "mno-tbm">, Group;
 def mtsxldtrk : Flag<["-"], "mtsxldtrk">, Group;

diff  --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index dc56b89c6b6078..c89e1df4e52d2b 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -267,6 +267,8 @@ bool 
X86TargetInfo::handleTargetFeatures(std::vector ,
   HasSHSTK = true;
 } else if (Feature == "+sm3") {
   HasSM3 = true;
+} else if (Feature == "+sm4") {
+  HasSM4 = true;
 } else if (Feature == "+movbe") {
   HasMOVBE = true;
 } else if (Feature == "+sgx") {
@@ -780,6 +782,8 @@ void X86TargetInfo::getTargetDefines(const LangOptions 
,
 Builder.defineMacro("__SGX__");
   if (HasSM3)
 Builder.defineMacro("__SM3__");
+  if (HasSM4)
+Builder.defineMacro("__SM4__");
   if (HasPREFETCHI)
 Builder.defineMacro("__PREFETCHI__");
   if (HasPREFETCHWT1)
@@ -1010,6 +1014,7 @@ bool X86TargetInfo::isValidFeatureName(StringRef Name) 
const {
   .Case("sha512", true)
   .Case("shstk", true)
   .Case("sm3", true)
+  .Case("sm4", true)
   

[PATCH] D155148: [X86] Add SM4 instructions.

2023-07-19 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe updated this revision to Diff 542305.
FreddyYe added a comment.

rebase and fix lit fail


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155148

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/immintrin.h
  clang/lib/Headers/sm4intrin.h
  clang/test/CodeGen/X86/sm4-builtins.c
  clang/test/CodeGen/attr-target-x86.c
  clang/test/Driver/x86-target-features.c
  clang/test/Preprocessor/x86_target_features.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/include/llvm/TargetParser/X86TargetParser.def
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/lib/TargetParser/Host.cpp
  llvm/lib/TargetParser/X86TargetParser.cpp
  llvm/test/CodeGen/X86/sm4-intrinsics.ll
  llvm/test/MC/Disassembler/X86/sm4-32.txt
  llvm/test/MC/Disassembler/X86/sm4-64.txt
  llvm/test/MC/X86/sm4-32-att.s
  llvm/test/MC/X86/sm4-32-intel.s
  llvm/test/MC/X86/sm4-64-att.s
  llvm/test/MC/X86/sm4-64-intel.s
  llvm/test/TableGen/x86-fold-tables.inc

Index: llvm/test/TableGen/x86-fold-tables.inc
===
--- llvm/test/TableGen/x86-fold-tables.inc
+++ llvm/test/TableGen/x86-fold-tables.inc
@@ -3169,6 +3169,10 @@
   {X86::VSHUFPSZ256rri, X86::VSHUFPSZ256rmi, 0},
   {X86::VSHUFPSZrri, X86::VSHUFPSZrmi, 0},
   {X86::VSHUFPSrri, X86::VSHUFPSrmi, 0},
+  {X86::VSM4KEY4Yrr, X86::VSM4KEY4Yrm, 0},
+  {X86::VSM4KEY4rr, X86::VSM4KEY4rm, 0},
+  {X86::VSM4RNDS4Yrr, X86::VSM4RNDS4Yrm, 0},
+  {X86::VSM4RNDS4rr, X86::VSM4RNDS4rm, 0},
   {X86::VSQRTPDZ128rkz, X86::VSQRTPDZ128mkz, 0},
   {X86::VSQRTPDZ256rkz, X86::VSQRTPDZ256mkz, 0},
   {X86::VSQRTPDZrkz, X86::VSQRTPDZmkz, 0},
Index: llvm/test/MC/X86/sm4-64-intel.s
===
--- /dev/null
+++ llvm/test/MC/X86/sm4-64-intel.s
@@ -0,0 +1,114 @@
+// RUN: llvm-mc -triple x86_64 -x86-asm-syntax=intel -output-asm-variant=1 --show-encoding %s | FileCheck %s
+
+// CHECK: vsm4key4 ymm12, ymm13, ymm4
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0xe4]
+  vsm4key4 ymm12, ymm13, ymm4
+
+// CHECK: vsm4key4 xmm12, xmm13, xmm4
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0xe4]
+  vsm4key4 xmm12, xmm13, xmm4
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [rbp + 8*r14 + 268435456]
+// CHECK: encoding: [0xc4,0x22,0x16,0xda,0xa4,0xf5,0x00,0x00,0x00,0x10]
+  vsm4key4 ymm12, ymm13, ymmword ptr [rbp + 8*r14 + 268435456]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [r8 + 4*rax + 291]
+// CHECK: encoding: [0xc4,0x42,0x16,0xda,0xa4,0x80,0x23,0x01,0x00,0x00]
+  vsm4key4 ymm12, ymm13, ymmword ptr [r8 + 4*rax + 291]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [rip]
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0x25,0x00,0x00,0x00,0x00]
+  vsm4key4 ymm12, ymm13, ymmword ptr [rip]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [2*rbp - 1024]
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0x24,0x6d,0x00,0xfc,0xff,0xff]
+  vsm4key4 ymm12, ymm13, ymmword ptr [2*rbp - 1024]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [rcx + 4064]
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0xa1,0xe0,0x0f,0x00,0x00]
+  vsm4key4 ymm12, ymm13, ymmword ptr [rcx + 4064]
+
+// CHECK: vsm4key4 ymm12, ymm13, ymmword ptr [rdx - 4096]
+// CHECK: encoding: [0xc4,0x62,0x16,0xda,0xa2,0x00,0xf0,0xff,0xff]
+  vsm4key4 ymm12, ymm13, ymmword ptr [rdx - 4096]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+// CHECK: encoding: [0xc4,0x22,0x12,0xda,0xa4,0xf5,0x00,0x00,0x00,0x10]
+  vsm4key4 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+// CHECK: encoding: [0xc4,0x42,0x12,0xda,0xa4,0x80,0x23,0x01,0x00,0x00]
+  vsm4key4 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [rip]
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0x25,0x00,0x00,0x00,0x00]
+  vsm4key4 xmm12, xmm13, xmmword ptr [rip]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0x24,0x6d,0x00,0xfe,0xff,0xff]
+  vsm4key4 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [rcx + 2032]
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0xa1,0xf0,0x07,0x00,0x00]
+  vsm4key4 xmm12, xmm13, xmmword ptr [rcx + 2032]
+
+// CHECK: vsm4key4 xmm12, xmm13, xmmword ptr [rdx - 2048]
+// CHECK: encoding: [0xc4,0x62,0x12,0xda,0xa2,0x00,0xf8,0xff,0xff]
+  vsm4key4 xmm12, xmm13, xmmword ptr [rdx - 2048]
+
+// CHECK: vsm4rnds4 ymm12, ymm13, ymm4
+// CHECK: encoding: [0xc4,0x62,0x17,0xda,0xe4]
+  vsm4rnds4 ymm12, ymm13, ymm4
+
+// 

[PATCH] D155145: [X86] Add AVX-VNNI-INT16 instructions.

2023-07-19 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe added a comment.

ping... Anyone help accept?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155145

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


[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

2023-07-19 Thread John McIver via Phabricator via cfe-commits
jmciver created this revision.
jmciver added reviewers: nikic, efriedma, fhahn.
Herald added subscribers: kmitropoulou, ormris, ChuanqiXu, StephenFan, wenlei, 
steven_wu, hiraditya.
Herald added a project: All.
jmciver published this revision for review.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This commit is in support of future uninitialized memory handling and adds
alloca instruction support to getInitialValueOfAllocation. This unifies initial
memory state querying (both stack and heap) to a single utility function.

Several optimizations are refactored to take advantage of alloca support in
getInitialValueOfAllocation, see below list. A majority of the optimizations are
effected by the migration of PromoteMemToReg to use getInitialValueOfAllocation,
which requires TLI for allocation function data, but is not used in support of
alloca instructions.

- PromoteMemToReg
- Mem2Reg
- IPO
- CoroSplit
- Coroutines (clang)
- GVN
- NewGVN
- Statepoint

Coroutines have a clang based optimization call to PromoteMemToReg from
FinishFunction, which requires a TLI object outside of the optimization pass
framework. Generation of the TLI is added at the module level to prevent
generation of multiple TLI objects for each coroutine function contained
within. Furthermore generation of the TLI object is lazy.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155773

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  llvm/include/llvm/Analysis/MemoryBuiltins.h
  llvm/include/llvm/Transforms/Scalar/SROA.h
  llvm/include/llvm/Transforms/Utils/PromoteMemToReg.h
  llvm/lib/Analysis/MemoryBuiltins.cpp
  llvm/lib/Transforms/Coroutines/CoroFrame.cpp
  llvm/lib/Transforms/Coroutines/CoroInternal.h
  llvm/lib/Transforms/Coroutines/CoroSplit.cpp
  llvm/lib/Transforms/IPO/ArgumentPromotion.cpp
  llvm/lib/Transforms/Scalar/GVN.cpp
  llvm/lib/Transforms/Scalar/NewGVN.cpp
  llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
  llvm/lib/Transforms/Scalar/SROA.cpp
  llvm/lib/Transforms/Utils/Mem2Reg.cpp
  llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll

Index: llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
@@ -39,8 +39,8 @@
 ; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
 ; CHECK-O-NEXT: Running pass: SROAPass
 ; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
-; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
+; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O3-NEXT: Running pass: CallSiteSplittingPass
 ; CHECK-O-NEXT: Running pass: SampleProfileLoaderPass
 ; CHECK-O-NEXT: Running analysis: ProfileSummaryAnalysis
Index: llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
@@ -40,8 +40,8 @@
 ; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
 ; CHECK-O-NEXT: Running pass: SROAPass
 ; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
-; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
+; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O3-NEXT: Running pass: CallSiteSplittingPass
 ; CHECK-O-NEXT: Running pass: OpenMPOptPass
 ; CHECK-O-NEXT: Running pass: IPSCCPPass
Index: llvm/test/Other/new-pm-thinlto-prelink-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-defaults.ll
@@ -52,8 +52,8 @@
 ; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
 ; CHECK-O-NEXT: Running pass: SROAPass
 ; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
-; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
+; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O3-NEXT: Running pass: CallSiteSplittingPass
 ; CHECK-O-NEXT: Running pass: OpenMPOptPass
 ; CHECK-O-NEXT: Running pass: IPSCCPPass
Index: llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
@@ -38,8 +38,8 @@
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: 

[PATCH] D153906: [clang] Allow disassembly of multi-module bitcode files

2023-07-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

Is a simpler change like D154923  sufficient? 
It also handles the case when we don't emit `.ll`, but `.o` or `.s`.


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

https://reviews.llvm.org/D153906

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


[PATCH] D155539: [CUDA][HIP] Use the same default language std as C++

2023-07-19 Thread Yaxun Liu via 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 rG2d1d07152bd2: [CUDA][HIP] Use the same default language std 
as C++ (authored by yaxunl).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D155539?vs=541836=542293#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155539

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangStandards.def
  clang/lib/Basic/LangStandards.cpp
  clang/test/CodeGenCUDA/long-double.cu
  clang/test/Driver/unknown-std.cpp
  clang/test/Preprocessor/lang-std.cpp

Index: clang/test/Preprocessor/lang-std.cpp
===
--- clang/test/Preprocessor/lang-std.cpp
+++ clang/test/Preprocessor/lang-std.cpp
@@ -1,12 +1,14 @@
-// UNSUPPORTED: target={{.*-(ps4|ps5)}}
 /// Test default standards.
-/// PS4/PS5 default to gnu++14.
+/// CUDA/HIP uses the same default standards as C++.
 
-// RUN: %clang_cc1 -dM -E %s | FileCheck --check-prefix=CXX17 %s
-// RUN: %clang_cc1 -dM -E -x cuda %s | FileCheck --check-prefix=CXX14 %s
-// RUN: %clang_cc1 -dM -E -x hip %s | FileCheck --check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E %s | grep __cplusplus >%T-cpp-std.txt
+// RUN: %clang_cc1 -dM -E -x cuda %s | grep __cplusplus >%T-cuda-cuda.txt
+// RUN: %clang_cc1 -dM -E -x hip %s | grep __cplusplus >%T-hip-std.txt
+// RUN: diff %T-cpp-std.txt %T-cuda-cuda.txt
+// RUN: diff %T-cpp-std.txt %T-hip-std.txt
 
 // RUN: %clang_cc1 -dM -E -x cuda -std=c++14 %s | FileCheck --check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E -x cuda -std=c++17 %s | FileCheck --check-prefix=CXX17 %s
 // RUN: %clang_cc1 -dM -E -x hip -std=c++98 %s | FileCheck --check-prefix=CXX98 %s
 
 // CXX98: #define __cplusplus 199711L
Index: clang/test/Driver/unknown-std.cpp
===
--- clang/test/Driver/unknown-std.cpp
+++ clang/test/Driver/unknown-std.cpp
@@ -4,7 +4,10 @@
 
 // RUN: not %clang %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
 // RUN: not %clang -x objective-c++ %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
-// RUN: not %clang -x cuda -nocudainc -nocudalib --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s -std=foobar -c 2>&1 | FileCheck --match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
+// RUN: not %clang -x cuda -nocudainc -nocudalib --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN:   %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
+// RUN: not %clang -x hip -nocudainc -nocudalib %s -std=foobar -c 2>&1 \
+// RUN:   | FileCheck --match-full-lines %s
 
 // CHECK: error: invalid value 'foobar' in '-std=foobar'
 // CHECK-NEXT: note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard
@@ -21,7 +24,6 @@
 // CHECK-NEXT: note: use 'gnu++23' for 'ISO C++ 2023 DIS with GNU extensions' standard
 // CHECK-NEXT: note: use 'c++2c' or 'c++26' for 'Working draft for C++2c' standard
 // CHECK-NEXT: note: use 'gnu++2c' or 'gnu++26' for 'Working draft for C++2c with GNU extensions' standard
-// CUDA-NEXT: note: use 'cuda' for 'NVIDIA CUDA(tm)' standard
 
 // Make sure that no other output is present.
 // CHECK-NOT: {{^.+$}}
Index: clang/test/CodeGenCUDA/long-double.cu
===
--- clang/test/CodeGenCUDA/long-double.cu
+++ clang/test/CodeGenCUDA/long-double.cu
@@ -6,7 +6,7 @@
 // RUN:   -aux-triple x86_64-unknown-gnu-linux -fcuda-is-device \
 // RUN:   -emit-llvm -o - %s 2>&1 | FileCheck %s
 
-// CHECK: @_ZN15infinity_helperIeE5valueE = {{.*}} double 0x47EFD586B834, align 8
+// CHECK: @_ZN15infinity_helperIeE5valueE = {{.*}} double 0x47EFD586B834,{{.*}} align 8
 // CHECK: @size = {{.*}} i32 8
 
 #include "Inputs/cuda.h"
Index: clang/lib/Basic/LangStandards.cpp
===
--- clang/lib/Basic/LangStandards.cpp
+++ clang/lib/Basic/LangStandards.cpp
@@ -54,8 +54,6 @@
 return LangStandard::lang_opencl12;
   case Language::OpenCLCXX:
 return LangStandard::lang_openclcpp10;
-  case Language::CUDA:
-return LangStandard::lang_cuda;
   case Language::Asm:
   case Language::C:
 // The PS4 uses C99 as the default C standard.
@@ -66,13 +64,13 @@
 return LangStandard::lang_gnu11;
   case Language::CXX:
   case Language::ObjCXX:
+  case Language::CUDA:
+  case Language::HIP:
 if (T.isPS())
   return LangStandard::lang_gnucxx14;
 return LangStandard::lang_gnucxx17;
   case Language::RenderScript:
 return LangStandard::lang_c99;
-  case Language::HIP:
-return LangStandard::lang_hip;
   case Language::HLSL:
 return LangStandard::lang_hlsl2021;
   }
Index: clang/include/clang/Basic/LangStandards.def
===
--- 

[clang] 2d1d071 - [CUDA][HIP] Use the same default language std as C++

2023-07-19 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2023-07-19T23:54:58-04:00
New Revision: 2d1d07152bd26b001dedec3400b4b01d3bb11622

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

LOG: [CUDA][HIP] Use the same default language std as C++

Currently CUDA/HIP defines their own language standards in
LanguageStandards.def but they are redundant. They are the same as stdc++14.
The fact that CUDA/HIP uses c++* in option -std= indicates that they have the
same language standards as C++. The CUDA/HIP specific language features are
conveyed through language options, not language standards features. It makes
sense to let CUDA/HIP uses the same default language standard as C++.

Reviewed by: Siu Chi Chan, Artem Belevich

Differential Revision: https://reviews.llvm.org/D155539

Fixes: SWDEV-407685

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/LangStandards.def
clang/lib/Basic/LangStandards.cpp
clang/test/CodeGenCUDA/long-double.cu
clang/test/Driver/unknown-std.cpp
clang/test/Preprocessor/lang-std.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bce9e2ab3eba82..f87507530ff9f1 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -878,6 +878,9 @@ RISC-V Support
 
 CUDA/HIP Language Changes
 ^
+- Clang has been updated to align its default language standard for CUDA/HIP 
with
+  that of C++. The standard has now been enhanced to gnu++17, supplanting the
+  previously used c++14.
 
 CUDA Support
 

diff  --git a/clang/include/clang/Basic/LangStandards.def 
b/clang/include/clang/Basic/LangStandards.def
index 911b626e4c9661..5c28bdd28ef257 100644
--- a/clang/include/clang/Basic/LangStandards.def
+++ b/clang/include/clang/Basic/LangStandards.def
@@ -214,14 +214,6 @@ LANGSTANDARD_ALIAS_DEPR(openclcpp10, "CLC++")
 LANGSTANDARD_ALIAS_DEPR(openclcpp10, "CLC++1.0")
 LANGSTANDARD_ALIAS_DEPR(openclcpp2021, "CLC++2021")
 
-// CUDA
-LANGSTANDARD(cuda, "cuda", CUDA, "NVIDIA CUDA(tm)",
- LineComment | CPlusPlus | CPlusPlus11 | CPlusPlus14 | Digraphs)
-
-// HIP
-LANGSTANDARD(hip, "hip", HIP, "HIP",
- LineComment | CPlusPlus | CPlusPlus11 | CPlusPlus14 | Digraphs)
-
 // HLSL
 LANGSTANDARD(hlsl, "hlsl",
  HLSL, "High Level Shader Language",

diff  --git a/clang/lib/Basic/LangStandards.cpp 
b/clang/lib/Basic/LangStandards.cpp
index c6a1a0acc2cb7e..033c0efe8d4f5d 100644
--- a/clang/lib/Basic/LangStandards.cpp
+++ b/clang/lib/Basic/LangStandards.cpp
@@ -54,8 +54,6 @@ LangStandard::Kind 
clang::getDefaultLanguageStandard(clang::Language Lang,
 return LangStandard::lang_opencl12;
   case Language::OpenCLCXX:
 return LangStandard::lang_openclcpp10;
-  case Language::CUDA:
-return LangStandard::lang_cuda;
   case Language::Asm:
   case Language::C:
 // The PS4 uses C99 as the default C standard.
@@ -66,13 +64,13 @@ LangStandard::Kind 
clang::getDefaultLanguageStandard(clang::Language Lang,
 return LangStandard::lang_gnu11;
   case Language::CXX:
   case Language::ObjCXX:
+  case Language::CUDA:
+  case Language::HIP:
 if (T.isPS())
   return LangStandard::lang_gnucxx14;
 return LangStandard::lang_gnucxx17;
   case Language::RenderScript:
 return LangStandard::lang_c99;
-  case Language::HIP:
-return LangStandard::lang_hip;
   case Language::HLSL:
 return LangStandard::lang_hlsl2021;
   }

diff  --git a/clang/test/CodeGenCUDA/long-double.cu 
b/clang/test/CodeGenCUDA/long-double.cu
index 454a93ce5f6b6a..d52de972ea3da4 100644
--- a/clang/test/CodeGenCUDA/long-double.cu
+++ b/clang/test/CodeGenCUDA/long-double.cu
@@ -6,7 +6,7 @@
 // RUN:   -aux-triple x86_64-unknown-gnu-linux -fcuda-is-device \
 // RUN:   -emit-llvm -o - %s 2>&1 | FileCheck %s
 
-// CHECK: @_ZN15infinity_helperIeE5valueE = {{.*}} double 0x47EFD586B834, 
align 8
+// CHECK: @_ZN15infinity_helperIeE5valueE = {{.*}} double 
0x47EFD586B834,{{.*}} align 8
 // CHECK: @size = {{.*}} i32 8
 
 #include "Inputs/cuda.h"

diff  --git a/clang/test/Driver/unknown-std.cpp 
b/clang/test/Driver/unknown-std.cpp
index e918c087095ef0..5c58042a0a2c71 100644
--- a/clang/test/Driver/unknown-std.cpp
+++ b/clang/test/Driver/unknown-std.cpp
@@ -4,7 +4,10 @@
 
 // RUN: not %clang %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
 // RUN: not %clang -x objective-c++ %s -std=foobar -c 2>&1 | FileCheck 
--match-full-lines %s
-// RUN: not %clang -x cuda -nocudainc -nocudalib 
--cuda-path=%S/Inputs/CUDA/usr/local/cuda %s -std=foobar -c 2>&1 | FileCheck 
--match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
+// RUN: not %clang -x cuda -nocudainc -nocudalib 
--cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN:   %s -std=foobar -c 2>&1 | FileCheck 

[PATCH] D151547: [RISCV] Remove experimental for zihintntl.

2023-07-19 Thread Jianjian Guan via Phabricator via cfe-commits
jacquesguan added a comment.

In D151547#4514424 , @asb wrote:

> I remain concerned about exposing the intrinsics if they're not yet agreed as 
> finalised. I see there is now a PR to add them to riscv-c-api doc 
> https://github.com/riscv-non-isa/riscv-c-api-doc/pull/47
>
> I'd be OK with merging this now if the intrinsics were temporarily removed, 
> or logic were added to gate them in some way (though we don't have precedent 
> on the best way to do this I don't think). Otherwise, I'd rather wait until 
> the intrinsics are agreed.

I saw that https://github.com/riscv-non-isa/riscv-c-api-doc/pull/47 is 
basically agreed and close to merge, I think we could wait it to avoid repeat 
patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151547

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


[PATCH] D151547: [RISCV] Remove experimental for zihintntl.

2023-07-19 Thread Jianjian Guan via Phabricator via cfe-commits
jacquesguan updated this revision to Diff 542290.
jacquesguan marked 2 inline comments as done.
jacquesguan added a comment.

rebase main and address comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151547

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/test/CodeGen/RISCV/ntlh-intrinsics/riscv32-zihintntl.c
  clang/test/Preprocessor/riscv-target-features.c
  llvm/docs/RISCVUsage.rst
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/RISCVFeatures.td
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/CodeGen/RISCV/nontemporal-scalable.ll
  llvm/test/CodeGen/RISCV/nontemporal.ll
  llvm/test/CodeGen/RISCV/prefetch.ll
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/rv32zihintntl-invalid.s
  llvm/test/MC/RISCV/rv32zihintntl-valid.s
  llvm/test/MC/RISCV/rv32zihintntlc-invalid.s
  llvm/test/MC/RISCV/rv32zihintntlc-valid.s

Index: llvm/test/MC/RISCV/rv32zihintntlc-valid.s
===
--- llvm/test/MC/RISCV/rv32zihintntlc-valid.s
+++ llvm/test/MC/RISCV/rv32zihintntlc-valid.s
@@ -1,15 +1,15 @@
-# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zihintntl,+c -show-encoding \
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+zihintntl,+c -show-encoding \
 # RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zihintntl,+c -show-encoding \
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+zihintntl,+c -show-encoding \
 # RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+experimental-zihintntl,+c < %s \
-# RUN: | llvm-objdump --mattr=+experimental-zihintntl,+c -d -r - \
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+zihintntl,+c < %s \
+# RUN: | llvm-objdump --mattr=+zihintntl,+c -d -r - \
 # RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+experimental-zihintntl,+c < %s \
-# RUN: | llvm-objdump --mattr=+experimental-zihintntl,+c -d -r - \
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+zihintntl,+c < %s \
+# RUN: | llvm-objdump --mattr=+zihintntl,+c -d -r - \
 # RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-# RUN: not llvm-mc %s -triple=riscv32 -mattr=+experimental-zihintntl 2>&1 | FileCheck -check-prefix=CHECK-NO-C %s
-# RUN: not llvm-mc %s -triple=riscv64 -mattr=+experimental-zihintntl 2>&1 | FileCheck -check-prefix=CHECK-NO-C %s
+# RUN: not llvm-mc %s -triple=riscv32 -mattr=+zihintntl 2>&1 | FileCheck -check-prefix=CHECK-NO-C %s
+# RUN: not llvm-mc %s -triple=riscv64 -mattr=+zihintntl 2>&1 | FileCheck -check-prefix=CHECK-NO-C %s
 
 # CHECK-ASM-AND-OBJ: ntl.p1
 # CHECK-ASM: encoding: [0x33,0x00,0x20,0x00]
Index: llvm/test/MC/RISCV/rv32zihintntlc-invalid.s
===
--- llvm/test/MC/RISCV/rv32zihintntlc-invalid.s
+++ llvm/test/MC/RISCV/rv32zihintntlc-invalid.s
@@ -1,5 +1,5 @@
-# RUN: not llvm-mc -triple riscv32 -mattr=+experimental-zihintntl,+c < %s 2>&1 | FileCheck %s
-# RUN: not llvm-mc -triple riscv64 -mattr=+experimental-zihintntl,+c < %s 2>&1 | FileCheck %s
+# RUN: not llvm-mc -triple riscv32 -mattr=+zihintntl,+c < %s 2>&1 | FileCheck %s
+# RUN: not llvm-mc -triple riscv64 -mattr=+zihintntl,+c < %s 2>&1 | FileCheck %s
 
 c.ntl.p1 1 # CHECK: :[[@LINE]]:10: error: invalid operand for instruction
 c.ntl.pall 2 # CHECK: :[[@LINE]]:12: error: invalid operand for instruction
Index: llvm/test/MC/RISCV/rv32zihintntl-valid.s
===
--- llvm/test/MC/RISCV/rv32zihintntl-valid.s
+++ llvm/test/MC/RISCV/rv32zihintntl-valid.s
@@ -1,12 +1,12 @@
-# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zihintntl -riscv-no-aliases -show-encoding \
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+zihintntl -riscv-no-aliases -show-encoding \
 # RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zihintntl -riscv-no-aliases -show-encoding \
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+zihintntl -riscv-no-aliases -show-encoding \
 # RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+experimental-zihintntl < %s \
-# RUN: | llvm-objdump --mattr=+experimental-zihintntl -M no-aliases -d -r - \
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+zihintntl < %s \
+# RUN: | llvm-objdump --mattr=+zihintntl -M no-aliases -d -r - \
 # RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+experimental-zihintntl < %s \
-# RUN: | llvm-objdump --mattr=+experimental-zihintntl -M no-aliases -d -r - \
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+zihintntl < %s \
+# RUN: | llvm-objdump --mattr=+zihintntl -M 

[PATCH] D155776: [NFC] Add checks for self-assignment.

2023-07-19 Thread Sindhu Chittireddy via Phabricator via cfe-commits
schittir created this revision.
Herald added a project: All.
schittir requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155776

Files:
  clang/include/clang/Sema/ObjCMethodList.h
  clang/lib/AST/APValue.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/Interpreter/Value.cpp


Index: clang/lib/Interpreter/Value.cpp
===
--- clang/lib/Interpreter/Value.cpp
+++ clang/lib/Interpreter/Value.cpp
@@ -201,16 +201,17 @@
 }
 
 Value ::operator=(Value &) noexcept {
-  if (IsManuallyAlloc)
-ValueStorage::getFromPayload(getPtr())->Release();
+  if (this != RHS) {
+if (IsManuallyAlloc)
+  ValueStorage::getFromPayload(getPtr())->Release();
 
-  Interp = std::exchange(RHS.Interp, nullptr);
-  OpaqueType = std::exchange(RHS.OpaqueType, nullptr);
-  ValueKind = std::exchange(RHS.ValueKind, K_Unspecified);
-  IsManuallyAlloc = std::exchange(RHS.IsManuallyAlloc, false);
-
-  Data = RHS.Data;
+Interp = std::exchange(RHS.Interp, nullptr);
+OpaqueType = std::exchange(RHS.OpaqueType, nullptr);
+ValueKind = std::exchange(RHS.ValueKind, K_Unspecified);
+IsManuallyAlloc = std::exchange(RHS.IsManuallyAlloc, false);
 
+Data = RHS.Data;
+  }
   return *this;
 }
 
Index: clang/lib/CodeGen/CGDebugInfo.h
===
--- clang/lib/CodeGen/CGDebugInfo.h
+++ clang/lib/CodeGen/CGDebugInfo.h
@@ -832,8 +832,10 @@
 
   // Define copy assignment operator.
   ApplyDebugLocation =(ApplyDebugLocation &) {
-CGF = Other.CGF;
-Other.CGF = nullptr;
+if (this != Other) {
+  CGF = Other.CGF;
+  Other.CGF = nullptr;
+}
 return *this;
   }
 
Index: clang/lib/AST/APValue.cpp
===
--- clang/lib/AST/APValue.cpp
+++ clang/lib/AST/APValue.cpp
@@ -390,11 +390,13 @@
 }
 
 APValue ::operator=(APValue &) {
-  if (Kind != None && Kind != Indeterminate)
-DestroyDataAndMakeUninit();
-  Kind = RHS.Kind;
-  Data = RHS.Data;
-  RHS.Kind = None;
+  if (this != RHS) {
+if (Kind != None && Kind != Indeterminate)
+  DestroyDataAndMakeUninit();
+Kind = RHS.Kind;
+Data = RHS.Data;
+RHS.Kind = None;
+  }
   return *this;
 }
 
Index: clang/include/clang/Sema/ObjCMethodList.h
===
--- clang/include/clang/Sema/ObjCMethodList.h
+++ clang/include/clang/Sema/ObjCMethodList.h
@@ -37,8 +37,10 @@
 NextAndExtraBits(L.NextAndExtraBits) {}
 
   ObjCMethodList =(const ObjCMethodList ) {
-MethodAndHasMoreThanOneDecl = L.MethodAndHasMoreThanOneDecl;
-NextAndExtraBits = L.NextAndExtraBits;
+if (this != L) {
+  MethodAndHasMoreThanOneDecl = L.MethodAndHasMoreThanOneDecl;
+  NextAndExtraBits = L.NextAndExtraBits;
+}
 return *this;
   }
 


Index: clang/lib/Interpreter/Value.cpp
===
--- clang/lib/Interpreter/Value.cpp
+++ clang/lib/Interpreter/Value.cpp
@@ -201,16 +201,17 @@
 }
 
 Value ::operator=(Value &) noexcept {
-  if (IsManuallyAlloc)
-ValueStorage::getFromPayload(getPtr())->Release();
+  if (this != RHS) {
+if (IsManuallyAlloc)
+  ValueStorage::getFromPayload(getPtr())->Release();
 
-  Interp = std::exchange(RHS.Interp, nullptr);
-  OpaqueType = std::exchange(RHS.OpaqueType, nullptr);
-  ValueKind = std::exchange(RHS.ValueKind, K_Unspecified);
-  IsManuallyAlloc = std::exchange(RHS.IsManuallyAlloc, false);
-
-  Data = RHS.Data;
+Interp = std::exchange(RHS.Interp, nullptr);
+OpaqueType = std::exchange(RHS.OpaqueType, nullptr);
+ValueKind = std::exchange(RHS.ValueKind, K_Unspecified);
+IsManuallyAlloc = std::exchange(RHS.IsManuallyAlloc, false);
 
+Data = RHS.Data;
+  }
   return *this;
 }
 
Index: clang/lib/CodeGen/CGDebugInfo.h
===
--- clang/lib/CodeGen/CGDebugInfo.h
+++ clang/lib/CodeGen/CGDebugInfo.h
@@ -832,8 +832,10 @@
 
   // Define copy assignment operator.
   ApplyDebugLocation =(ApplyDebugLocation &) {
-CGF = Other.CGF;
-Other.CGF = nullptr;
+if (this != Other) {
+  CGF = Other.CGF;
+  Other.CGF = nullptr;
+}
 return *this;
   }
 
Index: clang/lib/AST/APValue.cpp
===
--- clang/lib/AST/APValue.cpp
+++ clang/lib/AST/APValue.cpp
@@ -390,11 +390,13 @@
 }
 
 APValue ::operator=(APValue &) {
-  if (Kind != None && Kind != Indeterminate)
-DestroyDataAndMakeUninit();
-  Kind = RHS.Kind;
-  Data = RHS.Data;
-  RHS.Kind = None;
+  if (this != RHS) {
+if (Kind != None && Kind != Indeterminate)
+  DestroyDataAndMakeUninit();
+Kind = RHS.Kind;
+Data = RHS.Data;
+RHS.Kind = None;
+  }
   return *this;
 }
 
Index: 

[PATCH] D155775: [Clang][Driver][RFC] Add driver support for C++ Parallel Algorithm Offload

2023-07-19 Thread Alex Voicu via Phabricator via cfe-commits
AlexVlx updated this revision to Diff 542287.
AlexVlx added a comment.

Removed some accidental noise.


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

https://reviews.llvm.org/D155775

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/ROCm.h
  clang/test/Driver/Inputs/stdpar/stdpar_lib.hpp
  clang/test/Driver/stdpar.c

Index: clang/test/Driver/stdpar.c
===
--- /dev/null
+++ clang/test/Driver/stdpar.c
@@ -0,0 +1,18 @@
+// RUN: %clang -### -stdpar --compile %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=STDPAR-MISSING-LIB %s
+// STDPAR-MISSING-LIB: error: cannot find HIP Standard Parallelism Acceleration library; provide it via '--stdpar-path'
+
+// RUN: %clang -### --stdpar --stdpar-path=%S/Inputs/stdpar \
+// RUN:   --stdpar-thrust-path=%S/Inputs/stdpar/thrust \
+// RUN:   --stdpar-prim-path=%S/Inputs/stdpar/prim --compile %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=STDPAR-COMPILE %s
+// STDPAR-COMPILE: "-x" "hip"
+// STDPAR-COMPILE: "-idirafter" "{{.*/Inputs/stdpar/thrust}}"
+// STDPAR-COMPILE: "-idirafter" "{{.*/Inputs/stdpar/prim}}"
+// STDPAR-COMPILE: "-idirafter" "{{.*/Inputs/stdpar}}"
+// STDPAR-COMPILE: "-include" "stdpar_lib.hpp"
+
+// RUN: touch %t.o
+// RUN: %clang -### -stdpar %t.o 2>&1 | FileCheck --check-prefix=STDPAR-LINK %s
+// STDPAR-LINK: "-rpath"
+// STDPAR-LINK: "-l{{.*hip.*}}"
Index: clang/lib/Driver/ToolChains/ROCm.h
===
--- clang/lib/Driver/ToolChains/ROCm.h
+++ clang/lib/Driver/ToolChains/ROCm.h
@@ -77,6 +77,9 @@
   const Driver 
   bool HasHIPRuntime = false;
   bool HasDeviceLibrary = false;
+  bool HasHIPStdParLibrary = false;
+  bool HasRocThrustLibrary = false;
+  bool HasRocPrimLibrary = false;
 
   // Default version if not detected or specified.
   const unsigned DefaultVersionMajor = 3;
@@ -96,6 +99,13 @@
   std::vector RocmDeviceLibPathArg;
   // HIP runtime path specified by --hip-path.
   StringRef HIPPathArg;
+  // HIP Standard Parallel Algorithm acceleration library specified by
+  // --stdpar-path
+  StringRef HIPStdParPathArg;
+  // rocThrust algorithm library specified by --stdpar-thrust-path
+  StringRef HIPRocThrustPathArg;
+  // rocPrim algorithm library specified by --stdpar-prim-path
+  StringRef HIPRocPrimPathArg;
   // HIP version specified by --hip-version.
   StringRef HIPVersionArg;
   // Wheter -nogpulib is specified.
@@ -180,6 +190,9 @@
   /// Check whether we detected a valid ROCm device library.
   bool hasDeviceLibrary() const { return HasDeviceLibrary; }
 
+  /// Check whether we detected a valid HIP STDPAR Acceleration library.
+  bool hasHIPStdParLibrary() const { return HasHIPStdParLibrary; }
+
   /// Print information about the detected ROCm installation.
   void print(raw_ostream ) const;
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6527,6 +6527,12 @@
 if (Args.hasFlag(options::OPT_fgpu_allow_device_init,
  options::OPT_fno_gpu_allow_device_init, false))
   CmdArgs.push_back("-fgpu-allow-device-init");
+if (Args.hasArg(options::OPT_stdpar)) {
+  CmdArgs.push_back("-stdpar");
+
+  if (Args.hasArg(options::OPT_stdpar_interpose_alloc))
+CmdArgs.push_back("-stdpar-interpose-alloc");
+}
 Args.addOptInFlag(CmdArgs, options::OPT_fhip_kernel_arg_name,
   options::OPT_fno_hip_kernel_arg_name);
   }
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -329,6 +329,19 @@
   RocmDeviceLibPathArg =
   Args.getAllArgValues(clang::driver::options::OPT_rocm_device_lib_path_EQ);
   HIPPathArg = Args.getLastArgValue(clang::driver::options::OPT_hip_path_EQ);
+  HIPStdParPathArg =
+Args.getLastArgValue(clang::driver::options::OPT_stdpar_path_EQ);
+  HasHIPStdParLibrary = !HIPStdParPathArg.empty() &&
+D.getVFS().exists(HIPStdParPathArg + "/stdpar_lib.hpp");
+  HIPRocThrustPathArg =
+Args.getLastArgValue(clang::driver::options::OPT_stdpar_thrust_path_EQ);
+  HasRocThrustLibrary = !HIPRocThrustPathArg.empty() &&
+D.getVFS().exists(HIPRocThrustPathArg + "/thrust");
+  HIPRocPrimPathArg =
+Args.getLastArgValue(clang::driver::options::OPT_stdpar_prim_path_EQ);
+  HasRocPrimLibrary = !HIPRocPrimPathArg.empty() &&
+  D.getVFS().exists(HIPRocPrimPathArg + "/rocprim");
+
   if (auto *A = 

[PATCH] D155775: [Clang][Driver][RFC] Add driver support for C++ Parallel Algorithm Offload

2023-07-19 Thread Alex Voicu via Phabricator via cfe-commits
AlexVlx created this revision.
AlexVlx added reviewers: jansvoboda11, arsenm, yaxunl, MaskRay.
AlexVlx added a project: clang.
Herald added subscribers: cmtice, kerbowa, ormris, hiraditya, tpr, jvesely.
Herald added a reviewer: jhenderson.
Herald added a project: All.
AlexVlx requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, wdng.
Herald added a project: LLVM.

This patch adds the Driver changes needed by the standard algorithm offload 
feature being proposed here: 
https://discourse.llvm.org/t/rfc-adding-c-parallel-algorithm-offload-support-to-clang-llvm/72159/1.
 The verbose documentation is included in its parent patch. What this change 
does can be summed up as follows:

1. add two flags, one for enabling `stdpar` compilation, the second enabling 
the optional allocation interposition mode;
2. the flags correspond to new LangOpt members;
3. if we are compiling or linking with `-stdpar`, we enable HIP; in the 
compilation case C and C++ inputs are treated as HIP inputs;
4. the ROCm / AMDGPU driver is augmented to look for and include an 
implementation detail forwarding header, which is provided here 
https://github.com/ROCmSoftwarePlatform/roc-stdpar/blob/main/include/stdpar_lib.hpp;
 we error out if the user requested `stdpar` but the header or its dependencies 
cannot be found (it is plausible that in the future we'll move the check for 
the dependencies to the header itself in order to reduce the compiler 
footprint).

Tests for the behaviour described above are also added.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155775

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/ROCm.h
  clang/test/Driver/Inputs/stdpar/stdpar_lib.hpp
  clang/test/Driver/stdpar.c
  llvm/include/llvm/CodeGen/AccelTable.h
  llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp
  llvm/test/DebugInfo/Generic/accel-table-hash-collisions.ll
  llvm/test/DebugInfo/Generic/apple-names-hash-collisions.ll
  llvm/test/DebugInfo/Generic/debug-names-hash-collisions.ll
  llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp
  llvm/utils/gn/secondary/clang/lib/Headers/BUILD.gn

Index: llvm/utils/gn/secondary/clang/lib/Headers/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Headers/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Headers/BUILD.gn
@@ -238,7 +238,6 @@
 "sha512intrin.h",
 "shaintrin.h",
 "sifive_vector.h",
-"sm3intrin.h",
 "smmintrin.h",
 "stdalign.h",
 "stdarg.h",
Index: llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp
===
--- llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp
+++ llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp
@@ -11,7 +11,6 @@
 //===--===//
 
 #include "llvm-dwarfdump.h"
-#include "llvm/ADT/MapVector.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/StringSet.h"
@@ -464,7 +463,7 @@
 static void findAllApple(
 DWARFContext , raw_ostream ,
 std::function GetNameForDWARFReg) {
-  MapVector> NameToDies;
+  StringMap> NameToDies;
 
   auto PushDIEs = [&](const AppleAcceleratorTable ) {
 for (const auto  : Accel.entries()) {
Index: llvm/test/DebugInfo/Generic/debug-names-hash-collisions.ll
===
--- llvm/test/DebugInfo/Generic/debug-names-hash-collisions.ll
+++ llvm/test/DebugInfo/Generic/debug-names-hash-collisions.ll
@@ -29,21 +29,21 @@
 ; Check that all the names are present in the output
 ; CHECK: Bucket 0
 ; CHECK: Hash: 0xF8CF70D
-; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZN4lldb7SBBlockaSERKS0_"
-; CHECK: Hash: 0xF8CF70D
 ; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZN4lldb7SBBlockC1ERKS0_"
-; CHECK: Hash: 0x135A482C
-; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZN4lldb7SBErroraSERKS0_"
+; CHECK: Hash: 0xF8CF70D
+; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZN4lldb7SBBlockaSERKS0_"
 ; CHECK: Hash: 0x135A482C
 ; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZN4lldb7SBErrorC1ERKS0_"
+; CHECK: Hash: 0x135A482C
+; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZN4lldb7SBErroraSERKS0_"
 ; CHECK-NOT: String:
 ; CHECK: Bucket 1
 ; CHECK-NEXT: EMPTY
 ; CHECK: Bucket 2
 ; CHECK: Hash: 0x2841B989
-; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZL11numCommutes"
-; CHECK: Hash: 0x2841B989
 ; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZL11NumCommutes"
+; CHECK: Hash: 0x2841B989
+; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZL11numCommutes"
 ; CHECK: Hash: 0x3E190F5F
 ; CHECK-NEXT:String: 0x{{[0-9a-f]*}} "_ZL9NumRemats"
 ; CHECK: Hash: 0x3E190F5F
Index: llvm/test/DebugInfo/Generic/apple-names-hash-collisions.ll

[PATCH] D155774: [NFC] Remove needless nullchecks.

2023-07-19 Thread Sindhu Chittireddy via Phabricator via cfe-commits
schittir created this revision.
schittir added reviewers: aaron.ballman, tahonermann.
Herald added a project: All.
schittir requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155774

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Lex/ModuleMap.cpp
  clang/lib/Sema/SemaExpr.cpp


Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -10926,11 +10926,9 @@
 return true;
 
   // Adjust scalar if desired.
-  if (Scalar) {
-if (ScalarCast != CK_NoOp)
-  *Scalar = S.ImpCastExprToType(Scalar->get(), VectorEltTy, ScalarCast);
-*Scalar = S.ImpCastExprToType(Scalar->get(), VectorTy, CK_VectorSplat);
-  }
+  if (ScalarCast != CK_NoOp)
+*Scalar = S.ImpCastExprToType(Scalar->get(), VectorEltTy, ScalarCast);
+  *Scalar = S.ImpCastExprToType(Scalar->get(), VectorTy, CK_VectorSplat);
   return false;
 }
 
Index: clang/lib/Lex/ModuleMap.cpp
===
--- clang/lib/Lex/ModuleMap.cpp
+++ clang/lib/Lex/ModuleMap.cpp
@@ -2475,7 +2475,7 @@
   bool NeedsFramework = false;
   Map.addUnresolvedHeader(ActiveModule, std::move(Header), NeedsFramework);
 
-  if (NeedsFramework && ActiveModule)
+  if (NeedsFramework)
 Diags.Report(CurrModuleDeclLoc, diag::note_mmap_add_framework_keyword)
   << ActiveModule->getFullModuleName()
   << FixItHint::CreateReplacement(CurrModuleDeclLoc, "framework module");
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -5234,7 +5234,7 @@
   // Is accessible from all the threads within the grid and from the host
   // through the runtime library (cudaGetSymbolAddress() / cudaGetSymbolSize()
   // / cudaMemcpyToSymbol() / cudaMemcpyFromSymbol())."
-  if (GV && LangOpts.CUDA) {
+  if (LangOpts.CUDA) {
 if (LangOpts.CUDAIsDevice) {
   if (Linkage != llvm::GlobalValue::InternalLinkage &&
   (D->hasAttr() || D->hasAttr() ||


Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -10926,11 +10926,9 @@
 return true;
 
   // Adjust scalar if desired.
-  if (Scalar) {
-if (ScalarCast != CK_NoOp)
-  *Scalar = S.ImpCastExprToType(Scalar->get(), VectorEltTy, ScalarCast);
-*Scalar = S.ImpCastExprToType(Scalar->get(), VectorTy, CK_VectorSplat);
-  }
+  if (ScalarCast != CK_NoOp)
+*Scalar = S.ImpCastExprToType(Scalar->get(), VectorEltTy, ScalarCast);
+  *Scalar = S.ImpCastExprToType(Scalar->get(), VectorTy, CK_VectorSplat);
   return false;
 }
 
Index: clang/lib/Lex/ModuleMap.cpp
===
--- clang/lib/Lex/ModuleMap.cpp
+++ clang/lib/Lex/ModuleMap.cpp
@@ -2475,7 +2475,7 @@
   bool NeedsFramework = false;
   Map.addUnresolvedHeader(ActiveModule, std::move(Header), NeedsFramework);
 
-  if (NeedsFramework && ActiveModule)
+  if (NeedsFramework)
 Diags.Report(CurrModuleDeclLoc, diag::note_mmap_add_framework_keyword)
   << ActiveModule->getFullModuleName()
   << FixItHint::CreateReplacement(CurrModuleDeclLoc, "framework module");
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -5234,7 +5234,7 @@
   // Is accessible from all the threads within the grid and from the host
   // through the runtime library (cudaGetSymbolAddress() / cudaGetSymbolSize()
   // / cudaMemcpyToSymbol() / cudaMemcpyFromSymbol())."
-  if (GV && LangOpts.CUDA) {
+  if (LangOpts.CUDA) {
 if (LangOpts.CUDAIsDevice) {
   if (Linkage != llvm::GlobalValue::InternalLinkage &&
   (D->hasAttr() || D->hasAttr() ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143617: [Clang][CMake] Support perf, LBR, and Instrument CLANG_BOLT options

2023-07-19 Thread Amir Ayupov via Phabricator via cfe-commits
Amir updated this revision to Diff 542280.
Amir added a comment.

Make the name of BOLT-instrumented Clang binary (CLANG_BOLT_INSTRUMENTED)
a user-settable cache variable


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143617

Files:
  clang/CMakeLists.txt
  clang/cmake/caches/BOLT.cmake
  clang/utils/perf-training/CMakeLists.txt
  clang/utils/perf-training/bolt.lit.cfg
  clang/utils/perf-training/bolt.lit.site.cfg.in
  clang/utils/perf-training/perf-helper.py

Index: clang/utils/perf-training/perf-helper.py
===
--- clang/utils/perf-training/perf-helper.py
+++ clang/utils/perf-training/perf-helper.py
@@ -67,6 +67,69 @@
 return 0
 
 
+def perf(args):
+parser = argparse.ArgumentParser(
+prog="perf-helper perf", description="perf wrapper for BOLT profile collection"
+)
+parser.add_argument(
+"--lbr", action="store_true", help="Use perf with branch stacks"
+)
+parser.add_argument("cmd", nargs="*", help="")
+
+# Use python's arg parser to handle all leading option arguments, but pass
+# everything else through to perf
+first_cmd = next(arg for arg in args if not arg.startswith("--"))
+last_arg_idx = args.index(first_cmd)
+
+opts = parser.parse_args(args[:last_arg_idx])
+cmd = args[last_arg_idx:]
+
+perf_args = [
+"perf",
+"record",
+"--event=cycles:u",
+"--freq=max",
+"--output=%d.perf.data" % os.getpid(),
+]
+if opts.lbr:
+perf_args += ["--branch-filter=any,u"]
+perf_args.extend(cmd)
+
+start_time = time.time()
+subprocess.check_call(perf_args)
+
+elapsed = time.time() - start_time
+print("... data collection took %.4fs" % elapsed)
+return 0
+
+
+def perf2bolt(args):
+parser = argparse.ArgumentParser(
+prog="perf-helper perf2bolt",
+description="perf2bolt conversion wrapper for perf.data files",
+)
+parser.add_argument("bolt", help="Path to llvm-bolt")
+parser.add_argument("path", help="Path containing perf.data files")
+parser.add_argument("binary", help="Input binary")
+parser.add_argument(
+"--lbr", action="store_true", help="Use LBR perf2bolt mode"
+)
+opts = parser.parse_args(args)
+
+p2b_args = [
+opts.bolt,
+opts.binary,
+"--aggregate-only",
+"--profile-format=yaml",
+]
+if not opts.lbr:
+p2b_args += ["-nl"]
+p2b_args += ["-p"]
+for filename in findFilesWithExtension(opts.path, "perf.data"):
+subprocess.check_call(p2b_args + [filename, "-o", filename + ".fdata"])
+return 0
+
+
 def dtrace(args):
 parser = argparse.ArgumentParser(
 prog="perf-helper dtrace",
@@ -507,6 +570,8 @@
 "cc1": cc1,
 "gen-order-file": genOrderFile,
 "merge-fdata": merge_fdata,
+"perf": perf,
+"perf2bolt": perf2bolt,
 }
 
 
Index: clang/utils/perf-training/bolt.lit.site.cfg.in
===
--- clang/utils/perf-training/bolt.lit.site.cfg.in
+++ clang/utils/perf-training/bolt.lit.site.cfg.in
@@ -9,6 +9,8 @@
 config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.python_exe = "@Python3_EXECUTABLE@"
 config.clang_obj_root = path(r"@CLANG_BINARY_DIR@")
+config.clang_bolt_mode = "@CLANG_BOLT@"
+config.clang_bolt_name = "@CLANG_BOLT_INSTRUMENTED@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@CLANG_SOURCE_DIR@/utils/perf-training/bolt.lit.cfg")
Index: clang/utils/perf-training/bolt.lit.cfg
===
--- clang/utils/perf-training/bolt.lit.cfg
+++ clang/utils/perf-training/bolt.lit.cfg
@@ -6,15 +6,52 @@
 import os
 import subprocess
 
-config.clang = os.path.realpath(lit.util.which('clang-bolt.inst', config.clang_tools_dir)).replace('\\', '/')
+clang_binary = "clang"
+perf_wrapper = ""
+if config.clang_bolt_mode.lower() == "instrument":
+clang_binary = config.clang_bolt_name
+else:  # perf or LBR
+perf_wrapper = "%s %s/perf-helper.py perf" % (
+config.python_exe,
+config.perf_helper_dir,
+)
+if config.clang_bolt_mode.lower() == "lbr":
+perf_wrapper += " --lbr"
+perf_wrapper += " -- "
 
-config.name = 'Clang Perf Training'
-config.suffixes = ['.c', '.cc', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s', '.S', '.modulemap', '.test']
+config.clang = os.path.realpath(
+lit.util.which(clang_binary, config.clang_tools_dir)
+).replace("\\", "/")
+
+config.name = "Clang Perf Training"
+config.suffixes = [
+".c",
+".cc",
+".cpp",
+".m",
+".mm",
+".cu",
+".ll",
+".cl",
+".s",
+".S",
+".modulemap",
+".test",
+]
 
 use_lit_shell = os.environ.get("LIT_USE_INTERNAL_SHELL")
 config.test_format = lit.formats.ShTest(use_lit_shell == "0")
-config.substitutions.append( 

[PATCH] D154324: [C++20] [Modules] [ODRHash] Use CanonicalType for base classes

2023-07-19 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

In D154324#4516917 , @ChuanqiXu wrote:

> In D154324#4516605 , @alexfh wrote:
>
>> Hi, we've started seeing compilation errors with our modularized build after 
>> this commit. The errors say `'SomeType' has different definitions in 
>> different modules`, but then point to the same definition that comes from 
>> the same textual header included into two modules.
>>
>> The setup (which I couldn't completely isolate yet) is roughly similar to 
>> this (hopefully, I didn't miss any important parts):
>>
>> Textual header p.h:
>>
>>   #include 
>>   
>>   #include "protobuf/generated_enum_util.h"
>>   ...
>>   
>>   template > typename =
>> typename 
>> std::enable_if::value>::type>
>>   class SomeType : E> {
>>   ...
>>   };
>>
>> Module A, a.h:
>>
>>   #include 
>>   
>>   #include "protobuf/generated_enum_util.h"
>>   
>>   namespace q {
>>   template > typename std::enable_if<::proto2::is_proto_enum::value>::type>
>>   class X {};
>>   }
>>   
>>   #include "p.h"
>>
>> Module B, b.h:
>>
>>   // ...
>>   // something likely unrelated
>>   // ...
>>   #include "p.h"
>>
>> Module C (uses module A, module B), c.h:
>>
>>   #include "a.h"
>>   #include "b.h"
>
> Maybe we got something wrong with this. I'd like to revert this patch in case 
> it breaks something. But would you like to reduce your reproducer further to 
> a state without external includes to STL or protobuf? Then we can add the 
> reduced reproducer to the tests to avoid further regressions.

That turned out to be quite time-consuming, but I can try nevertheless. I also 
asked @rsmith if he could figure out what the problem is. Hopefully, he can 
help with the test case, if gets to the bottom of the problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154324

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


[PATCH] D155147: [X86] Add SM3 instructions.

2023-07-19 Thread Freddy, Ye via 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 rGc6f66de21af0: [X86] Add SM3 instructions. (authored by 
FreddyYe).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155147

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/immintrin.h
  clang/lib/Headers/sm3intrin.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/X86/sm3-builtins.c
  clang/test/CodeGen/X86/sm3-error.c
  clang/test/CodeGen/attr-target-x86.c
  clang/test/Driver/x86-target-features.c
  clang/test/Preprocessor/x86_target_features.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/include/llvm/TargetParser/X86TargetParser.def
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/lib/TargetParser/Host.cpp
  llvm/lib/TargetParser/X86TargetParser.cpp
  llvm/test/CodeGen/X86/sm3-intrinsics.ll
  llvm/test/MC/Disassembler/X86/sm3-32.txt
  llvm/test/MC/Disassembler/X86/sm3-64.txt
  llvm/test/MC/X86/sm3-att-32.s
  llvm/test/MC/X86/sm3-att-64.s
  llvm/test/MC/X86/sm3-intel-32.s
  llvm/test/MC/X86/sm3-intel-64.s
  llvm/test/TableGen/x86-fold-tables.inc

Index: llvm/test/TableGen/x86-fold-tables.inc
===
--- llvm/test/TableGen/x86-fold-tables.inc
+++ llvm/test/TableGen/x86-fold-tables.inc
@@ -4800,6 +4800,9 @@
   {X86::VSHUFPSZ128rrikz, X86::VSHUFPSZ128rmikz, 0},
   {X86::VSHUFPSZ256rrikz, X86::VSHUFPSZ256rmikz, 0},
   {X86::VSHUFPSZrrikz, X86::VSHUFPSZrmikz, 0},
+  {X86::VSM3MSG1rr, X86::VSM3MSG1rm, 0},
+  {X86::VSM3MSG2rr, X86::VSM3MSG2rm, 0},
+  {X86::VSM3RNDS2rr, X86::VSM3RNDS2rm, 0},
   {X86::VSQRTPDZ128rk, X86::VSQRTPDZ128mk, 0},
   {X86::VSQRTPDZ256rk, X86::VSQRTPDZ256mk, 0},
   {X86::VSQRTPDZrk, X86::VSQRTPDZmk, 0},
Index: llvm/test/MC/X86/sm3-intel-64.s
===
--- /dev/null
+++ llvm/test/MC/X86/sm3-intel-64.s
@@ -0,0 +1,86 @@
+// RUN: llvm-mc -triple x86_64 -x86-asm-syntax=intel -output-asm-variant=1 --show-encoding %s | FileCheck %s
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmm4
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0xe4]
+  vsm3msg1 xmm12, xmm13, xmm4
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+// CHECK: encoding: [0xc4,0x22,0x10,0xda,0xa4,0xf5,0x00,0x00,0x00,0x10]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+// CHECK: encoding: [0xc4,0x42,0x10,0xda,0xa4,0x80,0x23,0x01,0x00,0x00]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [rip]
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0x25,0x00,0x00,0x00,0x00]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [rip]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0x24,0x6d,0x00,0xfe,0xff,0xff]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [rcx + 2032]
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0xa1,0xf0,0x07,0x00,0x00]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [rcx + 2032]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [rdx - 2048]
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0xa2,0x00,0xf8,0xff,0xff]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [rdx - 2048]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmm4
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0xe4]
+  vsm3msg2 xmm12, xmm13, xmm4
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+// CHECK: encoding: [0xc4,0x22,0x11,0xda,0xa4,0xf5,0x00,0x00,0x00,0x10]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+// CHECK: encoding: [0xc4,0x42,0x11,0xda,0xa4,0x80,0x23,0x01,0x00,0x00]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [rip]
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0x25,0x00,0x00,0x00,0x00]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [rip]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0x24,0x6d,0x00,0xfe,0xff,0xff]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [rcx + 2032]
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0xa1,0xf0,0x07,0x00,0x00]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [rcx + 2032]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [rdx - 2048]
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0xa2,0x00,0xf8,0xff,0xff]
+  vsm3msg2 xmm12, xmm13, xmmword ptr 

[clang] c6f66de - [X86] Add SM3 instructions.

2023-07-19 Thread Freddy Ye via cfe-commits

Author: Freddy Ye
Date: 2023-07-20T10:24:16+08:00
New Revision: c6f66de21af060ead6e5402858351e9e869dc15f

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

LOG: [X86] Add SM3 instructions.

For more details about these instructions, please refer to the latest ISE 
document: 
https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: pengfei

Differential Revision: https://reviews.llvm.org/D155147

Added: 
clang/lib/Headers/sm3intrin.h
clang/test/CodeGen/X86/sm3-builtins.c
clang/test/CodeGen/X86/sm3-error.c
llvm/test/CodeGen/X86/sm3-intrinsics.ll
llvm/test/MC/Disassembler/X86/sm3-32.txt
llvm/test/MC/Disassembler/X86/sm3-64.txt
llvm/test/MC/X86/sm3-att-32.s
llvm/test/MC/X86/sm3-att-64.s
llvm/test/MC/X86/sm3-intel-32.s
llvm/test/MC/X86/sm3-intel-64.s

Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/BuiltinsX86.def
clang/include/clang/Driver/Options.td
clang/lib/Basic/Targets/X86.cpp
clang/lib/Basic/Targets/X86.h
clang/lib/Headers/CMakeLists.txt
clang/lib/Headers/immintrin.h
clang/lib/Sema/SemaChecking.cpp
clang/test/CodeGen/attr-target-x86.c
clang/test/Driver/x86-target-features.c
clang/test/Preprocessor/x86_target_features.c
llvm/docs/ReleaseNotes.rst
llvm/include/llvm/IR/IntrinsicsX86.td
llvm/include/llvm/TargetParser/X86TargetParser.def
llvm/lib/Target/X86/X86.td
llvm/lib/Target/X86/X86InstrInfo.td
llvm/lib/Target/X86/X86InstrSSE.td
llvm/lib/TargetParser/Host.cpp
llvm/lib/TargetParser/X86TargetParser.cpp
llvm/test/TableGen/x86-fold-tables.inc

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 21d8e34a25e804..bce9e2ab3eba82 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -817,6 +817,10 @@ X86 Support
   * Support intrinsic of ``_mm256_sha512msg1_epi64``.
   * Support intrinsic of ``_mm256_sha512msg2_epi64``.
   * Support intrinsic of ``_mm256_sha512rnds2_epi64``.
+- Support ISA of ``SM3``.
+  * Support intrinsic of ``_mm_sm3msg1_epi32``.
+  * Support intrinsic of ``_mm_sm3msg2_epi32``.
+  * Support intrinsic of ``_mm_sm3rnds2_epi32``.
 
 Arm and AArch64 Support
 ^^^

diff  --git a/clang/include/clang/Basic/BuiltinsX86.def 
b/clang/include/clang/Basic/BuiltinsX86.def
index fd4f769994a999..7fe19d86a256bd 100644
--- a/clang/include/clang/Basic/BuiltinsX86.def
+++ b/clang/include/clang/Basic/BuiltinsX86.def
@@ -2146,6 +2146,11 @@ TARGET_HEADER_BUILTIN(_InterlockedIncrement64,   
"WiWiD*",   "nh", INTRIN_H, ALL
 TARGET_HEADER_BUILTIN(_InterlockedOr64,  "WiWiD*Wi", "nh", INTRIN_H, 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedXor64, "WiWiD*Wi", "nh", INTRIN_H, 
ALL_MS_LANGUAGES, "")
 
+// SM3
+TARGET_BUILTIN(__builtin_ia32_vsm3msg1, "V4UiV4UiV4UiV4Ui", "nV:128:", "sm3")
+TARGET_BUILTIN(__builtin_ia32_vsm3msg2, "V4UiV4UiV4UiV4Ui", "nV:128:", "sm3")
+TARGET_BUILTIN(__builtin_ia32_vsm3rnds2, "V4UiV4UiV4UiV4UiIUi", "nV:128:", 
"sm3")
+
 #undef BUILTIN
 #undef TARGET_BUILTIN
 #undef TARGET_HEADER_BUILTIN

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index df5c091cf12db1..0aede381ec6dc8 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5058,6 +5058,8 @@ def msha : Flag<["-"], "msha">, 
Group;
 def mno_sha : Flag<["-"], "mno-sha">, Group;
 def msha512 : Flag<["-"], "msha512">, Group;
 def mno_sha512 : Flag<["-"], "mno-sha512">, Group;
+def msm3 : Flag<["-"], "msm3">, Group;
+def mno_sm3 : Flag<["-"], "mno-sm3">, Group;
 def mtbm : Flag<["-"], "mtbm">, Group;
 def mno_tbm : Flag<["-"], "mno-tbm">, Group;
 def mtsxldtrk : Flag<["-"], "mtsxldtrk">, Group;

diff  --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index b09ec21f77dbed..dc56b89c6b6078 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -265,6 +265,8 @@ bool 
X86TargetInfo::handleTargetFeatures(std::vector ,
   HasSHA512 = true;
 } else if (Feature == "+shstk") {
   HasSHSTK = true;
+} else if (Feature == "+sm3") {
+  HasSM3 = true;
 } else if (Feature == "+movbe") {
   HasMOVBE = true;
 } else if (Feature == "+sgx") {
@@ -776,6 +778,8 @@ void X86TargetInfo::getTargetDefines(const LangOptions 
,
 Builder.defineMacro("__SHSTK__");
   if (HasSGX)
 Builder.defineMacro("__SGX__");
+  if (HasSM3)
+Builder.defineMacro("__SM3__");
   if (HasPREFETCHI)
 Builder.defineMacro("__PREFETCHI__");
   if (HasPREFETCHWT1)
@@ -1005,6 +1009,7 @@ bool X86TargetInfo::isValidFeatureName(StringRef Name) 
const {
   

[PATCH] D155147: [X86] Add SM3 instructions.

2023-07-19 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe updated this revision to Diff 542274.
FreddyYe added a comment.

rebase and fix lit fail


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155147

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/immintrin.h
  clang/lib/Headers/sm3intrin.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/X86/sm3-builtins.c
  clang/test/CodeGen/X86/sm3-error.c
  clang/test/CodeGen/attr-target-x86.c
  clang/test/Driver/x86-target-features.c
  clang/test/Preprocessor/x86_target_features.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/include/llvm/TargetParser/X86TargetParser.def
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/lib/TargetParser/Host.cpp
  llvm/lib/TargetParser/X86TargetParser.cpp
  llvm/test/CodeGen/X86/sm3-intrinsics.ll
  llvm/test/MC/Disassembler/X86/sm3-32.txt
  llvm/test/MC/Disassembler/X86/sm3-64.txt
  llvm/test/MC/X86/sm3-att-32.s
  llvm/test/MC/X86/sm3-att-64.s
  llvm/test/MC/X86/sm3-intel-32.s
  llvm/test/MC/X86/sm3-intel-64.s
  llvm/test/TableGen/x86-fold-tables.inc

Index: llvm/test/TableGen/x86-fold-tables.inc
===
--- llvm/test/TableGen/x86-fold-tables.inc
+++ llvm/test/TableGen/x86-fold-tables.inc
@@ -4800,6 +4800,9 @@
   {X86::VSHUFPSZ128rrikz, X86::VSHUFPSZ128rmikz, 0},
   {X86::VSHUFPSZ256rrikz, X86::VSHUFPSZ256rmikz, 0},
   {X86::VSHUFPSZrrikz, X86::VSHUFPSZrmikz, 0},
+  {X86::VSM3MSG1rr, X86::VSM3MSG1rm, 0},
+  {X86::VSM3MSG2rr, X86::VSM3MSG2rm, 0},
+  {X86::VSM3RNDS2rr, X86::VSM3RNDS2rm, 0},
   {X86::VSQRTPDZ128rk, X86::VSQRTPDZ128mk, 0},
   {X86::VSQRTPDZ256rk, X86::VSQRTPDZ256mk, 0},
   {X86::VSQRTPDZrk, X86::VSQRTPDZmk, 0},
Index: llvm/test/MC/X86/sm3-intel-64.s
===
--- /dev/null
+++ llvm/test/MC/X86/sm3-intel-64.s
@@ -0,0 +1,86 @@
+// RUN: llvm-mc -triple x86_64 -x86-asm-syntax=intel -output-asm-variant=1 --show-encoding %s | FileCheck %s
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmm4
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0xe4]
+  vsm3msg1 xmm12, xmm13, xmm4
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+// CHECK: encoding: [0xc4,0x22,0x10,0xda,0xa4,0xf5,0x00,0x00,0x00,0x10]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+// CHECK: encoding: [0xc4,0x42,0x10,0xda,0xa4,0x80,0x23,0x01,0x00,0x00]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [rip]
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0x25,0x00,0x00,0x00,0x00]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [rip]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0x24,0x6d,0x00,0xfe,0xff,0xff]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [rcx + 2032]
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0xa1,0xf0,0x07,0x00,0x00]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [rcx + 2032]
+
+// CHECK: vsm3msg1 xmm12, xmm13, xmmword ptr [rdx - 2048]
+// CHECK: encoding: [0xc4,0x62,0x10,0xda,0xa2,0x00,0xf8,0xff,0xff]
+  vsm3msg1 xmm12, xmm13, xmmword ptr [rdx - 2048]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmm4
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0xe4]
+  vsm3msg2 xmm12, xmm13, xmm4
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+// CHECK: encoding: [0xc4,0x22,0x11,0xda,0xa4,0xf5,0x00,0x00,0x00,0x10]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [rbp + 8*r14 + 268435456]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+// CHECK: encoding: [0xc4,0x42,0x11,0xda,0xa4,0x80,0x23,0x01,0x00,0x00]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [r8 + 4*rax + 291]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [rip]
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0x25,0x00,0x00,0x00,0x00]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [rip]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0x24,0x6d,0x00,0xfe,0xff,0xff]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [2*rbp - 512]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [rcx + 2032]
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0xa1,0xf0,0x07,0x00,0x00]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [rcx + 2032]
+
+// CHECK: vsm3msg2 xmm12, xmm13, xmmword ptr [rdx - 2048]
+// CHECK: encoding: [0xc4,0x62,0x11,0xda,0xa2,0x00,0xf8,0xff,0xff]
+  vsm3msg2 xmm12, xmm13, xmmword ptr [rdx - 2048]
+
+// CHECK: vsm3rnds2 xmm12, xmm13, xmm4, 123
+// CHECK: encoding: [0xc4,0x63,0x11,0xde,0xe4,0x7b]
+ 

[PATCH] D143617: [Clang][CMake] Support perf, LBR, and Instrument CLANG_BOLT options

2023-07-19 Thread Amir Ayupov via Phabricator via cfe-commits
Amir updated this revision to Diff 542272.
Amir added a comment.

Set CLANG_BOLT_INSTRUMENTED in parent scope too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143617

Files:
  clang/CMakeLists.txt
  clang/cmake/caches/BOLT.cmake
  clang/utils/perf-training/CMakeLists.txt
  clang/utils/perf-training/bolt.lit.cfg
  clang/utils/perf-training/bolt.lit.site.cfg.in
  clang/utils/perf-training/perf-helper.py

Index: clang/utils/perf-training/perf-helper.py
===
--- clang/utils/perf-training/perf-helper.py
+++ clang/utils/perf-training/perf-helper.py
@@ -67,6 +67,69 @@
 return 0
 
 
+def perf(args):
+parser = argparse.ArgumentParser(
+prog="perf-helper perf", description="perf wrapper for BOLT profile collection"
+)
+parser.add_argument(
+"--lbr", action="store_true", help="Use perf with branch stacks"
+)
+parser.add_argument("cmd", nargs="*", help="")
+
+# Use python's arg parser to handle all leading option arguments, but pass
+# everything else through to perf
+first_cmd = next(arg for arg in args if not arg.startswith("--"))
+last_arg_idx = args.index(first_cmd)
+
+opts = parser.parse_args(args[:last_arg_idx])
+cmd = args[last_arg_idx:]
+
+perf_args = [
+"perf",
+"record",
+"--event=cycles:u",
+"--freq=max",
+"--output=%d.perf.data" % os.getpid(),
+]
+if opts.lbr:
+perf_args += ["--branch-filter=any,u"]
+perf_args.extend(cmd)
+
+start_time = time.time()
+subprocess.check_call(perf_args)
+
+elapsed = time.time() - start_time
+print("... data collection took %.4fs" % elapsed)
+return 0
+
+
+def perf2bolt(args):
+parser = argparse.ArgumentParser(
+prog="perf-helper perf2bolt",
+description="perf2bolt conversion wrapper for perf.data files",
+)
+parser.add_argument("bolt", help="Path to llvm-bolt")
+parser.add_argument("path", help="Path containing perf.data files")
+parser.add_argument("binary", help="Input binary")
+parser.add_argument(
+"--lbr", action="store_true", help="Use LBR perf2bolt mode"
+)
+opts = parser.parse_args(args)
+
+p2b_args = [
+opts.bolt,
+opts.binary,
+"--aggregate-only",
+"--profile-format=yaml",
+]
+if not opts.lbr:
+p2b_args += ["-nl"]
+p2b_args += ["-p"]
+for filename in findFilesWithExtension(opts.path, "perf.data"):
+subprocess.check_call(p2b_args + [filename, "-o", filename + ".fdata"])
+return 0
+
+
 def dtrace(args):
 parser = argparse.ArgumentParser(
 prog="perf-helper dtrace",
@@ -507,6 +570,8 @@
 "cc1": cc1,
 "gen-order-file": genOrderFile,
 "merge-fdata": merge_fdata,
+"perf": perf,
+"perf2bolt": perf2bolt,
 }
 
 
Index: clang/utils/perf-training/bolt.lit.site.cfg.in
===
--- clang/utils/perf-training/bolt.lit.site.cfg.in
+++ clang/utils/perf-training/bolt.lit.site.cfg.in
@@ -9,6 +9,8 @@
 config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.python_exe = "@Python3_EXECUTABLE@"
 config.clang_obj_root = path(r"@CLANG_BINARY_DIR@")
+config.clang_bolt_mode = "@CLANG_BOLT@"
+config.clang_bolt_name = "@CLANG_BOLT_INSTRUMENTED@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@CLANG_SOURCE_DIR@/utils/perf-training/bolt.lit.cfg")
Index: clang/utils/perf-training/bolt.lit.cfg
===
--- clang/utils/perf-training/bolt.lit.cfg
+++ clang/utils/perf-training/bolt.lit.cfg
@@ -6,15 +6,52 @@
 import os
 import subprocess
 
-config.clang = os.path.realpath(lit.util.which('clang-bolt.inst', config.clang_tools_dir)).replace('\\', '/')
+clang_binary = "clang"
+perf_wrapper = ""
+if config.clang_bolt_mode.lower() == "instrument":
+clang_binary = config.clang_bolt_name
+else:  # perf or LBR
+perf_wrapper = "%s %s/perf-helper.py perf" % (
+config.python_exe,
+config.perf_helper_dir,
+)
+if config.clang_bolt_mode.lower() == "lbr":
+perf_wrapper += " --lbr"
+perf_wrapper += " -- "
 
-config.name = 'Clang Perf Training'
-config.suffixes = ['.c', '.cc', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s', '.S', '.modulemap', '.test']
+config.clang = os.path.realpath(
+lit.util.which(clang_binary, config.clang_tools_dir)
+).replace("\\", "/")
+
+config.name = "Clang Perf Training"
+config.suffixes = [
+".c",
+".cc",
+".cpp",
+".m",
+".mm",
+".cu",
+".ll",
+".cl",
+".s",
+".S",
+".modulemap",
+".test",
+]
 
 use_lit_shell = os.environ.get("LIT_USE_INTERNAL_SHELL")
 config.test_format = lit.formats.ShTest(use_lit_shell == "0")
-config.substitutions.append( ('%clang_cpp_skip_driver', ' %s --driver-mode=g++ ' % 

[PATCH] D155769: [Clang][docs][RFC] Add documentation for C++ Parallel Algorithm Offload

2023-07-19 Thread Alex Voicu via Phabricator via cfe-commits
AlexVlx created this revision.
AlexVlx added reviewers: rjmccall, yaxunl, aaron.ballman.
AlexVlx added a project: clang.
Herald added a subscriber: arphaman.
Herald added a project: All.
AlexVlx requested review of this revision.
Herald added a subscriber: cfe-commits.

This patch adds the documentation for the standard algorithm offload feature 
being proposed here: 
https://discourse.llvm.org/t/rfc-adding-c-parallel-algorithm-offload-support-to-clang-llvm/72159/1.
 It is the parent of a series of patches that make up the implementation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155769

Files:
  clang/docs/StdParSupport.rst
  clang/docs/index.rst

Index: clang/docs/index.rst
===
--- clang/docs/index.rst
+++ clang/docs/index.rst
@@ -47,6 +47,7 @@
OpenCLSupport
OpenMPSupport
SYCLSupport
+   StdParSupport
HLSL/HLSLDocs
ThinLTO
APINotes
Index: clang/docs/StdParSupport.rst
===
--- /dev/null
+++ clang/docs/StdParSupport.rst
@@ -0,0 +1,381 @@
+==
+C++ Standard Parallelism Offload Support: Compiler And Runtime
+==
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the implementation of support for offloading the
+execution of standard C++ algorithms to accelerators that can be targeted via
+HIP. Furthermore, it enumerates restrictions on user defined code, as well as
+the interactions with runtimes.
+
+Algorithm Offload: What, Why, Where
+===
+
+C++17 introduced overloads
+`for most algorithms in the standard library `_
+which allow the user to specify a desired
+`execution policy `_.
+The `parallel_unsequenced_policy `_
+maps relatively well to the execution model of many accelerators, such as GPUs.
+This, coupled with the ubiquity of GPU accelerated algorithm libraries that
+implement most / all corresponding libraries in the standard library
+(e.g. `rocThrust `_), makes
+it feasible to provide seamless accelerator offload for supported algorithms,
+when an accelerated version exists. Thus, it becomes possible to easily access
+the computational resources of an accelerator, via a well specified, familiar,
+algorithmic interface, without having to delve into low-level hardware specific
+details. Putting it all together:
+
+- **What**: standard library algorithms, when invoked with the
+  ``parallel_unsequenced_policy``
+- **Why**: democratise accelerator programming, without loss of user familiarity
+- **Where**: any and all accelerators that can be targeted by Clang/LLVM via HIP
+
+Small Example
+=
+
+Given the following C++ code, which assumes the ``std`` namespace is included:
+
+.. code-block:: C++
+
+   bool has_the_answer(const vector& v) {
+ return find(execution::par_unseq, cbegin(v), cend(v), 42) != cend(v);
+   }
+
+if Clang is invoked with the ``-stdpar --offload-target=foo`` flags, the call to
+``find`` will be offloaded to an accelerator that is part of the ``foo`` target
+family. If either ``foo`` or its runtime environment do not support transparent
+on-demand paging (such as e.g. that provided in Linux via
+`HMM `_), it is necessary to also include
+the ``--stdpar-interpose-alloc`` flag. If the accelerator specific algorithm
+library ``foo`` uses doesn't have an implementation of a particular algorithm,
+execution seamlessly falls back to the host CPU. It is legal to specify multiple
+``--offload-target``s. All the flags we introduce, as well as a thorough view of
+various restrictions and their implications will be provided below.
+
+Implementation - General View
+=
+
+We built support for Algorithm Offload support atop the pre-existing HIP
+infrastructure. More specifically, when one requests offload via ``-stdpar``,
+compilation is switched to HIP compilation, as if ``-x hip`` was specified.
+Similarly, linking is also switched to HIP linking, as if ``--hip-link`` was
+specified. Note that these are implicit, and one should not assume that any
+interop with HIP specific language constructs is available e.g. ``__device__``
+annotations are neither necessary nor guaranteed to work.
+
+Since there are no language restriction mechanisms in place, it is necessary to
+relax HIP language specific semantic checks performed by the FE; they would
+identify otherwise valid, offloadable code, as invalid HIP code. Given that we
+know that the user intended only for certain algorithms to be offloaded, and
+encoded this 

[PATCH] D154324: [C++20] [Modules] [ODRHash] Use CanonicalType for base classes

2023-07-19 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D154324#4516605 , @alexfh wrote:

> Hi, we've started seeing compilation errors with our modularized build after 
> this commit. The errors say `'SomeType' has different definitions in 
> different modules`, but then point to the same definition that comes from the 
> same textual header included into two modules.
>
> The setup (which I couldn't completely isolate yet) is roughly similar to 
> this (hopefully, I didn't miss any important parts):
>
> Textual header p.h:
>
>   #include 
>   
>   #include "protobuf/generated_enum_util.h"
>   ...
>   
>   template  typename =
> typename 
> std::enable_if::value>::type>
>   class SomeType : E> {
>   ...
>   };
>
> Module A, a.h:
>
>   #include 
>   
>   #include "protobuf/generated_enum_util.h"
>   
>   namespace q {
>   template  typename std::enable_if<::proto2::is_proto_enum::value>::type>
>   class X {};
>   }
>   
>   #include "p.h"
>
> Module B, b.h:
>
>   // ...
>   // something likely unrelated
>   // ...
>   #include "p.h"
>
> Module C (uses module A, module B), c.h:
>
>   #include "a.h"
>   #include "b.h"

Maybe we got something wrong with this. I'd like to revert this patch in case 
it breaks something. But would you like to reduce your reproducer further to a 
state without external includes to STL or protobuf? Then we can add the reduced 
reproducer to the tests to avoid further regressions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154324

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


[PATCH] D86310: [X86] Align i128 to 16 bytes in x86 datalayouts

2023-07-19 Thread Harald van Dijk via Phabricator via cfe-commits
hvdijk added a comment.

In D86310#4516876 , @pengfei wrote:

> Just FYI. There are a few reports about the compatibility issues, e.g., 
> #41784 .

Thanks. This is a case where clang breaks up `__int128` into 2x `i64` before it 
gets to LLVM. It is therefore not affected by this patch. Your other link also 
references #20283 , which is 
the same issue of clang breaking `__int128` into 2x `i64`.

Although this patch will not fix those issues, it may make it easier to fix 
them later on: it will give clang the ability to use LLVM's `i128` type rather 
than trying to emulate it.

> There's also concern about the alignment difference between `_BitInt(128)` 
> and `__int128`, see #60925 

That references https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/11, where the 
answer four months ago was basically "it's probably already too late for that" 
with a suggestion to try and post on the mailing list to try and convince 
others that this was important enough to do. Nothing was posted to the mailing 
list, and by now GCC has started implementing what the ABI specifies 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989). I think we would need an 
extraordinary rationale if we want to convince others that the ABI should be 
changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86310

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


[PATCH] D155146: [X86] Add SHA512 instructions.

2023-07-19 Thread Freddy, Ye via 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 rGfc3b7874b6c9: [X86] Add SHA512 instructions. (authored by 
FreddyYe).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155146

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/immintrin.h
  clang/lib/Headers/sha512intrin.h
  clang/test/CodeGen/X86/sha512-builtins.c
  clang/test/CodeGen/attr-target-x86.c
  clang/test/Driver/x86-target-features.c
  clang/test/Preprocessor/x86_target_features.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/include/llvm/TargetParser/X86TargetParser.def
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/lib/TargetParser/Host.cpp
  llvm/lib/TargetParser/X86TargetParser.cpp
  llvm/test/CodeGen/X86/sha512-intrinsics.ll
  llvm/test/MC/Disassembler/X86/sha512-32.txt
  llvm/test/MC/Disassembler/X86/sha512-64.txt
  llvm/test/MC/X86/sha512-32-att.s
  llvm/test/MC/X86/sha512-32-intel.s
  llvm/test/MC/X86/sha512-64-att.s
  llvm/test/MC/X86/sha512-64-intel.s

Index: llvm/test/MC/X86/sha512-64-intel.s
===
--- /dev/null
+++ llvm/test/MC/X86/sha512-64-intel.s
@@ -0,0 +1,14 @@
+// RUN: llvm-mc -triple x86_64 -x86-asm-syntax=intel -output-asm-variant=1 --show-encoding %s | FileCheck %s
+
+// CHECK: vsha512msg1 ymm12, xmm3
+// CHECK: encoding: [0xc4,0x62,0x7f,0xcc,0xe3]
+  vsha512msg1 ymm12, xmm3
+
+// CHECK: vsha512msg2 ymm12, ymm3
+// CHECK: encoding: [0xc4,0x62,0x7f,0xcd,0xe3]
+  vsha512msg2 ymm12, ymm3
+
+// CHECK: vsha512rnds2 ymm12, ymm3, xmm4
+// CHECK: encoding: [0xc4,0x62,0x67,0xcb,0xe4]
+  vsha512rnds2 ymm12, ymm3, xmm4
+
Index: llvm/test/MC/X86/sha512-64-att.s
===
--- /dev/null
+++ llvm/test/MC/X86/sha512-64-att.s
@@ -0,0 +1,14 @@
+// RUN: llvm-mc -triple x86_64 --show-encoding %s | FileCheck %s
+
+// CHECK: vsha512msg1 %xmm3, %ymm12
+// CHECK: encoding: [0xc4,0x62,0x7f,0xcc,0xe3]
+  vsha512msg1 %xmm3, %ymm12
+
+// CHECK: vsha512msg2 %ymm3, %ymm12
+// CHECK: encoding: [0xc4,0x62,0x7f,0xcd,0xe3]
+  vsha512msg2 %ymm3, %ymm12
+
+// CHECK: vsha512rnds2 %xmm4, %ymm3, %ymm12
+// CHECK: encoding: [0xc4,0x62,0x67,0xcb,0xe4]
+  vsha512rnds2 %xmm4, %ymm3, %ymm12
+
Index: llvm/test/MC/X86/sha512-32-intel.s
===
--- /dev/null
+++ llvm/test/MC/X86/sha512-32-intel.s
@@ -0,0 +1,13 @@
+// RUN: llvm-mc -triple i686 -x86-asm-syntax=intel -output-asm-variant=1 --show-encoding %s | FileCheck %s
+
+// CHECK:  vsha512msg1 ymm2, xmm3
+// CHECK: encoding: [0xc4,0xe2,0x7f,0xcc,0xd3]
+   vsha512msg1 ymm2, xmm3
+
+// CHECK:  vsha512msg2 ymm2, ymm3
+// CHECK: encoding: [0xc4,0xe2,0x7f,0xcd,0xd3]
+   vsha512msg2 ymm2, ymm3
+
+// CHECK:  vsha512rnds2 ymm2, ymm3, xmm4
+// CHECK: encoding: [0xc4,0xe2,0x67,0xcb,0xd4]
+   vsha512rnds2 ymm2, ymm3, xmm4
Index: llvm/test/MC/X86/sha512-32-att.s
===
--- /dev/null
+++ llvm/test/MC/X86/sha512-32-att.s
@@ -0,0 +1,13 @@
+// RUN: llvm-mc -triple i686 --show-encoding %s | FileCheck %s
+
+// CHECK:  vsha512msg1 %xmm3, %ymm2
+// CHECK: encoding: [0xc4,0xe2,0x7f,0xcc,0xd3]
+   vsha512msg1 %xmm3, %ymm2
+
+// CHECK:  vsha512msg2 %ymm3, %ymm2
+// CHECK: encoding: [0xc4,0xe2,0x7f,0xcd,0xd3]
+   vsha512msg2 %ymm3, %ymm2
+
+// CHECK:  vsha512rnds2 %xmm4, %ymm3, %ymm2
+// CHECK: encoding: [0xc4,0xe2,0x67,0xcb,0xd4]
+   vsha512rnds2 %xmm4, %ymm3, %ymm2
Index: llvm/test/MC/Disassembler/X86/sha512-64.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/X86/sha512-64.txt
@@ -0,0 +1,15 @@
+# RUN: llvm-mc --disassemble %s -triple=x86_64 | FileCheck %s --check-prefixes=ATT
+# RUN: llvm-mc --disassemble %s -triple=x86_64 --output-asm-variant=1 | FileCheck %s --check-prefixes=INTEL
+
+# ATT:   vsha512msg1 %xmm3, %ymm12
+# INTEL: vsha512msg1 ymm12, xmm3
+0xc4,0x62,0x7f,0xcc,0xe3
+
+# ATT:   vsha512msg2 %ymm3, %ymm12
+# INTEL: vsha512msg2 ymm12, ymm3
+0xc4,0x62,0x7f,0xcd,0xe3
+
+# ATT:   vsha512rnds2 %xmm4, %ymm3, %ymm12
+# INTEL: vsha512rnds2 ymm12, ymm3, xmm4
+0xc4,0x62,0x67,0xcb,0xe4
+
Index: llvm/test/MC/Disassembler/X86/sha512-32.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/X86/sha512-32.txt
@@ -0,0 +1,15 @@
+# RUN: llvm-mc --disassemble %s -triple=i386 | 

[clang] fc3b787 - [X86] Add SHA512 instructions.

2023-07-19 Thread Freddy Ye via cfe-commits

Author: Freddy Ye
Date: 2023-07-20T09:44:44+08:00
New Revision: fc3b7874b6c95f04a249e2c9da3c5221f50c85b2

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

LOG: [X86] Add SHA512 instructions.

For more details about this instruction, please refer to the latest ISE 
document: 
https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: RKSimon, skan

Differential Revision: https://reviews.llvm.org/D155146

Added: 
clang/lib/Headers/sha512intrin.h
clang/test/CodeGen/X86/sha512-builtins.c
llvm/test/CodeGen/X86/sha512-intrinsics.ll
llvm/test/MC/Disassembler/X86/sha512-32.txt
llvm/test/MC/Disassembler/X86/sha512-64.txt
llvm/test/MC/X86/sha512-32-att.s
llvm/test/MC/X86/sha512-32-intel.s
llvm/test/MC/X86/sha512-64-att.s
llvm/test/MC/X86/sha512-64-intel.s

Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/BuiltinsX86.def
clang/include/clang/Driver/Options.td
clang/lib/Basic/Targets/X86.cpp
clang/lib/Basic/Targets/X86.h
clang/lib/Headers/CMakeLists.txt
clang/lib/Headers/immintrin.h
clang/test/CodeGen/attr-target-x86.c
clang/test/Driver/x86-target-features.c
clang/test/Preprocessor/x86_target_features.c
llvm/docs/ReleaseNotes.rst
llvm/include/llvm/IR/IntrinsicsX86.td
llvm/include/llvm/TargetParser/X86TargetParser.def
llvm/lib/Target/X86/X86.td
llvm/lib/Target/X86/X86InstrInfo.td
llvm/lib/Target/X86/X86InstrSSE.td
llvm/lib/TargetParser/Host.cpp
llvm/lib/TargetParser/X86TargetParser.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index d09bffb0e25062..21d8e34a25e804 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -813,6 +813,10 @@ X86 Support
 
 - Add ISA of ``AMX-COMPLEX`` which supports ``tcmmimfp16ps`` and
   ``tcmmrlfp16ps``.
+- Support ISA of ``SHA512``.
+  * Support intrinsic of ``_mm256_sha512msg1_epi64``.
+  * Support intrinsic of ``_mm256_sha512msg2_epi64``.
+  * Support intrinsic of ``_mm256_sha512rnds2_epi64``.
 
 Arm and AArch64 Support
 ^^^

diff  --git a/clang/include/clang/Basic/BuiltinsX86.def 
b/clang/include/clang/Basic/BuiltinsX86.def
index 122896b417c845..fd4f769994a999 100644
--- a/clang/include/clang/Basic/BuiltinsX86.def
+++ b/clang/include/clang/Basic/BuiltinsX86.def
@@ -2132,6 +2132,11 @@ TARGET_BUILTIN(__builtin_ia32_vcvtneoph2ps256, 
"V8fV16xC*", "nV:256:", "avxnecon
 TARGET_BUILTIN(__builtin_ia32_vcvtneps2bf16128, "V8yV4f", "nV:128:", 
"avx512bf16,avx512vl|avxneconvert")
 TARGET_BUILTIN(__builtin_ia32_vcvtneps2bf16256, "V8yV8f", "nV:256:", 
"avx512bf16,avx512vl|avxneconvert")
 
+// SHA512
+TARGET_BUILTIN(__builtin_ia32_vsha512msg1, "V4ULLiV4ULLiV2ULLi", "nV:256:", 
"sha512")
+TARGET_BUILTIN(__builtin_ia32_vsha512msg2, "V4ULLiV4ULLiV4ULLi", "nV:256:", 
"sha512")
+TARGET_BUILTIN(__builtin_ia32_vsha512rnds2, "V4ULLiV4ULLiV4ULLiV2ULLi", 
"nV:256:", "sha512")
+
 TARGET_HEADER_BUILTIN(_InterlockedAnd64, "WiWiD*Wi", "nh", INTRIN_H, 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedDecrement64,   "WiWiD*",   "nh", INTRIN_H, 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange64,"WiWiD*Wi", "nh", INTRIN_H, 
ALL_MS_LANGUAGES, "")

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8ffb9388d330f0..df5c091cf12db1 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5056,6 +5056,8 @@ def msgx : Flag<["-"], "msgx">, 
Group;
 def mno_sgx : Flag<["-"], "mno-sgx">, Group;
 def msha : Flag<["-"], "msha">, Group;
 def mno_sha : Flag<["-"], "mno-sha">, Group;
+def msha512 : Flag<["-"], "msha512">, Group;
+def mno_sha512 : Flag<["-"], "mno-sha512">, Group;
 def mtbm : Flag<["-"], "mtbm">, Group;
 def mno_tbm : Flag<["-"], "mno-tbm">, Group;
 def mtsxldtrk : Flag<["-"], "mtsxldtrk">, Group;

diff  --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index 08d2722a8e52c0..b09ec21f77dbed 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -261,6 +261,8 @@ bool 
X86TargetInfo::handleTargetFeatures(std::vector ,
   HasAVX512VP2INTERSECT = true;
 } else if (Feature == "+sha") {
   HasSHA = true;
+} else if (Feature == "+sha512") {
+  HasSHA512 = true;
 } else if (Feature == "+shstk") {
   HasSHSTK = true;
 } else if (Feature == "+movbe") {
@@ -749,6 +751,8 @@ void X86TargetInfo::getTargetDefines(const LangOptions 
,
 Builder.defineMacro("__AVX512VP2INTERSECT__");
   if (HasSHA)
 Builder.defineMacro("__SHA__");
+  if (HasSHA512)
+Builder.defineMacro("__SHA512__");
 
   if 

[PATCH] D153059: [-Wunsafe-buffer-usage] Group parameter fix-its

2023-07-19 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Alright, I think I managed to fully chew through this patch and I think it's 
beautiful and everything makes sense to me!

I have a tiny complaint though: It is very large though, 500 lines of code is 
very hard to digest all at once. Because we aren't coming in with all the 
context you had when you wrote this code, it's often very hard for us readers 
to guess the intention behind every section of the diff, and how they are 
supposed to work together.

In this patch there are a few refactoring steps that weren't responsible for 
any change in behavior:

- Introduce the `VariableGroupsManager` abstraction;
- Extract `eraseVarsForUnfixableGroupMates()` into a function;
- Extract `listVariableGroupAsString` into a function;

But because I didn't know that at first, I had to carefully look at every line 
of code to confirm that it actually doesn't change anything.

So it'd help tremendously if these refactorings were extracted into a parallel 
"no functional change" ("NFC") patch (with zero tests: no failures on existing 
tests => the patch is indeed NFC) that doesn't do anything other than "prepare 
the codebase" for this patch. Then in the NFC patch we'd discuss architecture 
and confirm that it truly doesn't change anything, whereas in this patch every 
line of code would be filled with meaning and purpose! ^.^

I'm not sure it makes sense split it up now, probably depends on whether Jan 
and Rashmi have the same troubles as me ^.^

I also has nitpicks.




Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:2130-2131
+ [](const VarDecl *GrpMember) -> bool {
+   return FixItsForVariable.find(GrpMember) ==
+  FixItsForVariable.end();
+ })) {

(`.contains()` is unfortunately C++20)



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:2156-2157
+
+  if (auto *FD = dyn_cast(
+  D)) { // If `D` is not a `FunctionDecl`, no parameter will be fixed.
+std::vector ParmsNeedFixMask(FD->getNumParams(), false);

Would it make sense to make `createFunctionOverloadsForParms` accept a 
`FunctionDecl *D` from the start?



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:2162-2163
+for (unsigned i = 0; i < FD->getNumParams(); i++)
+  if (FixItsForVariable.find(FD->getParamDecl(i)) !=
+  FixItsForVariable.end()) {
+ParmsNeedFixMask[i] = true;

Another good use for `.count()`.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:2224
+  // `FixItsForVariable` now contains only variables that can be
+  // fixed. A variable can be fixed if its' declaration and all Fixables
+  // associated to it can all be fixed.





Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:2430
+  // The union group over the ones in "Groups" that contain parameters of `D`:
+  llvm::SetVector
+  GrpsUnionForParms; // these variables need to be fixed in one step

Why `SetVector`? Do we care about order? Maybe just `SmallSet`?



Comment at: clang/lib/Sema/AnalysisBasedWarnings.cpp:2171
+if (VarGroupForVD.size() <= 1)
+  return "";
+

Does the empty string actually ever make sense for the caller? Maybe just 
assert that this never happens, and force the caller to check that?



Comment at: 
clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-multi-parm-span.cpp:37-39
+// CHECK: fix-it:{{.*}}:{[[@LINE+3]]:24-[[@LINE+3]]:30}:"std::span p"
+// CHECK: fix-it:{{.*}}:{[[@LINE+2]]:32-[[@LINE+2]]:39}:"std::span q"
+// CHECK: fix-it:{{.*}}:{[[@LINE+1]]:41-[[@LINE+1]]:48}:"std::span a"

The fix is emitted 3 times right? Once for each warning?

Would it make sense to duplicate the three `CHECK:` lines three times to 
confirm that?


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

https://reviews.llvm.org/D153059

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


[PATCH] D86310: [X86] Align i128 to 16 bytes in x86 datalayouts

2023-07-19 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei added a comment.

Just FYI. There are a few reports about the compatibility issues, e.g., #41784 
. There's also concern about 
the alignment difference between `_BitInt(128)` and `__int128`, see #60925 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86310

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


[PATCH] D155146: [X86] Add SHA512 instructions.

2023-07-19 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe updated this revision to Diff 542267.
FreddyYe added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155146

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/immintrin.h
  clang/lib/Headers/sha512intrin.h
  clang/test/CodeGen/X86/sha512-builtins.c
  clang/test/CodeGen/attr-target-x86.c
  clang/test/Driver/x86-target-features.c
  clang/test/Preprocessor/x86_target_features.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/include/llvm/TargetParser/X86TargetParser.def
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/lib/TargetParser/Host.cpp
  llvm/lib/TargetParser/X86TargetParser.cpp
  llvm/test/CodeGen/X86/sha512-intrinsics.ll
  llvm/test/MC/Disassembler/X86/sha512-32.txt
  llvm/test/MC/Disassembler/X86/sha512-64.txt
  llvm/test/MC/X86/sha512-32-att.s
  llvm/test/MC/X86/sha512-32-intel.s
  llvm/test/MC/X86/sha512-64-att.s
  llvm/test/MC/X86/sha512-64-intel.s

Index: llvm/test/MC/X86/sha512-64-intel.s
===
--- /dev/null
+++ llvm/test/MC/X86/sha512-64-intel.s
@@ -0,0 +1,14 @@
+// RUN: llvm-mc -triple x86_64 -x86-asm-syntax=intel -output-asm-variant=1 --show-encoding %s | FileCheck %s
+
+// CHECK: vsha512msg1 ymm12, xmm3
+// CHECK: encoding: [0xc4,0x62,0x7f,0xcc,0xe3]
+  vsha512msg1 ymm12, xmm3
+
+// CHECK: vsha512msg2 ymm12, ymm3
+// CHECK: encoding: [0xc4,0x62,0x7f,0xcd,0xe3]
+  vsha512msg2 ymm12, ymm3
+
+// CHECK: vsha512rnds2 ymm12, ymm3, xmm4
+// CHECK: encoding: [0xc4,0x62,0x67,0xcb,0xe4]
+  vsha512rnds2 ymm12, ymm3, xmm4
+
Index: llvm/test/MC/X86/sha512-64-att.s
===
--- /dev/null
+++ llvm/test/MC/X86/sha512-64-att.s
@@ -0,0 +1,14 @@
+// RUN: llvm-mc -triple x86_64 --show-encoding %s | FileCheck %s
+
+// CHECK: vsha512msg1 %xmm3, %ymm12
+// CHECK: encoding: [0xc4,0x62,0x7f,0xcc,0xe3]
+  vsha512msg1 %xmm3, %ymm12
+
+// CHECK: vsha512msg2 %ymm3, %ymm12
+// CHECK: encoding: [0xc4,0x62,0x7f,0xcd,0xe3]
+  vsha512msg2 %ymm3, %ymm12
+
+// CHECK: vsha512rnds2 %xmm4, %ymm3, %ymm12
+// CHECK: encoding: [0xc4,0x62,0x67,0xcb,0xe4]
+  vsha512rnds2 %xmm4, %ymm3, %ymm12
+
Index: llvm/test/MC/X86/sha512-32-intel.s
===
--- /dev/null
+++ llvm/test/MC/X86/sha512-32-intel.s
@@ -0,0 +1,13 @@
+// RUN: llvm-mc -triple i686 -x86-asm-syntax=intel -output-asm-variant=1 --show-encoding %s | FileCheck %s
+
+// CHECK:  vsha512msg1 ymm2, xmm3
+// CHECK: encoding: [0xc4,0xe2,0x7f,0xcc,0xd3]
+   vsha512msg1 ymm2, xmm3
+
+// CHECK:  vsha512msg2 ymm2, ymm3
+// CHECK: encoding: [0xc4,0xe2,0x7f,0xcd,0xd3]
+   vsha512msg2 ymm2, ymm3
+
+// CHECK:  vsha512rnds2 ymm2, ymm3, xmm4
+// CHECK: encoding: [0xc4,0xe2,0x67,0xcb,0xd4]
+   vsha512rnds2 ymm2, ymm3, xmm4
Index: llvm/test/MC/X86/sha512-32-att.s
===
--- /dev/null
+++ llvm/test/MC/X86/sha512-32-att.s
@@ -0,0 +1,13 @@
+// RUN: llvm-mc -triple i686 --show-encoding %s | FileCheck %s
+
+// CHECK:  vsha512msg1 %xmm3, %ymm2
+// CHECK: encoding: [0xc4,0xe2,0x7f,0xcc,0xd3]
+   vsha512msg1 %xmm3, %ymm2
+
+// CHECK:  vsha512msg2 %ymm3, %ymm2
+// CHECK: encoding: [0xc4,0xe2,0x7f,0xcd,0xd3]
+   vsha512msg2 %ymm3, %ymm2
+
+// CHECK:  vsha512rnds2 %xmm4, %ymm3, %ymm2
+// CHECK: encoding: [0xc4,0xe2,0x67,0xcb,0xd4]
+   vsha512rnds2 %xmm4, %ymm3, %ymm2
Index: llvm/test/MC/Disassembler/X86/sha512-64.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/X86/sha512-64.txt
@@ -0,0 +1,15 @@
+# RUN: llvm-mc --disassemble %s -triple=x86_64 | FileCheck %s --check-prefixes=ATT
+# RUN: llvm-mc --disassemble %s -triple=x86_64 --output-asm-variant=1 | FileCheck %s --check-prefixes=INTEL
+
+# ATT:   vsha512msg1 %xmm3, %ymm12
+# INTEL: vsha512msg1 ymm12, xmm3
+0xc4,0x62,0x7f,0xcc,0xe3
+
+# ATT:   vsha512msg2 %ymm3, %ymm12
+# INTEL: vsha512msg2 ymm12, ymm3
+0xc4,0x62,0x7f,0xcd,0xe3
+
+# ATT:   vsha512rnds2 %xmm4, %ymm3, %ymm12
+# INTEL: vsha512rnds2 ymm12, ymm3, xmm4
+0xc4,0x62,0x67,0xcb,0xe4
+
Index: llvm/test/MC/Disassembler/X86/sha512-32.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/X86/sha512-32.txt
@@ -0,0 +1,15 @@
+# RUN: llvm-mc --disassemble %s -triple=i386 | FileCheck %s --check-prefixes=ATT
+# RUN: llvm-mc --disassemble %s -triple=i386 --output-asm-variant=1 | FileCheck %s --check-prefixes=INTEL
+
+# 

[PATCH] D143617: [Clang][CMake] Support perf, LBR, and Instrument CLANG_BOLT options

2023-07-19 Thread Amir Ayupov via Phabricator via cfe-commits
Amir updated this revision to Diff 542264.
Amir marked an inline comment as done.
Amir added a comment.

Fix instrumentation mode


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143617

Files:
  clang/CMakeLists.txt
  clang/cmake/caches/BOLT.cmake
  clang/utils/perf-training/CMakeLists.txt
  clang/utils/perf-training/bolt.lit.cfg
  clang/utils/perf-training/bolt.lit.site.cfg.in
  clang/utils/perf-training/perf-helper.py

Index: clang/utils/perf-training/perf-helper.py
===
--- clang/utils/perf-training/perf-helper.py
+++ clang/utils/perf-training/perf-helper.py
@@ -67,6 +67,69 @@
 return 0
 
 
+def perf(args):
+parser = argparse.ArgumentParser(
+prog="perf-helper perf", description="perf wrapper for BOLT profile collection"
+)
+parser.add_argument(
+"--lbr", action="store_true", help="Use perf with branch stacks"
+)
+parser.add_argument("cmd", nargs="*", help="")
+
+# Use python's arg parser to handle all leading option arguments, but pass
+# everything else through to perf
+first_cmd = next(arg for arg in args if not arg.startswith("--"))
+last_arg_idx = args.index(first_cmd)
+
+opts = parser.parse_args(args[:last_arg_idx])
+cmd = args[last_arg_idx:]
+
+perf_args = [
+"perf",
+"record",
+"--event=cycles:u",
+"--freq=max",
+"--output=%d.perf.data" % os.getpid(),
+]
+if opts.lbr:
+perf_args += ["--branch-filter=any,u"]
+perf_args.extend(cmd)
+
+start_time = time.time()
+subprocess.check_call(perf_args)
+
+elapsed = time.time() - start_time
+print("... data collection took %.4fs" % elapsed)
+return 0
+
+
+def perf2bolt(args):
+parser = argparse.ArgumentParser(
+prog="perf-helper perf2bolt",
+description="perf2bolt conversion wrapper for perf.data files",
+)
+parser.add_argument("bolt", help="Path to llvm-bolt")
+parser.add_argument("path", help="Path containing perf.data files")
+parser.add_argument("binary", help="Input binary")
+parser.add_argument(
+"--lbr", action="store_true", help="Use LBR perf2bolt mode"
+)
+opts = parser.parse_args(args)
+
+p2b_args = [
+opts.bolt,
+opts.binary,
+"--aggregate-only",
+"--profile-format=yaml",
+]
+if not opts.lbr:
+p2b_args += ["-nl"]
+p2b_args += ["-p"]
+for filename in findFilesWithExtension(opts.path, "perf.data"):
+subprocess.check_call(p2b_args + [filename, "-o", filename + ".fdata"])
+return 0
+
+
 def dtrace(args):
 parser = argparse.ArgumentParser(
 prog="perf-helper dtrace",
@@ -507,6 +570,8 @@
 "cc1": cc1,
 "gen-order-file": genOrderFile,
 "merge-fdata": merge_fdata,
+"perf": perf,
+"perf2bolt": perf2bolt,
 }
 
 
Index: clang/utils/perf-training/bolt.lit.site.cfg.in
===
--- clang/utils/perf-training/bolt.lit.site.cfg.in
+++ clang/utils/perf-training/bolt.lit.site.cfg.in
@@ -9,6 +9,8 @@
 config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.python_exe = "@Python3_EXECUTABLE@"
 config.clang_obj_root = path(r"@CLANG_BINARY_DIR@")
+config.clang_bolt_mode = "@CLANG_BOLT@"
+config.clang_bolt_name = "@CLANG_BOLT_INSTRUMENTED@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@CLANG_SOURCE_DIR@/utils/perf-training/bolt.lit.cfg")
Index: clang/utils/perf-training/bolt.lit.cfg
===
--- clang/utils/perf-training/bolt.lit.cfg
+++ clang/utils/perf-training/bolt.lit.cfg
@@ -6,15 +6,52 @@
 import os
 import subprocess
 
-config.clang = os.path.realpath(lit.util.which('clang-bolt.inst', config.clang_tools_dir)).replace('\\', '/')
+clang_binary = "clang"
+perf_wrapper = ""
+if config.clang_bolt_mode.lower() == "instrument":
+clang_binary = config.clang_bolt_name
+else:  # perf or LBR
+perf_wrapper = "%s %s/perf-helper.py perf" % (
+config.python_exe,
+config.perf_helper_dir,
+)
+if config.clang_bolt_mode.lower() == "lbr":
+perf_wrapper += " --lbr"
+perf_wrapper += " -- "
 
-config.name = 'Clang Perf Training'
-config.suffixes = ['.c', '.cc', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s', '.S', '.modulemap', '.test']
+config.clang = os.path.realpath(
+lit.util.which(clang_binary, config.clang_tools_dir)
+).replace("\\", "/")
+
+config.name = "Clang Perf Training"
+config.suffixes = [
+".c",
+".cc",
+".cpp",
+".m",
+".mm",
+".cu",
+".ll",
+".cl",
+".s",
+".S",
+".modulemap",
+".test",
+]
 
 use_lit_shell = os.environ.get("LIT_USE_INTERNAL_SHELL")
 config.test_format = lit.formats.ShTest(use_lit_shell == "0")
-config.substitutions.append( ('%clang_cpp_skip_driver', ' %s 

[PATCH] D155529: [clang-format] Add SpaceInParensOption for __attribute__ keyword

2023-07-19 Thread Gedare Bloom via Phabricator via cfe-commits
gedare updated this revision to Diff 542254.
gedare added a comment.

remove blank line


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155529

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/ConfigParseTest.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16718,6 +16718,7 @@
   Spaces.SpacesInParensOptions = {};
   Spaces.SpacesInParensOptions.Other = true;
   Spaces.SpacesInParensOptions.InConditionalStatements = true;
+  Spaces.SpacesInParensOptions.InAttributeSpecifiers = true;
   verifyFormat("do_something( ::globalVar );", Spaces);
   verifyFormat("call( x, y, z );", Spaces);
   verifyFormat("call();", Spaces);
@@ -16790,6 +16791,11 @@
   verifyFormat("SomeType *__attribute__((attr)) *a = NULL;", Spaces);
   verifyFormat("void __attribute__((naked)) foo(int bar)", Spaces);
 
+  Spaces.SpacesInParensOptions.InAttributeSpecifiers = true;
+  verifyFormat("SomeType *__attribute__( ( attr ) ) *a = NULL;", Spaces);
+  verifyFormat("void __attribute__( ( naked ) ) foo(int bar)", Spaces);
+  Spaces.SpacesInParensOptions.InAttributeSpecifiers = false;
+
   // Run the first set of tests again with:
   Spaces.SpaceAfterCStyleCast = true;
   verifyFormat("call(x, y, z);", Spaces);
@@ -16821,6 +16827,8 @@
   verifyFormat("bool *y = ( bool * ) ( void * ) (x);", Spaces);
   verifyFormat("bool *y = ( bool * ) (x);", Spaces);
   verifyFormat("throw ( int32 ) x;", Spaces);
+  verifyFormat("SomeType *__attribute__((attr)) *a = NULL;", Spaces);
+  verifyFormat("void __attribute__((naked)) foo(int bar)", Spaces);
 
   // Run subset of tests again with:
   Spaces.SpacesInParensOptions.InCStyleCasts = false;
Index: clang/unittests/Format/ConfigParseTest.cpp
===
--- clang/unittests/Format/ConfigParseTest.cpp
+++ clang/unittests/Format/ConfigParseTest.cpp
@@ -594,19 +594,23 @@
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
   CHECK_PARSE("SpacesInParentheses: true", SpacesInParensOptions,
-  FormatStyle::SpacesInParensCustom(true, false, false, true));
+  FormatStyle::SpacesInParensCustom(true, true, false, false,
+  true));
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
   CHECK_PARSE("SpacesInConditionalStatement: true", SpacesInParensOptions,
-  FormatStyle::SpacesInParensCustom(true, false, false, false));
+  FormatStyle::SpacesInParensCustom(false, true, false, false,
+  false));
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
   CHECK_PARSE("SpacesInCStyleCastParentheses: true", SpacesInParensOptions,
-  FormatStyle::SpacesInParensCustom(false, true, false, false));
+  FormatStyle::SpacesInParensCustom(false, false, true, false,
+  false));
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
   CHECK_PARSE("SpaceInEmptyParentheses: true", SpacesInParensOptions,
-  FormatStyle::SpacesInParensCustom(false, false, true, false));
+  FormatStyle::SpacesInParensCustom(false, false, false, true,
+  false));
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
 
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3810,10 +3810,16 @@
   }
 
   if (Left.is(tok::l_paren) || Right.is(tok::r_paren)) {
-return (Right.is(TT_CastRParen) ||
-(Left.MatchingParen && Left.MatchingParen->is(TT_CastRParen)))
-   ? Style.SpacesInParensOptions.InCStyleCasts
-   : Style.SpacesInParensOptions.Other;
+if (Right.is(TT_CastRParen) ||
+(Left.MatchingParen && Left.MatchingParen->is(TT_CastRParen))) {
+  return Style.SpacesInParensOptions.InCStyleCasts;
+}
+if (Left.is(TT_AttributeParen) || Right.is(TT_AttributeParen) ||
+(Left.Previous && Left.Previous->is(TT_AttributeParen)) ||
+(Right.Next && Right.Next->is(TT_AttributeParen))) {
+  return Style.SpacesInParensOptions.InAttributeSpecifiers;
+}
+return Style.SpacesInParensOptions.Other;
   }
   if (Right.isOneOf(tok::semi, tok::comma))
 return false;
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -713,6 +713,7 @@
 
 template <> 

[PATCH] D155529: [clang-format] Add SpaceInParensOption for __attribute__ keyword

2023-07-19 Thread Gedare Bloom via Phabricator via cfe-commits
gedare updated this revision to Diff 542253.
gedare added a comment.

Rebase onto D155239 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155529

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/ConfigParseTest.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16718,6 +16718,7 @@
   Spaces.SpacesInParensOptions = {};
   Spaces.SpacesInParensOptions.Other = true;
   Spaces.SpacesInParensOptions.InConditionalStatements = true;
+  Spaces.SpacesInParensOptions.InAttributeSpecifiers = true;
   verifyFormat("do_something( ::globalVar );", Spaces);
   verifyFormat("call( x, y, z );", Spaces);
   verifyFormat("call();", Spaces);
@@ -16790,6 +16791,11 @@
   verifyFormat("SomeType *__attribute__((attr)) *a = NULL;", Spaces);
   verifyFormat("void __attribute__((naked)) foo(int bar)", Spaces);
 
+  Spaces.SpacesInParensOptions.InAttributeSpecifiers = true;
+  verifyFormat("SomeType *__attribute__( ( attr ) ) *a = NULL;", Spaces);
+  verifyFormat("void __attribute__( ( naked ) ) foo(int bar)", Spaces);
+  Spaces.SpacesInParensOptions.InAttributeSpecifiers = false;
+
   // Run the first set of tests again with:
   Spaces.SpaceAfterCStyleCast = true;
   verifyFormat("call(x, y, z);", Spaces);
@@ -16821,6 +16827,8 @@
   verifyFormat("bool *y = ( bool * ) ( void * ) (x);", Spaces);
   verifyFormat("bool *y = ( bool * ) (x);", Spaces);
   verifyFormat("throw ( int32 ) x;", Spaces);
+  verifyFormat("SomeType *__attribute__((attr)) *a = NULL;", Spaces);
+  verifyFormat("void __attribute__((naked)) foo(int bar)", Spaces);
 
   // Run subset of tests again with:
   Spaces.SpacesInParensOptions.InCStyleCasts = false;
Index: clang/unittests/Format/ConfigParseTest.cpp
===
--- clang/unittests/Format/ConfigParseTest.cpp
+++ clang/unittests/Format/ConfigParseTest.cpp
@@ -594,19 +594,23 @@
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
   CHECK_PARSE("SpacesInParentheses: true", SpacesInParensOptions,
-  FormatStyle::SpacesInParensCustom(true, false, false, true));
+  FormatStyle::SpacesInParensCustom(true, true, false, false,
+  true));
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
   CHECK_PARSE("SpacesInConditionalStatement: true", SpacesInParensOptions,
-  FormatStyle::SpacesInParensCustom(true, false, false, false));
+  FormatStyle::SpacesInParensCustom(false, true, false, false,
+  false));
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
   CHECK_PARSE("SpacesInCStyleCastParentheses: true", SpacesInParensOptions,
-  FormatStyle::SpacesInParensCustom(false, true, false, false));
+  FormatStyle::SpacesInParensCustom(false, false, true, false,
+  false));
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
   CHECK_PARSE("SpaceInEmptyParentheses: true", SpacesInParensOptions,
-  FormatStyle::SpacesInParensCustom(false, false, true, false));
+  FormatStyle::SpacesInParensCustom(false, false, false, true,
+  false));
   Style.SpacesInParens = FormatStyle::SIPO_Never;
   Style.SpacesInParensOptions = {};
 
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3810,10 +3810,16 @@
   }
 
   if (Left.is(tok::l_paren) || Right.is(tok::r_paren)) {
-return (Right.is(TT_CastRParen) ||
-(Left.MatchingParen && Left.MatchingParen->is(TT_CastRParen)))
-   ? Style.SpacesInParensOptions.InCStyleCasts
-   : Style.SpacesInParensOptions.Other;
+if (Right.is(TT_CastRParen) ||
+(Left.MatchingParen && Left.MatchingParen->is(TT_CastRParen))) {
+  return Style.SpacesInParensOptions.InCStyleCasts;
+}
+if (Left.is(TT_AttributeParen) || Right.is(TT_AttributeParen) ||
+(Left.Previous && Left.Previous->is(TT_AttributeParen)) ||
+(Right.Next && Right.Next->is(TT_AttributeParen))) {
+  return Style.SpacesInParensOptions.InAttributeSpecifiers;
+}
+return Style.SpacesInParensOptions.Other;
   }
   if (Right.isOneOf(tok::semi, tok::comma))
 return false;
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ 

[PATCH] D153092: [Clang][CodeGen]`vtable`, `typeinfo` et al. are globals

2023-07-19 Thread Bjorn Pettersson via Phabricator via cfe-commits
bjope added inline comments.



Comment at: clang/lib/CodeGen/CGVTables.cpp:693
 return Int32Ty;
-  return Int8PtrTy;
+  return GlobalsInt8PtrTy;
 }

I noticed that we have some old fixes downstream that conflicts with the 
changes you've made here. I thought that perhaps we could get rid of those now 
when you've fixed the code upstream.

Isn't the VTable holding function pointers when not using the relative layout, 
and then this should be a pointer to the ProgramAddressSpace and not a pointer 
to the DefaultGlobalsAddressSpace?

Downstream we've been using a special `FnVoidPtrTy` here. Defined as 
`FnVoidPtrTy = Int8Ty->getPointerTo(DL.getProgramAddressSpace());`.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153092

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


[PATCH] D144829: [BPF] Add a few new insns under cpu=v4

2023-07-19 Thread Alexei Starovoitov via Phabricator via cfe-commits
ast accepted this revision.
ast added a comment.

lgtm. @eddyz87 pls take a look


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144829

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


[PATCH] D155239: [clang-format] Add SpacesInParens with SpacesInParensOptions

2023-07-19 Thread Gedare Bloom via Phabricator via cfe-commits
gedare updated this revision to Diff 542249.
gedare added a comment.

Add config parse tests for deprecated options, and add tests for __attribute__


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155239

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/ConfigParseTest.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/FormatTestVerilog.cpp

Index: clang/unittests/Format/FormatTestVerilog.cpp
===
--- clang/unittests/Format/FormatTestVerilog.cpp
+++ clang/unittests/Format/FormatTestVerilog.cpp
@@ -807,7 +807,8 @@
"  if (x)\n"
"x = x;",
Style);
-  Style.SpacesInConditionalStatement = true;
+  Style.SpacesInParens = FormatStyle::SIPO_Custom;
+  Style.SpacesInParensOptions.InConditionalStatements = true;
   verifyFormat("if ( x )\n"
"  x = x;\n"
"else if ( x )\n"
@@ -903,7 +904,8 @@
   verifyFormat("repeat (x) begin\n"
"end");
   auto Style = getDefaultStyle();
-  Style.SpacesInConditionalStatement = true;
+  Style.SpacesInParens = FormatStyle::SIPO_Custom;
+  Style.SpacesInParensOptions.InConditionalStatements = true;
   verifyFormat("foreach ( x[x] )\n"
"  x = x;",
Style);
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11031,14 +11031,16 @@
   verifyFormat("template  void operator=(T) && {}", AlignMiddle);
 
   FormatStyle Spaces = getLLVMStyle();
-  Spaces.SpacesInCStyleCastParentheses = true;
+  Spaces.SpacesInParens = FormatStyle::SIPO_Custom;
+  Spaces.SpacesInParensOptions = {};
+  Spaces.SpacesInParensOptions.InCStyleCasts = true;
   verifyFormat("Deleted =(const Deleted &) & = default;", Spaces);
   verifyFormat("SomeType MemberFunction(const Deleted &) & = delete;", Spaces);
   verifyFormat("Deleted =(const Deleted &) &;", Spaces);
   verifyFormat("SomeType MemberFunction(const Deleted &) &;", Spaces);
 
-  Spaces.SpacesInCStyleCastParentheses = false;
-  Spaces.SpacesInParentheses = true;
+  Spaces.SpacesInParensOptions.InCStyleCasts = false;
+  Spaces.SpacesInParensOptions.Other = true;
   verifyFormat("Deleted =( const Deleted & ) & = default;", Spaces);
   verifyFormat("SomeType MemberFunction( const Deleted & ) & = delete;",
Spaces);
@@ -13674,7 +13676,8 @@
 
   FormatStyle SpaceBetweenBraces = getLLVMStyle();
   SpaceBetweenBraces.SpacesInAngles = FormatStyle::SIAS_Always;
-  SpaceBetweenBraces.SpacesInParentheses = true;
+  SpaceBetweenBraces.SpacesInParens = FormatStyle::SIPO_Custom;
+  SpaceBetweenBraces.SpacesInParensOptions.Other = true;
   SpaceBetweenBraces.SpacesInSquareBrackets = true;
   verifyFormat("vector< int > x{ 1, 2, 3, 4 };", SpaceBetweenBraces);
   verifyFormat("f( {}, { {}, {} }, MyMap[ { k, v } ] );", SpaceBetweenBraces);
@@ -13697,7 +13700,8 @@
 "};",
 format("vectorx{1,2,3,4,};", SpaceBetweenBraces));
   verifyFormat("vector< int > x{};", SpaceBetweenBraces);
-  SpaceBetweenBraces.SpaceInEmptyParentheses = true;
+  SpaceBetweenBraces.SpacesInParens = FormatStyle::SIPO_Custom;
+  SpaceBetweenBraces.SpacesInParensOptions.InEmptyParentheses = true;
   verifyFormat("vector< int > x{ };", SpaceBetweenBraces);
 }
 
@@ -16707,10 +16711,13 @@
   verifyFormat("! ! x", Spaces);
 }
 
-TEST_F(FormatTest, ConfigurableSpacesInParentheses) {
+TEST_F(FormatTest, ConfigurableSpacesInParens) {
   FormatStyle Spaces = getLLVMStyle();
 
-  Spaces.SpacesInParentheses = true;
+  Spaces.SpacesInParens = FormatStyle::SIPO_Custom;
+  Spaces.SpacesInParensOptions = {};
+  Spaces.SpacesInParensOptions.Other = true;
+  Spaces.SpacesInParensOptions.InConditionalStatements = true;
   verifyFormat("do_something( ::globalVar );", Spaces);
   verifyFormat("call( x, y, z );", Spaces);
   verifyFormat("call();", Spaces);
@@ -16737,9 +16744,12 @@
"  break;\n"
"}",
Spaces);
+  verifyFormat("SomeType *__attribute__( ( attr ) ) *a = NULL;", Spaces);
+  verifyFormat("void __attribute__( ( naked ) ) foo( int bar )", Spaces);
 
-  Spaces.SpacesInParentheses = false;
-  Spaces.SpacesInCStyleCastParentheses = true;
+  Spaces.SpacesInParens = FormatStyle::SIPO_Custom;
+  Spaces.SpacesInParensOptions = {};
+  Spaces.SpacesInParensOptions.InCStyleCasts = true;
   verifyFormat("Type *A = ( Type * )P;", Spaces);
   verifyFormat("Type *A = ( vector )P;", Spaces);
   verifyFormat("x = ( int32 )y;", Spaces);
@@ -16750,9 +16760,10 @@
   verifyFormat("#define x (( int )-1)", Spaces);
 
   // Run the first set of tests again with:
-  Spaces.SpacesInParentheses = 

[PATCH] D151587: [clang][ConstantEmitter] have tryEmitPrivate[ForVarInit] try ConstExprEmitter fast-path first

2023-07-19 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

This seems to work:

  diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
  index 25d3535e..98b1e4d 100644
  --- a/clang/lib/AST/Expr.cpp
  +++ b/clang/lib/AST/Expr.cpp
  @@ -3319,6 +3319,10 @@ bool Expr::isConstantInitializer(ASTContext , bool 
IsForRef,
 // kill the second parameter.
  
 if (IsForRef) {
  +if (auto *EWC = dyn_cast(this))
  +  return EWC->getSubExpr()->isConstantInitializer(Ctx, true, Culprit);
  +if (auto *MTE = dyn_cast(this))
  +  return MTE->getSubExpr()->isConstantInitializer(Ctx, false, Culprit);
   EvalResult Result;
   if (EvaluateAsLValue(Result, Ctx) && !Result.HasSideEffects)
 return true;
  diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
  index f0185d0..69b0d0d 100644
  --- a/clang/lib/AST/ExprConstant.cpp
  +++ b/clang/lib/AST/ExprConstant.cpp
  @@ -8381,6 +8381,9 @@ bool LValueExprEvaluator::VisitCallExpr(const CallExpr 
*E) {
  
   bool LValueExprEvaluator::VisitMaterializeTemporaryExpr(
   const MaterializeTemporaryExpr *E) {
  +  if (Info.EvalMode == EvalInfo::EM_ConstantFold)
  +return false;
  +
 // Walk through the expression to find the materialized temporary itself.
 SmallVector CommaLHSs;
 SmallVector Adjustments;
  @@ -8388,8 +8391,8 @@ bool LValueExprEvaluator::VisitMaterializeTemporaryExpr(
 E->getSubExpr()->skipRValueSubobjectAdjustments(CommaLHSs, 
Adjustments);
  
 // If we passed any comma operators, evaluate their LHSs.
  -  for (unsigned I = 0, N = CommaLHSs.size(); I != N; ++I)
  -if (!EvaluateIgnoredValue(Info, CommaLHSs[I]))
  +  for (const Expr *E : CommaLHSs)
  +if (!EvaluateIgnoredValue(Info, E))
 return false;
  
 // A materialized temporary with static storage duration can appear within 
the
  @@ -15472,7 +15475,7 @@ bool Expr::EvaluateAsInitializer(APValue , 
const ASTContext ,
 EStatus.Diag = 
  
 EvalInfo Info(Ctx, EStatus,
  -(IsConstantInitialization && Ctx.getLangOpts().CPlusPlus11)
  +(IsConstantInitialization && Ctx.getLangOpts().CPlusPlus)
   ? EvalInfo::EM_ConstantExpression
   : EvalInfo::EM_ConstantFold);
 Info.setEvaluatingDecl(VD, Value);


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151587

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


[PATCH] D144829: [WIP][BPF] Add a few new insns under cpu=v4

2023-07-19 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song updated this revision to Diff 542245.
yonghong-song added a comment.

- remove a copy-paste comment from s390 arch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144829

Files:
  clang/lib/Basic/Targets/BPF.cpp
  clang/lib/Basic/Targets/BPF.h
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/lib/Target/BPF/AsmParser/BPFAsmParser.cpp
  llvm/lib/Target/BPF/BPF.td
  llvm/lib/Target/BPF/BPFISelDAGToDAG.cpp
  llvm/lib/Target/BPF/BPFISelLowering.cpp
  llvm/lib/Target/BPF/BPFISelLowering.h
  llvm/lib/Target/BPF/BPFInstrFormats.td
  llvm/lib/Target/BPF/BPFInstrInfo.td
  llvm/lib/Target/BPF/BPFMIPeephole.cpp
  llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp
  llvm/lib/Target/BPF/BPFSubtarget.cpp
  llvm/lib/Target/BPF/BPFSubtarget.h
  llvm/lib/Target/BPF/Disassembler/BPFDisassembler.cpp
  llvm/lib/Target/BPF/MCTargetDesc/BPFAsmBackend.cpp
  llvm/lib/Target/BPF/MCTargetDesc/BPFInstPrinter.cpp
  llvm/lib/Target/BPF/MCTargetDesc/BPFMCCodeEmitter.cpp
  llvm/lib/Target/BPF/MCTargetDesc/BPFMCFixups.h
  llvm/lib/Target/BPF/MCTargetDesc/BPFMCTargetDesc.cpp
  llvm/test/CodeGen/BPF/bswap.ll
  llvm/test/CodeGen/BPF/ldsx.ll
  llvm/test/CodeGen/BPF/movsx.ll
  llvm/test/CodeGen/BPF/sdiv_smod.ll

Index: llvm/test/CodeGen/BPF/sdiv_smod.ll
===
--- /dev/null
+++ llvm/test/CodeGen/BPF/sdiv_smod.ll
@@ -0,0 +1,77 @@
+; RUN: llc -march=bpfel -mcpu=v4 -verify-machineinstrs -show-mc-encoding < %s | FileCheck %s
+; Source:
+;  int foo(int a, int b, int c) {
+;return a/b + a%c;
+;  }
+;  long bar(long a, long b, long c) {
+;   return a/b + a%c;
+; }
+; Compilation flags:
+;   clang -target bpf -O2 -S -emit-llvm -Xclang -disable-llvm-passes t.c
+
+; Function Attrs: nounwind
+define dso_local i32 @foo(i32 noundef %a, i32 noundef %b, i32 noundef %c) #0 {
+entry:
+  %a.addr = alloca i32, align 4
+  %b.addr = alloca i32, align 4
+  %c.addr = alloca i32, align 4
+  store i32 %a, ptr %a.addr, align 4, !tbaa !3
+  store i32 %b, ptr %b.addr, align 4, !tbaa !3
+  store i32 %c, ptr %c.addr, align 4, !tbaa !3
+  %0 = load i32, ptr %a.addr, align 4, !tbaa !3
+  %1 = load i32, ptr %b.addr, align 4, !tbaa !3
+  %div = sdiv i32 %0, %1
+  %2 = load i32, ptr %a.addr, align 4, !tbaa !3
+  %3 = load i32, ptr %c.addr, align 4, !tbaa !3
+  %rem = srem i32 %2, %3
+  %add = add nsw i32 %div, %rem
+  ret i32 %add
+}
+
+; CHECK:   w0 = w1
+; CHECK-NEXT:  *(u32 *)(r10 - 8) = w2
+; CHECK-NEXT:  *(u32 *)(r10 - 4) = w0
+; CHECK-NEXT:  *(u32 *)(r10 - 12) = w3
+; CHECK-NEXT:  w1 s%= w3  # encoding: [0x9c,0x31,0x01,0x00,0x00,0x00,0x00,0x00]
+; CHECK-NEXT:  w0 s/= w2  # encoding: [0x3c,0x20,0x01,0x00,0x00,0x00,0x00,0x00]
+
+; Function Attrs: nounwind
+define dso_local i64 @bar(i64 noundef %a, i64 noundef %b, i64 noundef %c) #0 {
+entry:
+  %a.addr = alloca i64, align 8
+  %b.addr = alloca i64, align 8
+  %c.addr = alloca i64, align 8
+  store i64 %a, ptr %a.addr, align 8, !tbaa !7
+  store i64 %b, ptr %b.addr, align 8, !tbaa !7
+  store i64 %c, ptr %c.addr, align 8, !tbaa !7
+  %0 = load i64, ptr %a.addr, align 8, !tbaa !7
+  %1 = load i64, ptr %b.addr, align 8, !tbaa !7
+  %div = sdiv i64 %0, %1
+  %2 = load i64, ptr %a.addr, align 8, !tbaa !7
+  %3 = load i64, ptr %c.addr, align 8, !tbaa !7
+  %rem = srem i64 %2, %3
+  %add = add nsw i64 %div, %rem
+  ret i64 %add
+}
+
+; CHECK:   r0 = r1
+; CHECK-NEXT:  *(u64 *)(r10 - 16) = r2
+; CHECK-NEXT:  *(u64 *)(r10 - 8) = r0
+; CHECK-NEXT:  *(u64 *)(r10 - 24) = r3
+; CHECK-NEXT:  r1 s%= r3  # encoding: [0x9f,0x31,0x01,0x00,0x00,0x00,0x00,0x00]
+; CHECK-NEXT:  r0 s/= r2  # encoding: [0x3f,0x20,0x01,0x00,0x00,0x00,0x00,0x00]
+
+attributes #0 = { nounwind "frame-pointer"="all" "no-trapping-math"="true" "stack-protector-buffer-size"="8" }
+
+!llvm.module.flags = !{!0, !1}
+!llvm.ident = !{!2}
+
+!0 = !{i32 1, !"wchar_size", i32 4}
+!1 = !{i32 7, !"frame-pointer", i32 2}
+!2 = !{!"clang version 17.0.0 (https://github.com/llvm/llvm-project.git 569bd3b841e3167ddd7c6ceeddb282d3c280e761)"}
+!3 = !{!4, !4, i64 0}
+!4 = !{!"int", !5, i64 0}
+!5 = !{!"omnipotent char", !6, i64 0}
+!6 = !{!"Simple C/C++ TBAA"}
+!7 = !{!8, !8, i64 0}
+!8 = !{!"long", !5, i64 0}
Index: llvm/test/CodeGen/BPF/movsx.ll
===
--- /dev/null
+++ llvm/test/CodeGen/BPF/movsx.ll
@@ -0,0 +1,79 @@
+; RUN: llc -march=bpfel -mcpu=v4 -verify-machineinstrs -show-mc-encoding < %s | FileCheck %s
+; Source:
+;   short f1(char a) {
+; return a;
+;   }
+;   int f2(char a) {
+; return a;
+;   }
+;   long f3(char a) {
+; return a;
+;   }
+;   int f4(short a) {
+; return a;
+;   }
+;   long f5(short a) {
+; return a;
+;   }
+;   long f6(int a) {
+; return a;
+;   }
+; Compilation flags:
+;   clang -target bpf -O2 -S -emit-llvm t.c
+
+; Function Attrs: mustprogress nofree norecurse nosync nounwind willreturn memory(none)

[PATCH] D155714: [clang] Fix diagnostics for defaulted, implicitly deleted 'operator=='.

2023-07-19 Thread Amirreza Ashouri via Phabricator via cfe-commits
AMP999 updated this revision to Diff 542240.
AMP999 added a comment.

Revised the formatting of the change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155714

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
  clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
  clang/test/CXX/class/class.compare/class.eq/p2.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p1.cpp


Index: clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
===
--- clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
+++ clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
@@ -80,7 +80,7 @@
   // expected-note@#base {{deleted comparison function for base class 'C'}}
   // expected-note@#base {{no viable three-way comparison function for base 
class 'D1'}}
   // expected-note@#base {{three-way comparison cannot be synthesized because 
there is no viable function for '<' comparison}}
-  // expected-note@#base {{no viable three-way comparison function for base 
class 'D2'}}
+  // expected-note@#base {{no viable 'operator==' for base class 'D2'}}
   // expected-note@#base {{three-way comparison cannot be synthesized because 
there is no viable function for '==' comparison}}
   // expected-note@#base {{deleted comparison function for base class 'E'}}
   // expected-note@#base {{implied comparison for base class 'F' is ambiguous}}
@@ -112,7 +112,7 @@
   // expected-note@#arr {{deleted comparison function for member 'arr'}}
   // expected-note@#arr {{no viable three-way comparison function for member 
'arr'}}
   // expected-note@#arr {{three-way comparison cannot be synthesized because 
there is no viable function for '<' comparison}}
-  // expected-note@#arr {{no viable three-way comparison function for member 
'arr'}}
+  // expected-note@#arr {{no viable 'operator==' for member 'arr'}}
   // expected-note@#arr {{three-way comparison cannot be synthesized because 
there is no viable function for '==' comparison}}
   // expected-note@#arr {{deleted comparison function for member 'arr'}}
   // expected-note@#arr {{implied comparison for member 'arr' is ambiguous}}
Index: clang/test/CXX/class/class.compare/class.eq/p2.cpp
===
--- clang/test/CXX/class/class.compare/class.eq/p2.cpp
+++ clang/test/CXX/class/class.compare/class.eq/p2.cpp
@@ -37,7 +37,7 @@
 template struct X {
   X();
   bool operator==(const X&) const = default; // #x expected-note 4{{deleted 
here}}
-  T t; // expected-note 3{{because there is no viable three-way comparison 
function for member 't'}}
+  T t; // expected-note 3{{because there is no viable 'operator==' for member 
't'}}
// expected-note@-1 {{because it would invoke a deleted comparison 
function for member 't'}}
 };
 
Index: clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
===
--- clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
+++ clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
@@ -5,6 +5,14 @@
   // expected-note@-1 {{defaulted 'operator!=' is implicitly deleted because 
there is no viable 'operator==' for 'A'}}
 };
 
+struct A2 {
+  struct E {};
+  E e;
+  bool operator==(const A2&) const = default; // expected-warning {{explicitly 
defaulted equality comparison operator is implicitly deleted}} 
expected-note{{replace 'default'}}
+  // expected-note@-2 {{defaulted 'operator==' is implicitly deleted because 
there is no viable 'operator==' for member 'e'}}
+};
+
+
 struct Q {};
 bool operator!=(Q, Q); // expected-note {{defaulted 'operator!=' is implicitly 
deleted because this non-rewritten comparison function would be the best match 
for the comparison}}
 struct B {
Index: clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
===
--- clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
+++ clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
@@ -100,7 +100,7 @@
   struct Q {
 struct X {
   friend std::strong_ordering operator<=>(const X&, const X&);
-} x; // expected-note {{no viable three-way comparison}}
+} x; // expected-note {{no viable 'operator=='}}
 // expected-error@+1 {{defaulting the corresponding implicit 'operator==' 
for this defaulted 'operator<=>' would delete it after its first declaration}}
 friend std::strong_ordering operator<=>(const Q&, const Q&) = default;
   };
Index: clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
===
--- clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
+++ 

[PATCH] D155759: [Clang][CodeGen] Follow-up for `vtable`, `typeinfo` et al. are globals

2023-07-19 Thread Alex Voicu via 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 rGf385abf131e0: [Clang][CodeGen] Follow-up for `vtable`, 
`typeinfo` et al. are globals (authored by AlexVlx).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155759

Files:
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp


Index: clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 %s -triple amdgcn-amd-amdhsa -emit-llvm -fcxx-exceptions 
-fexceptions -std=c++11 -o - | FileCheck %s
+
+struct X {
+  ~X();
+};
+
+struct Error {
+  Error(const X&) noexcept;
+};
+
+void f() {
+  try {
+throw Error(X());
+  } catch (...) { }
+}
+
+// CHECK: declare void @__cxa_throw(ptr, ptr addrspace(1), ptr)
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -1252,7 +1252,7 @@
   // void __cxa_throw(void *thrown_exception, std::type_info *tinfo,
   //  void (*dest) (void *));
 
-  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.Int8PtrTy, CGM.Int8PtrTy };
+  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.GlobalsInt8PtrTy, CGM.Int8PtrTy };
   llvm::FunctionType *FTy =
 llvm::FunctionType::get(CGM.VoidTy, Args, /*isVarArg=*/false);
 


Index: clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 %s -triple amdgcn-amd-amdhsa -emit-llvm -fcxx-exceptions -fexceptions -std=c++11 -o - | FileCheck %s
+
+struct X {
+  ~X();
+};
+
+struct Error {
+  Error(const X&) noexcept;
+};
+
+void f() {
+  try {
+throw Error(X());
+  } catch (...) { }
+}
+
+// CHECK: declare void @__cxa_throw(ptr, ptr addrspace(1), ptr)
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -1252,7 +1252,7 @@
   // void __cxa_throw(void *thrown_exception, std::type_info *tinfo,
   //  void (*dest) (void *));
 
-  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.Int8PtrTy, CGM.Int8PtrTy };
+  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.GlobalsInt8PtrTy, CGM.Int8PtrTy };
   llvm::FunctionType *FTy =
 llvm::FunctionType::get(CGM.VoidTy, Args, /*isVarArg=*/false);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] f385abf - [Clang][CodeGen] Follow-up for `vtable`, `typeinfo` et al. are globals

2023-07-19 Thread Alex Voicu via cfe-commits

Author: Alex Voicu
Date: 2023-07-19T23:57:12+01:00
New Revision: f385abf131e01b12b14ac3bc7214eb119b40523e

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

LOG: [Clang][CodeGen] Follow-up for `vtable`, `typeinfo` et al. are globals

https://reviews.llvm.org/rG8acdcf4016876d122733991561be706b64026e73 didn't 
include handling for the fact that `throw`'s implementation takes a pointer to 
a type's `typeinfo` struct, which implies that its signature needs to change as 
well. This corrects that and adds a test.

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D155759

Added: 
clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp

Modified: 
clang/lib/CodeGen/ItaniumCXXABI.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/ItaniumCXXABI.cpp 
b/clang/lib/CodeGen/ItaniumCXXABI.cpp
index 16e53c466424ab..8870383f8d663c 100644
--- a/clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ b/clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -1252,7 +1252,7 @@ static llvm::FunctionCallee getThrowFn(CodeGenModule 
) {
   // void __cxa_throw(void *thrown_exception, std::type_info *tinfo,
   //  void (*dest) (void *));
 
-  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.Int8PtrTy, CGM.Int8PtrTy };
+  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.GlobalsInt8PtrTy, CGM.Int8PtrTy };
   llvm::FunctionType *FTy =
 llvm::FunctionType::get(CGM.VoidTy, Args, /*isVarArg=*/false);
 

diff  --git 
a/clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp 
b/clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
new file mode 100644
index 00..d8c23d427e67a3
--- /dev/null
+++ b/clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 %s -triple amdgcn-amd-amdhsa -emit-llvm -fcxx-exceptions 
-fexceptions -std=c++11 -o - | FileCheck %s
+
+struct X {
+  ~X();
+};
+
+struct Error {
+  Error(const X&) noexcept;
+};
+
+void f() {
+  try {
+throw Error(X());
+  } catch (...) { }
+}
+
+// CHECK: declare void @__cxa_throw(ptr, ptr addrspace(1), ptr)



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


[PATCH] D154324: [C++20] [Modules] [ODRHash] Use CanonicalType for base classes

2023-07-19 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

Hi, we've started seeing compilation errors with our modularized build after 
this commit. The errors say `'SomeType' has different definitions in different 
modules`, but then point to the same definition that comes from the same 
textual header included into two modules.

The setup (which I couldn't completely isolate yet) is roughly similar to this 
(hopefully, I didn't miss any important parts):

Textual header p.h:

  #include 
  
  #include "protobuf/generated_enum_util.h"
  ...
  
  template ::value>::type>
  class SomeType : E> {
  ...
  };

Textual header a.h:

  #include 
  
  #include "protobuf/generated_enum_util.h"
  
  namespace q {
  template ::value>::type>
  class X {};
  }
  
  #include "p.h"

Textual header b.h:

  // ...
  // something likely unrelated
  // ...
  #include "p.h"

Module C, c.h:

  #include "a.h"
  #include "b.h"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154324

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


[PATCH] D152914: [Draft] Make __builtin_cpu builtins target-independent

2023-07-19 Thread Pavel Iliin via Phabricator via cfe-commits
ilinpv added a comment.

In D152914#4497599 , @nemanjai wrote:

> I took a quick look at your patch. I think it would be preferable to make the 
> builtins target-independent rather than implementing the builtin by the same 
> name for multiple targets. Although I think it is very useful to support a 
> plus-separated list for `__builtin_cpu_supports()`, I think that's probably 
> something for a subsequent patch. We would need to figure out code generation 
> for that - perhaps that part will have to be completely target specific.

I fully agree with you to make  `__builtin_cpu_supports()` target-independent ( 
and I will update my patch on top of yours ). If plus-separated format is not 
supported by all target then I would suggest to make SemaBuiltinCpuSupports 
target-dependent - it will allow me to imlement plus-separated format on 
AArch64 keeping  `__builtin_cpu_supports()` target-independent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152914

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


[clang] 990645f - Revert "[OptTable] Make explicitly included options override excluded ones"

2023-07-19 Thread Justin Bogner via cfe-commits

Author: Justin Bogner
Date: 2023-07-19T15:43:50-07:00
New Revision: 990645f949c7ede7467b93294bbddbe4661513f1

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

LOG: Revert "[OptTable] Make explicitly included options override excluded ones"

Looks like a couple of flang bots are broken by this change. Reverting
to investigate.

This reverts commit b2eda85f047f27788ccd7b9af9bd59c5d44b2051.

Added: 


Modified: 
clang-tools-extra/clangd/CompileCommands.cpp
clang/include/clang/Driver/Options.h
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
llvm/lib/Option/OptTable.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CompileCommands.cpp 
b/clang-tools-extra/clangd/CompileCommands.cpp
index 80d90ff27648e3..957a6f873e1022 100644
--- a/clang-tools-extra/clangd/CompileCommands.cpp
+++ b/clang-tools-extra/clangd/CompileCommands.cpp
@@ -238,10 +238,13 @@ void CommandMangler::operator()(tooling::CompileCommand 
,
   ArgList = OptTable.ParseArgs(
   llvm::ArrayRef(OriginalArgs).drop_front(), IgnoredCount, IgnoredCount,
   /*FlagsToInclude=*/
-  IsCLMode ? (driver::options::CLOption | driver::options::CoreOption)
+  IsCLMode ? (driver::options::CLOption | driver::options::CoreOption |
+  driver::options::CLDXCOption)
: /*everything*/ 0,
   /*FlagsToExclude=*/driver::options::NoDriverOption |
-  (IsCLMode ? 0 : driver::options::CLOption));
+  (IsCLMode
+   ? 0
+   : (driver::options::CLOption | driver::options::CLDXCOption)));
 
   llvm::SmallVector IndicesToDrop;
   // Having multiple architecture options (e.g. when building fat binaries)
@@ -446,6 +449,8 @@ unsigned char getModes(const llvm::opt::Option ) {
   if (!Opt.hasFlag(driver::options::NoDriverOption)) {
 if (Opt.hasFlag(driver::options::CLOption)) {
   Result |= DM_CL;
+} else if (Opt.hasFlag(driver::options::CLDXCOption)) {
+  Result |= DM_CL;
 } else {
   Result |= DM_GCC;
   if (Opt.hasFlag(driver::options::CoreOption)) {

diff  --git a/clang/include/clang/Driver/Options.h 
b/clang/include/clang/Driver/Options.h
index 58f5df132feca8..54c6f5faa37c22 100644
--- a/clang/include/clang/Driver/Options.h
+++ b/clang/include/clang/Driver/Options.h
@@ -36,8 +36,9 @@ enum ClangFlags {
   FC1Option = (1 << 15),
   FlangOnlyOption = (1 << 16),
   DXCOption = (1 << 17),
-  Ignored = (1 << 18),
-  TargetSpecific = (1 << 19),
+  CLDXCOption = (1 << 18),
+  Ignored = (1 << 19),
+  TargetSpecific = (1 << 20),
 };
 
 enum ID {

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 90fa3c6dabdde4..8ffb9388d330f0 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -53,6 +53,10 @@ def CC1AsOption : OptionFlag;
 // are made available when the driver is running in DXC compatibility mode.
 def DXCOption : OptionFlag;
 
+// CLDXCOption - This is a cl.exe/dxc.exe compatibility option. Options with 
this flag
+// are made available when the driver is running in CL/DXC compatibility mode.
+def CLDXCOption : OptionFlag;
+
 // NoDriverOption - This option should not be accepted by the driver.
 def NoDriverOption : OptionFlag;
 
@@ -6852,7 +6856,7 @@ def defsym : Separate<["-"], "defsym">,
 // clang-cl Options
 
//===--===//
 
-def cl_Group : OptionGroup<"">,
+def cl_Group : OptionGroup<"">, Flags<[CLDXCOption]>,
   HelpText<"CL.EXE COMPATIBILITY OPTIONS">;
 
 def cl_compile_Group : OptionGroup<"">,
@@ -6861,45 +6865,42 @@ def cl_compile_Group : OptionGroup<"">,
 def cl_ignored_Group : OptionGroup<"">,
   Group;
 
-class CLFlagOpts flags>
-  : Flags;
+class CLFlag : Option<["/", "-"], name, KIND_FLAG>,
+  Group, Flags<[CLOption, NoXarchOption]>;
+
+class CLDXCFlag : Option<["/", "-"], name, KIND_FLAG>,
+  Group, Flags<[CLDXCOption, NoXarchOption]>;
+
+class CLCompileFlag : Option<["/", "-"], name, KIND_FLAG>,
+  Group, Flags<[CLOption, NoXarchOption]>;
 
-class CLFlag flags = [CLOption]>
-  : Option<["/", "-"], name, KIND_FLAG>,
-Group, CLFlagOpts;
+class CLIgnoredFlag : Option<["/", "-"], name, KIND_FLAG>,
+  Group, Flags<[CLOption, NoXarchOption]>;
 
-class CLCompileFlag flags = [CLOption]>
-  : Option<["/", "-"], name, KIND_FLAG>,
-Group, CLFlagOpts;
+class CLJoined : Option<["/", "-"], name, KIND_JOINED>,
+  Group, Flags<[CLOption, NoXarchOption]>;
 
-class CLIgnoredFlag flags = [CLOption]>
-  : Option<["/", "-"], name, KIND_FLAG>,
-Group, CLFlagOpts;
+class CLDXCJoined : Option<["/", "-"], name, KIND_JOINED>,
+  Group, Flags<[CLDXCOption, NoXarchOption]>;
 
-class 

[PATCH] D155729: [OptTable] Make explicitly included options override excluded ones

2023-07-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

Thank you! The clean up is nice. I missed the original change that added the 
DXCOption complexity..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155729

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


[PATCH] D155729: [OptTable] Make explicitly included options override excluded ones

2023-07-19 Thread Justin Bogner via 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 rGb2eda85f047f: [OptTable] Make explicitly included options 
override excluded ones (authored by bogner).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155729

Files:
  clang-tools-extra/clangd/CompileCommands.cpp
  clang/include/clang/Driver/Options.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
  llvm/lib/Option/OptTable.cpp

Index: llvm/lib/Option/OptTable.cpp
===
--- llvm/lib/Option/OptTable.cpp
+++ llvm/lib/Option/OptTable.cpp
@@ -421,7 +421,8 @@
 if (FlagsToInclude && !Opt.hasFlag(FlagsToInclude))
   continue;
 if (Opt.hasFlag(FlagsToExclude))
-  continue;
+  if (!FlagsToInclude || !Opt.hasFlag(FlagsToInclude))
+continue;
 
 // See if this option matches.
 if (std::unique_ptr A =
@@ -650,7 +651,8 @@
 if (FlagsToInclude && !(Flags & FlagsToInclude))
   continue;
 if (Flags & FlagsToExclude)
-  continue;
+  if (!FlagsToInclude || !(Flags & FlagsToInclude))
+continue;
 
 // If an alias doesn't have a help text, show a help text for the aliased
 // option instead.
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -164,8 +164,8 @@
   const unsigned OldPos = Pos;
   std::unique_ptr Arg(OptTable.ParseOneArg(
   ArgList, Pos,
-  /* Include */ ClangCLMode ? CoreOption | CLOption | CLDXCOption : 0,
-  /* Exclude */ ClangCLMode ? 0 : CLOption | CLDXCOption));
+  /* Include */ ClangCLMode ? CoreOption | CLOption : 0,
+  /* Exclude */ ClangCLMode ? 0 : CLOption));
 
   if (!Arg)
 continue;
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -6496,7 +6496,6 @@
   if (IsClCompatMode) {
 // Include CL and Core options.
 IncludedFlagsBitmask |= options::CLOption;
-IncludedFlagsBitmask |= options::CLDXCOption;
 IncludedFlagsBitmask |= options::CoreOption;
   } else {
 ExcludedFlagsBitmask |= options::CLOption;
@@ -6504,13 +6503,10 @@
   if (IsDXCMode()) {
 // Include DXC and Core options.
 IncludedFlagsBitmask |= options::DXCOption;
-IncludedFlagsBitmask |= options::CLDXCOption;
 IncludedFlagsBitmask |= options::CoreOption;
   } else {
 ExcludedFlagsBitmask |= options::DXCOption;
   }
-  if (!IsClCompatMode && !IsDXCMode())
-ExcludedFlagsBitmask |= options::CLDXCOption;
 
   return std::make_pair(IncludedFlagsBitmask, ExcludedFlagsBitmask);
 }
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -53,10 +53,6 @@
 // are made available when the driver is running in DXC compatibility mode.
 def DXCOption : OptionFlag;
 
-// CLDXCOption - This is a cl.exe/dxc.exe compatibility option. Options with this flag
-// are made available when the driver is running in CL/DXC compatibility mode.
-def CLDXCOption : OptionFlag;
-
 // NoDriverOption - This option should not be accepted by the driver.
 def NoDriverOption : OptionFlag;
 
@@ -6856,7 +6852,7 @@
 // clang-cl Options
 //===--===//
 
-def cl_Group : OptionGroup<"">, Flags<[CLDXCOption]>,
+def cl_Group : OptionGroup<"">,
   HelpText<"CL.EXE COMPATIBILITY OPTIONS">;
 
 def cl_compile_Group : OptionGroup<"">,
@@ -6865,42 +6861,45 @@
 def cl_ignored_Group : OptionGroup<"">,
   Group;
 
-class CLFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
-
-class CLDXCFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLDXCOption, NoXarchOption]>;
-
-class CLCompileFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
+class CLFlagOpts flags>
+  : Flags;
 
-class CLIgnoredFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
+class CLFlag flags = [CLOption]>
+  : Option<["/", "-"], name, KIND_FLAG>,
+Group, CLFlagOpts;
 
-class CLJoined : Option<["/", "-"], name, KIND_JOINED>,
-  Group, Flags<[CLOption, NoXarchOption]>;
+class CLCompileFlag flags = [CLOption]>
+  : Option<["/", "-"], name, KIND_FLAG>,
+Group, CLFlagOpts;
 
-class CLDXCJoined : Option<["/", "-"], name, KIND_JOINED>,
-  Group, Flags<[CLDXCOption, NoXarchOption]>;
+class CLIgnoredFlag flags = [CLOption]>
+  : Option<["/", "-"], name, 

[clang] b2eda85 - [OptTable] Make explicitly included options override excluded ones

2023-07-19 Thread Justin Bogner via cfe-commits

Author: Justin Bogner
Date: 2023-07-19T15:28:34-07:00
New Revision: b2eda85f047f27788ccd7b9af9bd59c5d44b2051

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

LOG: [OptTable] Make explicitly included options override excluded ones

When we have both explicitly included and excluded option sets, we
were excluding anything from the latter set regardless of what was in
the former. This doesn't compose well and led to an overly complicated
design around DXC options where a third flag was introduced to handle
options that overlapped between DXC and CL.

With this change we check the included options before excluding
anything from the exclude list, which allows for options that are in
multiple categories to be handled in a sensible way. This allows us to
remove CLDXCOption but should otherwise be NFC.

Differential Revision: https://reviews.llvm.org/D155729

Added: 


Modified: 
clang-tools-extra/clangd/CompileCommands.cpp
clang/include/clang/Driver/Options.h
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
llvm/lib/Option/OptTable.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CompileCommands.cpp 
b/clang-tools-extra/clangd/CompileCommands.cpp
index 957a6f873e1022..80d90ff27648e3 100644
--- a/clang-tools-extra/clangd/CompileCommands.cpp
+++ b/clang-tools-extra/clangd/CompileCommands.cpp
@@ -238,13 +238,10 @@ void CommandMangler::operator()(tooling::CompileCommand 
,
   ArgList = OptTable.ParseArgs(
   llvm::ArrayRef(OriginalArgs).drop_front(), IgnoredCount, IgnoredCount,
   /*FlagsToInclude=*/
-  IsCLMode ? (driver::options::CLOption | driver::options::CoreOption |
-  driver::options::CLDXCOption)
+  IsCLMode ? (driver::options::CLOption | driver::options::CoreOption)
: /*everything*/ 0,
   /*FlagsToExclude=*/driver::options::NoDriverOption |
-  (IsCLMode
-   ? 0
-   : (driver::options::CLOption | driver::options::CLDXCOption)));
+  (IsCLMode ? 0 : driver::options::CLOption));
 
   llvm::SmallVector IndicesToDrop;
   // Having multiple architecture options (e.g. when building fat binaries)
@@ -449,8 +446,6 @@ unsigned char getModes(const llvm::opt::Option ) {
   if (!Opt.hasFlag(driver::options::NoDriverOption)) {
 if (Opt.hasFlag(driver::options::CLOption)) {
   Result |= DM_CL;
-} else if (Opt.hasFlag(driver::options::CLDXCOption)) {
-  Result |= DM_CL;
 } else {
   Result |= DM_GCC;
   if (Opt.hasFlag(driver::options::CoreOption)) {

diff  --git a/clang/include/clang/Driver/Options.h 
b/clang/include/clang/Driver/Options.h
index 54c6f5faa37c22..58f5df132feca8 100644
--- a/clang/include/clang/Driver/Options.h
+++ b/clang/include/clang/Driver/Options.h
@@ -36,9 +36,8 @@ enum ClangFlags {
   FC1Option = (1 << 15),
   FlangOnlyOption = (1 << 16),
   DXCOption = (1 << 17),
-  CLDXCOption = (1 << 18),
-  Ignored = (1 << 19),
-  TargetSpecific = (1 << 20),
+  Ignored = (1 << 18),
+  TargetSpecific = (1 << 19),
 };
 
 enum ID {

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8ffb9388d330f0..90fa3c6dabdde4 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -53,10 +53,6 @@ def CC1AsOption : OptionFlag;
 // are made available when the driver is running in DXC compatibility mode.
 def DXCOption : OptionFlag;
 
-// CLDXCOption - This is a cl.exe/dxc.exe compatibility option. Options with 
this flag
-// are made available when the driver is running in CL/DXC compatibility mode.
-def CLDXCOption : OptionFlag;
-
 // NoDriverOption - This option should not be accepted by the driver.
 def NoDriverOption : OptionFlag;
 
@@ -6856,7 +6852,7 @@ def defsym : Separate<["-"], "defsym">,
 // clang-cl Options
 
//===--===//
 
-def cl_Group : OptionGroup<"">, Flags<[CLDXCOption]>,
+def cl_Group : OptionGroup<"">,
   HelpText<"CL.EXE COMPATIBILITY OPTIONS">;
 
 def cl_compile_Group : OptionGroup<"">,
@@ -6865,42 +6861,45 @@ def cl_compile_Group : OptionGroup<"">,
 def cl_ignored_Group : OptionGroup<"">,
   Group;
 
-class CLFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
-
-class CLDXCFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLDXCOption, NoXarchOption]>;
-
-class CLCompileFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
+class CLFlagOpts flags>
+  : Flags;
 
-class CLIgnoredFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
+class CLFlag flags = [CLOption]>
+  : Option<["/", "-"], name, 

[clang-tools-extra] b2eda85 - [OptTable] Make explicitly included options override excluded ones

2023-07-19 Thread Justin Bogner via cfe-commits

Author: Justin Bogner
Date: 2023-07-19T15:28:34-07:00
New Revision: b2eda85f047f27788ccd7b9af9bd59c5d44b2051

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

LOG: [OptTable] Make explicitly included options override excluded ones

When we have both explicitly included and excluded option sets, we
were excluding anything from the latter set regardless of what was in
the former. This doesn't compose well and led to an overly complicated
design around DXC options where a third flag was introduced to handle
options that overlapped between DXC and CL.

With this change we check the included options before excluding
anything from the exclude list, which allows for options that are in
multiple categories to be handled in a sensible way. This allows us to
remove CLDXCOption but should otherwise be NFC.

Differential Revision: https://reviews.llvm.org/D155729

Added: 


Modified: 
clang-tools-extra/clangd/CompileCommands.cpp
clang/include/clang/Driver/Options.h
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
llvm/lib/Option/OptTable.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CompileCommands.cpp 
b/clang-tools-extra/clangd/CompileCommands.cpp
index 957a6f873e1022..80d90ff27648e3 100644
--- a/clang-tools-extra/clangd/CompileCommands.cpp
+++ b/clang-tools-extra/clangd/CompileCommands.cpp
@@ -238,13 +238,10 @@ void CommandMangler::operator()(tooling::CompileCommand 
,
   ArgList = OptTable.ParseArgs(
   llvm::ArrayRef(OriginalArgs).drop_front(), IgnoredCount, IgnoredCount,
   /*FlagsToInclude=*/
-  IsCLMode ? (driver::options::CLOption | driver::options::CoreOption |
-  driver::options::CLDXCOption)
+  IsCLMode ? (driver::options::CLOption | driver::options::CoreOption)
: /*everything*/ 0,
   /*FlagsToExclude=*/driver::options::NoDriverOption |
-  (IsCLMode
-   ? 0
-   : (driver::options::CLOption | driver::options::CLDXCOption)));
+  (IsCLMode ? 0 : driver::options::CLOption));
 
   llvm::SmallVector IndicesToDrop;
   // Having multiple architecture options (e.g. when building fat binaries)
@@ -449,8 +446,6 @@ unsigned char getModes(const llvm::opt::Option ) {
   if (!Opt.hasFlag(driver::options::NoDriverOption)) {
 if (Opt.hasFlag(driver::options::CLOption)) {
   Result |= DM_CL;
-} else if (Opt.hasFlag(driver::options::CLDXCOption)) {
-  Result |= DM_CL;
 } else {
   Result |= DM_GCC;
   if (Opt.hasFlag(driver::options::CoreOption)) {

diff  --git a/clang/include/clang/Driver/Options.h 
b/clang/include/clang/Driver/Options.h
index 54c6f5faa37c22..58f5df132feca8 100644
--- a/clang/include/clang/Driver/Options.h
+++ b/clang/include/clang/Driver/Options.h
@@ -36,9 +36,8 @@ enum ClangFlags {
   FC1Option = (1 << 15),
   FlangOnlyOption = (1 << 16),
   DXCOption = (1 << 17),
-  CLDXCOption = (1 << 18),
-  Ignored = (1 << 19),
-  TargetSpecific = (1 << 20),
+  Ignored = (1 << 18),
+  TargetSpecific = (1 << 19),
 };
 
 enum ID {

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8ffb9388d330f0..90fa3c6dabdde4 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -53,10 +53,6 @@ def CC1AsOption : OptionFlag;
 // are made available when the driver is running in DXC compatibility mode.
 def DXCOption : OptionFlag;
 
-// CLDXCOption - This is a cl.exe/dxc.exe compatibility option. Options with 
this flag
-// are made available when the driver is running in CL/DXC compatibility mode.
-def CLDXCOption : OptionFlag;
-
 // NoDriverOption - This option should not be accepted by the driver.
 def NoDriverOption : OptionFlag;
 
@@ -6856,7 +6852,7 @@ def defsym : Separate<["-"], "defsym">,
 // clang-cl Options
 
//===--===//
 
-def cl_Group : OptionGroup<"">, Flags<[CLDXCOption]>,
+def cl_Group : OptionGroup<"">,
   HelpText<"CL.EXE COMPATIBILITY OPTIONS">;
 
 def cl_compile_Group : OptionGroup<"">,
@@ -6865,42 +6861,45 @@ def cl_compile_Group : OptionGroup<"">,
 def cl_ignored_Group : OptionGroup<"">,
   Group;
 
-class CLFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
-
-class CLDXCFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLDXCOption, NoXarchOption]>;
-
-class CLCompileFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
+class CLFlagOpts flags>
+  : Flags;
 
-class CLIgnoredFlag : Option<["/", "-"], name, KIND_FLAG>,
-  Group, Flags<[CLOption, NoXarchOption]>;
+class CLFlag flags = [CLOption]>
+  : Option<["/", "-"], name, 

[PATCH] D154658: Optimize emission of `dynamic_cast` to final classes.

2023-07-19 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

LGTM, except, should we have a way to turn this optimization off specifically?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154658

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


[PATCH] D153914: [clang-cl] Enable concatenation of predefined identifiers

2023-07-19 Thread Richard Dzenis via Phabricator via cfe-commits
RIscRIpt added inline comments.



Comment at: clang/include/clang/Basic/TokenKinds.h:87-93
+/// Return true if this token is a predefined macro
+/// unexpandable by MSVC preprocessor.
+inline bool isUnexpandableMsMacro(TokenKind K) {
+  return K == tok::kw___FUNCTION__ || K == tok::kw___FUNCSIG__ ||
+ K == tok::kw_L__FUNCTION__ || K == tok::kw_L__FUNCSIG__ ||
+ K == tok::kw___FUNCDNAME__;
+}

tahonermann wrote:
> cor3ntin wrote:
> > tahonermann wrote:
> > > RIscRIpt wrote:
> > > > tahonermann wrote:
> > > > > 
> > > > Thanks, I like the name. But shouldn't we reflect that we are referring 
> > > > to only Microsoft (unexpandable) macros? How about 
> > > > `isFunctionLocalPredefinedMsMacro`?
> > > I don't think the Microsoft association is meaningful. Sure, some of the 
> > > predefined macros are only treated differently when compiling in 
> > > Microsoft mode, but some of those macros aren't Microsoft specific. Also, 
> > > there might be macros provided by other implementations that we'll want 
> > > to emulate some day.
> > I think it is, there is currently no way to link 
> > `isFunctionLocalPredefinedMacro` to the MS feature. "MSPredefinedMacro" is 
> > pretty self explanatory, same reason we most often - but not always - use 
> > GNU in the name of function related to GNU extensions.
> > There are enough similar-sounding features and extensions that we should 
> > try to make it clear which feature we are talking about.
> Perhaps we still haven't found the right name then. With the name that I've 
> been advocating, this function should also return true for 
> `tok::kw___PRETTY_FUNCTION__` even though that macro should not expand to 
> something that can be concatenated with other string literals (whether 
> compiling in Microsoft mode or not).
> 
> The Microsoft extension is the localized expansion to a string literal that 
> can be concatenated with other string literals. We probably should isolate 
> the conditions for that behavior to one place and if we do that, then I guess 
> naming this function as specific to Microsoft mode is ok; we can always 
> rename it later if it gets used for non-Microsoft extensions.
> 
> Here is my suggestion then:
>   // Return true if the token corresponds to a function local predefined
>   // macro that, in Microsoft modes, expands to a string literal (that can
>   // then be concatenated with other string literals).
>   inline bool isMsFunctionLocalStringLiteralMacro(TokenKind K, const 
> LangOptions ) {
> return langOpts.MicrosoftExt && (
> K == tok::kw___FUNCTION__ || K == tok::kw_L__FUNCTION__ ||
> K == tok::kw___FUNCSIG__ || K == tok::kw_L__FUNCSIG__ ||
> K == tok::kw___FUNCDNAME__);
>   }  
> 
> This will avoid the need for callers to check for `MicrosoftExt`; that is 
> what I really want to avoid since it is easy to forget to do that check.
1. By requiring user to pass `LangOptions` I think we can remove MS association 
(implying that there could be other non-msft cases in the future)
2. We would have to include a `LangOptions.h` in `TokenKinds.h`, are we ok with 
this? Alternatively while this function is for msft cases only, we could pass 
`bool MicrosoftExt`

Personally, I like version with `LangOptions` and removal of `MS`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153914

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


[clang] aa972f6 - -fsanitize=function, MicrosoftMangle: Switch to xxh3_64bits

2023-07-19 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2023-07-19T15:20:50-07:00
New Revision: aa972f607c55cdbab3b9182aacb3ed6a5d9e73e1

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

LOG: -fsanitize=function,MicrosoftMangle: Switch to xxh3_64bits

Following recent changes switching from xxh64 to xxh32 for better
hashing performance (e.g., D154813). These particular instances likely
have negligible time, but this change moves us toward removing xxHash64.

The type hash for -fsanitize=function will change, following a recent
change D148785 (not in any release yet) to the type hash scheme, though
sanitizers don't sign up for cross-version compatibility anyway.

The MicrosoftMangle instance is for internal symbols that need no
compatibility guarantee, as emphasized by the comment.

Added: 


Modified: 
clang/lib/AST/MicrosoftMangle.cpp
clang/lib/CodeGen/CodeGenFunction.cpp
clang/test/CodeGen/ubsan-function.cpp
clang/test/CodeGenCXX/catch-undef-behavior.cpp

Removed: 




diff  --git a/clang/lib/AST/MicrosoftMangle.cpp 
b/clang/lib/AST/MicrosoftMangle.cpp
index 430a57d7b4ec01..3306d90dc85664 100644
--- a/clang/lib/AST/MicrosoftMangle.cpp
+++ b/clang/lib/AST/MicrosoftMangle.cpp
@@ -485,7 +485,7 @@ 
MicrosoftMangleContextImpl::MicrosoftMangleContextImpl(ASTContext ,
   SourceManager  = Context.getSourceManager();
   if (const FileEntry *FE = SM.getFileEntryForID(SM.getMainFileID())) {
 // Truncate the hash so we get 8 characters of hexadecimal.
-uint32_t TruncatedHash = uint32_t(xxHash64(FE->getName()));
+uint32_t TruncatedHash = uint32_t(xxh3_64bits(FE->getName()));
 AnonymousNamespaceHash = llvm::utohexstr(TruncatedHash);
   } else {
 // If we don't have a path to the main file, we'll just use 0.

diff  --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
b/clang/lib/CodeGen/CodeGenFunction.cpp
index b8d39371a93308..fab70b66d1d965 100644
--- a/clang/lib/CodeGen/CodeGenFunction.cpp
+++ b/clang/lib/CodeGen/CodeGenFunction.cpp
@@ -577,8 +577,8 @@ CodeGenFunction::getUBSanFunctionTypeHash(QualType Ty) 
const {
   std::string Mangled;
   llvm::raw_string_ostream Out(Mangled);
   CGM.getCXXABI().getMangleContext().mangleTypeName(Ty, Out, false);
-  return llvm::ConstantInt::get(CGM.Int32Ty,
-
static_cast(llvm::xxHash64(Mangled)));
+  return llvm::ConstantInt::get(
+  CGM.Int32Ty, static_cast(llvm::xxh3_64bits(Mangled)));
 }
 
 void CodeGenFunction::EmitKernelMetadata(const FunctionDecl *FD,

diff  --git a/clang/test/CodeGen/ubsan-function.cpp 
b/clang/test/CodeGen/ubsan-function.cpp
index ba55ee021cc9df..1c281c8544578f 100644
--- a/clang/test/CodeGen/ubsan-function.cpp
+++ b/clang/test/CodeGen/ubsan-function.cpp
@@ -17,7 +17,7 @@ void fun() {}
 // CHECK: [[LABEL1]]:
 // CHECK: getelementptr <{ i32, i32 }>, ptr {{.*}}, i32 -1, i32 1, !nosanitize
 // CHECK: load i32, ptr {{.*}}, align {{.*}}, !nosanitize
-// CHECK: icmp eq i32 {{.*}}, -1522505972, !nosanitize
+// CHECK: icmp eq i32 {{.*}}, 905068220, !nosanitize
 // CHECK: br i1 {{.*}}, label %[[LABEL3:.*]], label %[[LABEL2:[^,]*]], 
{{.*}}!nosanitize
 // CHECK: [[LABEL2]]:
 // 64:call void @__ubsan_handle_function_type_mismatch_abort(ptr @[[#]], 
i64 %[[#]]) #[[#]], !nosanitize
@@ -32,4 +32,4 @@ void fun() {}
 // CHECK-NEXT:   ret void
 void caller(void (*f)()) { f(); }
 
-// CHECK: ![[FUNCSAN]] = !{i32 -1056584962, i32 -1522505972}
+// CHECK: ![[FUNCSAN]] = !{i32 -1056584962, i32 905068220}

diff  --git a/clang/test/CodeGenCXX/catch-undef-behavior.cpp 
b/clang/test/CodeGenCXX/catch-undef-behavior.cpp
index 9e4f0fb402c28a..6fd7d16f86369f 100644
--- a/clang/test/CodeGenCXX/catch-undef-behavior.cpp
+++ b/clang/test/CodeGenCXX/catch-undef-behavior.cpp
@@ -405,7 +405,7 @@ void indirect_function_call(void (*p)(int)) {
   // CalleeTypeHash check
   // CHECK: [[CalleeTypeHashPtr:%.+]] = getelementptr <{ i32, i32 }>, ptr 
[[PTR]], i32 -1, i32 1
   // CHECK-NEXT: [[CalleeTypeHash:%.+]] = load i32, ptr [[CalleeTypeHashPtr]]
-  // CHECK-NEXT: [[CalleeTypeHashMatch:%.+]] = icmp eq i32 [[CalleeTypeHash]], 
27004076
+  // CHECK-NEXT: [[CalleeTypeHashMatch:%.+]] = icmp eq i32 [[CalleeTypeHash]], 
-1988405058
   // CHECK-NEXT: br i1 [[CalleeTypeHashMatch]]
 
   p(42);
@@ -740,4 +740,4 @@ void ThisAlign::this_align_lambda_2() {
 
 // CHECK: attributes [[NR_NUW]] = { noreturn nounwind }
 
-// CHECK-FUNCSAN: ![[FUNCSAN]] = !{i32 -1056584962, i32 -1302768377}
+// CHECK-FUNCSAN: ![[FUNCSAN]] = !{i32 -1056584962, i32 -1000226989}



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


[PATCH] D155759: [Clang][CodeGen] Follow-up for `vtable`, `typeinfo` et al. are globals

2023-07-19 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155759

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


[PATCH] D155756: -fsanitize={function,kcfi}: Switch to xxh3_64bits

2023-07-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D155756#4516501 , @samitolvanen 
wrote:

> Changing the hash function breaks compatibility with the Rust KCFI 
> implementation 
> .
>  I would personally like to avoid changing how KCFI type hashes are computed 
> unless there's a very compelling reason to switch away from xxHash64.

Thank you for the rapid reply. So this looks unfortunate, I'll change just 
-fsanitize=function then (the scheme was just changed a few months ago, not 
even across arelease; though sanitizers don't really commit to cross-version 
compatibility). Perhaps the only minor downside is that `xxHash64` is going to 
linger forever.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155756

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


[PATCH] D154658: Optimize emission of `dynamic_cast` to final classes.

2023-07-19 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154658

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


[PATCH] D155759: [Clang][CodeGen] Follow-up for `vtable`, `typeinfo` et al. are globals

2023-07-19 Thread Alex Voicu via Phabricator via cfe-commits
AlexVlx created this revision.
AlexVlx added reviewers: yaxunl, efriedma, rjmccall.
Herald added a project: All.
AlexVlx requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Unfortunately, 
https://reviews.llvm.org/rG8acdcf4016876d122733991561be706b64026e73 didn't 
include handling for the fact that `throw`'s implementation takes a pointer to 
a type's `typeinfo` struct, which implies that its signature needs to change as 
well. This patch corrects that and adds a test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155759

Files:
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp


Index: clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 %s -triple amdgcn-amd-amdhsa -emit-llvm -fcxx-exceptions 
-fexceptions -std=c++11 -o - | FileCheck %s
+
+struct X {
+  ~X();
+};
+
+struct Error {
+  Error(const X&) noexcept;
+};
+
+void f() {
+  try {
+throw Error(X());
+  } catch (...) { }
+}
+
+// CHECK: declare void @__cxa_throw(ptr, ptr addrspace(1), ptr)
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -1252,7 +1252,7 @@
   // void __cxa_throw(void *thrown_exception, std::type_info *tinfo,
   //  void (*dest) (void *));
 
-  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.Int8PtrTy, CGM.Int8PtrTy };
+  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.GlobalsInt8PtrTy, CGM.Int8PtrTy };
   llvm::FunctionType *FTy =
 llvm::FunctionType::get(CGM.VoidTy, Args, /*isVarArg=*/false);
 


Index: clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/throw-expression-typeinfo-in-address-space.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 %s -triple amdgcn-amd-amdhsa -emit-llvm -fcxx-exceptions -fexceptions -std=c++11 -o - | FileCheck %s
+
+struct X {
+  ~X();
+};
+
+struct Error {
+  Error(const X&) noexcept;
+};
+
+void f() {
+  try {
+throw Error(X());
+  } catch (...) { }
+}
+
+// CHECK: declare void @__cxa_throw(ptr, ptr addrspace(1), ptr)
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -1252,7 +1252,7 @@
   // void __cxa_throw(void *thrown_exception, std::type_info *tinfo,
   //  void (*dest) (void *));
 
-  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.Int8PtrTy, CGM.Int8PtrTy };
+  llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.GlobalsInt8PtrTy, CGM.Int8PtrTy };
   llvm::FunctionType *FTy =
 llvm::FunctionType::get(CGM.VoidTy, Args, /*isVarArg=*/false);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D151587: [clang][ConstantEmitter] have tryEmitPrivate[ForVarInit] try ConstExprEmitter fast-path first

2023-07-19 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:8360
+  // Do not constant fold an R-value.
+  if (Info.EvalMode == EvalInfo::EM_ConstantFold && !E->isLValue())
+return false;

efriedma wrote:
> efriedma wrote:
> > nickdesaulniers wrote:
> > > efriedma wrote:
> > > > nickdesaulniers wrote:
> > > > > nickdesaulniers wrote:
> > > > > > efriedma wrote:
> > > > > > > nickdesaulniers wrote:
> > > > > > > > efriedma wrote:
> > > > > > > > > Checking isLValue() doesn't make sense; consider:
> > > > > > > > > 
> > > > > > > > > ```
> > > > > > > > > struct R { mutable long x; };
> > > > > > > > > struct Z { const R , y; };
> > > > > > > > > Z z = { R{1}, z.x.x=10 };
> > > > > > > > > ```
> > > > > > > > > 
> > > > > > > > > Maybe also want to check for EM_IgnoreSideEffects?  Not sure 
> > > > > > > > > what cases, if any, that would affect.
> > > > > > > > > 
> > > > > > > > > We should probably check `E->getStorageDuration() == 
> > > > > > > > > SD_Static`.  The cases where it's a local temporary don't hit 
> > > > > > > > > the getOrCreateValue() codepath, so the evaluated value 
> > > > > > > > > should be handled correctly.
> > > > > > > > > 
> > > > > > > > > Checking EvalMode feels a little weird, but I guess it should 
> > > > > > > > > do the right thing in the cases I can think of?  I'd like a 
> > > > > > > > > second opinion on this.
> > > > > > > > Changing this condition to:
> > > > > > > > ```
> > > > > > > > if (E->getStorageDuration() == SD_Static && 
> > > > > > > >   
> > > > > > > > Info.EvalMode == EvalInfo::EM_ConstantFold &&   
> > > > > > > >   
> > > > > > > > E->isXValue())  
> > > > > > > >   
> > > > > > > >   return false;
> > > > > > > > ```
> > > > > > > > allows all tests in tree to pass, but messes up the test case 
> > > > > > > > you posted above. I'm trying to sus out what else might be 
> > > > > > > > different about that test case...we should return `false` for 
> > > > > > > > that, but I'm not sure what's different about that case.
> > > > > > > > 
> > > > > > > > In particular, I was playing with 
> > > > > > > > `E->isUsableInConstantExpressions` and 
> > > > > > > > `E->getLifetimeExtendedTemporaryDecl()`, but getting your case 
> > > > > > > > to work, I end up regressing 
> > > > > > > > clang/test/SemaCXX/attr-require-constant-initialization.cpp...argh!!
> > > > > > > Shouldn't that just be the following?
> > > > > > > 
> > > > > > > ```
> > > > > > > if (E->getStorageDuration() == SD_Static &&   
> > > > > > > 
> > > > > > > Info.EvalMode == EvalInfo::EM_ConstantFold)   
> > > > > > >  
> > > > > > >   return false;
> > > > > > > ```
> > > > > > > 
> > > > > > > A materialized temporary is always going to be either an LValue 
> > > > > > > or an XValue, and the difference between the two isn't relevant 
> > > > > > > here.
> > > > > > I wish it were that simple. Checking those two alone will produce 
> > > > > > failures in the following tests:
> > > > > > 
> > > > > > Failed Tests (2):
> > > > > >   Clang :: CodeGenCXX/mangle-ms.cpp
> > > > > >   Clang :: SemaCXX/attr-require-constant-initialization.cpp
> > > > > > 
> > > > > > error: 'error' diagnostics seen but not expected: 
> > > > > >   File 
> > > > > > /android0/llvm-project/clang/test/SemaCXX/attr-require-constant-initialization.cpp
> > > > > >  Line 92: variable does not have a constant initializer
> > > > > > 
> > > > > > as an example of one failure, which is basically:
> > > > > > 
> > > > > > ```
> > > > > > void foo(void) {
> > > > > >   __attribute__((require_constant_initialization)) static const int 
> > > > > > _init = 42;
> > > > > > }
> > > > > > ```
> > > > > > specifically, `-std=c++03` is the only language version that fails.
> > > > > > 
> > > > > Oh, perhaps it should simply be:
> > > > > 
> > > > > ```
> > > > > if (Info.EvalMode == EvalInfo::EM_ConstantFold && E->isXValue())
> > > > >   return false;
> > > > > ```
> > > > > 
> > > > > let me add your test case for that, too.
> > > > It looks like that case is using Expr::isConstantInitializer, which 
> > > > uses EM_ConstantFold, which then blows up.  No combination of the 
> > > > checks you're trying will let you distinguish between that case and the 
> > > > case you're trying to bail out; in both cases, the EvalMode is 
> > > > EvalMode, it's an lvalue, and the storage duration is static.
> > > > 
> > > > Maybe the code in question shouldn't be using isConstantInitializer at 
> > > > all.
> > > > 
> > > > Checking for a reference type doesn't solve anything; it just makes the 
> > > > issues more complicated to reproduce.
> > > d572f82e490b alludes to `Expr::isConstantInitializer` being error 
> > > prone...back in 2011...
> > > 
> > > > Maybe the code in 

[PATCH] D155756: -fsanitize={function,kcfi}: Switch to xxh3_64bits

2023-07-19 Thread Sami Tolvanen via Phabricator via cfe-commits
samitolvanen added a comment.

Changing the hash function breaks compatibility with the Rust KCFI 
implementation 
.
 I would personally like to avoid changing how KCFI type hashes are computed 
unless there's a very compelling reason to switch away from xxHash64.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155756

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


[PATCH] D155667: [-Wunsafe-buffer-usage] Check source location validity before using `TypeLoc`s

2023-07-19 Thread Ziqing Luo via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa6302b6934b3: [-Wunsafe-buffer-usage] Check source location 
validity before using `TypeLoc`s (authored by ziqingluo-90).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155667

Files:
  clang/lib/Analysis/UnsafeBufferUsage.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp


Index: clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
@@ -33,6 +33,26 @@
   }
 }
 
+// The analysis requires accurate source location informations from
+// `TypeLoc`s of types of variable (parameter) declarations in order
+// to generate fix-its for them. But those information is not always
+// available (probably due to some bugs in clang but it is irrelevant
+// to the safe-buffer project).  The following is an example.  When
+// `_Atomic` is used, we cannot get valid source locations of the
+// pointee type of `unsigned *`.  The analysis gives up in such a
+// case.
+// CHECK-NOT: fix-it:
+void typeLocSourceLocationInvalid(_Atomic unsigned *map) { // 
expected-warning{{'map' is an unsafe pointer used for buffer access}}
+  map[5] = 5; // expected-note{{used in buffer access here}}
+}
+
+// CHECK: fix-it:"{{.*}}":{[[@LINE+1]]:33-[[@LINE+1]]:46}:"std::span 
map"
+void typeLocSourceLocationValid(unsigned *map) { // expected-warning{{'map' is 
an unsafe pointer used for buffer access}} \
+   expected-note{{change type 
of 'map' to 'std::span' to preserve bounds information}}
+  map[5] = 5; // expected-note{{used in buffer access here}}
+}
+// CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:2-[[@LINE-1]]:2}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}}
 void typeLocSourceLocationValid(unsigned *map) {return 
typeLocSourceLocationValid(std::span(map, <# size #>));}\n"
+
 // We do not fix parameters participating unsafe operations for the
 // following functions/methods or function-like expressions:
 
@@ -128,4 +148,3 @@
   int tmp;
   tmp = x[5]; // expected-note{{used in buffer access here}}
 }
-
Index: clang/lib/Analysis/UnsafeBufferUsage.cpp
===
--- clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -1385,8 +1385,18 @@
   TypeLoc PteTyLoc = TyLoc.getUnqualifiedLoc().getNextTypeLoc();
   SourceLocation VDNameStartLoc = VD->getLocation();
 
-  if (!SM.isBeforeInTranslationUnit(PteTyLoc.getSourceRange().getEnd(),
-VDNameStartLoc)) {
+  if (!(VDNameStartLoc.isValid() && PteTyLoc.getSourceRange().isValid())) {
+// We are expecting these locations to be valid. But in some cases, they 
are
+// not all valid. It is a Clang bug to me and we are not responsible for
+// fixing it.  So we will just give up for now when it happens.
+return std::nullopt;
+  }
+
+  // Note that TypeLoc.getEndLoc() returns the begin location of the last 
token:
+  SourceLocation PteEndOfTokenLoc =
+  Lexer::getLocForEndOfToken(PteTyLoc.getEndLoc(), 0, SM, LangOpts);
+
+  if (!SM.isBeforeInTranslationUnit(PteEndOfTokenLoc, VDNameStartLoc)) {
 // We only deal with the cases where the source text of the pointee type
 // appears on the left-hand side of the variable identifier completely,
 // including the following forms:
@@ -1401,13 +1411,8 @@
 // `PteTy` via source ranges.
 *QualifiersToAppend = PteTy.getQualifiers();
   }
-
-  // Note that TypeLoc.getEndLoc() returns the begin location of the last 
token:
-  SourceRange CSR{
-  PteTyLoc.getBeginLoc(),
-  Lexer::getLocForEndOfToken(PteTyLoc.getEndLoc(), 0, SM, LangOpts)};
-
-  return getRangeText(CSR, SM, LangOpts)->str();
+  return getRangeText({PteTyLoc.getBeginLoc(), PteEndOfTokenLoc}, SM, LangOpts)
+  ->str();
 }
 
 // Returns the text of the name (with qualifiers) of a `FunctionDecl`.


Index: clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
@@ -33,6 +33,26 @@
   }
 }
 
+// The analysis requires accurate source location informations from
+// `TypeLoc`s of types of variable (parameter) declarations in order
+// to generate fix-its for them. But those information is not always
+// available (probably due to some bugs in clang but it is irrelevant
+// to the safe-buffer project).  The following is an example.  When
+// `_Atomic` is used, we cannot get valid source locations of the
+// pointee type of 

[clang] a6302b6 - [-Wunsafe-buffer-usage] Check source location validity before using `TypeLoc`s

2023-07-19 Thread via cfe-commits

Author: ziqingluo-90
Date: 2023-07-19T15:04:42-07:00
New Revision: a6302b6934b349fff122eeb6c4b39eff580c4b1b

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

LOG: [-Wunsafe-buffer-usage] Check source location validity before using 
`TypeLoc`s

The safe-buffer analysis analyzes TypeLocs of types of variable
declarations in order to get source locations of them.

However, in some cases, the source locations of a TypeLoc are not
valid. Using invalid source locations results in assertion violation
or incorrect analysis or fix-its.

It is still not clear to me in what circumstances a TypeLoc does not
have valid source locations (it looks like a bug in Clang to me, but
it is not our responsibility to fix it). So we will conservatively
give up the analysis when required source locations are not valid.

Reviewed By: NoQ (Artem Dergachev)

Differential Revision: https://reviews.llvm.org/D155667

Added: 


Modified: 
clang/lib/Analysis/UnsafeBufferUsage.cpp
clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp

Removed: 




diff  --git a/clang/lib/Analysis/UnsafeBufferUsage.cpp 
b/clang/lib/Analysis/UnsafeBufferUsage.cpp
index 495d171c618c99..5295d9d92b2977 100644
--- a/clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ b/clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -1385,8 +1385,18 @@ getPointeeTypeText(const ParmVarDecl *VD, const 
SourceManager ,
   TypeLoc PteTyLoc = TyLoc.getUnqualifiedLoc().getNextTypeLoc();
   SourceLocation VDNameStartLoc = VD->getLocation();
 
-  if (!SM.isBeforeInTranslationUnit(PteTyLoc.getSourceRange().getEnd(),
-VDNameStartLoc)) {
+  if (!(VDNameStartLoc.isValid() && PteTyLoc.getSourceRange().isValid())) {
+// We are expecting these locations to be valid. But in some cases, they 
are
+// not all valid. It is a Clang bug to me and we are not responsible for
+// fixing it.  So we will just give up for now when it happens.
+return std::nullopt;
+  }
+
+  // Note that TypeLoc.getEndLoc() returns the begin location of the last 
token:
+  SourceLocation PteEndOfTokenLoc =
+  Lexer::getLocForEndOfToken(PteTyLoc.getEndLoc(), 0, SM, LangOpts);
+
+  if (!SM.isBeforeInTranslationUnit(PteEndOfTokenLoc, VDNameStartLoc)) {
 // We only deal with the cases where the source text of the pointee type
 // appears on the left-hand side of the variable identifier completely,
 // including the following forms:
@@ -1401,13 +1411,8 @@ getPointeeTypeText(const ParmVarDecl *VD, const 
SourceManager ,
 // `PteTy` via source ranges.
 *QualifiersToAppend = PteTy.getQualifiers();
   }
-
-  // Note that TypeLoc.getEndLoc() returns the begin location of the last 
token:
-  SourceRange CSR{
-  PteTyLoc.getBeginLoc(),
-  Lexer::getLocForEndOfToken(PteTyLoc.getEndLoc(), 0, SM, LangOpts)};
-
-  return getRangeText(CSR, SM, LangOpts)->str();
+  return getRangeText({PteTyLoc.getBeginLoc(), PteEndOfTokenLoc}, SM, LangOpts)
+  ->str();
 }
 
 // Returns the text of the name (with qualifiers) of a `FunctionDecl`.

diff  --git 
a/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp 
b/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
index f5be80b518ad32..44f44d0e077e11 100644
--- a/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
+++ b/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-unsupported.cpp
@@ -33,6 +33,26 @@ void unnamedPointeeType(PTR_TO_ANON p) {  // 
expected-warning{{'p' is an unsafe
   }
 }
 
+// The analysis requires accurate source location informations from
+// `TypeLoc`s of types of variable (parameter) declarations in order
+// to generate fix-its for them. But those information is not always
+// available (probably due to some bugs in clang but it is irrelevant
+// to the safe-buffer project).  The following is an example.  When
+// `_Atomic` is used, we cannot get valid source locations of the
+// pointee type of `unsigned *`.  The analysis gives up in such a
+// case.
+// CHECK-NOT: fix-it:
+void typeLocSourceLocationInvalid(_Atomic unsigned *map) { // 
expected-warning{{'map' is an unsafe pointer used for buffer access}}
+  map[5] = 5; // expected-note{{used in buffer access here}}
+}
+
+// CHECK: fix-it:"{{.*}}":{[[@LINE+1]]:33-[[@LINE+1]]:46}:"std::span 
map"
+void typeLocSourceLocationValid(unsigned *map) { // expected-warning{{'map' is 
an unsafe pointer used for buffer access}} \
+   expected-note{{change type 
of 'map' to 'std::span' to preserve bounds information}}
+  map[5] = 5; // expected-note{{used in buffer access here}}
+}
+// CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:2-[[@LINE-1]]:2}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}}
 void 

[PATCH] D142660: [AIX] supporting -X options for llvm-ranlib in AIX OS

2023-07-19 Thread Digger Lin via Phabricator via cfe-commits
DiggerLin updated this revision to Diff 542209.
DiggerLin marked 5 inline comments as done.
DiggerLin added a comment.

address comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142660

Files:
  clang/test/lit.cfg.py
  llvm/include/llvm/Object/Archive.h
  llvm/include/llvm/Object/ArchiveWriter.h
  llvm/lib/Object/Archive.cpp
  llvm/lib/Object/ArchiveWriter.cpp
  llvm/test/lit.cfg.py
  llvm/test/tools/llvm-ranlib/aix-X-option.test
  llvm/tools/llvm-ar/llvm-ar.cpp

Index: llvm/tools/llvm-ar/llvm-ar.cpp
===
--- llvm/tools/llvm-ar/llvm-ar.cpp
+++ llvm/tools/llvm-ar/llvm-ar.cpp
@@ -69,7 +69,10 @@
  << "  -v --version  - Display the version of this program\n"
  << "  -D- Use zero for timestamps and uids/gids "
 "(default)\n"
- << "  -U- Use actual timestamps and uids/gids\n";
+ << "  -U- Use actual timestamps and uids/gids\n"
+ << "  -X{32|64|32_64}   - Specifies which archive symbol tables "
+"should "
+"be generated if they do not already exist (AIX OS only)\n";
 }
 
 static void printArHelp(StringRef ToolName) {
@@ -225,7 +228,7 @@
 static bool CompareFullPath = false;  ///< 'P' modifier
 static bool OnlyUpdate = false;   ///< 'u' modifier
 static bool Verbose = false;  ///< 'v' modifier
-static bool Symtab = true;///< 's' modifier
+static WriteSymTabType Symtab = true; ///< 's' modifier
 static bool Deterministic = true; ///< 'D' and 'U' modifiers
 static bool Thin = false; ///< 'T' modifier
 static bool AddLibrary = false;   ///< 'L' modifier
@@ -1074,9 +1077,27 @@
   // In summary, we only need to update the symbol table if we have none.
   // This is actually very common because of broken build systems that think
   // they have to run ranlib.
-  if (OldArchive->hasSymbolTable())
-return;
+  if (OldArchive->hasSymbolTable()) {
+if (OldArchive->kind() != object::Archive::K_AIXBIG)
+  return;
 
+// For archives in the Big Archive format, the bit mode option specifies
+// which symbol table to generate. The presence of a symbol table that does
+// not match the specified bit mode does not prevent creation of the symbol
+// table that has been requested.
+if (OldArchive->kind() == object::Archive::K_AIXBIG) {
+  BigArchive *BigArc = dyn_cast(OldArchive);
+  if (BigArc->has32BitGlobalSymtab() &&
+  Symtab.getBitMode() == WriteSymTabType::BitMode::Bit32)
+return;
+
+  if (BigArc->has64BitGlobalSymtab() &&
+  Symtab.getBitMode() == WriteSymTabType::BitMode::Bit64)
+return;
+
+  Symtab.setBitMode(WriteSymTabType::BitMode::Both);
+}
+  }
   if (OldArchive->isThin())
 Thin = true;
   performWriteOperation(CreateSymTab, OldArchive, nullptr, nullptr);
@@ -1250,6 +1271,7 @@
 
 static BitModeTy getBitMode(const char *RawBitMode) {
   return StringSwitch(RawBitMode)
+  .Case("", BitModeTy::Bit32)
   .Case("32", BitModeTy::Bit32)
   .Case("64", BitModeTy::Bit64)
   .Case("32_64", BitModeTy::Bit32_64)
@@ -1389,6 +1411,8 @@
 
 static int ranlib_main(int argc, char **argv) {
   std::vector Archives;
+
+  bool HasAIXXOption = false;
   for (int i = 1; i < argc; ++i) {
 StringRef arg(argv[i]);
 if (handleGenericOption(arg)) {
@@ -1406,6 +1430,30 @@
 } else if (arg.front() == 'v') {
   cl::PrintVersionMessage();
   return 0;
+} else if (arg.front() == 'X') {
+  if (object::Archive::getDefaultKindForHost() ==
+  object::Archive::K_AIXBIG) {
+HasAIXXOption = true;
+arg.consume_front("X");
+const char *Xarg = arg.data();
+if (Xarg[0] == '\0') {
+  if (argv[i + 1][0] != '-')
+BitMode = getBitMode(argv[++i]);
+  else
+BitMode = BitModeTy::Unknown;
+} else
+  BitMode = getBitMode(arg.data());
+
+// -X option in ranlib do not accept "any"
+if (BitMode == BitModeTy::Unknown || BitMode == BitModeTy::Any)
+  fail(
+  Twine("the specified object mode is not valid. Specify -X32, "
+"-X64, or -X32_64"));
+  } else {
+fail(Twine("-") + Twine(arg) +
+ " option not supported on non AIX OS");
+  }
+  break;
 } else {
   // TODO: GNU ranlib also supports a -t flag
   fail("Invalid option: '-" + arg + "'");
@@ -1417,6 +1465,30 @@
 }
   }
 
+  if (object::Archive::getDefaultKindForHost() == object::Archive::K_AIXBIG) {
+// If not specify -X option, get BitMode from enviorment variable
+// "OBJECT_MODE" for AIX OS if specify.

[PATCH] D155756: -fsanitize={function,kcfi}: Switch to xxh3_64bits

2023-07-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay created this revision.
MaskRay added a reviewer: samitolvanen.
Herald added a project: All.
MaskRay requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Following recent changes switching from xxh64 to xxh32 for better
hashing performance (e.g., D154813 ). These 
particular instances likely
have negligible time, but this change moves us toward removing xxHash64.

The type hash for -fsanitize={function,kcfi} will change. This is
totally fine for =function, I assume that this is fine for =kcfi as well
as we cannot sign for compatibility across different Clang versions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155756

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/kcfi-normalize.c
  clang/test/CodeGen/ubsan-function.cpp
  clang/test/CodeGenCXX/catch-undef-behavior.cpp

Index: clang/test/CodeGenCXX/catch-undef-behavior.cpp
===
--- clang/test/CodeGenCXX/catch-undef-behavior.cpp
+++ clang/test/CodeGenCXX/catch-undef-behavior.cpp
@@ -405,7 +405,7 @@
   // CalleeTypeHash check
   // CHECK: [[CalleeTypeHashPtr:%.+]] = getelementptr <{ i32, i32 }>, ptr [[PTR]], i32 -1, i32 1
   // CHECK-NEXT: [[CalleeTypeHash:%.+]] = load i32, ptr [[CalleeTypeHashPtr]]
-  // CHECK-NEXT: [[CalleeTypeHashMatch:%.+]] = icmp eq i32 [[CalleeTypeHash]], 27004076
+  // CHECK-NEXT: [[CalleeTypeHashMatch:%.+]] = icmp eq i32 [[CalleeTypeHash]], -1988405058
   // CHECK-NEXT: br i1 [[CalleeTypeHashMatch]]
 
   p(42);
@@ -740,4 +740,4 @@
 
 // CHECK: attributes [[NR_NUW]] = { noreturn nounwind }
 
-// CHECK-FUNCSAN: ![[FUNCSAN]] = !{i32 -1056584962, i32 -1302768377}
+// CHECK-FUNCSAN: ![[FUNCSAN]] = !{i32 -1056584962, i32 -1000226989}
Index: clang/test/CodeGen/ubsan-function.cpp
===
--- clang/test/CodeGen/ubsan-function.cpp
+++ clang/test/CodeGen/ubsan-function.cpp
@@ -17,7 +17,7 @@
 // CHECK: [[LABEL1]]:
 // CHECK: getelementptr <{ i32, i32 }>, ptr {{.*}}, i32 -1, i32 1, !nosanitize
 // CHECK: load i32, ptr {{.*}}, align {{.*}}, !nosanitize
-// CHECK: icmp eq i32 {{.*}}, -1522505972, !nosanitize
+// CHECK: icmp eq i32 {{.*}}, 905068220, !nosanitize
 // CHECK: br i1 {{.*}}, label %[[LABEL3:.*]], label %[[LABEL2:[^,]*]], {{.*}}!nosanitize
 // CHECK: [[LABEL2]]:
 // 64:call void @__ubsan_handle_function_type_mismatch_abort(ptr @[[#]], i64 %[[#]]) #[[#]], !nosanitize
@@ -32,4 +32,4 @@
 // CHECK-NEXT:   ret void
 void caller(void (*f)()) { f(); }
 
-// CHECK: ![[FUNCSAN]] = !{i32 -1056584962, i32 -1522505972}
+// CHECK: ![[FUNCSAN]] = !{i32 -1056584962, i32 905068220}
Index: clang/test/CodeGen/kcfi-normalize.c
===
--- clang/test/CodeGen/kcfi-normalize.c
+++ clang/test/CodeGen/kcfi-normalize.c
@@ -10,24 +10,24 @@
 void foo(void (*fn)(int), int arg) {
 // CHECK-LABEL: define{{.*}}foo
 // CHECK-SAME: {{.*}}!kcfi_type ![[TYPE1:[0-9]+]]
-// CHECK: call void %0(i32 noundef %1){{.*}}[ "kcfi"(i32 1162514891) ]
+// CHECK: call void %0(i32 noundef %1){{.*}}[ "kcfi"(i32 -168959710) ]
 fn(arg);
 }
 
 void bar(void (*fn)(int, int), int arg1, int arg2) {
 // CHECK-LABEL: define{{.*}}bar
 // CHECK-SAME: {{.*}}!kcfi_type ![[TYPE2:[0-9]+]]
-// CHECK: call void %0(i32 noundef %1, i32 noundef %2){{.*}}[ "kcfi"(i32 448046469) ]
+// CHECK: call void %0(i32 noundef %1, i32 noundef %2){{.*}}[ "kcfi"(i32 -993618679) ]
 fn(arg1, arg2);
 }
 
 void baz(void (*fn)(int, int, int), int arg1, int arg2, int arg3) {
 // CHECK-LABEL: define{{.*}}baz
 // CHECK-SAME: {{.*}}!kcfi_type ![[TYPE3:[0-9]+]]
-// CHECK: call void %0(i32 noundef %1, i32 noundef %2, i32 noundef %3){{.*}}[ "kcfi"(i32 -2049681433) ]
+// CHECK: call void %0(i32 noundef %1, i32 noundef %2, i32 noundef %3){{.*}}[ "kcfi"(i32 903305451) ]
 fn(arg1, arg2, arg3);
 }
 
-// CHECK: ![[TYPE1]] = !{i32 -1143117868}
-// CHECK: ![[TYPE2]] = !{i32 -460921415}
-// CHECK: ![[TYPE3]] = !{i32 -333839615}
+// CHECK: ![[TYPE1]] = !{i32 2050575439}
+// CHECK: ![[TYPE2]] = !{i32 -1315331729}
+// CHECK: ![[TYPE3]] = !{i32 565093442}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1998,8 +1998,8 @@
   if (getCodeGenOpts().SanitizeCfiICallNormalizeIntegers)
 Out << ".normalized";
 
-  return llvm::ConstantInt::get(Int32Ty,
-static_cast(llvm::xxHash64(OutName)));
+  return llvm::ConstantInt::get(
+  Int32Ty, static_cast(llvm::xxh3_64bits(OutName)));
 }
 
 void CodeGenModule::SetLLVMFunctionAttributes(GlobalDecl GD,
Index: clang/lib/CodeGen/CodeGenFunction.cpp
===

[PATCH] D155524: [-Wunsafe-buffer-usage] Ignore the FixableGadgets that will not be fixed at an earlier stage

2023-07-19 Thread Ziqing Luo via Phabricator via cfe-commits
ziqingluo-90 updated this revision to Diff 542199.
ziqingluo-90 added a comment.

Address comments


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

https://reviews.llvm.org/D155524

Files:
  clang/lib/Analysis/UnsafeBufferUsage.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage-pragma-fixit.cpp

Index: clang/test/SemaCXX/warn-unsafe-buffer-usage-pragma-fixit.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage-pragma-fixit.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage-pragma-fixit.cpp
@@ -107,3 +107,128 @@
 
   p[5]; // not to note since the associated warning is suppressed
 }
+
+
+// Test suppressing interacts with variable grouping:
+
+// The implication edges are: `a` -> `b` -> `c`.
+// If the unsafe operation on `a` is supressed, none of the variables
+// will be fixed.
+void suppressedVarInGroup() {
+  int * a;
+  // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:
+  int * b;
+  // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:
+  int * c;
+  // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:
+
+#pragma clang unsafe_buffer_usage begin
+  a[5] = 5;
+#pragma clang unsafe_buffer_usage end
+  a = b;
+  b = c;
+}
+
+// To show that if `a[5]` is not suppressed in the
+// `suppressedVarInGroup` function above, all variables will be fixed.
+void suppressedVarInGroup_control() {
+  int * a;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span a"
+  int * b;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span b"
+  int * c;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span c"
+
+  a[5] = 5;
+  a = b;
+  b = c;
+}
+
+// The implication edges are: `a` -> `b` -> `c`.
+// The unsafe operation on `b` is supressed, while the unsafe
+// operation on `a` is not suppressed. Variable `b` will still be
+// fixed when fixing `a`.
+void suppressedVarInGroup2() {
+  int * a;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span a"
+  int * b;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span b"
+  int * c;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span c"
+
+  a[5] = 5;
+#pragma clang unsafe_buffer_usage begin
+  b[5] = 5;
+#pragma clang unsafe_buffer_usage end
+  a = b;
+  b = c;
+}
+
+// The implication edges are: `a` -> `b` -> `c`.
+// The unsafe operation on `b` is supressed, while the unsafe
+// operation on `c` is not suppressed. Only variable `c` will be fixed
+// then.
+void suppressedVarInGroup3() {
+  int * a;
+  // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:
+  int * b;
+  // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:
+  int * c;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span c"
+
+  c[5] = 5;
+#pragma clang unsafe_buffer_usage begin
+  b[5] = 5;
+#pragma clang unsafe_buffer_usage end
+  a = b;
+  b = c;
+}
+
+// The implication edges are: `a` -> `b` -> `c` -> `a`.
+// The unsafe operation on `b` is supressed, while the unsafe
+// operation on `c` is not suppressed. Since the implication graph
+// forms a cycle, all variables will be fixed.
+void suppressedVarInGroup4() {
+  int * a;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span a"
+  int * b;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span b"
+  int * c;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span c"
+
+  c[5] = 5;
+#pragma clang unsafe_buffer_usage begin
+  b[5] = 5;
+#pragma clang unsafe_buffer_usage end
+  a = b;
+  b = c;
+  c = a;
+}
+
+// There are two groups: `a` -> `b` -> `c` and `d` -> `e` -> `f`.
+// Suppressing unsafe operations on variables in one group does not
+// affect other groups.
+void suppressedVarInGroup5() {
+  int * a;
+  // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:
+  int * b;
+  // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:
+  int * c;
+  // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:
+  int * d;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span d"
+  int * e;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span e"
+  int * f;
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:10}:"std::span f"
+
+#pragma clang unsafe_buffer_usage begin
+  a[5] = 5;
+#pragma clang unsafe_buffer_usage end
+  a = b;
+  b = c;
+
+  d[5] = 5;
+  d = e;
+  e = f;
+}
Index: clang/lib/Analysis/UnsafeBufferUsage.cpp
===
--- clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -1092,15 +1092,18 @@
 
   M.match(*D->getBody(), D->getASTContext());
 
-  // Gadgets "claim" variables they're responsible for. Once this loop finishes,
-  // the tracker will only track DREs that weren't claimed by any gadgets,
-  // i.e. not understood by the analysis.
-  for (const auto  : CB.FixableGadgets) {
-for (const auto *DRE : G->getClaimedVarUseSites()) {
-  CB.Tracker.claimUse(DRE);
+  // If no `WarningGadget`s ever matched, there is no unsafe operations 

[PATCH] D155385: [clangd] enable unused-include warnings for standard library headers

2023-07-19 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
sammccall marked an inline comment as done.
Closed by commit rGe289ee99cec4: [clangd] enable unused-include warnings for 
standard library headers (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D155385?vs=540751=542204#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155385

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/tool/ClangdMain.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -73,10 +73,6 @@
 }
 
 TEST(IncludeCleaner, StdlibUnused) {
-  setIncludeCleanerAnalyzesStdlib(true);
-  auto Cleanup =
-  llvm::make_scope_exit([] { setIncludeCleanerAnalyzesStdlib(false); });
-
   auto TU = TestTU::withCode(R"cpp(
 #include 
 #include 
Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -273,15 +273,6 @@
 init(CodeCompleteOptions().ImportInsertions),
 };
 
-opt IncludeCleanerStdlib{
-"include-cleaner-stdlib",
-cat(Features),
-desc("Apply include-cleaner analysis to standard library headers "
- "(immature!)"),
-init(false),
-Hidden,
-};
-
 opt HeaderInsertionDecorators{
 "header-insertion-decorators",
 cat(Features),
@@ -317,7 +308,7 @@
 RetiredFlag ClangTidyChecks("clang-tidy-checks");
 RetiredFlag InlayHints("inlay-hints");
 RetiredFlag FoldingRanges("folding-ranges");
-
+RetiredFlag IncludeCleanerStdlib("include-cleaner-stdlib");
 
 opt LimitResults{
 "limit-results",
@@ -968,7 +959,6 @@
   };
   if (ForceOffsetEncoding != OffsetEncoding::UnsupportedEncoding)
 Opts.Encoding = ForceOffsetEncoding;
-  setIncludeCleanerAnalyzesStdlib(IncludeCleanerStdlib);
 
   if (CheckFile.getNumOccurrences()) {
 llvm::SmallString<256> Path;
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -36,7 +36,6 @@
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/GenericUniformityImpl.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/STLFunctionalExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"
@@ -55,10 +54,6 @@
 #include 
 
 namespace clang::clangd {
-
-static bool AnalyzeStdlib = false;
-void setIncludeCleanerAnalyzesStdlib(bool B) { AnalyzeStdlib = B; }
-
 namespace {
 
 bool isIgnored(llvm::StringRef HeaderPath, HeaderFilter IgnoreHeaders) {
@@ -78,11 +73,8 @@
   // FIXME(kirillbobyrev): We currently do not support the umbrella headers.
   // System headers are likely to be standard library headers.
   // Until we have good support for umbrella headers, don't warn about them.
-  if (Inc.Written.front() == '<') {
-if (AnalyzeStdlib && tooling::stdlib::Header::named(Inc.Written))
-  return true;
-return false;
-  }
+  if (Inc.Written.front() == '<')
+return tooling::stdlib::Header::named(Inc.Written).has_value();
   assert(Inc.HeaderID);
   auto HID = static_cast(*Inc.HeaderID);
   auto FE = AST.getSourceManager().getFileManager().getFileRef(


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -73,10 +73,6 @@
 }
 
 TEST(IncludeCleaner, StdlibUnused) {
-  setIncludeCleanerAnalyzesStdlib(true);
-  auto Cleanup =
-  llvm::make_scope_exit([] { setIncludeCleanerAnalyzesStdlib(false); });
-
   auto TU = TestTU::withCode(R"cpp(
 #include 
 #include 
Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -273,15 +273,6 @@
 init(CodeCompleteOptions().ImportInsertions),
 };
 
-opt IncludeCleanerStdlib{
-"include-cleaner-stdlib",
-cat(Features),
-desc("Apply include-cleaner analysis to standard library headers "
- "(immature!)"),
-init(false),
-Hidden,
-};
-
 opt HeaderInsertionDecorators{
 "header-insertion-decorators",
 cat(Features),
@@ -317,7 +308,7 @@
 RetiredFlag ClangTidyChecks("clang-tidy-checks");
 RetiredFlag InlayHints("inlay-hints");
 RetiredFlag FoldingRanges("folding-ranges");
-
+RetiredFlag 

[clang-tools-extra] e289ee9 - [clangd] enable unused-include warnings for standard library headers

2023-07-19 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2023-07-19T23:43:47+02:00
New Revision: e289ee99cec4607243aeaa01504f6b3cf65b65fe

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

LOG: [clangd] enable unused-include warnings for standard library headers

Other  headers are still excluded.

Differential Revision: https://reviews.llvm.org/D155385

Added: 


Modified: 
clang-tools-extra/clangd/IncludeCleaner.cpp
clang-tools-extra/clangd/tool/ClangdMain.cpp
clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/IncludeCleaner.cpp 
b/clang-tools-extra/clangd/IncludeCleaner.cpp
index 6c33fd3588..2ecc15973337a7 100644
--- a/clang-tools-extra/clangd/IncludeCleaner.cpp
+++ b/clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -36,7 +36,6 @@
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/GenericUniformityImpl.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/STLFunctionalExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"
@@ -55,10 +54,6 @@
 #include 
 
 namespace clang::clangd {
-
-static bool AnalyzeStdlib = false;
-void setIncludeCleanerAnalyzesStdlib(bool B) { AnalyzeStdlib = B; }
-
 namespace {
 
 bool isIgnored(llvm::StringRef HeaderPath, HeaderFilter IgnoreHeaders) {
@@ -78,11 +73,8 @@ bool mayConsiderUnused(
   // FIXME(kirillbobyrev): We currently do not support the umbrella headers.
   // System headers are likely to be standard library headers.
   // Until we have good support for umbrella headers, don't warn about them.
-  if (Inc.Written.front() == '<') {
-if (AnalyzeStdlib && tooling::stdlib::Header::named(Inc.Written))
-  return true;
-return false;
-  }
+  if (Inc.Written.front() == '<')
+return tooling::stdlib::Header::named(Inc.Written).has_value();
   assert(Inc.HeaderID);
   auto HID = static_cast(*Inc.HeaderID);
   auto FE = AST.getSourceManager().getFileManager().getFileRef(

diff  --git a/clang-tools-extra/clangd/tool/ClangdMain.cpp 
b/clang-tools-extra/clangd/tool/ClangdMain.cpp
index 865dd0a44aa4a9..ca5cced197cd24 100644
--- a/clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ b/clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -273,15 +273,6 @@ opt ImportInsertions{
 init(CodeCompleteOptions().ImportInsertions),
 };
 
-opt IncludeCleanerStdlib{
-"include-cleaner-stdlib",
-cat(Features),
-desc("Apply include-cleaner analysis to standard library headers "
- "(immature!)"),
-init(false),
-Hidden,
-};
-
 opt HeaderInsertionDecorators{
 "header-insertion-decorators",
 cat(Features),
@@ -317,7 +308,7 @@ RetiredFlag CrossFileRename("cross-file-rename");
 RetiredFlag ClangTidyChecks("clang-tidy-checks");
 RetiredFlag InlayHints("inlay-hints");
 RetiredFlag FoldingRanges("folding-ranges");
-
+RetiredFlag IncludeCleanerStdlib("include-cleaner-stdlib");
 
 opt LimitResults{
 "limit-results",
@@ -968,7 +959,6 @@ clangd accepts flags on the commandline, and in the 
CLANGD_FLAGS environment var
   };
   if (ForceOffsetEncoding != OffsetEncoding::UnsupportedEncoding)
 Opts.Encoding = ForceOffsetEncoding;
-  setIncludeCleanerAnalyzesStdlib(IncludeCleanerStdlib);
 
   if (CheckFile.getNumOccurrences()) {
 llvm::SmallString<256> Path;

diff  --git a/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp 
b/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
index aefdba05dace7a..c55351fb1f91d8 100644
--- a/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -73,10 +73,6 @@ MATCHER_P(writtenInclusion, Written, "") {
 }
 
 TEST(IncludeCleaner, StdlibUnused) {
-  setIncludeCleanerAnalyzesStdlib(true);
-  auto Cleanup =
-  llvm::make_scope_exit([] { setIncludeCleanerAnalyzesStdlib(false); });
-
   auto TU = TestTU::withCode(R"cpp(
 #include 
 #include 



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


[PATCH] D155705: [clang] Fix specialization of non-templated member classes of class templates

2023-07-19 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added a comment.

Thank you for the fix! Can you explain why the fix fixes the bug? It is not a 
lot of change but I am not familiar enough to see what the underlying issue 
actually is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155705

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


[clang] eddc485 - [Driver][test] Add -no-canonical-prefixes after D154357

2023-07-19 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2023-07-19T14:39:52-07:00
New Revision: eddc4850d81f4c9f79d0b17869d67eac8ca88070

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

LOG: [Driver][test] Add -no-canonical-prefixes after D154357

If the path components of %clang contain a symlink, e.g.

```
% cd /tmp; ln -s Rel xxx
% /tmp/xxx/bin/clang --target=powerpc-unknown-eabi -xc /dev/null '-###'
InstalledDir: /tmp/xxx/bin
...
"-internal-isystem" 
"/tmp/Rel/bin/../lib/clang-runtimes/powerpc-unknown-eabi/include"
```

the test will fail. Such commands should use -no-canonical-prefixes, or
derive the include and library paths from cc1 -isysroot using driver
--sysroot.

Added: 


Modified: 
clang/test/Driver/baremetal.cpp

Removed: 




diff  --git a/clang/test/Driver/baremetal.cpp b/clang/test/Driver/baremetal.cpp
index 4e29be813d152f..c04f4506a0994d 100644
--- a/clang/test/Driver/baremetal.cpp
+++ b/clang/test/Driver/baremetal.cpp
@@ -385,7 +385,7 @@
 // CHECK-RV32IMAFC-SAME: 
"-L[[SYSROOT:[^"]+]]{{[/\\]+}}rv32imafc{{[/\\]+}}ilp32f{{[/\\]+}}lib"
 // CHECK-RV32IMAFC-SAME: 
"-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal{{[/\\]+}}rv32imafc{{[/\\]+}}ilp32f"
 
-// RUN: %clang %s -### --target=powerpc-unknown-eabi 2>&1 \
+// RUN: %clang -no-canonical-prefixes %s -### --target=powerpc-unknown-eabi 
2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PPCEABI %s
 // CHECK-PPCEABI: InstalledDir: [[INSTALLEDDIR:.+]]
 // CHECK-PPCEABI: "-nostdsysteminc"
@@ -398,7 +398,7 @@
 // CHECK-PPCEABI-SAME: "-L[[RESOURCE]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-PPCEABI-SAME: "-lc" "-lm" "-lclang_rt.builtins-powerpc" "-o" "a.out"
 
-// RUN: %clang %s -### --target=powerpc64-unknown-eabi 2>&1 \
+// RUN: %clang -no-canonical-prefixes %s -### --target=powerpc64-unknown-eabi 
2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PPC64EABI %s
 // CHECK-PPC64EABI: InstalledDir: [[INSTALLEDDIR:.+]]
 // CHECK-PPC64EABI: "-nostdsysteminc"
@@ -411,7 +411,7 @@
 // CHECK-PPC64EABI-SAME: "-L[[RESOURCE]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-PPC64EABI-SAME: "-lc" "-lm" "-lclang_rt.builtins-powerpc64" "-o" 
"a.out"
 
-// RUN: %clang %s -### --target=powerpcle-unknown-eabi 2>&1 \
+// RUN: %clang -no-canonical-prefixes %s -### --target=powerpcle-unknown-eabi 
2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PPCLEEABI %s
 // CHECK-PPCLEEABI: InstalledDir: [[INSTALLEDDIR:.+]]
 // CHECK-PPCLEEABI: "-nostdsysteminc"
@@ -424,7 +424,7 @@
 // CHECK-PPCLEEABI-SAME: "-L[[RESOURCE]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-PPCLEEABI-SAME: "-lc" "-lm" "-lclang_rt.builtins-powerpcle" "-o" 
"a.out"
 
-// RUN: %clang %s -### --target=powerpc64le-unknown-eabi 2>&1 \
+// RUN: %clang -no-canonical-prefixes %s -### 
--target=powerpc64le-unknown-eabi 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PPC64LEEABI %s
 // CHECK-PPC64LEEABI: InstalledDir: [[INSTALLEDDIR:.+]]
 // CHECK-PPC64LEEABI: "-nostdsysteminc"



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


[PATCH] D142660: [AIX] supporting -X options for llvm-ranlib in AIX OS

2023-07-19 Thread Digger Lin via Phabricator via cfe-commits
DiggerLin marked 10 inline comments as done.
DiggerLin added inline comments.



Comment at: llvm/tools/llvm-ar/llvm-ar.cpp:1394
   object::Archive::K_AIXBIG) {
 Match = *(*ArgIt + 2) != '\0' ? *ArgIt + 2 : *(++ArgIt);
 BitMode = getBitMode(Match);

jhenderson wrote:
> Unrelated to this patch, but I spotted this when comparing the llvm-ar and 
> llvm-ranlib parsing logic: what happens if -X is the very final argument, 
> without a value? E.g. `llvm-ar (any other args...) -X`?
```
-bash-5.0$ /home/zhijian/llvm/dev/build/bin/llvm-ar -X  tmpk.a d_default.o

/home/zhijian/llvm/dev/build/bin/llvm-ar: error: invalid bit mode: tmpk.a


-bash-5.0$ ar -X tmpk.a d_default.o
ar: 0707-132 The specified object mode is not valid.
Specify -X32, -X64, -X32_64, -Xd64, or -Xany

-bash-5.0$llvm-ranlib -X  tmpk.a d_default.o
llvm-ranlib: error: the specified object mode is not valid. Specify -X32, -X64, 
or -X32_64

-bash-5.0$ ranlib -X  tmpk.a d_default.o
0654-602 The specified object mode is not valid.
Specify -X32, -X64, or -X32_64.
```

I will change the behaviors of llvm-ar in a new separate patch. 



Comment at: llvm/tools/llvm-ar/llvm-ar.cpp:1437
+const char *Xarg = arg.data();
+if (Xarg[0] == '\0')
+  BitMode = BitModeTy::Unknown;

jhenderson wrote:
> If I'm reading this correctly, llvm-ranlib will accept "-X32" but reject "-X 
> 32". Is that intentional? If so, what's the motivation behind it (I would say 
> that there needs to be a motivation other than "that's what AIX ranlib does)?
thanks. add functionality to accept -X 32



Comment at: llvm/tools/llvm-ar/llvm-ar.cpp:1442
+
+// -X option in ranlib do not accept "any"
+if (BitMode == BitModeTy::Unknown || BitMode == BitModeTy::Any)

jhenderson wrote:
> I know that AIX ranlib doesn't accept "any" whereas I believe AIX ar does. I 
> wonder though what the benefit is of preventing llvm-ranlib from accepting 
> "any"? Dropping that special case would simplify the code.
agree with you. but we discussed about whether to accept `any` in our internal 
, we decide to keep all the behavior  as AIX `ranlib`



Comment at: llvm/tools/llvm-ar/llvm-ar.cpp:1463
 
+  if (object::Archive::getDefaultKindForHost() == object::Archive::K_AIXBIG) {
+// If not specify -X option, get BitMode from enviorment variable

jhenderson wrote:
> Is there a particular reason that this is after the command-line option 
> parsing for llvm-ranlib, but before it in llvm-ar? If this were before the 
> option parsing, you wouldn't need the `HasAixXOption` variable.
in AIX OS  `ranlib` has behavior as


```
-bash-5.0$ env OBJECT_MODE=31 ranlib tmpk.a
0654-603 The OBJECT_MODE environment variable has an invalid setting.
OBJECT_MODE must be 32, 64, or 32_64.
-bash-5.0$ env OBJECT_MODE=31 ranlib -X32  tmpk.a
-bash-5.0$
```  

Given invalid env OBJECT_MODE , if there is no -X option in the ranlib command, 
it will output as 

```
0654-603 The OBJECT_MODE environment variable has an invalid setting.
OBJECT_MODE must be 32, 64, or 32_64.
```

Given invalid env OBJECT_MODE , and there is -X option in the ranlib command,  
it do not care about the invalid env OBJECT_MODE,  So I has to parse the -X 
option before the getBitMode(getenv("OBJECT_MODE"))




Comment at: llvm/tools/llvm-ar/llvm-ar.cpp:1469-1471
+  if (BitMode == BitModeTy::Any || BitMode == BitModeTy::Unknown)
+fail("The OBJECT_MODE environment variable has an invalid setting. "
+ "OBJECT_MODE must be 32, 64, or 32_64.");

jhenderson wrote:
> This is an inconsistency with llvm-ar's current behaviour: llvm-ar treats 
> `Unknown` as 32, whereas here you're outright rejecting it. I'm not convinced 
> this inconsistency makes sense, nor do I see it benefiting the user. In my 
> opinion the two should do the same thing. I think a garbage string should be 
> outright rejected in both cases. An empty string for the environment variable 
> or command-line option should probably be rejected too, but I'm okay with it 
> being accepted, if AIX ranlib behaves that way. However, I think llvm-ranlib 
> and llvm-ar should do the same whatever that is.
> 
> Once these inconsistencies have been ironed out, I think it'll be a lot 
> simpler to share code between the two tools.
In AIX OS , `nm` and `ar` , do not accept invalid env var OBJECT_MODE, for 
example, I will create two separate patches to fix the behavior of llvm-nm and 
llvm-ar (they look invalid env var OBJECT_MODE as default 32bit)


```
bash-5.0$ env OBJECT_MODE=31 nm   d_default.o
0654-216 nm: The OBJECT_MODE environment variable has an invalid setting.
OBJECT_MODE must be 32, 64, 32_64, d64 or any.
-bash-5.0$ env OBJECT_MODE=31 ar  -q tmpk.a d_default.o
ar: 0707-133 The OBJECT_MODE environment 

[PATCH] D155385: [clangd] enable unused-include warnings for standard library headers

2023-07-19 Thread Sam McCall via Phabricator via cfe-commits
sammccall marked an inline comment as done.
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:75-77
+if (tooling::stdlib::Header::named(Inc.Written))
   return true;
 return false;

kadircet wrote:
> 
believe it or not, this doesn't compile: something something explicit 
conversions
(done though)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155385

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


[PATCH] D150226: [Clang] Remove ability to downgrade warning on the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values

2023-07-19 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D150226#4515843 , @aaron.ballman 
wrote:

> In D150226#4515783 , @dblaikie 
> wrote:
>
>> In D150226#4498024 , 
>> @aaron.ballman wrote:
>>
>>> In D150226#4461846 , @efriedma 
>>> wrote:
>>>
 The fundamental problem here is the interaction with SFINAE; if we don't 
 diagnose this as an error, we actually miscompile some cases.  Because of 
 that, a flag wouldn't really be "turning off the warning"; it would be 
 enabling a non-compliant language mode that has different rules for 
 whether enum casts are legal.

 If it weren't for that, I don't think anyone would be in a hurry to turn 
 the warning into a hard error.
>>>
>>> +1 to this. I'm worried about the miscompiles continuing in the wild. We 
>>> did the best we could when landing the warning-as-error changes in D131307 
>>>  by telling users explicitly "This 
>>> diagnostic is expected to turn into an error-only diagnostic in the next 
>>> Clang release." in the release notes. Obviously, that's not ideal because 
>>> very few folks read release notes, but we don't have any better mechanism 
>>> for communicating these kinds of changes.
>>>
>>> What do folks think is a reasonable path forward here? Given that we're 
>>> going to branch the Clang 17 release in a few weeks (AIUI), my suggestion 
>>> is to kick the can down the road by landing these changes just after we 
>>> branch. That way the changes land such that early adopters can test and see 
>>> how disruptive we're being without time pressure or hassle of dealing with 
>>> release branches. Do folks think that's a reasonable approach? (I'm open to 
>>> other suggestions.)
>>
>> I'm not quite following if/what the objection is to removing the "ignore in 
>> system headers" for the warning for a release or two prior to making this a 
>> hard error? That seems like a fairly low-cost change (it does kick the can 
>> down the road a release or two before it becomes a hard error - but isn't 
>> worse for users, for the most part - if they were going to get a hard error 
>> from a system header before, at least now instead they'd get a warning or 
>> warning-defaulted-to-error instead, they could turn it off (but they had 
>> been warned that their system headers were going to cause them problems 
>> soon) and then it becomes a hard error a release or two later).
>
> Thank you for bringing that up, sorry for not being more explicit -- by 
> "these changes", I meant "whatever form we decide they should take" as 
> opposed to "the patch as it is now."

Ah, OK.

> In terms of removing the "ignore in system headers" flag, I'm not strongly 
> opposed to it, but I do worry it will throw the baby out with the bathwater. 
> The specific use case I'm worried about is: user has a system header with the 
> problematic code, they run into this diagnostic and they can't address it 
> themselves so they disable the warning for the project. The user then doesn't 
> learn about the problems in their own (non-system header) code until it 
> becomes a hard error later.

OK, I think we're still talking past each other/making different comparisons.
I think you're comparing "make this a warning in system headers" to "not doing 
anything" (so, yes, it causes people to ignore the warning even in their own 
code when if they had done nothing/we had done nothing to force them, they 
would've kept getting the warning in their code)
Whereas I'm comparing "make this a warning in system headers" to "making this a 
hard error" (in which case a user for which it would've been a hard error and 
they'd have had no choice but to fix their system headers (might be 
hard/impossible) would have some relief valve for a time/some notice that this 
would be a problem in the future when it becomes a hard error)

If we picture a timeline:
Time 1) Code is valid/no problem
Time 2) Warning added (not in system headers)
Time 3) Warning becomes error by default (but could be disabled by a user) 
(still not in system headers)
Time 4) Becomes hard error

And if someone has a system header with a violation, they won't know about it 
until (4) and they won't be able to do much/anything about it.

I'm suggesting making the process longer.

Time 4) default-error warning becomes enabled in system headers

Users who, in the first timeline, would be stuck - at least have a release 
valve. I think they are better off than they were in the first timeline - even 
though they lose warning coverage over their own code (which is bad), at least 
they can still build their project and know they have problems in their system 
headers they should report/etc and try to have addressed.

then Time 5) make it a hard error.

So it takes a bit longer to get to (5), and users who would be OK in the 
original 

[PATCH] D155729: [OptTable] Make explicitly included options override excluded ones

2023-07-19 Thread Justin Bogner via Phabricator via cfe-commits
bogner added inline comments.



Comment at: clang/include/clang/Driver/Options.h:40
+  Ignored = (1 << 18),
+  TargetSpecific = (1 << 19),
 };

bob80905 wrote:
> Given that the id for these flags have changed, does it make sense to write a 
> test that makes sure these flags with these bits still behave as expected? 
> (Ignored and target specific, specifically).
The actual values of the flags aren't really visible anywhere (and in the case 
of ignored, it's actually just changing the value back to what it was before 
https://reviews.llvm.org/D128462). I'm not sure that there's much we can do to 
write such a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155729

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


[PATCH] D155641: [-Wunsafe-buffer-usage] Do not assert that function parameters have names.

2023-07-19 Thread Ziqing Luo via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
ziqingluo-90 marked an inline comment as done.
Closed by commit rG4b5f17e008c6: [-Wunsafe-buffer-usage] Do not assert that 
function parameters have names (authored by ziqingluo-90).

Changed prior to commit:
  https://reviews.llvm.org/D155641?vs=541723=542188#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155641

Files:
  clang/lib/Analysis/UnsafeBufferUsage.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp


Index: clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
@@ -156,4 +156,9 @@
   if (++MyName){}
 }
 
+// CHECK-NOT: fix-it:{{.*}}:
+void parmHasNoName(int *p, int *) { // cannot fix the function because there 
is one parameter has no name.
+  p[5] = 5;
+}
+
 #endif
Index: clang/lib/Analysis/UnsafeBufferUsage.cpp
===
--- clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -1885,9 +1885,12 @@
   const ParmVarDecl *Parm = FD->getParamDecl(i);
 
   if (Parm->isImplicit())
-continue;
-  assert(Parm->getIdentifier() &&
- "A parameter of a function definition has no name");
+continue;  
+  // FIXME: If a parameter has no name, it is unused in the
+  // definition. So we could just leave it as it is.
+  if (!Parm->getIdentifier()) 
+   // If a parameter of a function definition has no name:
+return std::nullopt;
   if (i == ParmIdx)
 // This is our spanified paramter!
 SS << NewTypeText.str() << "(" << 
Parm->getIdentifier()->getName().str() << ", "


Index: clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
@@ -156,4 +156,9 @@
   if (++MyName){}
 }
 
+// CHECK-NOT: fix-it:{{.*}}:
+void parmHasNoName(int *p, int *) { // cannot fix the function because there is one parameter has no name.
+  p[5] = 5;
+}
+
 #endif
Index: clang/lib/Analysis/UnsafeBufferUsage.cpp
===
--- clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -1885,9 +1885,12 @@
   const ParmVarDecl *Parm = FD->getParamDecl(i);
 
   if (Parm->isImplicit())
-continue;
-  assert(Parm->getIdentifier() &&
- "A parameter of a function definition has no name");
+continue;  
+  // FIXME: If a parameter has no name, it is unused in the
+  // definition. So we could just leave it as it is.
+  if (!Parm->getIdentifier()) 
+	// If a parameter of a function definition has no name:
+return std::nullopt;
   if (i == ParmIdx)
 // This is our spanified paramter!
 SS << NewTypeText.str() << "(" << Parm->getIdentifier()->getName().str() << ", "
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 4b5f17e - [-Wunsafe-buffer-usage] Do not assert that function parameters have names

2023-07-19 Thread Ziqing Luo via cfe-commits

Author: Ziqing Luo
Date: 2023-07-19T14:14:28-07:00
New Revision: 4b5f17e008c684998a5ee10454d34714736eb6c5

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

LOG: [-Wunsafe-buffer-usage] Do not assert that function parameters have names

It is possible that a function parameter does not have a name even in
a function definition.  This patch deals with such cases in generating
function overload fix-its for safe buffers.

Reviewed by: NoQ (Artem Dergachev)

Differential revision: https://reviews.llvm.org/D155641

Added: 


Modified: 
clang/lib/Analysis/UnsafeBufferUsage.cpp
clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp

Removed: 




diff  --git a/clang/lib/Analysis/UnsafeBufferUsage.cpp 
b/clang/lib/Analysis/UnsafeBufferUsage.cpp
index 142c56beddafea..495d171c618c99 100644
--- a/clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ b/clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -1885,9 +1885,12 @@ createOverloadsForFixedParams(unsigned ParmIdx, 
StringRef NewTyText,
   const ParmVarDecl *Parm = FD->getParamDecl(i);
 
   if (Parm->isImplicit())
-continue;
-  assert(Parm->getIdentifier() &&
- "A parameter of a function definition has no name");
+continue;  
+  // FIXME: If a parameter has no name, it is unused in the
+  // definition. So we could just leave it as it is.
+  if (!Parm->getIdentifier()) 
+   // If a parameter of a function definition has no name:
+return std::nullopt;
   if (i == ParmIdx)
 // This is our spanified paramter!
 SS << NewTypeText.str() << "(" << 
Parm->getIdentifier()->getName().str() << ", "

diff  --git a/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp 
b/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
index cef6afd5933b3c..85210dd4d337bd 100644
--- a/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
+++ b/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
@@ -156,4 +156,9 @@ void macroIdentifier(int *MACRO_NAME) { // The fix-it ends 
with a macro. It will
   if (++MyName){}
 }
 
+// CHECK-NOT: fix-it:{{.*}}:
+void parmHasNoName(int *p, int *) { // cannot fix the function because there 
is one parameter has no name.
+  p[5] = 5;
+}
+
 #endif



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


[PATCH] D142660: [AIX] supporting -X options for llvm-ranlib in AIX OS

2023-07-19 Thread Digger Lin via Phabricator via cfe-commits
DiggerLin marked 14 inline comments as done.
DiggerLin added a comment.

In D142660#4509464 , @jhenderson 
wrote:

> I still have concerns about the option-parsing logic being duplicated, but 
> I'm out of time to review it now. I'll try to look tomorrow.

In AIX OS , `nm` and `ar` , do not accept invalid env var OBJECT_MODE, for 
example, I will create two patch to fix the behavior of llvm-nm and llvm-ar 
(they look invalid env var OBJECT_MODE as default 32bit)

  bash-5.0$ env OBJECT_MODE=31 nm   d_default.o
  0654-216 nm: The OBJECT_MODE environment variable has an invalid setting.
  OBJECT_MODE must be 32, 64, 32_64, d64 or any.
  -bash-5.0$ env OBJECT_MODE=31 ar  -q tmpk.a d_default.o
  ar: 0707-133 The OBJECT_MODE environment variable has an invalid setting.
  OBJECT_MODE must be 32, 64, 32_64, d64, or any. 






Comment at: llvm/test/tools/llvm-ranlib/aix-X-option.test:17
+## Test OBJECT_MODE environment variable when adding symbol table
+# RUN: env OBJECT_MODE= llvm-ranlib t_X32.a
+# RUN: env OBJECT_MODE=32 llvm-ranlib t_X32.a

jhenderson wrote:
> Doesn't this line want an llvm-nm check after it, like the others?
yes, thanks



Comment at: llvm/test/tools/llvm-ranlib/aix-X-option.test:67
+
+#GL64-NOT:var_0x1F7 in t64_1.o
+#GL64-NOT:array_0x1F7 in t64_1.o

jhenderson wrote:
> I'm concerned you're going to have an ordering issue in one of the 64 bit or 
> 32 bit "NOT" cases. FileCheck -NOT patterns only check the region between the 
> previous non-NOT pattern before the -NOT one up to the next non-NOT pattern 
> (or the end of the file). So, as things stand, --check-prefixes=GLOB32,GL64 
> will verify that the 32-bit table appears and then no 64-bit table is printed 
> AFTER the 32-bit table, but not whether the 64-bit table appears BEFORE the 
> 32-bit table. Similarly, --check-prefixes=GLOB64,GL32 will check that the 
> 64-bit table is printed and then no 32-bit table is printed after it, but not 
> whether the 32-bit table is printed before it.
> 
> Given that the names of the symbols are irrelevant to this test case, and 
> really all that's interesting is which object they're in (since this test 
> isn't about checking that the symbol tables have the correct contents - that 
> is the duty of a test that doesn't make use of the -X option), could you 
> simplify the input objects to have a single like-named symbol and then simply 
> ensure the correct object names appear in the output? You could use 
> --implicit-check-not to check that e.g. "in t64" or "in t32" don't appear in 
> your output.
> 
> If you adopted this approach, you'd have two CHECK lines as e.g. follows:
> ```
> # GLOB32: symbol1 in t32_1.o
> # GLOB32-NEXT: symbol2 in t32_2.o
> 
> # GLOB64: symbol1 in t64_1.o
> # GLOB64-NEXT: symbol2 in t64_2.o
> ```
> And you'd have FileCheck lines that look like one of the following:
> ```
> FileCheck --check-prefixes=GLOB32 --implicit-check-not="in t64"
> FileCheck --check-prefixes=GLOB64 --implicit-check-not="in t32"
> FileCheck --check-prefixes=GLOB32,GLOB64
> ```
> 
> By simplifying down to one symbol each, you could also pass the symbol name 
> in as a yaml2obj -D value and only have one YAML file in the test.
thanks for detail explain, I changed as your suggestion.



Comment at: llvm/tools/llvm-ar/llvm-ar.cpp:74-75
+ << "  -X {32|64|32_64}  - Specifies which archive symbol tables "
+"should"
+"be generated if they do not already exist (AIX OS only)\n";
 }

jhenderson wrote:
> Please reflow this string. That should make it fairly obvious that there's a 
> mistake in it too (hint: print the help and spot the missing space...).
thanks



Comment at: llvm/tools/llvm-ar/llvm-ar.cpp:237
 static bool Verbose = false;  ///< 'v' modifier
-static bool Symtab = true;///< 's' modifier
+static WriteSymTabType Symtab = true; ///< 's' modifier
 static bool Deterministic = true; ///< 'D' and 'U' modifiers

jhenderson wrote:
> DiggerLin wrote:
> > jhenderson wrote:
> > > Maybe I'm missing something, but I don't see why you need to make this a 
> > > custom type. You already have the BitMode value that you read in from the 
> > > environment/command-line, and so you can just use that in conjunction 
> > > with the `Symtab` boolean to determine what symbol table to write, surely?
> > the Symtab are use to specify whether the symbol table need to write(for 
> > non-AIX). and what the symbol table need to write for AIX OS.
> > 
> > there are function like
> > 
> > ```
> >   writeArchiveToBuffer(ArrayRef NewMembers,
> >  WriteSymTabType WriteSymtab, object::Archive::Kind 
> > Kind,
> >  bool Deterministic, bool Thin)
> > ```
> > and 
> > 
> > ```
> > Error writeArchive(StringRef ArcName, ArrayRef 

[PATCH] D86310: [X86] Align i128 to 16 bytes in x86 datalayouts

2023-07-19 Thread Trevor Gross via Phabricator via cfe-commits
tmgross added a comment.

Here's confirmation that `_BitInt(128)` should be 8-byte aligned and not 16 
(so, different from `__int128`) from https://gitlab.com/x86-psABIs/x86-64-ABI:

> • For N > 64, they are treated as struct of 64-bit integer chunks. The number 
> of
> chunks is the smallest number that can contain the type. _BitInt(N) types are
> byte-aligned to 64 bits. The size of these types is the smallest multiple of 
> the 64-bit
> chunks greater than or equal to N.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86310

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


[PATCH] D86310: [X86] Align i128 to 16 bytes in x86 datalayouts

2023-07-19 Thread Harald van Dijk via Phabricator via cfe-commits
hvdijk added a comment.

In D86310#4516184 , @tmgross wrote:

> Is the compatibility note here only meant to address calls between LLVM and 
> GCC, not generated code? Because of course, struct layout and pass-in-memory 
> function calls are incompatible.

There should be no compatibility issue there between GCC and clang in most 
cases, because clang ensures __int128 is aligned to 16 bytes everywhere, even 
if the LLVM data layout specifies lower alignment. clang's __int128 and LLVM's 
i128 play by different rules, currently. This change would make them play by 
the same rules.

> Rust just uses LLVM's `i128` value directly so it doesn't necessarily need to 
> be called out on its own (think we are in agreement here, just clarifying)

I do think it needs to be called out on its own: Rust makes its

>> [...]
>> QUESTIONS
>>
>> Is the behaviour of LLVM, clang, GCC, and MSVC indeed as I described, or did 
>> I make a mistake anywhere?
>
> I believe that MSVC is in general ambiguous about these details on types that 
> it does not support, but I would assume that being consistent with the Linux 
> ABI is preferred and probably what MSVC would choose if they ever do decide 
> on a specification for this type (unless LLVM has contact with Microsoft that 
> may be able to clarify? They make no guarantees against breaking things in 
> any case.)
>
>> [...]
>
> It probably makes sense to have reasoning for choosing the selected behavior 
> and having something specific to test against, so I'll link what I know.
>
> - From AMD4 ABI Draft 0.99.7 (2014) 
> :
>
>> [paraphrased from Figure 3.1]
>> type - sizeof - alignment - AMD64 architecture
>> long - 8 - 8 - signed eightbyte [I included this in the table for the below 
>> reference]
>> `__int128` - 16 - 16 - signed sixteenbyte
>> signed `__int128` - 16 - 16 - signed sixteenbyte
>> `long double` - 16 - 16 - 80-bit extended (IEEE-754)
>> `__float128` - 16 - 16 - 128-bit extended (IEEE-754)
>> [...]
>> The `__int128` type is stored in little-endian order in memory, i.e., the 64
>> low-order bits are stored at a a lower address than the 64 high-order bits
>> [...]
>> Arguments of type `__int128` offer the same operations as INTEGERs,
>> yet they do not fit into one general purpose register but require two 
>> registers.
>> For classification purposes `__int128` is treated as if it were implemented
>> as:
>>
>>   typedef struct {
>>   long low, high;
>>   } __int128;
>>
>> with the exception that arguments of type `__int128` that are stored in
>> memory must be aligned on a 16-byte boundary
>
>
>
> - K1OM agrees 
> https://www.intel.com/content/dam/develop/external/us/en/documents/k1om-psabi-1-0.pdf
> - These types don't seem to be mentioned anywhere in i386 1997 
> https://www.sco.com/developers/devspecs/abi386-4.pdf
> - Also not in MIPS RISC 1996 
> https://math-atlas.sourceforge.net/devel/assembly/mipsabi32.pdf
> - MIPSpro64 doesn't mention 128-bit integers but does mention 128-bit floats. 
> From page 24 https://math-atlas.sourceforge.net/devel/assembly/mipsabi64.pdf
>
>> Quad-precision floating point parameters (C long double or Fortran REAL*16) 
>> are
>> always 16-byte aligned. This requires that they be passed in even-odd 
>> floating point
>> register pairs, even if doing so requires skipping a register parameter 
>> and/or a
>> 64-bit save area slot. [The 32-bit ABI does not consider long double 
>> parameters,
>> since they were not supported.]
>
>
>
> - From PPC64 section 3.1.4 
> https://math-atlas.sourceforge.net/devel/assembly/PPC-elf64abi-1.7.pdf:
>
>> [paraphrased from table]
>> type - sizeof - alignment
>> `__int128_t` - 16 - quadword
>> `__uint128_t` - 16 - quadword
>> `long double` - 16 - quadword
>
>
>
> - z/Arch: this is the only target that clang seems to align to 8, see [1]. 
> Also from 1.1.2.4 in https://github.com/IBM/s390x-abi/releases/tag/v1.6:
>
>> [paraphrased from table]
>> type - size (bytes) - alignment
>> `__int128` - 16 - 8
>> signed `__int128` - 16 - 8
>> `long double` - 16 - 8
>
> [1]: https://reviews.llvm.org/D130900




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86310

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


[PATCH] D154130: [lit] Avoid os.path.realpath on Windows due to MAX_PATH limitations

2023-07-19 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added a comment.

It is unclear to me why/when we would ever want the substitute drive expansion; 
the modified tests aren't very elucidating. My naive expectation is that we 
effectively want to restore the Python 3.7 behavior.




Comment at: clang/test/ExtractAPI/relative_include.m:24
+// RUN: %{/t:real}/Frameworks/MyFramework.framework/Headers/MyHeader.h \
+// RUN: %{/t:real}/QuotedHeader.h \
 // RUN: -o %t/output.json 2>&1 -verify | FileCheck -allow-empty %s

I'm curious why this test requires the `%{/t:real}` normalization. Why would it 
be desirable to expand substitute drives for this test?



Comment at: clang/test/Lexer/case-insensitive-include-win.c:8
 // RUN: touch %t.dir/foo.h
-// RUN: not %clang_cl /FI\\?\%t.dir\FOO.h /WX -fsyntax-only %s 2>&1 | 
FileCheck %s
+// RUN: not %clang_cl /FI\\?\%{t:real}.dir\FOO.h /WX -fsyntax-only %s 2>&1 | 
FileCheck %s
 

I'm curious why this test requires the `%{/t:real}` normalization. Why would it 
be desirable to expand substitute drives for this test?


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

https://reviews.llvm.org/D154130

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


[clang-tools-extra] 2870303 - [clang-tidy][NFC] Fixes in release notes

2023-07-19 Thread Piotr Zegar via cfe-commits

Author: Piotr Zegar
Date: 2023-07-19T20:45:17Z
New Revision: 287030384c90d705fbdb2112cfaf39d1497d23f5

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

LOG: [clang-tidy][NFC] Fixes in release notes

Correct link in release notes and format of some notes.

Added: 


Modified: 
clang-tools-extra/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 1b8f3bf113c01c..1a0dbf0a7db8a6 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -397,7 +397,7 @@ Changes in existing checks
   with attributes and to support nested inline namespace introduced in c++20.
 
 - Fixed an issue in `modernize-loop-convert
-  ` generating wrong code
+  ` generating wrong code
   when using structured bindings.
 
 - In :doc:`modernize-use-default-member-init
@@ -424,12 +424,9 @@ Changes in existing checks
   special member functions are not available.
 
 - Improved :doc:`performance-no-automatic-move
-  `: warn on ``const &&``
-  constructors.
-
-- Fixed a false positive in :doc:`performance-no-automatic-move
-  ` when warning would be
-  emitted for a const local variable to which NRVO is applied.
+  ` check to warn on
+  ``const &&`` constructors and ignore ``const`` local variable to which NRVO
+  is applied.
 
 - Fixed an issue in the :doc:`performance-noexcept-move-constructor
   ` checker that was 
causing



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


[PATCH] D86310: [X86] Align i128 to 16 bytes in x86 datalayouts

2023-07-19 Thread Trevor Gross via Phabricator via cfe-commits
tmgross added a comment.

In D86310#4504168 , @hvdijk wrote:

> THE CURRENT STATE
> [...]
> Compatibility between LLVM and GCC
>
> For x86, the current i128 handling is compatible. The alignment to 8 byte 
> boundaries causes no compatibility issues because nothing else supports i128.
> For x86, the current fp128 handling is incompatible. The use of i128 with 
> lower alignment in a call into libgcc breaks compatibility.
>
> For x64, the current i128 handling is compatible but fragile. The alignment 
> to 8 byte boundaries causes no compatibility issue because all calls into 
> libgcc pass values in registers. If support for _ _udivmodti4 and _ 
> _udivmodti4 were to be added in the future, the current i128 handling would 
> be wrong.
> For x64, the current fp128 handling is compatible. The alignment to 8 byte 
> boundaries causes no compatibility issue because all calls into libgcc pass 
> values in registers. No other libgcc functions use pointers.

Is the compatibility note here only meant to address calls between LLVM and 
GCC, not generated code? Because of course, struct layout and pass-in-memory 
function calls are incompatible.

> ISSUES
>
> As far as I can tell, the compatibility issues in the current version of LLVM 
> are: the fp128 handling in x86, potentially the i128 handling in x64, and the 
> i128 handling in Rust.

Rust just uses LLVM's `i128` value directly so it doesn't necessarily need to 
be called out on its own (think we are in agreement here, just clarifying)

> [...]
> QUESTIONS
>
> Is the behaviour of LLVM, clang, GCC, and MSVC indeed as I described, or did 
> I make a mistake anywhere?

I believe that MSVC is in general ambiguous about these details on types that 
it does not support, but I would assume that being consistent with the Linux 
ABI is preferred and probably what MSVC would choose if they ever do decide on 
a specification for this type (unless LLVM has contact with Microsoft that may 
be able to clarify? They make no guarantees against breaking things in any 
case.)

> [...]

It probably makes sense to have reasoning for choosing the selected behavior 
and having something specific to test against, so I'll link what I know.

- From AMD4 ABI Draft 0.99.7 (2014) 
:

> [paraphrased from Figure 3.1]
> type - sizeof - alignment - AMD64 architecture
> long - 8 - 8 - signed eightbyte [I included this in the table for the below 
> reference]
> `__int128` - 16 - 16 - signed sixteenbyte
> signed `__int128` - 16 - 16 - signed sixteenbyte
> `long double` - 16 - 16 - 80-bit extended (IEEE-754)
> `__float128` - 16 - 16 - 128-bit extended (IEEE-754)
> [...]
> The `__int128` type is stored in little-endian order in memory, i.e., the 64
> low-order bits are stored at a a lower address than the 64 high-order bits
> [...]
> Arguments of type `__int128` offer the same operations as INTEGERs,
> yet they do not fit into one general purpose register but require two 
> registers.
> For classification purposes `__int128` is treated as if it were implemented
> as:
>
>   typedef struct {
>   long low, high;
>   } __int128;
>
> with the exception that arguments of type `__int128` that are stored in
> memory must be aligned on a 16-byte boundary



- K1OM agrees 
https://www.intel.com/content/dam/develop/external/us/en/documents/k1om-psabi-1-0.pdf
- These types don't seem to be mentioned anywhere in i386 1997 
https://www.sco.com/developers/devspecs/abi386-4.pdf
- Also not in MIPS RISC 1996 
https://math-atlas.sourceforge.net/devel/assembly/mipsabi32.pdf
- MIPSpro64 doesn't mention 128-bit integers but does mention 128-bit floats. 
From page 24 https://math-atlas.sourceforge.net/devel/assembly/mipsabi64.pdf

> Quad-precision floating point parameters (C long double or Fortran REAL*16) 
> are
> always 16-byte aligned. This requires that they be passed in even-odd 
> floating point
> register pairs, even if doing so requires skipping a register parameter 
> and/or a
> 64-bit save area slot. [The 32-bit ABI does not consider long double 
> parameters,
> since they were not supported.]



- From PPC64 section 3.1.4 
https://math-atlas.sourceforge.net/devel/assembly/PPC-elf64abi-1.7.pdf:

> [paraphrased from table]
> type - sizeof - alignment
> `__int128_t` - 16 - quadword
> `__uint128_t` - 16 - quadword
> `long double` - 16 - quadword



- z/Arch: this is the only target that clang seems to align to 8, see [1]. Also 
from 1.1.2.4 in https://github.com/IBM/s390x-abi/releases/tag/v1.6:

> [paraphrased from table]
> type - size (bytes) - alignment
> `__int128` - 16 - 8
> signed `__int128` - 16 - 8
> `long double` - 16 - 8

[1]: https://reviews.llvm.org/D130900


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86310

___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D155342: [clang][JumpDiagnostics] ignore non-asm goto target scopes

2023-07-19 Thread Nathan Chancellor via Phabricator via cfe-commits
nathanchance added a comment.

Thanks, I can confirm that the `__attribute__((__cleanup__(...)))` errors that 
we observed with Peter's work-in-progress guards series are resolved and that 
all the errors I observed when building the kernel after 
https://reviews.llvm.org/D154696 was merged are no longer present when that 
change is re-applied on top of this one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155342

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


[PATCH] D155667: [-Wunsafe-buffer-usage] Check source location validity before using `TypeLoc`s

2023-07-19 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155667

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


[PATCH] D153914: [clang-cl] Enable concatenation of predefined identifiers

2023-07-19 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added inline comments.



Comment at: clang/include/clang/Basic/TokenKinds.h:87-93
+/// Return true if this token is a predefined macro
+/// unexpandable by MSVC preprocessor.
+inline bool isUnexpandableMsMacro(TokenKind K) {
+  return K == tok::kw___FUNCTION__ || K == tok::kw___FUNCSIG__ ||
+ K == tok::kw_L__FUNCTION__ || K == tok::kw_L__FUNCSIG__ ||
+ K == tok::kw___FUNCDNAME__;
+}

cor3ntin wrote:
> tahonermann wrote:
> > RIscRIpt wrote:
> > > tahonermann wrote:
> > > > 
> > > Thanks, I like the name. But shouldn't we reflect that we are referring 
> > > to only Microsoft (unexpandable) macros? How about 
> > > `isFunctionLocalPredefinedMsMacro`?
> > I don't think the Microsoft association is meaningful. Sure, some of the 
> > predefined macros are only treated differently when compiling in Microsoft 
> > mode, but some of those macros aren't Microsoft specific. Also, there might 
> > be macros provided by other implementations that we'll want to emulate some 
> > day.
> I think it is, there is currently no way to link 
> `isFunctionLocalPredefinedMacro` to the MS feature. "MSPredefinedMacro" is 
> pretty self explanatory, same reason we most often - but not always - use GNU 
> in the name of function related to GNU extensions.
> There are enough similar-sounding features and extensions that we should try 
> to make it clear which feature we are talking about.
Perhaps we still haven't found the right name then. With the name that I've 
been advocating, this function should also return true for 
`tok::kw___PRETTY_FUNCTION__` even though that macro should not expand to 
something that can be concatenated with other string literals (whether 
compiling in Microsoft mode or not).

The Microsoft extension is the localized expansion to a string literal that can 
be concatenated with other string literals. We probably should isolate the 
conditions for that behavior to one place and if we do that, then I guess 
naming this function as specific to Microsoft mode is ok; we can always rename 
it later if it gets used for non-Microsoft extensions.

Here is my suggestion then:
  // Return true if the token corresponds to a function local predefined
  // macro that, in Microsoft modes, expands to a string literal (that can
  // then be concatenated with other string literals).
  inline bool isMsFunctionLocalStringLiteralMacro(TokenKind K, const 
LangOptions ) {
return langOpts.MicrosoftExt && (
K == tok::kw___FUNCTION__ || K == tok::kw_L__FUNCTION__ ||
K == tok::kw___FUNCSIG__ || K == tok::kw_L__FUNCSIG__ ||
K == tok::kw___FUNCDNAME__);
  }  

This will avoid the need for callers to check for `MicrosoftExt`; that is what 
I really want to avoid since it is easy to forget to do that check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153914

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


[PATCH] D153092: [Clang][CodeGen]`vtable`, `typeinfo` et al. are globals

2023-07-19 Thread Alex Voicu via Phabricator via cfe-commits
AlexVlx added inline comments.



Comment at: clang/lib/CodeGen/CGVTables.cpp:836
+fnPtr =
+llvm::ConstantExpr::getAddrSpaceCast(fnPtr, CGM.GlobalsInt8PtrTy);
+  return builder.add(fnPtr);

efriedma wrote:
> If I follow correctly, the fnPtr is guaranteed to be in the global 
> address-space, but GetAddrOfFunction returns a generic pointer.  So the 
> vtable entries are in the global address-space for efficiency? Seems 
> reasonable.
> 
> There isn't really much point to explicitly checking `FnAS != GVAS` before 
> the call to getAddrSpaceCast; getAddrSpaceCast does the same check internally.
Right, we know that these are going to be in global memory, and there is 
overhead when dealing with flat/generic. I would've liked to remove the check, 
but I think that's infeasible with how getAddrSpaceCast is currently 
implemented, because it `assert`s on `castIsValid`; addrspacecasts from the 
same AS to the same AS are invalid, so the `assert` flares on targets where 
FnAS == GVAS (e.g. x86). This is not super ergonomic IMHO, as it should be 
valid & a NOP just returning the source, but that's a change that would be 
required to allow deleting the silly check, I believe.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153092

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


[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration

2023-07-19 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: flang/runtime/CMakeLists.txt:251
 
-  INSTALL_WITH_TOOLCHAIN
-)
+if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+  add_flang_library(FortranRuntime STATIC

pscoro wrote:
> efriedma wrote:
> > pscoro wrote:
> > > efriedma wrote:
> > > > This "if" doesn't make sense to me.  If we're not building flang-rt, we 
> > > > shouldn't be here, so I don't see why you need an "if" in the first 
> > > > place.
> > > `add_subdirectory(runtime)` is a line that still exists in 
> > > `flang/CMakeLists.txt`. This exists because `Fortran_main` is still being 
> > > built at the same time as the compiler, and to do so, the runtime 
> > > subdirectory still needs to be added to flang (`flang/CMakeLists.txt` -> 
> > > `add_subdirectory(runtime)` -> `flang/runtime/CMakeLists.txt` -> 
> > > `add_subdirectory(FortranMain)`. The solution I had was to just add a 
> > > check around the `FortranRuntime` library production so that it only 
> > > happens for flang-rt.
> > > 
> > > If you have a better solution let me know. Overall, I'm not sure if 
> > > Fortran_main is currently being handled in the best way (ie, its still 
> > > being built at the same time as the compiler, which doesn't seem ideal), 
> > > but am not sure what course of action to take with it since it doesn't 
> > > really belong in flang-rt either (see documentation for details)
> > Fortran_main should be "part of" flang-rt in the sense that building 
> > flang-rt builds it.  Most of the same reasons we want to build flang-rt.a 
> > as a runtime apply.
> > 
> > Since the output needs to be separate, building flang-rt should produce two 
> > libraries: flang-rt.a and FortranMain.a.
> I agree with this idea and have been trying to make it work but in the 
> process I discovered that my "fix" above (`if (DEFINED LLVM_ENABLE_RUNTIMES 
> AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)`) is worse than I thought.
> 
> By building the llvm target with flang-rt as an enabled runtime, we are 
> essentially saying: build the flang compiler, and then invoke cmake again to 
> build the runtimes project (externally), which builds flang-rt.
> 
> The problem is that check-all depends on check-flang which depends on the 
> runtime. The if guard above was not actually doing what I thought it was, and 
> the reason why configuring didnt fail with "flang-rt does not exist" is 
> because the if guard was still evaluating to true. Basically, the guard 
> ensured that FortranRuntime was only being built if flang-rt is built, but 
> the add_library call was still being reached *during the configuration of the 
> flang compiler*.
> 
> I am having trouble dealing with this dependency since runtimes get built 
> externally (and after the compiler is built, which is when the check-all 
> custom target gets built). I will have to investigate more closely how other 
> runtimes handle this. My initial thought was perhaps the runtime testing 
> should be decoupled from check-flang/check-all however I don't know if that's 
> a good idea, and I also think that only helps with flang-rt, but if 
> Fortran_main is required to build any executable I imagine that it should be 
> needed for check-flang?
> 
> This is just an update of whats holding me back right now. If you have any 
> tips please let me know. Thanks for bringing this to my attention.
For comparison, check-clang doesn't require any runtime libraries at all. All 
the checks only check the generated LLVM IR/driver commands/etc.  Any tests 
that require runtime execution go into either the regression tests for the 
runtimes themselves, or into lllvm-test-suite.

Probably check-flang should do something similar. It probably makes sense to 
add a check-flang-rt target or something like that.  (Not sure which existing 
flang tests are impacted.)


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


[PATCH] D151834: Include math-errno with fast-math

2023-07-19 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added a comment.

Review anyone please? Thanks.


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

https://reviews.llvm.org/D151834

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


[PATCH] D147283: [Sema] Search template parameter scopes before searching namespace/file scopes when performing unqualified name lookup

2023-07-19 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak updated this revision to Diff 542165.
ahatanak added a comment.

Remove unneeded code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147283

Files:
  clang/lib/Sema/SemaLookup.cpp
  clang/test/SemaCXX/namespace.cpp

Index: clang/test/SemaCXX/namespace.cpp
===
--- clang/test/SemaCXX/namespace.cpp
+++ clang/test/SemaCXX/namespace.cpp
@@ -96,3 +96,12 @@
 
   }
 }
+
+namespace N0 {
+  template  class S;
+  template  class C;
+}
+
+template  class N0::C {
+  void foo(S c) {}
+};
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -1298,13 +1298,20 @@
   // }
   //
   UnqualUsingDirectiveSet UDirs(*this);
-  bool VisitedUsingDirectives = false;
   bool LeftStartingScope = false;
 
   // When performing a scope lookup, we want to find local extern decls.
   FindLocalExternScope FindLocals(R);
+  Scope *InnermostFileScope = nullptr;
+  DeclContext *InnermostFileScopeDC = nullptr;
+
+  for (; S; S = S->getParent()) {
+if (isNamespaceOrTranslationUnitScope(S)) {
+  if (!InnermostFileScope)
+InnermostFileScope = S;
+  continue;
+}
 
-  for (; S && !isNamespaceOrTranslationUnitScope(S); S = S->getParent()) {
 bool SearchNamespaceScope = true;
 // Check whether the IdResolver has anything in this scope.
 for (; I != IEnd && S->isDeclScope(*I); ++I) {
@@ -1387,34 +1394,8 @@
 // If this is a file context, we need to perform unqualified name
 // lookup considering using directives.
 if (Ctx->isFileContext()) {
-  // If we haven't handled using directives yet, do so now.
-  if (!VisitedUsingDirectives) {
-// Add using directives from this context up to the top level.
-for (DeclContext *UCtx = Ctx; UCtx; UCtx = UCtx->getParent()) {
-  if (UCtx->isTransparentContext())
-continue;
-
-  UDirs.visit(UCtx, UCtx);
-}
-
-// Find the innermost file scope, so we can add using directives
-// from local scopes.
-Scope *InnermostFileScope = S;
-while (InnermostFileScope &&
-   !isNamespaceOrTranslationUnitScope(InnermostFileScope))
-  InnermostFileScope = InnermostFileScope->getParent();
-UDirs.visitScopeChain(Initial, InnermostFileScope);
-
-UDirs.done();
-
-VisitedUsingDirectives = true;
-  }
-
-  if (CppNamespaceLookup(*this, R, Context, Ctx, UDirs)) {
-R.resolveKind();
-return true;
-  }
-
+  if (!InnermostFileScopeDC)
+InnermostFileScopeDC = Ctx;
   continue;
 }
 
@@ -1430,6 +1411,8 @@
 }
   }
 
+  S = InnermostFileScope;
+
   // Stop if we ran out of scopes.
   // FIXME:  This really, really shouldn't be happening.
   if (!S) return false;
@@ -1443,11 +1426,45 @@
   //
   // FIXME: Cache this sorted list in Scope structure, and DeclContext, so we
   // don't build it for each lookup!
-  if (!VisitedUsingDirectives) {
-UDirs.visitScopeChain(Initial, S);
-UDirs.done();
+
+  // Add using directives from the innermost file scope context up to the top
+  // level.
+  for (DeclContext *UCtx = InnermostFileScopeDC; UCtx;
+   UCtx = UCtx->getParent()) {
+if (UCtx->isTransparentContext())
+  continue;
+
+UDirs.visit(UCtx, UCtx);
   }
 
+  // Add using directives from local scopes.
+  UDirs.visitScopeChain(Initial, S);
+  UDirs.done();
+
+  // Search the file scope DCs between the innermost file scope DC and the DC
+  // corresponding to the innermost file scope. This is needed, for example, in
+  // the following case where namespace 'N' cannot be found on the scope stack:
+  //
+  // namespace N {
+  // struct B {
+  //   B(int);
+  // };
+  // typedef B typedef_B;
+  // struct D : B {
+  //   D();
+  // };
+  // }
+  //
+  // N::D::D() : typedef_B(0) {}
+
+  for (DeclContext *Ctx = InnermostFileScopeDC, *LastCtx = S->getEntity();
+   Ctx && !Ctx->Equals(LastCtx); Ctx = Ctx->getLookupParent())
+if (!Ctx->isTransparentContext() &&
+CppNamespaceLookup(*this, R, Context, Ctx, UDirs)) {
+  R.resolveKind();
+  return true;
+}
+
   // If we're not performing redeclaration lookup, do not look for local
   // extern declarations outside of a function scope.
   if (!R.isForRedeclaration())
@@ -1458,6 +1475,9 @@
   // that aren't strictly lexical, and therefore we walk through the
   // context as well as walking through the scopes.
   for (; S; S = S->getParent()) {
+if (!isNamespaceOrTranslationUnitScope(S))
+  continue;
+
 // Check whether the IdResolver has anything in this scope.
 bool Found = false;
 for (; I != IEnd && S->isDeclScope(*I); ++I) 

[PATCH] D147283: [Sema] Search template parameter scopes before searching namespace/file scopes when performing unqualified name lookup

2023-07-19 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added inline comments.



Comment at: clang/lib/Sema/SemaLookup.cpp:1403
+  // Find the innermost file scope, so we can add using directives
+  // from local scopes.
+  InnermostFileScope = S;

This isn't needed as `InnermostFileScope` is set at the beginning of the loop.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147283

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


[PATCH] D153092: [Clang][CodeGen]`vtable`, `typeinfo` et al. are globals

2023-07-19 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGVTables.cpp:836
+fnPtr =
+llvm::ConstantExpr::getAddrSpaceCast(fnPtr, CGM.GlobalsInt8PtrTy);
+  return builder.add(fnPtr);

If I follow correctly, the fnPtr is guaranteed to be in the global 
address-space, but GetAddrOfFunction returns a generic pointer.  So the vtable 
entries are in the global address-space for efficiency? Seems reasonable.

There isn't really much point to explicitly checking `FnAS != GVAS` before the 
call to getAddrSpaceCast; getAddrSpaceCast does the same check internally.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153092

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


[PATCH] D147283: [Sema] Search template parameter scopes before searching namespace/file scopes when performing unqualified name lookup

2023-07-19 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added inline comments.



Comment at: clang/lib/Sema/SemaLookup.cpp:1392
-  if (!VisitedUsingDirectives) {
-// Add using directives from this context up to the top level.
-for (DeclContext *UCtx = Ctx; UCtx; UCtx = UCtx->getParent()) {

I noticed that we aren't visiting the contexts from the inside out despite the 
comment here: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaLookup.cpp#L133

```
// A given context is only every visited once, so it is important
// that contexts be visited from the inside out in order to get
// the effective DCs right.
```

But I think that's OK. I haven't been able to come up with an example where 
this is causing a problem.



Comment at: clang/lib/Sema/SemaLookup.cpp:1428
   // FIXME:  This really, really shouldn't be happening.
   if (!S) return false;
 

I think this line can be moved to the beginning of the function .I can try that 
after committing this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147283

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


[PATCH] D144164: [clang][Interp] Handle PtrMemOps

2023-07-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:234
 
+  if (!LT || !RT || !T)
+return this->bail(BO);

Should we be checking `!T` earlier (it's used within the `Discard` lambda with 
an unprotected dereference)?


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

https://reviews.llvm.org/D144164

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


[PATCH] D144164: [clang][Interp] Handle PtrMemOps

2023-07-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:213-214
 
+  if (BO->isPtrMemOp())
+return this->visit(RHS);
+

Do we need similar changes for unary operators, pointer arithmetic operators, 
etc?



Comment at: clang/lib/AST/Interp/Context.cpp:121
+  if (T->isFunctionPointerType() || T->isFunctionReferenceType() ||
+  T->isFunctionProtoType())
+return PT_FnPtr;

`isFunctionType()` in general?


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

https://reviews.llvm.org/D144164

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


[PATCH] D151587: [clang][ConstantEmitter] have tryEmitPrivate[ForVarInit] try ConstExprEmitter fast-path first

2023-07-19 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:8360
+  // Do not constant fold an R-value.
+  if (Info.EvalMode == EvalInfo::EM_ConstantFold && !E->isLValue())
+return false;

efriedma wrote:
> nickdesaulniers wrote:
> > efriedma wrote:
> > > nickdesaulniers wrote:
> > > > nickdesaulniers wrote:
> > > > > efriedma wrote:
> > > > > > nickdesaulniers wrote:
> > > > > > > efriedma wrote:
> > > > > > > > Checking isLValue() doesn't make sense; consider:
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > struct R { mutable long x; };
> > > > > > > > struct Z { const R , y; };
> > > > > > > > Z z = { R{1}, z.x.x=10 };
> > > > > > > > ```
> > > > > > > > 
> > > > > > > > Maybe also want to check for EM_IgnoreSideEffects?  Not sure 
> > > > > > > > what cases, if any, that would affect.
> > > > > > > > 
> > > > > > > > We should probably check `E->getStorageDuration() == 
> > > > > > > > SD_Static`.  The cases where it's a local temporary don't hit 
> > > > > > > > the getOrCreateValue() codepath, so the evaluated value should 
> > > > > > > > be handled correctly.
> > > > > > > > 
> > > > > > > > Checking EvalMode feels a little weird, but I guess it should 
> > > > > > > > do the right thing in the cases I can think of?  I'd like a 
> > > > > > > > second opinion on this.
> > > > > > > Changing this condition to:
> > > > > > > ```
> > > > > > > if (E->getStorageDuration() == SD_Static &&   
> > > > > > > 
> > > > > > > Info.EvalMode == EvalInfo::EM_ConstantFold && 
> > > > > > > 
> > > > > > > E->isXValue())
> > > > > > > 
> > > > > > >   return false;
> > > > > > > ```
> > > > > > > allows all tests in tree to pass, but messes up the test case you 
> > > > > > > posted above. I'm trying to sus out what else might be different 
> > > > > > > about that test case...we should return `false` for that, but I'm 
> > > > > > > not sure what's different about that case.
> > > > > > > 
> > > > > > > In particular, I was playing with 
> > > > > > > `E->isUsableInConstantExpressions` and 
> > > > > > > `E->getLifetimeExtendedTemporaryDecl()`, but getting your case to 
> > > > > > > work, I end up regressing 
> > > > > > > clang/test/SemaCXX/attr-require-constant-initialization.cpp...argh!!
> > > > > > Shouldn't that just be the following?
> > > > > > 
> > > > > > ```
> > > > > > if (E->getStorageDuration() == SD_Static && 
> > > > > >   
> > > > > > Info.EvalMode == EvalInfo::EM_ConstantFold) 
> > > > > >
> > > > > >   return false;
> > > > > > ```
> > > > > > 
> > > > > > A materialized temporary is always going to be either an LValue or 
> > > > > > an XValue, and the difference between the two isn't relevant here.
> > > > > I wish it were that simple. Checking those two alone will produce 
> > > > > failures in the following tests:
> > > > > 
> > > > > Failed Tests (2):
> > > > >   Clang :: CodeGenCXX/mangle-ms.cpp
> > > > >   Clang :: SemaCXX/attr-require-constant-initialization.cpp
> > > > > 
> > > > > error: 'error' diagnostics seen but not expected: 
> > > > >   File 
> > > > > /android0/llvm-project/clang/test/SemaCXX/attr-require-constant-initialization.cpp
> > > > >  Line 92: variable does not have a constant initializer
> > > > > 
> > > > > as an example of one failure, which is basically:
> > > > > 
> > > > > ```
> > > > > void foo(void) {
> > > > >   __attribute__((require_constant_initialization)) static const int 
> > > > > _init = 42;
> > > > > }
> > > > > ```
> > > > > specifically, `-std=c++03` is the only language version that fails.
> > > > > 
> > > > Oh, perhaps it should simply be:
> > > > 
> > > > ```
> > > > if (Info.EvalMode == EvalInfo::EM_ConstantFold && E->isXValue())
> > > >   return false;
> > > > ```
> > > > 
> > > > let me add your test case for that, too.
> > > It looks like that case is using Expr::isConstantInitializer, which uses 
> > > EM_ConstantFold, which then blows up.  No combination of the checks 
> > > you're trying will let you distinguish between that case and the case 
> > > you're trying to bail out; in both cases, the EvalMode is EvalMode, it's 
> > > an lvalue, and the storage duration is static.
> > > 
> > > Maybe the code in question shouldn't be using isConstantInitializer at 
> > > all.
> > > 
> > > Checking for a reference type doesn't solve anything; it just makes the 
> > > issues more complicated to reproduce.
> > d572f82e490b alludes to `Expr::isConstantInitializer` being error 
> > prone...back in 2011...
> > 
> > > Maybe the code in question shouldn't be using isConstantInitializer at 
> > > all.
> > 
> > Which code? My patch doesn't introduce explicit calls to that method.
> > Which code?
> 
> Sema::CheckCompleteVariableDeclaration
Maybe we can add a special case for 

[PATCH] D147283: [Sema] Search template parameter scopes before searching namespace/file scopes when performing unqualified name lookup

2023-07-19 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak updated this revision to Diff 542150.
ahatanak added a comment.

- Defer collecting using directives until lookup into local scopes is done.
- Simplify the second loop.
- Add more comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147283

Files:
  clang/lib/Sema/SemaLookup.cpp
  clang/test/SemaCXX/namespace.cpp

Index: clang/test/SemaCXX/namespace.cpp
===
--- clang/test/SemaCXX/namespace.cpp
+++ clang/test/SemaCXX/namespace.cpp
@@ -96,3 +96,12 @@
 
   }
 }
+
+namespace N0 {
+  template  class S;
+  template  class C;
+}
+
+template  class N0::C {
+  void foo(S c) {}
+};
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -1298,13 +1298,20 @@
   // }
   //
   UnqualUsingDirectiveSet UDirs(*this);
-  bool VisitedUsingDirectives = false;
   bool LeftStartingScope = false;
 
   // When performing a scope lookup, we want to find local extern decls.
   FindLocalExternScope FindLocals(R);
+  Scope *InnermostFileScope = nullptr;
+  DeclContext *InnermostFileScopeDC = nullptr;
+
+  for (; S; S = S->getParent()) {
+if (isNamespaceOrTranslationUnitScope(S)) {
+  if (!InnermostFileScope)
+InnermostFileScope = S;
+  continue;
+}
 
-  for (; S && !isNamespaceOrTranslationUnitScope(S); S = S->getParent()) {
 bool SearchNamespaceScope = true;
 // Check whether the IdResolver has anything in this scope.
 for (; I != IEnd && S->isDeclScope(*I); ++I) {
@@ -1387,33 +1394,17 @@
 // If this is a file context, we need to perform unqualified name
 // lookup considering using directives.
 if (Ctx->isFileContext()) {
-  // If we haven't handled using directives yet, do so now.
-  if (!VisitedUsingDirectives) {
-// Add using directives from this context up to the top level.
-for (DeclContext *UCtx = Ctx; UCtx; UCtx = UCtx->getParent()) {
-  if (UCtx->isTransparentContext())
-continue;
-
-  UDirs.visit(UCtx, UCtx);
-}
-
-// Find the innermost file scope, so we can add using directives
-// from local scopes.
-Scope *InnermostFileScope = S;
-while (InnermostFileScope &&
-   !isNamespaceOrTranslationUnitScope(InnermostFileScope))
-  InnermostFileScope = InnermostFileScope->getParent();
-UDirs.visitScopeChain(Initial, InnermostFileScope);
-
-UDirs.done();
+  if (InnermostFileScopeDC)
+continue;
 
-VisitedUsingDirectives = true;
-  }
+  InnermostFileScopeDC = Ctx;
 
-  if (CppNamespaceLookup(*this, R, Context, Ctx, UDirs)) {
-R.resolveKind();
-return true;
-  }
+  // Find the innermost file scope, so we can add using directives
+  // from local scopes.
+  InnermostFileScope = S;
+  while (InnermostFileScope &&
+ !isNamespaceOrTranslationUnitScope(InnermostFileScope))
+InnermostFileScope = InnermostFileScope->getParent();
 
   continue;
 }
@@ -1430,6 +1421,8 @@
 }
   }
 
+  S = InnermostFileScope;
+
   // Stop if we ran out of scopes.
   // FIXME:  This really, really shouldn't be happening.
   if (!S) return false;
@@ -1443,11 +1436,45 @@
   //
   // FIXME: Cache this sorted list in Scope structure, and DeclContext, so we
   // don't build it for each lookup!
-  if (!VisitedUsingDirectives) {
-UDirs.visitScopeChain(Initial, S);
-UDirs.done();
+
+  // Add using directives from the innermost file scope context up to the top
+  // level.
+  for (DeclContext *UCtx = InnermostFileScopeDC; UCtx;
+   UCtx = UCtx->getParent()) {
+if (UCtx->isTransparentContext())
+  continue;
+
+UDirs.visit(UCtx, UCtx);
   }
 
+  // Add using directives from local scopes.
+  UDirs.visitScopeChain(Initial, S);
+  UDirs.done();
+
+  // Search the file scope DCs between the innermost file scope DC and the DC
+  // corresponding to the innermost file scope. This is needed, for example, in
+  // the following case where namespace 'N' cannot be found on the scope stack:
+  //
+  // namespace N {
+  // struct B {
+  //   B(int);
+  // };
+  // typedef B typedef_B;
+  // struct D : B {
+  //   D();
+  // };
+  // }
+  //
+  // N::D::D() : typedef_B(0) {}
+
+  for (DeclContext *Ctx = InnermostFileScopeDC, *LastCtx = S->getEntity();
+   Ctx && !Ctx->Equals(LastCtx); Ctx = Ctx->getLookupParent())
+if (!Ctx->isTransparentContext() &&
+CppNamespaceLookup(*this, R, Context, Ctx, UDirs)) {
+  R.resolveKind();
+  return true;
+}
+
   // If we're not performing redeclaration lookup, do not look for local
   // extern declarations 

[PATCH] D155387: [Clang] Fix member lookup so that we don't ignore ambiguous lookups in some cases

2023-07-19 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:15191
   OverloadCandidateSet::iterator Best;
   switch (CandidateSet.BestViableFunction(*this, OpLoc, Best)) {
   case OR_Success:

@rsmith if `R.isAmbiguous()` should we even check the overload candidates? 

Right now in `clang/test/SemaCXX/arrow-operator.cpp` we are getting both an 
ambiguous name lookup and overload diagnostic. 


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

https://reviews.llvm.org/D155387

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


[PATCH] D151587: [clang][ConstantEmitter] have tryEmitPrivate[ForVarInit] try ConstExprEmitter fast-path first

2023-07-19 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:8360
+  // Do not constant fold an R-value.
+  if (Info.EvalMode == EvalInfo::EM_ConstantFold && !E->isLValue())
+return false;

nickdesaulniers wrote:
> efriedma wrote:
> > nickdesaulniers wrote:
> > > nickdesaulniers wrote:
> > > > efriedma wrote:
> > > > > nickdesaulniers wrote:
> > > > > > efriedma wrote:
> > > > > > > Checking isLValue() doesn't make sense; consider:
> > > > > > > 
> > > > > > > ```
> > > > > > > struct R { mutable long x; };
> > > > > > > struct Z { const R , y; };
> > > > > > > Z z = { R{1}, z.x.x=10 };
> > > > > > > ```
> > > > > > > 
> > > > > > > Maybe also want to check for EM_IgnoreSideEffects?  Not sure what 
> > > > > > > cases, if any, that would affect.
> > > > > > > 
> > > > > > > We should probably check `E->getStorageDuration() == SD_Static`.  
> > > > > > > The cases where it's a local temporary don't hit the 
> > > > > > > getOrCreateValue() codepath, so the evaluated value should be 
> > > > > > > handled correctly.
> > > > > > > 
> > > > > > > Checking EvalMode feels a little weird, but I guess it should do 
> > > > > > > the right thing in the cases I can think of?  I'd like a second 
> > > > > > > opinion on this.
> > > > > > Changing this condition to:
> > > > > > ```
> > > > > > if (E->getStorageDuration() == SD_Static && 
> > > > > >   
> > > > > > Info.EvalMode == EvalInfo::EM_ConstantFold &&   
> > > > > >   
> > > > > > E->isXValue())  
> > > > > >   
> > > > > >   return false;
> > > > > > ```
> > > > > > allows all tests in tree to pass, but messes up the test case you 
> > > > > > posted above. I'm trying to sus out what else might be different 
> > > > > > about that test case...we should return `false` for that, but I'm 
> > > > > > not sure what's different about that case.
> > > > > > 
> > > > > > In particular, I was playing with 
> > > > > > `E->isUsableInConstantExpressions` and 
> > > > > > `E->getLifetimeExtendedTemporaryDecl()`, but getting your case to 
> > > > > > work, I end up regressing 
> > > > > > clang/test/SemaCXX/attr-require-constant-initialization.cpp...argh!!
> > > > > Shouldn't that just be the following?
> > > > > 
> > > > > ```
> > > > > if (E->getStorageDuration() == SD_Static &&   
> > > > > 
> > > > > Info.EvalMode == EvalInfo::EM_ConstantFold)   
> > > > >  
> > > > >   return false;
> > > > > ```
> > > > > 
> > > > > A materialized temporary is always going to be either an LValue or an 
> > > > > XValue, and the difference between the two isn't relevant here.
> > > > I wish it were that simple. Checking those two alone will produce 
> > > > failures in the following tests:
> > > > 
> > > > Failed Tests (2):
> > > >   Clang :: CodeGenCXX/mangle-ms.cpp
> > > >   Clang :: SemaCXX/attr-require-constant-initialization.cpp
> > > > 
> > > > error: 'error' diagnostics seen but not expected: 
> > > >   File 
> > > > /android0/llvm-project/clang/test/SemaCXX/attr-require-constant-initialization.cpp
> > > >  Line 92: variable does not have a constant initializer
> > > > 
> > > > as an example of one failure, which is basically:
> > > > 
> > > > ```
> > > > void foo(void) {
> > > >   __attribute__((require_constant_initialization)) static const int 
> > > > _init = 42;
> > > > }
> > > > ```
> > > > specifically, `-std=c++03` is the only language version that fails.
> > > > 
> > > Oh, perhaps it should simply be:
> > > 
> > > ```
> > > if (Info.EvalMode == EvalInfo::EM_ConstantFold && E->isXValue())
> > >   return false;
> > > ```
> > > 
> > > let me add your test case for that, too.
> > It looks like that case is using Expr::isConstantInitializer, which uses 
> > EM_ConstantFold, which then blows up.  No combination of the checks you're 
> > trying will let you distinguish between that case and the case you're 
> > trying to bail out; in both cases, the EvalMode is EvalMode, it's an 
> > lvalue, and the storage duration is static.
> > 
> > Maybe the code in question shouldn't be using isConstantInitializer at all.
> > 
> > Checking for a reference type doesn't solve anything; it just makes the 
> > issues more complicated to reproduce.
> d572f82e490b alludes to `Expr::isConstantInitializer` being error 
> prone...back in 2011...
> 
> > Maybe the code in question shouldn't be using isConstantInitializer at all.
> 
> Which code? My patch doesn't introduce explicit calls to that method.
> Which code?

Sema::CheckCompleteVariableDeclaration


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151587

___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D155239: [clang-format] Add SpacesInParens with SpacesInParensOptions

2023-07-19 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks requested changes to this revision.
HazardyKnusperkeks added a comment.
This revision now requires changes to proceed.

D155529#inline-1505573 
But what does `clang-format` without this patch format? I just want to make 
sure, that we don't have a regression when this lands, but D155529 
 not.




Comment at: clang/unittests/Format/ConfigParseTest.cpp:411-425
   CHECK_PARSE("BasedOnStyle: Google\n"
   "ConstructorInitializerAllOnOneLineOrOnePerLine: true\n"
   "AllowAllConstructorInitializersOnNextLine: false",
   PackConstructorInitializers, FormatStyle::PCIS_CurrentLine);
   Style.PackConstructorInitializers = FormatStyle::PCIS_NextLine;
   CHECK_PARSE("BasedOnStyle: Google\n"
   "ConstructorInitializerAllOnOneLineOrOnePerLine: false",

You need to write similar tests to show that your backwards compatible parsing 
works as intended.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155239

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


[PATCH] D151834: Include math-errno with fast-math

2023-07-19 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added inline comments.



Comment at: clang/test/CodeGen/math-errno.c:28
+// FAST-LABEL: define dso_local nofpclass(nan inf) float @f1
+// FAST: call fast nofpclass(nan inf) float @sqrtf(float noundef nofpclass(nan 
inf) {{.*}}) #[[ATTR3_FAST:[0-9]+]]
+//

andrew.w.kaylor wrote:
> Shouldn't the precise pragma remove the nofpcalss(nan inf) attributes? The 
> definition of setFPPreciseEnabled looks like it's trying to do that. Maybe we 
> need another patch to handle that?
> Shouldn't the precise pragma remove the nofpcalss(nan inf) attributes? The 
> definition of setFPPreciseEnabled looks like it's trying to do that. Maybe we 
> need another patch to handle that?

I will make a note of it and work on it in a subsequent patch.



Comment at: clang/test/CodeGen/math-errno.c:40
+// CHECK-LABEL: define dso_local float @f2
+// CHECK: tail call float @llvm.sqrt.f32(float {{.*}})
+

andrew.w.kaylor wrote:
> Again, this may be beyond the scope of your change, but it seems like 
> '#pragma float_control(precise, off) should lead to fast-math flags being set 
> on this call.
> Again, this may be beyond the scope of your change, but it seems like 
> '#pragma float_control(precise, off) should lead to fast-math flags being set 
> on this call.

Yes. Making a note of it.



Comment at: clang/test/CodeGen/math-errno.c:2
+// Tests that at -O2 math-errno is taken into account. Same than MSVC.
+// RUN: %clang_cc1 -Wno-implicit-function-declaration -fmath-errno \
+// RUN: -O2 -emit-llvm -o - %s \

andrew.w.kaylor wrote:
> Isn't math-errno true by default when fast-math isn't used?
Yes, that's correct. This RUN line simulates compilation at -O2. The following 
cc1 options are triggered: -fmath-errno -ffp-contract=on
 -fno-rounding-math -O2.  That's what I am using here. 


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

https://reviews.llvm.org/D151834

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


[PATCH] D151834: Include math-errno with fast-math

2023-07-19 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam updated this revision to Diff 542141.

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

https://reviews.llvm.org/D151834

Files:
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/test/CodeGen/math-errno.c

Index: clang/test/CodeGen/math-errno.c
===
--- /dev/null
+++ clang/test/CodeGen/math-errno.c
@@ -0,0 +1,64 @@
+// -O2
+// RUN: %clang_cc1 -Wno-implicit-function-declaration  \
+// RUN: -fmath-errno -ffp-contract=on -fno-rounding-math -O2 -emit-llvm -o - %s \
+// RUN: | FileCheck %s
+
+// -ffast-math
+// RUN: %clang_cc1 -Wno-implicit-function-declaration  \
+// RUN: -menable-no-infs -menable-no-nans -fapprox-func \
+// RUN: -funsafe-math-optimizations -fno-signed-zeros -mreassociate \
+// RUN: -freciprocal-math -ffp-contract=fast -fno-rounding-math -ffast-math \
+// RUN: -ffinite-math-only -ffast-math -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=FAST
+
+// -O0
+// RUN: %clang_cc1 -Wno-implicit-function-declaration  \
+// RUN: -fmath-errno -ffp-contract=on -fno-rounding-math -O0 \
+// RUN: -emit-llvm -o - %s | FileCheck %s -check-prefix=NOOPT
+
+#pragma float_control(precise,on)
+float f1(float x) {
+  return sqrtf(x);
+}
+
+// CHECK-LABEL: define dso_local float @f1
+// CHECK: tail call float @sqrtf(float noundef {{.*}}) #[[ATTR4_O2:[0-9]+]]
+
+// FAST-LABEL: define dso_local nofpclass(nan inf) float @f1
+// FAST: call fast nofpclass(nan inf) float @sqrtf(float noundef nofpclass(nan inf) {{.*}}) #[[ATTR3_FAST:[0-9]+]]
+
+// NOOPT-LABEL: define dso_local float @f1
+// NOOPT: call float @sqrtf(float noundef {{.*}}) #[[ATTR4_NOOPT:[0-9]+]]
+
+#pragma float_control(precise,off)
+float f2(float x) {
+  return sqrtf(x);
+}
+
+// CHECK-LABEL: define dso_local float @f2
+// CHECK: tail call float @llvm.sqrt.f32(float {{.*}})
+
+// FAST-LABEL: define dso_local nofpclass(nan inf) float @f2
+// FAST: call fast float @llvm.sqrt.f32(float {{.*}})
+
+// NOOPT-LABEL: define dso_local float @f2
+// NOOPT: call float @sqrtf(float {{.*}}) #[[ATTR4_NOOPT:[0-9]+]]
+
+__attribute__((optnone))
+float f3(float x) {
+  x = sqrtf(x);
+  return x;
+}
+
+// CHECK-LABEL: define dso_local float @f3
+// CHECK: call float @sqrtf(float noundef {{.*}})
+
+// FAST-LABEL: define dso_local nofpclass(nan inf) float @f3
+// FAST: call fast nofpclass(nan inf) float @sqrtf(float noundef nofpclass(nan inf) {{.*}}) #[[ATTR4_FAST:[0-9]+]]
+
+// NOOPT-LABEL: define dso_local float @f3
+// NOOPT:  call float @sqrtf(float noundef %0) #[[ATTR4_NOOPT:[0-9]+]]
+
+// CHECK: [[ATTR4_O2]] = { nounwind }
+// FAST: [[ATTR3_FAST]] =  { nounwind willreturn memory(none) }
+// NOOPT: [[ATTR4_NOOPT]] = { nounwind }
Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1252,6 +1252,12 @@
   llvm::AttributeList , unsigned ,
   bool AttrOnCallSite, bool IsThunk);
 
+  /// Adjust Memory attribute to ensure that the BE gets the right attribute
+  // in order to generate the library call or the intrinsic for the function
+  // name 'Name'.
+  void AdjustMemoryAttribute(StringRef Name, CGCalleeInfo CalleeInfo,
+ llvm::AttributeList );
+
   /// Adds attributes to F according to our CodeGenOptions and LangOptions, as
   /// though we had emitted it ourselves.  We remove any attributes on F that
   /// conflict with the attributes we add here.
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2247,6 +2247,17 @@
   return Mask;
 }
 
+void CodeGenModule::AdjustMemoryAttribute(StringRef Name,
+  CGCalleeInfo CalleeInfo,
+  llvm::AttributeList ) {
+  if (Attrs.getMemoryEffects().getModRef() == llvm::ModRefInfo::NoModRef) {
+Attrs = Attrs.removeFnAttribute(getLLVMContext(), llvm::Attribute::Memory);
+llvm::Attribute MemoryAttr = llvm::Attribute::getWithMemoryEffects(
+getLLVMContext(), llvm::MemoryEffects::writeOnly());
+Attrs = Attrs.addFnAttribute(getLLVMContext(), MemoryAttr);
+  }
+}
+
 /// Construct the IR attribute list of a function or call.
 ///
 /// When adding an attribute, please consider where it should be handled:
@@ -5442,11 +5453,18 @@
  /*AttrOnCallSite=*/true,
  /*IsThunk=*/false);
 
-  if (const FunctionDecl *FD = dyn_cast_or_null(CurFuncDecl))
+  if (const FunctionDecl *FD = dyn_cast_or_null(CurFuncDecl)) {
 if (FD->hasAttr())
   // All calls within a strictfp function are marked strictfp
   Attrs = 

[PATCH] D150226: [Clang] Remove ability to downgrade warning on the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values

2023-07-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D150226#4515783 , @dblaikie wrote:

> In D150226#4498024 , @aaron.ballman 
> wrote:
>
>> In D150226#4461846 , @efriedma 
>> wrote:
>>
>>> The fundamental problem here is the interaction with SFINAE; if we don't 
>>> diagnose this as an error, we actually miscompile some cases.  Because of 
>>> that, a flag wouldn't really be "turning off the warning"; it would be 
>>> enabling a non-compliant language mode that has different rules for whether 
>>> enum casts are legal.
>>>
>>> If it weren't for that, I don't think anyone would be in a hurry to turn 
>>> the warning into a hard error.
>>
>> +1 to this. I'm worried about the miscompiles continuing in the wild. We did 
>> the best we could when landing the warning-as-error changes in D131307 
>>  by telling users explicitly "This 
>> diagnostic is expected to turn into an error-only diagnostic in the next 
>> Clang release." in the release notes. Obviously, that's not ideal because 
>> very few folks read release notes, but we don't have any better mechanism 
>> for communicating these kinds of changes.
>>
>> What do folks think is a reasonable path forward here? Given that we're 
>> going to branch the Clang 17 release in a few weeks (AIUI), my suggestion is 
>> to kick the can down the road by landing these changes just after we branch. 
>> That way the changes land such that early adopters can test and see how 
>> disruptive we're being without time pressure or hassle of dealing with 
>> release branches. Do folks think that's a reasonable approach? (I'm open to 
>> other suggestions.)
>
> I'm not quite following if/what the objection is to removing the "ignore in 
> system headers" for the warning for a release or two prior to making this a 
> hard error? That seems like a fairly low-cost change (it does kick the can 
> down the road a release or two before it becomes a hard error - but isn't 
> worse for users, for the most part - if they were going to get a hard error 
> from a system header before, at least now instead they'd get a warning or 
> warning-defaulted-to-error instead, they could turn it off (but they had been 
> warned that their system headers were going to cause them problems soon) and 
> then it becomes a hard error a release or two later).

Thank you for bringing that up, sorry for not being more explicit -- by "these 
changes", I meant "whatever form we decide they should take" as opposed to "the 
patch as it is now."

In terms of removing the "ignore in system headers" flag, I'm not strongly 
opposed to it, but I do worry it will throw the baby out with the bathwater. 
The specific use case I'm worried about is: user has a system header with the 
problematic code, they run into this diagnostic and they can't address it 
themselves so they disable the warning for the project. The user then doesn't 
learn about the problems in their own (non-system header) code until it becomes 
a hard error later.


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

https://reviews.llvm.org/D150226

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


[PATCH] D155714: [clang] Fix diagnostics for defaulted, implicitly deleted 'operator=='.

2023-07-19 Thread Amirreza Ashouri via Phabricator via cfe-commits
AMP999 updated this revision to Diff 542136.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155714

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
  clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
  clang/test/CXX/class/class.compare/class.eq/p2.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p1.cpp


Index: clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
===
--- clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
+++ clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
@@ -80,7 +80,7 @@
   // expected-note@#base {{deleted comparison function for base class 'C'}}
   // expected-note@#base {{no viable three-way comparison function for base 
class 'D1'}}
   // expected-note@#base {{three-way comparison cannot be synthesized because 
there is no viable function for '<' comparison}}
-  // expected-note@#base {{no viable three-way comparison function for base 
class 'D2'}}
+  // expected-note@#base {{no viable 'operator==' for base class 'D2'}}
   // expected-note@#base {{three-way comparison cannot be synthesized because 
there is no viable function for '==' comparison}}
   // expected-note@#base {{deleted comparison function for base class 'E'}}
   // expected-note@#base {{implied comparison for base class 'F' is ambiguous}}
@@ -112,7 +112,7 @@
   // expected-note@#arr {{deleted comparison function for member 'arr'}}
   // expected-note@#arr {{no viable three-way comparison function for member 
'arr'}}
   // expected-note@#arr {{three-way comparison cannot be synthesized because 
there is no viable function for '<' comparison}}
-  // expected-note@#arr {{no viable three-way comparison function for member 
'arr'}}
+  // expected-note@#arr {{no viable 'operator==' for member 'arr'}}
   // expected-note@#arr {{three-way comparison cannot be synthesized because 
there is no viable function for '==' comparison}}
   // expected-note@#arr {{deleted comparison function for member 'arr'}}
   // expected-note@#arr {{implied comparison for member 'arr' is ambiguous}}
Index: clang/test/CXX/class/class.compare/class.eq/p2.cpp
===
--- clang/test/CXX/class/class.compare/class.eq/p2.cpp
+++ clang/test/CXX/class/class.compare/class.eq/p2.cpp
@@ -37,7 +37,7 @@
 template struct X {
   X();
   bool operator==(const X&) const = default; // #x expected-note 4{{deleted 
here}}
-  T t; // expected-note 3{{because there is no viable three-way comparison 
function for member 't'}}
+  T t; // expected-note 3{{because there is no viable 'operator==' for member 
't'}}
// expected-note@-1 {{because it would invoke a deleted comparison 
function for member 't'}}
 };
 
Index: clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
===
--- clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
+++ clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
@@ -5,6 +5,14 @@
   // expected-note@-1 {{defaulted 'operator!=' is implicitly deleted because 
there is no viable 'operator==' for 'A'}}
 };
 
+struct A2 {
+  struct E {};
+  E e;
+  bool operator==(const A2&) const = default; // expected-warning {{explicitly 
defaulted equality comparison operator is implicitly deleted}} 
expected-note{{replace 'default'}}
+  // expected-note@-2 {{defaulted 'operator==' is implicitly deleted because 
there is no viable 'operator==' for member 'e'}}
+};
+
+
 struct Q {};
 bool operator!=(Q, Q); // expected-note {{defaulted 'operator!=' is implicitly 
deleted because this non-rewritten comparison function would be the best match 
for the comparison}}
 struct B {
Index: clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
===
--- clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
+++ clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
@@ -100,7 +100,7 @@
   struct Q {
 struct X {
   friend std::strong_ordering operator<=>(const X&, const X&);
-} x; // expected-note {{no viable three-way comparison}}
+} x; // expected-note {{no viable 'operator=='}}
 // expected-error@+1 {{defaulting the corresponding implicit 'operator==' 
for this defaulted 'operator<=>' would delete it after its first declaration}}
 friend std::strong_ordering operator<=>(const Q&, const Q&) = default;
   };
Index: clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
===
--- clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
+++ clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
@@ -153,7 

[PATCH] D151587: [clang][ConstantEmitter] have tryEmitPrivate[ForVarInit] try ConstExprEmitter fast-path first

2023-07-19 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:8360
+  // Do not constant fold an R-value.
+  if (Info.EvalMode == EvalInfo::EM_ConstantFold && !E->isLValue())
+return false;

efriedma wrote:
> nickdesaulniers wrote:
> > nickdesaulniers wrote:
> > > efriedma wrote:
> > > > nickdesaulniers wrote:
> > > > > efriedma wrote:
> > > > > > Checking isLValue() doesn't make sense; consider:
> > > > > > 
> > > > > > ```
> > > > > > struct R { mutable long x; };
> > > > > > struct Z { const R , y; };
> > > > > > Z z = { R{1}, z.x.x=10 };
> > > > > > ```
> > > > > > 
> > > > > > Maybe also want to check for EM_IgnoreSideEffects?  Not sure what 
> > > > > > cases, if any, that would affect.
> > > > > > 
> > > > > > We should probably check `E->getStorageDuration() == SD_Static`.  
> > > > > > The cases where it's a local temporary don't hit the 
> > > > > > getOrCreateValue() codepath, so the evaluated value should be 
> > > > > > handled correctly.
> > > > > > 
> > > > > > Checking EvalMode feels a little weird, but I guess it should do 
> > > > > > the right thing in the cases I can think of?  I'd like a second 
> > > > > > opinion on this.
> > > > > Changing this condition to:
> > > > > ```
> > > > > if (E->getStorageDuration() == SD_Static &&   
> > > > > 
> > > > > Info.EvalMode == EvalInfo::EM_ConstantFold && 
> > > > > 
> > > > > E->isXValue())
> > > > > 
> > > > >   return false;
> > > > > ```
> > > > > allows all tests in tree to pass, but messes up the test case you 
> > > > > posted above. I'm trying to sus out what else might be different 
> > > > > about that test case...we should return `false` for that, but I'm not 
> > > > > sure what's different about that case.
> > > > > 
> > > > > In particular, I was playing with `E->isUsableInConstantExpressions` 
> > > > > and `E->getLifetimeExtendedTemporaryDecl()`, but getting your case to 
> > > > > work, I end up regressing 
> > > > > clang/test/SemaCXX/attr-require-constant-initialization.cpp...argh!!
> > > > Shouldn't that just be the following?
> > > > 
> > > > ```
> > > > if (E->getStorageDuration() == SD_Static && 
> > > >   
> > > > Info.EvalMode == EvalInfo::EM_ConstantFold) 
> > > >
> > > >   return false;
> > > > ```
> > > > 
> > > > A materialized temporary is always going to be either an LValue or an 
> > > > XValue, and the difference between the two isn't relevant here.
> > > I wish it were that simple. Checking those two alone will produce 
> > > failures in the following tests:
> > > 
> > > Failed Tests (2):
> > >   Clang :: CodeGenCXX/mangle-ms.cpp
> > >   Clang :: SemaCXX/attr-require-constant-initialization.cpp
> > > 
> > > error: 'error' diagnostics seen but not expected: 
> > >   File 
> > > /android0/llvm-project/clang/test/SemaCXX/attr-require-constant-initialization.cpp
> > >  Line 92: variable does not have a constant initializer
> > > 
> > > as an example of one failure, which is basically:
> > > 
> > > ```
> > > void foo(void) {
> > >   __attribute__((require_constant_initialization)) static const int 
> > > _init = 42;
> > > }
> > > ```
> > > specifically, `-std=c++03` is the only language version that fails.
> > > 
> > Oh, perhaps it should simply be:
> > 
> > ```
> > if (Info.EvalMode == EvalInfo::EM_ConstantFold && E->isXValue())
> >   return false;
> > ```
> > 
> > let me add your test case for that, too.
> It looks like that case is using Expr::isConstantInitializer, which uses 
> EM_ConstantFold, which then blows up.  No combination of the checks you're 
> trying will let you distinguish between that case and the case you're trying 
> to bail out; in both cases, the EvalMode is EvalMode, it's an lvalue, and the 
> storage duration is static.
> 
> Maybe the code in question shouldn't be using isConstantInitializer at all.
> 
> Checking for a reference type doesn't solve anything; it just makes the 
> issues more complicated to reproduce.
d572f82e490b alludes to `Expr::isConstantInitializer` being error prone...back 
in 2011...

> Maybe the code in question shouldn't be using isConstantInitializer at all.

Which code? My patch doesn't introduce explicit calls to that method.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151587

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


  1   2   3   >