[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

[Shao-Ce SUN via Phabricator via cfe-commits]

achieveartificialintelligence updated this revision to Diff 401528.
achieveartificialintelligence added a comment.

Address @craig.topper's comments. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93298

Files:
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoD.td
  llvm/lib/Target/RISCV/RISCVInstrInfoF.td
  llvm/lib/Target/RISCV/RISCVInstrInfoZfh.td
  llvm/lib/Target/RISCV/RISCVRegisterInfo.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/rv32i-invalid.s
  llvm/test/MC/RISCV/rv32zdinx-invalid.s
  llvm/test/MC/RISCV/rv32zdinx-valid.s
  llvm/test/MC/RISCV/rv32zfinx-invalid.s
  llvm/test/MC/RISCV/rv32zfinx-valid.s
  llvm/test/MC/RISCV/rv32zhinx-invalid.s
  llvm/test/MC/RISCV/rv32zhinx-valid.s
  llvm/test/MC/RISCV/rv32zhinxmin-invalid.s
  llvm/test/MC/RISCV/rv32zhinxmin-valid.s
  llvm/test/MC/RISCV/rv64zdinx-invalid.s
  llvm/test/MC/RISCV/rv64zdinx-valid.s
  llvm/test/MC/RISCV/rv64zfinx-invalid.s
  llvm/test/MC/RISCV/rv64zfinx-valid.s
  llvm/test/MC/RISCV/rv64zhinx-invalid.s
  llvm/test/MC/RISCV/rv64zhinx-valid.s
  llvm/test/MC/RISCV/rv64zhinxmin-invalid.s
  llvm/test/MC/RISCV/rv64zhinxmin-valid.s
  llvm/test/MC/RISCV/rvzdinx-aliases-valid.s
  llvm/test/MC/RISCV/rvzfinx-aliases-valid.s
  llvm/test/MC/RISCV/rvzhinx-aliases-valid.s

Index: llvm/test/MC/RISCV/rvzhinx-aliases-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rvzhinx-aliases-valid.s
@@ -0,0 +1,82 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+zhinx -riscv-no-aliases \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+zhinx \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+zhinx -riscv-no-aliases \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+zhinx \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+zhinx %s \
+# RUN: | llvm-objdump -d --mattr=+zhinx -M no-aliases - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+zhinx %s \
+# RUN: | llvm-objdump -d --mattr=+zhinx - \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+zhinx %s \
+# RUN: | llvm-objdump -d --mattr=+zhinx -M no-aliases - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+zhinx %s \
+# RUN: | llvm-objdump -d --mattr=+zhinx - \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+
+##===--===##
+## Assembler Pseudo Instructions (User-Level ISA, Version 2.2, Chapter 20)
+##===--===##
+
+# CHECK-INST: fsgnjx.h s1, s2, s2
+# CHECK-ALIAS: fabs.h s1, s2
+fabs.h s1, s2
+# CHECK-INST: fsgnjn.h s2, s3, s3
+# CHECK-ALIAS: fneg.h s2, s3
+fneg.h s2, s3
+
+# CHECK-INST: flt.h tp, s6, s5
+# CHECK-ALIAS: flt.h tp, s6, s5
+fgt.h x4, s5, s6
+# CHECK-INST: fle.h t2, s1, s0
+# CHECK-ALIAS: fle.h t2, s1, s0
+fge.h x7, x8, x9
+
+##===--===##
+## Aliases which omit the rounding mode.
+##===--===##
+
+# CHECK-INST: fmadd.h a0, a1, a2, a3, dyn
+# CHECK-ALIAS: fmadd.h a0, a1, a2, a3
+fmadd.h x10, x11, x12, x13
+# CHECK-INST: fmsub.h a4, a5, a6, a7, dyn
+# CHECK-ALIAS: fmsub.h a4, a5, a6, a7
+fmsub.h x14, x15, x16, x17
+# CHECK-INST: fnmsub.h s2, s3, s4, s5, dyn
+# CHECK-ALIAS: fnmsub.h s2, s3, s4, s5
+fnmsub.h x18, x19, x20, x21
+# CHECK-INST: fnmadd.h s6, s7, s8, s9, dyn
+# CHECK-ALIAS: fnmadd.h s6, s7, s8, s9
+fnmadd.h x22, x23, x24, x25
+# CHECK-INST: fadd.h s10, s11, t3, dyn
+# CHECK-ALIAS: fadd.h s10, s11, t3
+fadd.h x26, x27, x28
+# CHECK-INST: fsub.h t4, t5, t6, dyn
+# CHECK-ALIAS: fsub.h t4, t5, t6
+fsub.h x29, x30, x31
+# CHECK-INST: fmul.h s0, s1, s2, dyn
+# CHECK-ALIAS: fmul.h s0, s1, s2
+fmul.h s0, s1, s2
+# CHECK-INST: fdiv.h s3, s4, s5, dyn
+# CHECK-ALIAS: fdiv.h s3, s4, s5
+fdiv.h s3, s4, s5
+# CHECK-INST: fsqrt.h s6, s7, dyn
+# CHECK-ALIAS: fsqrt.h s6, s7
+fsqrt.h s6, s7
+# CHECK-INST: fcvt.w.h a0, s5, dyn
+# CHECK-ALIAS: fcvt.w.h a0, s5
+fcvt.w.h a0, s5
+# CHECK-INST: fcvt.wu.h a1, s6, dyn
+# CHECK-ALIAS: fcvt.wu.h a1, s6
+fcvt.wu.h a1, s6
+# CHECK-INST: fcvt.h.w t6, a4, dyn
+# CHECK-ALIAS: fcvt.h.w t6, a4
+fcvt.h.w t6, a4
+# CHECK-INST: fcvt.h.wu s0, a5, dyn
+# CHECK-ALIAS: fcvt.h.wu s0, a5
+fcvt.h.wu s0, a5
Index: llvm/test/MC/RISCV/rvzfinx-aliases-valid.s
=

[clang] 0be3da1 - [RISCV] Add intrinsic for Zbt extension

[Ben Shi via cfe-commits]

Author: Chenbing.Zheng
Date: 2022-01-20T08:27:05Z
New Revision: 0be3da1fab5a88d497081026fbcab7c0f6c88ef4

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

LOG: [RISCV] Add intrinsic for Zbt extension

RV32: fsl, fsr, fsri
RV64: fsl, fsr, fsri, fslw, fsrw, fsriw

Reviewed By: craig.topper

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

Added: 
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbt.c
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbt.c
llvm/test/CodeGen/RISCV/rv32zbt-intrinsic.ll
llvm/test/CodeGen/RISCV/rv64zbt-intrinsic.ll

Modified: 
clang/include/clang/Basic/BuiltinsRISCV.def
clang/lib/CodeGen/CGBuiltin.cpp
llvm/include/llvm/IR/IntrinsicsRISCV.td
llvm/lib/Target/RISCV/RISCVISelLowering.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsRISCV.def 
b/clang/include/clang/Basic/BuiltinsRISCV.def
index 568ab0bbaec78..495a036e576f8 100644
--- a/clang/include/clang/Basic/BuiltinsRISCV.def
+++ b/clang/include/clang/Basic/BuiltinsRISCV.def
@@ -61,5 +61,11 @@ TARGET_BUILTIN(__builtin_riscv_crc32c_w, "LiLi", "nc", 
"experimental-zbr")
 TARGET_BUILTIN(__builtin_riscv_crc32_d, "LiLi", "nc", "experimental-zbr,64bit")
 TARGET_BUILTIN(__builtin_riscv_crc32c_d, "LiLi", "nc", 
"experimental-zbr,64bit")
 
+// Zbt extension
+TARGET_BUILTIN(__builtin_riscv_fsl_32, "LiLiLiLi", "nc", "experimental-zbt")
+TARGET_BUILTIN(__builtin_riscv_fsr_32, "LiLiLiLi", "nc", "experimental-zbt")
+TARGET_BUILTIN(__builtin_riscv_fsl_64, "WiWiWiWi", "nc", 
"experimental-zbt,64bit")
+TARGET_BUILTIN(__builtin_riscv_fsr_64, "WiWiWiWi", "nc", 
"experimental-zbt,64bit")
+
 #undef BUILTIN
 #undef TARGET_BUILTIN

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index f9633f875b616..a49c035002786 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -18853,7 +18853,11 @@ Value *CodeGenFunction::EmitRISCVBuiltinExpr(unsigned 
BuiltinID,
   case RISCV::BI__builtin_riscv_crc32c_b:
   case RISCV::BI__builtin_riscv_crc32c_h:
   case RISCV::BI__builtin_riscv_crc32c_w:
-  case RISCV::BI__builtin_riscv_crc32c_d: {
+  case RISCV::BI__builtin_riscv_crc32c_d:
+  case RISCV::BI__builtin_riscv_fsl_32:
+  case RISCV::BI__builtin_riscv_fsr_32:
+  case RISCV::BI__builtin_riscv_fsl_64:
+  case RISCV::BI__builtin_riscv_fsr_64: {
 switch (BuiltinID) {
 default: llvm_unreachable("unexpected builtin ID");
 // Zbb
@@ -18944,6 +18948,16 @@ Value *CodeGenFunction::EmitRISCVBuiltinExpr(unsigned 
BuiltinID,
 case RISCV::BI__builtin_riscv_crc32c_d:
   ID = Intrinsic::riscv_crc32c_d;
   break;
+
+// Zbt
+case RISCV::BI__builtin_riscv_fsl_32:
+case RISCV::BI__builtin_riscv_fsl_64:
+  ID = Intrinsic::riscv_fsl;
+  break;
+case RISCV::BI__builtin_riscv_fsr_32:
+case RISCV::BI__builtin_riscv_fsr_64:
+  ID = Intrinsic::riscv_fsr;
+  break;
 }
 
 IntrinsicTypes = {ResultType};

diff  --git a/clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbt.c 
b/clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbt.c
new file mode 100644
index 0..74734cbff5e1f
--- /dev/null
+++ b/clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbt.c
@@ -0,0 +1,54 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple riscv32 -target-feature +experimental-zbt 
-emit-llvm %s -o - \
+// RUN: | FileCheck %s  -check-prefix=RV32ZBT
+
+// RV32ZBT-LABEL: @fsl(
+// RV32ZBT-NEXT:  entry:
+// RV32ZBT-NEXT:[[RS1_ADDR:%.*]] = alloca i32, align 4
+// RV32ZBT-NEXT:[[RS2_ADDR:%.*]] = alloca i32, align 4
+// RV32ZBT-NEXT:[[RS3_ADDR:%.*]] = alloca i32, align 4
+// RV32ZBT-NEXT:store i32 [[RS1:%.*]], i32* [[RS1_ADDR]], align 4
+// RV32ZBT-NEXT:store i32 [[RS2:%.*]], i32* [[RS2_ADDR]], align 4
+// RV32ZBT-NEXT:store i32 [[RS3:%.*]], i32* [[RS3_ADDR]], align 4
+// RV32ZBT-NEXT:[[TMP0:%.*]] = load i32, i32* [[RS1_ADDR]], align 4
+// RV32ZBT-NEXT:[[TMP1:%.*]] = load i32, i32* [[RS2_ADDR]], align 4
+// RV32ZBT-NEXT:[[TMP2:%.*]] = load i32, i32* [[RS3_ADDR]], align 4
+// RV32ZBT-NEXT:[[TMP3:%.*]] = call i32 @llvm.riscv.fsl.i32(i32 [[TMP0]], 
i32 [[TMP1]], i32 [[TMP2]])
+// RV32ZBT-NEXT:ret i32 [[TMP3]]
+//
+int fsl(int rs1, int rs2, int rs3) {
+  return __builtin_riscv_fsl_32(rs1, rs2, rs3);
+}
+
+// RV32ZBT-LABEL: @fsr(
+// RV32ZBT-NEXT:  entry:
+// RV32ZBT-NEXT:[[RS1_ADDR:%.*]] = alloca i32, align 4
+// RV32ZBT-NEXT:[[RS2_ADDR:%.*]] = alloca i32, align 4
+// RV32ZBT-NEXT:[[RS3_ADDR:%.*]] = alloca i32, align 4
+// RV32ZBT-NEXT:store i32 [[RS1:%.*]], i32* [[RS1_ADDR]], align 4
+// RV32ZBT-NEXT:store i32 [[RS2:%.*]], i32* [[RS2_ADDR]], align 4
+// RV32ZBT-NEXT:store i32 [[RS3:%.*]], i32* [

[PATCH] D117468: [RISCV] Add intrinsic for Zbt extension

[Ben Shi via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0be3da1fab5a: [RISCV] Add intrinsic for Zbt extension 
(authored by Chenbing.Zheng, committed by benshi001).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117468

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbt.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbt.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/test/CodeGen/RISCV/rv32zbt-intrinsic.ll
  llvm/test/CodeGen/RISCV/rv64zbt-intrinsic.ll

Index: llvm/test/CodeGen/RISCV/rv64zbt-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/rv64zbt-intrinsic.ll
@@ -0,0 +1,83 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbt -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV64ZBT
+
+declare i32 @llvm.riscv.fsl.i32(i32, i32, i32)
+
+define i32 @fsl_i32(i32 %a, i32 %b, i32 %c) nounwind {
+; RV64ZBT-LABEL: fsl_i32:
+; RV64ZBT:   # %bb.0:
+; RV64ZBT-NEXT:fslw a0, a0, a1, a2
+; RV64ZBT-NEXT:ret
+  %1 = call i32 @llvm.riscv.fsl.i32(i32 %a, i32 %b, i32 %c)
+  ret i32 %1
+}
+
+declare i32 @llvm.riscv.fsr.i32(i32, i32, i32)
+
+define i32 @fsr_i32(i32 %a, i32 %b, i32 %c) nounwind {
+; RV64ZBT-LABEL: fsr_i32:
+; RV64ZBT:   # %bb.0:
+; RV64ZBT-NEXT:fsrw a0, a0, a1, a2
+; RV64ZBT-NEXT:ret
+  %1 = call i32 @llvm.riscv.fsr.i32(i32 %a, i32 %b, i32 %c)
+  ret i32 %1
+}
+
+define i32 @fsli_i32(i32 %a, i32 %b) nounwind {
+; RV64ZBT-LABEL: fsli_i32:
+; RV64ZBT:   # %bb.0:
+; RV64ZBT-NEXT:fsriw a0, a1, a0, 27
+; RV64ZBT-NEXT:ret
+  %1 = call i32 @llvm.riscv.fsl.i32(i32 %a, i32 %b, i32 5)
+  ret i32 %1
+}
+
+define i32 @fsri_i32(i32 %a, i32 %b) nounwind {
+; RV64ZBT-LABEL: fsri_i32:
+; RV64ZBT:   # %bb.0:
+; RV64ZBT-NEXT:fsriw a0, a0, a1, 15
+; RV64ZBT-NEXT:ret
+  %1 = call i32 @llvm.riscv.fsr.i32(i32 %a, i32 %b, i32 15)
+  ret i32 %1
+}
+
+declare i64 @llvm.riscv.fsl.i64(i64, i64, i64)
+
+define i64 @fsl_i64(i64 %a, i64 %b, i64 %c) nounwind {
+; RV64ZBT-LABEL: fsl_i64:
+; RV64ZBT:   # %bb.0:
+; RV64ZBT-NEXT:fsl a0, a0, a1, a2
+; RV64ZBT-NEXT:ret
+  %1 = call i64 @llvm.riscv.fsl.i64(i64 %a, i64 %b, i64 %c)
+  ret i64 %1
+}
+
+declare i64 @llvm.riscv.fsr.i64(i64, i64, i64)
+
+define i64 @fsr_i64(i64 %a, i64 %b, i64 %c) nounwind {
+; RV64ZBT-LABEL: fsr_i64:
+; RV64ZBT:   # %bb.0:
+; RV64ZBT-NEXT:fsr a0, a0, a1, a2
+; RV64ZBT-NEXT:ret
+  %1 = call i64 @llvm.riscv.fsr.i64(i64 %a, i64 %b, i64 %c)
+  ret i64 %1
+}
+
+define i64 @fsli_i64(i64 %a, i64 %b) nounwind {
+; RV64ZBT-LABEL: fsli_i64:
+; RV64ZBT:   # %bb.0:
+; RV64ZBT-NEXT:fsri a0, a1, a0, 49
+; RV64ZBT-NEXT:ret
+  %1 = call i64 @llvm.riscv.fsl.i64(i64 %a, i64 %b, i64 15)
+  ret i64 %1
+}
+
+define i64 @fsri_i64(i64 %a, i64 %b) nounwind {
+; RV64ZBT-LABEL: fsri_i64:
+; RV64ZBT:   # %bb.0:
+; RV64ZBT-NEXT:fsri a0, a0, a1, 5
+; RV64ZBT-NEXT:ret
+  %1 = call i64 @llvm.riscv.fsr.i64(i64 %a, i64 %b, i64 5)
+  ret i64 %1
+}
Index: llvm/test/CodeGen/RISCV/rv32zbt-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/rv32zbt-intrinsic.ll
@@ -0,0 +1,43 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbt -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV32ZBT
+
+declare i32 @llvm.riscv.fsl.i32(i32, i32, i32)
+
+define i32 @fsl_i32(i32 %a, i32 %b, i32 %c) nounwind {
+; RV32ZBT-LABEL: fsl_i32:
+; RV32ZBT:   # %bb.0:
+; RV32ZBT-NEXT:fsl a0, a0, a1, a2
+; RV32ZBT-NEXT:ret
+  %1 = call i32 @llvm.riscv.fsl.i32(i32 %a, i32 %b, i32 %c)
+  ret i32 %1
+}
+
+declare i32 @llvm.riscv.fsr.i32(i32, i32, i32)
+
+define i32 @fsr_i32(i32 %a, i32 %b, i32 %c) nounwind {
+; RV32ZBT-LABEL: fsr_i32:
+; RV32ZBT:   # %bb.0:
+; RV32ZBT-NEXT:fsr a0, a0, a1, a2
+; RV32ZBT-NEXT:ret
+  %1 = call i32 @llvm.riscv.fsr.i32(i32 %a, i32 %b, i32 %c)
+  ret i32 %1
+}
+
+define i32 @fsli_i32(i32 %a, i32 %b) nounwind {
+; RV32ZBT-LABEL: fsli_i32:
+; RV32ZBT:   # %bb.0:
+; RV32ZBT-NEXT:fsri a0, a1, a0, 27
+; RV32ZBT-NEXT:ret
+  %1 = call i32 @llvm.riscv.fsl.i32(i32 %a, i32 %b, i32 5)
+  ret i32 %1
+}
+
+define i32 @fsri_i32(i32 %a, i32 %b) nounwind {
+; RV32ZBT-LABEL: fsri_i32:
+; RV32ZBT:   # %bb.0:
+; RV32ZBT-NEXT:fsri a0, a0, a1, 15
+; RV32ZBT-NEXT:ret
+  %1 = call i32 @llvm.riscv.fsr.i32(i32 %a, i32 %b, i32 15)
+  ret i32 %1
+}
Index: llvm/lib/Target/RISCV/RISCVISelLowering.cpp
===
--- llvm/lib/Target/RISCV/RISCV

[clang-tools-extra] baa08d1 - [clang-tidy] Revert documentation change (NFC)

[via cfe-commits]

Author: Richard
Date: 2022-01-20T01:27:23-07:00
New Revision: baa08d1ec3e20dc9107099119e7f27e3fbdc780d

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

LOG: [clang-tidy] Revert documentation change (NFC)

Restore a fix to the list of checks that was undone by a recent commit.

Added: 


Modified: 
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git a/clang-tools-extra/docs/clang-tidy/checks/list.rst 
b/clang-tools-extra/docs/clang-tidy/checks/list.rst
index 74c5dd1217046..9785c9f43a4b4 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -213,7 +213,7 @@ Clang-Tidy Checks
`llvmlibc-restrict-system-libc-headers 
`_, "Yes"
`misc-definitions-in-headers `_, "Yes"
`misc-misleading-bidirectional `_,
-   `misc-misleading-identifier `_,
+   `misc-misleading-identifier `_,
`misc-misplaced-const `_,
`misc-new-delete-overloads `_,
`misc-no-recursion `_,



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

[PATCH] D117753: [AArch64] Support for memset tagged intrinsic

[Son Tuan Vu via Phabricator via cfe-commits]

tyb0807 created this revision.
Herald added a subscriber: kristof.beyls.
tyb0807 requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This introduces a new ACLE intrinsic for memset tagged (see
https://github.com/ARM-software/acle/pull/38).

  void *__builtin_arm_mops_memset_tag(void *, int, size_t)

A corresponding LLVM intrinsic is introduced:

  i8* llvm.aarch64.mops.memset.tag(i8*, i8, i64)

The types match llvm.memset but the return type is not void.

Patch by Tomas Matheson


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117753

Files:
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/arm_acle.h
  clang/test/CodeGen/aarch64-mops.c
  llvm/include/llvm/IR/IntrinsicsAArch64.td

Index: llvm/include/llvm/IR/IntrinsicsAArch64.td
===
--- llvm/include/llvm/IR/IntrinsicsAArch64.td
+++ llvm/include/llvm/IR/IntrinsicsAArch64.td
@@ -890,6 +890,14 @@
 [IntrWriteMem, IntrArgMemOnly, NoCapture>, WriteOnly>]>;
 }
 
+//===--===//
+// Memory Operations (MOPS) Intrinsics
+let TargetPrefix = "aarch64" in {
+  // Sizes are chosen to correspond to the llvm.memset intrinsic: ptr, i8, i64
+  def int_aarch64_mops_memset_tag : DefaultAttrsIntrinsic<[llvm_ptr_ty], [llvm_ptr_ty, llvm_i8_ty, llvm_i64_ty],
+  [IntrWriteMem, IntrArgMemOnly, NoCapture>, WriteOnly>]>;
+}
+
 // Transactional Memory Extension (TME) Intrinsics
 let TargetPrefix = "aarch64" in {
 def int_aarch64_tstart  : GCCBuiltin<"__builtin_arm_tstart">,
Index: clang/test/CodeGen/aarch64-mops.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-mops.c
@@ -0,0 +1,152 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple aarch64-arm-unknown-eabi -target-feature +mops -target-feature +mte -O0 -S -emit-llvm -o - %s  | FileCheck %s
+
+#define __ARM_FEATURE_MOPS 1
+#include 
+#include 
+
+// CHECK-LABEL: @bzero_0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 0)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_0(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 0);
+}
+
+// CHECK-LABEL: @bzero_1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 1)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_1(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 1);
+}
+
+// CHECK-LABEL: @bzero_10(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 10)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_10(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 10);
+}
+
+// CHECK-LABEL: @bzero_1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 1)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_1(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 1);
+}
+
+// CHECK-LABEL: @bzero_n(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[SIZE_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:store i64 [[SIZE:%.*]], i64* [[SIZE_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i64, i64* [[SIZE_ADDR]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 [[TMP1]])
+// CHECK-NEXT:ret i8* [[TMP2]]
+//
+void *bzero_n(void *dst, size_t size) {
+  return __arm_mops_memset_tag(dst, 0, size);
+}
+
+// CHECK-LABEL: @memset_0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[VALUE_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:store i32 [[VA

[PATCH] D117753: [AArch64] Support for memset tagged intrinsic

[Son Tuan Vu via Phabricator via cfe-commits]

tyb0807 updated this revision to Diff 401534.
tyb0807 edited the summary of this revision.
tyb0807 added a comment.

Update commit message to clarify context.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117753

Files:
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/arm_acle.h
  clang/test/CodeGen/aarch64-mops.c
  llvm/include/llvm/IR/IntrinsicsAArch64.td

Index: llvm/include/llvm/IR/IntrinsicsAArch64.td
===
--- llvm/include/llvm/IR/IntrinsicsAArch64.td
+++ llvm/include/llvm/IR/IntrinsicsAArch64.td
@@ -890,6 +890,14 @@
 [IntrWriteMem, IntrArgMemOnly, NoCapture>, WriteOnly>]>;
 }
 
+//===--===//
+// Memory Operations (MOPS) Intrinsics
+let TargetPrefix = "aarch64" in {
+  // Sizes are chosen to correspond to the llvm.memset intrinsic: ptr, i8, i64
+  def int_aarch64_mops_memset_tag : DefaultAttrsIntrinsic<[llvm_ptr_ty], [llvm_ptr_ty, llvm_i8_ty, llvm_i64_ty],
+  [IntrWriteMem, IntrArgMemOnly, NoCapture>, WriteOnly>]>;
+}
+
 // Transactional Memory Extension (TME) Intrinsics
 let TargetPrefix = "aarch64" in {
 def int_aarch64_tstart  : GCCBuiltin<"__builtin_arm_tstart">,
Index: clang/test/CodeGen/aarch64-mops.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-mops.c
@@ -0,0 +1,152 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple aarch64-arm-unknown-eabi -target-feature +mops -target-feature +mte -O0 -S -emit-llvm -o - %s  | FileCheck %s
+
+#define __ARM_FEATURE_MOPS 1
+#include 
+#include 
+
+// CHECK-LABEL: @bzero_0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 0)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_0(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 0);
+}
+
+// CHECK-LABEL: @bzero_1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 1)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_1(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 1);
+}
+
+// CHECK-LABEL: @bzero_10(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 10)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_10(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 10);
+}
+
+// CHECK-LABEL: @bzero_1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 1)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_1(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 1);
+}
+
+// CHECK-LABEL: @bzero_n(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[SIZE_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:store i64 [[SIZE:%.*]], i64* [[SIZE_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i64, i64* [[SIZE_ADDR]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 [[TMP1]])
+// CHECK-NEXT:ret i8* [[TMP2]]
+//
+void *bzero_n(void *dst, size_t size) {
+  return __arm_mops_memset_tag(dst, 0, size);
+}
+
+// CHECK-LABEL: @memset_0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[VALUE_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:store i32 [[VALUE:%.*]], i32* [[VALUE_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[VALUE_ADDR]], align 4
+// CHECK-NEXT:[[TMP2:%.*]] = trunc i32 [[TMP1]] to i8
+// CHECK-NEXT:[[TMP3:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i

[PATCH] D116386: [clang-tidy] Narrow cppguidelines-macro-usage to actual constants

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp:23
 
-namespace {
-
-bool isCapsOnly(StringRef Name) {
-  return std::all_of(Name.begin(), Name.end(), [](const char C) {
-if (std::isupper(C) || std::isdigit(C) || C == '_')
-  return true;
-return false;
+static inline bool isCapsOnly(StringRef Name) {
+  return llvm::all_of(Name, [](const char C) {

LegalizeAdulthood wrote:
> carlosgalvezp wrote:
> > Nit: `inline` can be removed.
> Yeah, my IDE flagged it but since you asked for the `static`  `:)`
Sorry for the confusion, I should have added inline fixes directly to make it 
clear :) 



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst:11
+`ES.31 
`_,
 and
+`ES.32 
`_.
+

LegalizeAdulthood wrote:
> carlosgalvezp wrote:
> > LegalizeAdulthood wrote:
> > > carlosgalvezp wrote:
> > > > Is ES.32 really checked by this check? I don't see any example or test 
> > > > that indicates that.
> > > > 
> > > > I'm also unsure if ES.32 should be handled here or via the 
> > > > "readability-identifier-naming" check, which is where you enforce a 
> > > > particular naming convention for different identifiers. Setting 
> > > > ALL_CAPS for macros there would be an effective way of solving ES.32.
> > > It was always handled through an option on this check.
> > > (Look at lines 49-56 of `MacroUsageCheck.cpp`)
> > > 
> > > It's a little bit odd, because it either checks for the names
> > > or it checks for the constant/function like macros, it never
> > > does both at the same time.
> > > 
> > > This is the way the check was originally written, I haven't
> > > changed any of that.
> > Ah I see it now! I got really confused by the `CheckCapsOnly` option. Not 
> > for this patch, but I think the following could be improved:
> > 
> > * Set it default to True, not False. People expect that check enforce a 
> > given guideline as good as possible by default. Options exist to deviate 
> > from the guidelines and relax them, which would be the case e.g. when 
> > introducing the check in an old codebase.
> > 
> > * Be renamed to something more descriptive and split it into 2 options with 
> > one single purpose. Right now this option controls a) enforcing ES.32 and 
> > b) applying warnings to macros with all caps or not.
> Yeah, I wasn't a fan of the way this option was influencing the behavior of 
> this check.
> 
> Can you open a github issue for the points you raised?
Absolutely, much better place for this!



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-macro-usage.cpp:1
-// RUN: %check_clang_tidy %s cppcoreguidelines-macro-usage %t -- 
-header-filter=.* -system-headers --
+// RUN: %check_clang_tidy %s cppcoreguidelines-macro-usage -std=c++17-or-later 
%t -- -header-filter=.* -system-headers --
 

LegalizeAdulthood wrote:
> carlosgalvezp wrote:
> > I'm curious as to why this is needed. If I remove it the test fails, on 
> > line 15, but the `u8` prefix was introduced already since C++11?
> The `u''` (UTF-16) and `U''` (UTF-32) character literals were added in C++11.
> The `u8''` (UTF-8) character literal was added in C++17.
> https://en.cppreference.com/w/cpp/language/character_literal
Duh, I was checking //string// literal, not //character// literal
https://en.cppreference.com/w/cpp/language/string_literal


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116386

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

[clang] 794b1ee - [clang-format] Add tests for aligning `operator=` with `=delete`. NFC.

[Marek Kurdej via cfe-commits]

Author: Marek Kurdej
Date: 2022-01-20T09:39:08+01:00
New Revision: 794b1eebe749d739a0c530ca53cadc8925fbfec2

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

LOG: [clang-format] Add tests for aligning `operator=` with `=delete`. NFC.

Also, add test case from https://github.com/llvm/llvm-project/issues/33044.
This was actually fixed in 
https://github.com/llvm/llvm-project/commit/480a1fab72f4e367a5986d572914d252c318431d,
 but there were no tests for delete.

Added: 


Modified: 
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 6bd417388fc7..0ddbac48d716 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -16274,6 +16274,10 @@ TEST_F(FormatTest, AlignConsecutiveAssignments) {
"int &operator() = default;\n"
"int &operator=() {",
Alignment);
+  verifyFormat("int f() = delete;\n"
+   "int &operator() = delete;\n"
+   "int &operator=() {",
+   Alignment);
   verifyFormat("int f() = default; // comment\n"
"int &operator() = default; // comment\n"
"int &operator=() {",
@@ -16294,10 +16298,25 @@ TEST_F(FormatTest, AlignConsecutiveAssignments) {
"int &operator() = default;\n"
"int &operator=();",
Alignment);
+  verifyFormat("int f() = delete;\n"
+   "int &operator() = delete;\n"
+   "int &operator=();",
+   Alignment);
   verifyFormat("/* long long padding */ int f() = default;\n"
"int &operator() = default;\n"
"int &operator/**/ =();",
Alignment);
+  // https://llvm.org/PR33697
+  FormatStyle AlignmentWithPenalty = getLLVMStyle();
+  AlignmentWithPenalty.AlignConsecutiveAssignments =
+  FormatStyle::ACS_Consecutive;
+  AlignmentWithPenalty.PenaltyReturnTypeOnItsOwnLine = 5000;
+  verifyFormat("class  {\n"
+   "  void f() = delete;\n"
+   "   &operator=(\n"
+   "  const  &other) = delete;\n"
+   "};\n",
+   AlignmentWithPenalty);
 
   // Bug 25167
   /* Uncomment when fixed



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

[PATCH] D113336: [RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD added a comment.

This patch needs to be landed before D112613  
because clang_cc1 needs to do correct implication from `v`, `zve32f`, `zve64f` 
and `zve64d` and this patch fixes the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113336

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

[PATCH] D113336: [RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng accepted this revision.
kito-cheng added a comment.
This revision is now accepted and ready to land.

Otherwise LGTM.




Comment at: clang/lib/Basic/Targets/RISCV.cpp:220
 
-  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+  unsigned XLen = Features["64bit"] ? 64 : 32;
+  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeaturesVec);

Maybe update XLen based on the if condition? that might save one StringMap 
query.
```
  unsigned XLen = 32;

  if (getTriple().getArch() == llvm::Triple::riscv64) {
Features["64bit"] = true;
XLen = 64;
  }
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113336

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

[PATCH] D113336: [RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 401541.
eopXD marked an inline comment as done.
eopXD added a comment.

Update code based on @kito-cheng 's comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113336

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -881,3 +881,17 @@
 
   return Arch.str();
 }
+
+std::vector RISCVISAInfo::toFeatureVector() const {
+  std::vector FeatureVector;
+  for (auto Ext : Exts) {
+std::string ExtName = Ext.first;
+if (ExtName == "i") // i is not recognized in clang -cc1
+  continue;
+std::string Feature = isExperimentalExtension(ExtName)
+  ? "+experimental-" + ExtName
+  : "+" + ExtName;
+FeatureVector.push_back(Feature);
+  }
+  return FeatureVector;
+}
Index: llvm/include/llvm/Support/RISCVISAInfo.h
===
--- llvm/include/llvm/Support/RISCVISAInfo.h
+++ llvm/include/llvm/Support/RISCVISAInfo.h
@@ -67,6 +67,7 @@
 
   bool hasExtension(StringRef Ext) const;
   std::string toString() const;
+  std::vector toFeatureVector() const;
 
   static bool isSupportedExtensionFeature(StringRef Ext);
   static bool isSupportedExtension(StringRef Ext);
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -214,10 +214,26 @@
 llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
 const std::vector &FeaturesVec) const {
 
-  if (getTriple().getArch() == llvm::Triple::riscv64)
+  unsigned XLen = 32;
+
+  if (getTriple().getArch() == llvm::Triple::riscv64) {
 Features["64bit"] = true;
+XLen = 64;
+  }
+
+  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeaturesVec);
+  if (!ParseResult) {
+std::string Buffer;
+llvm::raw_string_ostream OutputErrMsg(Buffer);
+handleAllErrors(ParseResult.takeError(), [&](llvm::StringError &ErrMsg) {
+  OutputErrMsg << ErrMsg.getMessage();
+});
+Diags.Report(diag::err_invalid_feature_combination) << OutputErrMsg.str();
+return false;
+  }
 
-  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+  return TargetInfo::initFeatureMap(Features, Diags, CPU,
+(*ParseResult)->toFeatureVector());
 }
 
 /// Return true if has this feature, need to sync with handleTargetFeatures.


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -881,3 +881,17 @@
 
   return Arch.str();
 }
+
+std::vector RISCVISAInfo::toFeatureVector() const {
+  std::vector FeatureVector;
+  for (auto Ext : Exts) {
+std::string ExtName = Ext.first;
+if (ExtName == "i") // i is not recognized in clang -cc1
+  continue;
+std::string Feature = isExperimentalExtension(ExtName)
+  ? "+experimental-" + ExtName
+  : "+" + ExtName;
+FeatureVector.push_back(Feature);
+  }
+  return FeatureVector;
+}
Index: llvm/include/llvm/Support/RISCVISAInfo.h
===
--- llvm/include/llvm/Support/RISCVISAInfo.h
+++ llvm/include/llvm/Support/RISCVISAInfo.h
@@ -67,6 +67,7 @@
 
   bool hasExtension(StringRef Ext) const;
   std::string toString() const;
+  std::vector toFeatureVector() const;
 
   static bool isSupportedExtensionFeature(StringRef Ext);
   static bool isSupportedExtension(StringRef Ext);
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -214,10 +214,26 @@
 llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
 const std::vector &FeaturesVec) const {
 
-  if (getTriple().getArch() == llvm::Triple::riscv64)
+  unsigned XLen = 32;
+
+  if (getTriple().getArch() == llvm::Triple::riscv64) {
 Features["64bit"] = true;
+XLen = 64;
+  }
+
+  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeaturesVec);
+  if (!ParseResult) {
+std::string Buffer;
+llvm::raw_string_ostream OutputErrMsg(Buffer);
+handleAllErrors(ParseResult.takeError(), [&](llvm::StringError &ErrMsg) {
+  OutputErrMsg << ErrMsg.getMessage();
+});
+Diags.Report(diag::err_invalid_feature_combination) << OutputErrMsg.str();
+return false;
+  }
 
-  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+  return TargetInfo::initFeatureMap(Fe

[PATCH] D112987: [RISCV] Bump rvv-related extensions from 0.10 to 1.0

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 401546.
eopXD added a comment.

Rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112987

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/utils/TableGen/RISCVVEmitter.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -881,3 +881,17 @@
 
   return Arch.str();
 }
+
+std::vector RISCVISAInfo::toFeatureVector() const {
+  std::vector FeatureVector;
+  for (auto Ext : Exts) {
+std::string ExtName = Ext.first;
+if (ExtName == "i") // i is not recognized in clang -cc1
+  continue;
+std::string Feature = isExperimentalExtension(ExtName)
+  ? "+experimental-" + ExtName
+  : "+" + ExtName;
+FeatureVector.push_back(Feature);
+  }
+  return FeatureVector;
+}
Index: llvm/include/llvm/Support/RISCVISAInfo.h
===
--- llvm/include/llvm/Support/RISCVISAInfo.h
+++ llvm/include/llvm/Support/RISCVISAInfo.h
@@ -67,6 +67,7 @@
 
   bool hasExtension(StringRef Ext) const;
   std::string toString() const;
+  std::vector toFeatureVector() const;
 
   static bool isSupportedExtensionFeature(StringRef Ext);
   static bool isSupportedExtension(StringRef Ext);
Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -214,10 +214,26 @@
 llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
 const std::vector &FeaturesVec) const {
 
-  if (getTriple().getArch() == llvm::Triple::riscv64)
+  unsigned XLen = 32;
+
+  if (getTriple().getArch() == llvm::Triple::riscv64) {
 Features["64bit"] = true;
+XLen = 64;
+  }
+
+  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeaturesVec);
+  if (!ParseResult) {
+std::string Buffer;
+llvm::raw_string_ostream OutputErrMsg(Buffer);
+handleAllErrors(ParseResult.takeError(), [&](llvm::StringError &ErrMsg) {
+  OutputErrMsg << ErrMsg.getMessage();
+});
+Diags.Report(diag::err_invalid_feature_combination) << OutputErrMsg.str();
+return false;
+  }
 
-  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+  return TargetInfo::initFeatureMap(Features, Diags, CPU,
+(*ParseResult)->toFeatureVector());
 }
 
 /// Return true if has this feature, need to sync with handleTargetFeatures.


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -881,3 +881,17 @@
 
   return Arch.str();
 }
+
+std::vector RISCVISAInfo::toFeatureVector() const {
+  std::vector FeatureVector;
+  for (auto Ext : Exts) {
+std::string ExtName = Ext.first;
+if (ExtName == "i") // i is not recognized in clang -cc1
+  continue;
+std::string Feature = isExperimentalExtension(ExtName)
+  ? "+experimental-" + ExtName
+  : "+" + ExtName;
+FeatureVector.push_back(Feature);
+  }
+  return FeatureVector;
+}
Index: llvm/include/llvm/Support/RISCVISAInfo.h
===
--- llvm/include/llvm/Support/RISCVISAInfo.h
+++ llvm/include/llvm/Support/RISCVISAInfo.h
@@ -67,6 +67,7 @@
 
   bool hasExtension(StringRef Ext) const;
   std::string toString() const;
+  std::vector toFeatureVector() const;
 
   static bool isSupportedExtensionFeature(StringRef Ext);
   static bool isSupportedExtension(StringRef Ext);
Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =
Index: clang/lib/Basic/Targets/RISCV.c

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev created this revision.
sgatev added reviewers: ymandel, xazax.hun, gribozavr2.
Herald added subscribers: steakhal, rnkovacs.
sgatev requested review of this revision.
Herald added a project: clang.

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117754

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1828,4 +1828,41 @@
   });
 }
 
+TEST_F(TransferTest, VarDeclInDoWhile) {
+  std::string Code = R"(
+void target(int *Foo) {
+  do {
+int Bar = *Foo;
+  } while (true);
+  (void)0;
+  /*[[p]]*/
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const auto *FooVal =
+cast(Env.getValue(*FooDecl, SkipPast::None));
+const auto *FooPointeeVal =
+cast(Env.getValue(FooVal->getPointeeLoc()));
+
+const auto *BarVal = dyn_cast_or_null(
+Env.getValue(*BarDecl, SkipPast::None));
+ASSERT_THAT(BarVal, NotNull());
+
+EXPECT_EQ(BarVal, FooPointeeVal);
+  });
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -12,6 +12,7 @@
 
//===--===//
 
 #include 
+#include 
 #include 
 #include 
 
@@ -43,7 +44,9 @@
 std::vector> &BlockStates,
 const CFGBlock &Block, const Environment &InitEnv,
 TypeErasedDataflowAnalysis &Analysis) {
-  llvm::DenseSet Preds;
+  // Ensure the order of predecessor blocks is deterministic to avoid flakiness
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());
   if (Block.getTerminator().isTemporaryDtorsBranch()) {
 // This handles a special case where the code that produced the CFG 
includes
Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -83,6 +83,11 @@
   if (DeclToLocSizeBefore != DeclToLoc.size())
 Effect = LatticeJoinEffect::Changed;
 
+  const unsigned ExprToLocSizeBefore = ExprToLoc.size();
+  ExprToLoc = intersectDenseMaps(ExprToLoc, Other.ExprToLoc);
+  if (ExprToLocSizeBefore != ExprToLoc.size())
+Effect = LatticeJoinEffect::Changed;
+
   // FIXME: Add support for joining distinct values that are assigned to the
   // same storage locations in `LocToVal` and `Other.LocToVal`.
   const unsigned LocToValSizeBefore = LocToVal.size();


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1828,4 +1828,41 @@
   });
 }
 
+TEST_F(TransferTest, VarDeclInDoWhile) {
+  std::string Code = R"(
+void target(int *Foo) {
+  do {
+int Bar = *Foo;
+  } while (true);
+  (void)0;
+  /*[[p]]*/
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const auto *FooVal =
+cast(Env.getValue(*FooDecl, SkipPast::None));
+const auto *FooPoin

[PATCH] D112613: [RISCV] Change TARGET_BUILTIN require to zve32x for vector instruction

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 401549.
eopXD added a comment.

Rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112613

Files:
  clang/utils/TableGen/RISCVVEmitter.cpp


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 60b6e73 - [RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap

[via cfe-commits]

Author: eopXD
Date: 2022-01-20T01:47:10-08:00
New Revision: 60b6e73769f84110f2cc0a2dbbf610c8671aa696

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

LOG: [RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap

Under ASTContext, clang only copies the features from the options with
Target->initFeatureMap, and no implications is done there. This makes
clang_cc1 fail to imply into `zve32x` for the vector extension, and test
cases will have to add ` -target-feature +experimental-zve32x` in order
to work.

This patch fixes it.

Reviewed By: kito-cheng

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

Added: 


Modified: 
clang/lib/Basic/Targets/RISCV.cpp
llvm/include/llvm/Support/RISCVISAInfo.h
llvm/lib/Support/RISCVISAInfo.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/RISCV.cpp 
b/clang/lib/Basic/Targets/RISCV.cpp
index 43b031dbdad7a..dc4a451726bbe 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -214,10 +214,26 @@ bool RISCVTargetInfo::initFeatureMap(
 llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
 const std::vector &FeaturesVec) const {
 
-  if (getTriple().getArch() == llvm::Triple::riscv64)
+  unsigned XLen = 32;
+
+  if (getTriple().getArch() == llvm::Triple::riscv64) {
 Features["64bit"] = true;
+XLen = 64;
+  }
+
+  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeaturesVec);
+  if (!ParseResult) {
+std::string Buffer;
+llvm::raw_string_ostream OutputErrMsg(Buffer);
+handleAllErrors(ParseResult.takeError(), [&](llvm::StringError &ErrMsg) {
+  OutputErrMsg << ErrMsg.getMessage();
+});
+Diags.Report(diag::err_invalid_feature_combination) << OutputErrMsg.str();
+return false;
+  }
 
-  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+  return TargetInfo::initFeatureMap(Features, Diags, CPU,
+(*ParseResult)->toFeatureVector());
 }
 
 /// Return true if has this feature, need to sync with handleTargetFeatures.

diff  --git a/llvm/include/llvm/Support/RISCVISAInfo.h 
b/llvm/include/llvm/Support/RISCVISAInfo.h
index 2dca0fe65d563..93aaa82f4c0b1 100644
--- a/llvm/include/llvm/Support/RISCVISAInfo.h
+++ b/llvm/include/llvm/Support/RISCVISAInfo.h
@@ -67,6 +67,7 @@ class RISCVISAInfo {
 
   bool hasExtension(StringRef Ext) const;
   std::string toString() const;
+  std::vector toFeatureVector() const;
 
   static bool isSupportedExtensionFeature(StringRef Ext);
   static bool isSupportedExtension(StringRef Ext);

diff  --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 7aee909a0bdc6..d1d222d3c0eb0 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -881,3 +881,17 @@ std::string RISCVISAInfo::toString() const {
 
   return Arch.str();
 }
+
+std::vector RISCVISAInfo::toFeatureVector() const {
+  std::vector FeatureVector;
+  for (auto Ext : Exts) {
+std::string ExtName = Ext.first;
+if (ExtName == "i") // i is not recognized in clang -cc1
+  continue;
+std::string Feature = isExperimentalExtension(ExtName)
+  ? "+experimental-" + ExtName
+  : "+" + ExtName;
+FeatureVector.push_back(Feature);
+  }
+  return FeatureVector;
+}



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

[PATCH] D113336: [RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap

[Yueh-Ting Chen via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG60b6e73769f8: [RISCV] Imply extensions in 
RISCVTargetInfo::initFeatureMap (authored by eopXD).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113336

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -881,3 +881,17 @@
 
   return Arch.str();
 }
+
+std::vector RISCVISAInfo::toFeatureVector() const {
+  std::vector FeatureVector;
+  for (auto Ext : Exts) {
+std::string ExtName = Ext.first;
+if (ExtName == "i") // i is not recognized in clang -cc1
+  continue;
+std::string Feature = isExperimentalExtension(ExtName)
+  ? "+experimental-" + ExtName
+  : "+" + ExtName;
+FeatureVector.push_back(Feature);
+  }
+  return FeatureVector;
+}
Index: llvm/include/llvm/Support/RISCVISAInfo.h
===
--- llvm/include/llvm/Support/RISCVISAInfo.h
+++ llvm/include/llvm/Support/RISCVISAInfo.h
@@ -67,6 +67,7 @@
 
   bool hasExtension(StringRef Ext) const;
   std::string toString() const;
+  std::vector toFeatureVector() const;
 
   static bool isSupportedExtensionFeature(StringRef Ext);
   static bool isSupportedExtension(StringRef Ext);
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -214,10 +214,26 @@
 llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
 const std::vector &FeaturesVec) const {
 
-  if (getTriple().getArch() == llvm::Triple::riscv64)
+  unsigned XLen = 32;
+
+  if (getTriple().getArch() == llvm::Triple::riscv64) {
 Features["64bit"] = true;
+XLen = 64;
+  }
+
+  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeaturesVec);
+  if (!ParseResult) {
+std::string Buffer;
+llvm::raw_string_ostream OutputErrMsg(Buffer);
+handleAllErrors(ParseResult.takeError(), [&](llvm::StringError &ErrMsg) {
+  OutputErrMsg << ErrMsg.getMessage();
+});
+Diags.Report(diag::err_invalid_feature_combination) << OutputErrMsg.str();
+return false;
+  }
 
-  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+  return TargetInfo::initFeatureMap(Features, Diags, CPU,
+(*ParseResult)->toFeatureVector());
 }
 
 /// Return true if has this feature, need to sync with handleTargetFeatures.


Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -881,3 +881,17 @@
 
   return Arch.str();
 }
+
+std::vector RISCVISAInfo::toFeatureVector() const {
+  std::vector FeatureVector;
+  for (auto Ext : Exts) {
+std::string ExtName = Ext.first;
+if (ExtName == "i") // i is not recognized in clang -cc1
+  continue;
+std::string Feature = isExperimentalExtension(ExtName)
+  ? "+experimental-" + ExtName
+  : "+" + ExtName;
+FeatureVector.push_back(Feature);
+  }
+  return FeatureVector;
+}
Index: llvm/include/llvm/Support/RISCVISAInfo.h
===
--- llvm/include/llvm/Support/RISCVISAInfo.h
+++ llvm/include/llvm/Support/RISCVISAInfo.h
@@ -67,6 +67,7 @@
 
   bool hasExtension(StringRef Ext) const;
   std::string toString() const;
+  std::vector toFeatureVector() const;
 
   static bool isSupportedExtensionFeature(StringRef Ext);
   static bool isSupportedExtension(StringRef Ext);
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -214,10 +214,26 @@
 llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
 const std::vector &FeaturesVec) const {
 
-  if (getTriple().getArch() == llvm::Triple::riscv64)
+  unsigned XLen = 32;
+
+  if (getTriple().getArch() == llvm::Triple::riscv64) {
 Features["64bit"] = true;
+XLen = 64;
+  }
+
+  auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeaturesVec);
+  if (!ParseResult) {
+std::string Buffer;
+llvm::raw_string_ostream OutputErrMsg(Buffer);
+handleAllErrors(ParseResult.takeError(), [&](llvm::StringError &ErrMsg) {
+  OutputErrMsg << ErrMsg.getMessage();
+});
+Diags.Report(diag::err_invalid_feature_combination) << OutputErrMsg.str();
+return false;
+  }
 
-  return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
+  r

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Nuno Lopes via Phabricator via cfe-commits]

nlopes added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2535
 ArgAttrs[FirstIRArg + i] =
 llvm::AttributeSet::get(getLLVMContext(), Attrs);
 }

fhahn wrote:
> nlopes wrote:
> > ab wrote:
> > > Hmm, if I'm reading this right, this overwrites the `nonnull 
> > > dereferenceable align` attributes separately computed for `this` around 
> > > l2335, right? (or `inalloca` and `sret` before that)
> > > 
> > > It sounds like an ancient bug, that's only exposed because `noundef` ends 
> > > up triggering this logic much more often?
> > > 
> > > Many of our downstream tests hit this. The hacked up patch seems to do 
> > > the job; ideally we'd feed the previously-computed attrs when 
> > > constructing the AttrBuilder (which would also fix the padding argument), 
> > > but we'd need to match up the IR args first.  Maybe that's fine as a 
> > > special-case for arg 0 though
> > nice catch! It's an ancient bug where arg 0 is overwritten.
> Is anybody looking into a fix or should we revert the patch until this can be 
> properly addressed?
I would recommend against reverting this patch because of all the followup 
patches. There were quite a few commits afterwards plus fixes to buildbot 
configurations, so it's a non-trivial overhead to revert everything.
I was assuming @ab would fix it as he already root-caused the bug..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D112613: [RISCV] Change TARGET_BUILTIN require to zve32x for vector instruction

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 401554.
eopXD added a comment.

Rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112613

Files:
  clang/utils/TableGen/RISCVVEmitter.cpp


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116085: [clang-tidy] Performance improvements for NOLINTBEGIN/END blocks

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added a comment.

In D116085#3257210 , @carlosgalvezp 
wrote:

> Amazing job @salman-javed-nz ! Here's some initial comments. Reviewing the 
> `NoLintPragmaHandler.cpp` will take some more time from me. It would have 
> been easier to see the diff if the contents had been moved as an NFC patch to 
> a separate file, and then applying the optimizations in this patch. But it's 
> done now so I'll deal with it :)

Thank you :)

You might find the previous revision of this patch useful then 
(https://reviews.llvm.org/D116085?id=395606). In this earlier revision I made 
the change in the original file `ClangTidyDiagnosticHandler.cpp`.
There's been some refinements to that code in the subsequent revisions (the 
subsequent revisions aren't merely just moving the changes to a separate file) 
but it's still useful as a way to get the general gist of the new NOLINT 
tokenization and location caching process.




Comment at: clang-tools-extra/clang-tidy/CMakeLists.txt:20
   GlobList.cpp
+  NoLintPragmaHandler.cpp
 

carlosgalvezp wrote:
> I think "Pragma" is a very specific term, used for example in `#pragma gcc 
> diagnostic` or `// IWYU pragma: keep`, but in `clang-tidy` we don't use the 
> word `pragma`, so that might be confusing. What about renaming it to 
> `NoLintHandler.cpp` or `NoLintDirectiveHandler.cpp`?
Your suggestions sound better. I'm not attached to the name 
`NoLintPragmaHandler`.



Comment at: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h:125
+const Diagnostic &Info,
+SmallVectorImpl &NoLintErrors);
+

carlosgalvezp wrote:
> Why not `SmallVector`? Sounds like the `Impl` is some "private" 
> implementation?
`SmallVectorImpl` is the recommended type to use for output params.
- `SmallVector` is actually `SmallVectorImpl` 
under the hood.
- By declaring the function param as `SmallVectorImpl` I'm saying that I don't 
care about the size of the vector that the caller passes in.

See https://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h
```
Even though it has “Impl” in the name, SmallVectorImpl is widely used and is no 
longer “private to the implementation”.
```



Comment at: clang-tools-extra/clang-tidy/NoLintPragmaHandler.h:18
+namespace llvm {
+template  class SmallVectorImpl;
+} // namespace llvm

carlosgalvezp wrote:
> Why not `SmallVector`?
See my other comment about `SmallVectorImpl`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116085

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

[PATCH] D117759: [clang-format][NFC] Clean up tryMergeLessLess()

[Owen Pan via Phabricator via cfe-commits]

owenpan created this revision.
owenpan added reviewers: MyDeveloperDay, curdeius, HazardyKnusperkeks, 
pjessesco.
owenpan added a project: clang-format.
owenpan 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/D117759

Files:
  clang/lib/Format/FormatTokenLexer.cpp


Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -430,19 +430,15 @@
 return false;
 
   auto First = Tokens.end() - 3;
-  bool FourthTokenIsLess = false;
+  auto X = Tokens.size() > 3 ? First[-1] : nullptr;
+  auto Y = First[2];
 
-  if (Tokens.size() > 3) {
-auto Fourth = (Tokens.end() - 4)[0];
-FourthTokenIsLess = Fourth->is(tok::less);
-
-// Do not remove a whitespace between the two "<" e.g. "operator< <>".
-if (First[2]->is(tok::greater) && Fourth->is(tok::kw_operator))
-  return false;
-  }
+  // Do not remove a whitespace between the two "<" e.g. "operator< <>".
+  if (Y->is(tok::greater) && X && X->is(tok::kw_operator))
+return false;
 
-  if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
-  First[0]->isNot(tok::less) || FourthTokenIsLess)
+  if (Y->is(tok::less) || First[1]->isNot(tok::less) ||
+  First[0]->isNot(tok::less) || (X && X->is(tok::less)))
 return false;
 
   // Only merge if there currently is no whitespace between the two "<".


Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -430,19 +430,15 @@
 return false;
 
   auto First = Tokens.end() - 3;
-  bool FourthTokenIsLess = false;
+  auto X = Tokens.size() > 3 ? First[-1] : nullptr;
+  auto Y = First[2];
 
-  if (Tokens.size() > 3) {
-auto Fourth = (Tokens.end() - 4)[0];
-FourthTokenIsLess = Fourth->is(tok::less);
-
-// Do not remove a whitespace between the two "<" e.g. "operator< <>".
-if (First[2]->is(tok::greater) && Fourth->is(tok::kw_operator))
-  return false;
-  }
+  // Do not remove a whitespace between the two "<" e.g. "operator< <>".
+  if (Y->is(tok::greater) && X && X->is(tok::kw_operator))
+return false;
 
-  if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
-  First[0]->isNot(tok::less) || FourthTokenIsLess)
+  if (Y->is(tok::less) || First[1]->isNot(tok::less) ||
+  First[0]->isNot(tok::less) || (X && X->is(tok::less)))
 return false;
 
   // Only merge if there currently is no whitespace between the two "<".
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116221: [AArch64][ARM][Clang] Unaligned Access Warning Added

[Sam Elliott via Phabricator via cfe-commits]

lenary accepted this revision.
lenary added a comment.

LGTM. I've looked a lot closer at the tests this time around, and am happy with 
them, and I think the message is phrased better, and there shouldn't be 
warnings with `-cc1as`.


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

https://reviews.llvm.org/D116221

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

[PATCH] D117202: [ARM] Add Cortex-X1C Support for Clang and LLVM

[Ties Stuij via Phabricator via cfe-commits]

stuij marked 2 inline comments as done.
stuij added inline comments.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:205
+AARCH64_CPU_NAME("cortex-x1c", ARMV8_2A, FK_CRYPTO_NEON_FP_ARMV8, false,
+ (AArch64::AEK_RAS))
 AARCH64_CPU_NAME("cortex-x2", ARMV9A, FK_NEON_FP_ARMV8, false,

dmgreen wrote:
> Should this have the same features as the cortex-x1? AEK_DOTPROD and AEK_FP16 
> and the rest?
Yes, you're right. I've added these.



Comment at: llvm/lib/Target/AArch64/AArch64.td:983
+ FeatureNEON, FeaturePerfMon, FeatureSPE,
+ FeaturePAuth, FeatureFullFP16, 
FeatureFP16FML];
   list X2   = [HasV9_0aOps, FeatureNEON, FeaturePerfMon,

dmgreen wrote:
> Should this have dotprod and RCPC?
> 
> The TRM isn't super clear on what features are present. Is FP16FML present?
Right, the addition of FP16FML must have been copied from the X1, which was 
later removed when upstreaming. I removed it here, and I added dotard and RCPC. 
The only relevant change from X1 to X1C is the addition of PAUTH, as per the 
TRM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117202

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

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2535
 ArgAttrs[FirstIRArg + i] =
 llvm::AttributeSet::get(getLLVMContext(), Attrs);
 }

nlopes wrote:
> fhahn wrote:
> > nlopes wrote:
> > > ab wrote:
> > > > Hmm, if I'm reading this right, this overwrites the `nonnull 
> > > > dereferenceable align` attributes separately computed for `this` around 
> > > > l2335, right? (or `inalloca` and `sret` before that)
> > > > 
> > > > It sounds like an ancient bug, that's only exposed because `noundef` 
> > > > ends up triggering this logic much more often?
> > > > 
> > > > Many of our downstream tests hit this. The hacked up patch seems to do 
> > > > the job; ideally we'd feed the previously-computed attrs when 
> > > > constructing the AttrBuilder (which would also fix the padding 
> > > > argument), but we'd need to match up the IR args first.  Maybe that's 
> > > > fine as a special-case for arg 0 though
> > > nice catch! It's an ancient bug where arg 0 is overwritten.
> > Is anybody looking into a fix or should we revert the patch until this can 
> > be properly addressed?
> I would recommend against reverting this patch because of all the followup 
> patches. There were quite a few commits afterwards plus fixes to buildbot 
> configurations, so it's a non-trivial overhead to revert everything.
> I was assuming @ab would fix it as he already root-caused the bug..
FWIW it seems a bit unfortunate that there are some clear regressions when the 
tests got update, e.g. 
https://github.com/llvm/llvm-project/commit/1b1c8d83d3567a60280291c0adb95d1d60335509#diff-7e80d593f26f6f6fb24765c6a169884d7350685d565ee970b0a7b9abaf0fb205L355

I'll work with @ab to fix this though rather than reverting, because another 
revert would cause even more conflicts for us downstream.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D115856: [syntax][pseudo] Introduce the spec C++ grammar.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 401559.
hokein marked 7 inline comments as done.
hokein added a comment.

address comments and add lit test to verify cxx.bnf


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115856

Files:
  clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
  clang/test/CMakeLists.txt
  clang/test/Syntax/check-cxx-bnf.test
  clang/test/Syntax/lit.local.cfg
  clang/tools/CMakeLists.txt
  clang/tools/clang-pseudo/CMakeLists.txt
  clang/tools/clang-pseudo/ClangPseudo.cpp

Index: clang/tools/clang-pseudo/ClangPseudo.cpp
===
--- /dev/null
+++ clang/tools/clang-pseudo/ClangPseudo.cpp
@@ -0,0 +1,47 @@
+//===-- ClangPseudo.cpp - Clang pseudo parser tool ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Tooling/Syntax/Pseudo/Grammar.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/MemoryBuffer.h"
+
+using clang::syntax::pseudo::Grammar;
+using llvm::cl::desc;
+using llvm::cl::init;
+using llvm::cl::opt;
+
+static opt
+CheckGrammar("check-grammar", desc("Parse and check a BNF grammar file."),
+ init(""));
+
+int main(int argc, char *argv[]) {
+  llvm::cl::ParseCommandLineOptions(argc, argv, "");
+
+  if (CheckGrammar.getNumOccurrences()) {
+llvm::ErrorOr> Text =
+llvm::MemoryBuffer::getFile(CheckGrammar);
+if (std::error_code EC = Text.getError()) {
+  llvm::errs() << "Error: can't read grammar file '" << CheckGrammar
+   << "': " << EC.message() << "\n";
+  return 1;
+}
+std::vector Diags;
+auto RSpecs = Grammar::parseBNF(Text.get()->getBuffer(), Diags);
+
+if (!Diags.empty()) {
+  llvm::errs() << llvm::join(Diags, "\n");
+  return 2;
+}
+llvm::errs() << llvm::formatv("grammar file {0} is parsed successfully\n",
+  CheckGrammar);
+return 0;
+  }
+  return 0;
+}
Index: clang/tools/clang-pseudo/CMakeLists.txt
===
--- /dev/null
+++ clang/tools/clang-pseudo/CMakeLists.txt
@@ -0,0 +1,15 @@
+set(LLVM_LINK_COMPONENTS support)
+
+add_clang_tool(clang-pseudo
+  ClangPseudo.cpp
+  )
+
+set(CLANG_PSEUDO_LIB_DEPS
+  clangBasic
+  clangSyntaxPseudo
+  )
+
+clang_target_link_libraries(clang-pseudo
+  PRIVATE
+  ${CLANG_PSEUDO_LIB_DEPS}
+  )
\ No newline at end of file
Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -13,6 +13,7 @@
 add_clang_subdirectory(clang-offload-wrapper)
 add_clang_subdirectory(clang-scan-deps)
 add_clang_subdirectory(clang-repl)
+add_clang_subdirectory(clang-pseudo)
 
 add_clang_subdirectory(c-index-test)
 
Index: clang/test/Syntax/lit.local.cfg
===
--- /dev/null
+++ clang/test/Syntax/lit.local.cfg
@@ -0,0 +1,4 @@
+cxx_bnf_file = os.path.join(config.clang_src_dir, 'lib', 'Tooling', 'Syntax',
+'Pseudo', 'cxx.bnf')
+config.substitutions.append(('%cxx-bnf-file',
+ '%s' % (cxx_bnf_file)))
\ No newline at end of file
Index: clang/test/Syntax/check-cxx-bnf.test
===
--- /dev/null
+++ clang/test/Syntax/check-cxx-bnf.test
@@ -0,0 +1,2 @@
+// verify clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
+// RUN: clang-pseudo -check-grammar=%cxx-bnf-file
\ No newline at end of file
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -76,6 +76,7 @@
   clang-repl
   clang-diff
   clang-scan-deps
+  clang-pseudo
   diagtool
   hmaptool
   )
Index: clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
===
--- /dev/null
+++ clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
@@ -0,0 +1,739 @@
+# This is a C++ grammar from the C++ standard [1].
+#
+# The grammar is a superset of the true grammar requring semantic constraints to
+# resolve ambiguties. The grammar is context-free and ambiguous (beyond the
+# limit of LR(k)). We use general parsing algorithm (e.g GLR) to handle the
+# grammar and generate a transition table which is used to drive the parsing.
+#
+# It aims to align with the ISO C++ grammar as much as possible. We adjust it
+# to fit the need for the grammar-based parser:
+#  - attributes are omitted, which will be handled as comments;
+#  - we don't allo

[PATCH] D115856: [syntax][pseudo] Introduce the spec C++ grammar.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 401561.
hokein marked an inline comment as done.
hokein added a comment.

add new line to eof


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115856

Files:
  clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
  clang/test/CMakeLists.txt
  clang/test/Syntax/check-cxx-bnf.test
  clang/test/Syntax/lit.local.cfg
  clang/tools/CMakeLists.txt
  clang/tools/clang-pseudo/CMakeLists.txt
  clang/tools/clang-pseudo/ClangPseudo.cpp

Index: clang/tools/clang-pseudo/ClangPseudo.cpp
===
--- /dev/null
+++ clang/tools/clang-pseudo/ClangPseudo.cpp
@@ -0,0 +1,47 @@
+//===-- ClangPseudo.cpp - Clang pseudo parser tool ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Tooling/Syntax/Pseudo/Grammar.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/MemoryBuffer.h"
+
+using clang::syntax::pseudo::Grammar;
+using llvm::cl::desc;
+using llvm::cl::init;
+using llvm::cl::opt;
+
+static opt
+CheckGrammar("check-grammar", desc("Parse and check a BNF grammar file."),
+ init(""));
+
+int main(int argc, char *argv[]) {
+  llvm::cl::ParseCommandLineOptions(argc, argv, "");
+
+  if (CheckGrammar.getNumOccurrences()) {
+llvm::ErrorOr> Text =
+llvm::MemoryBuffer::getFile(CheckGrammar);
+if (std::error_code EC = Text.getError()) {
+  llvm::errs() << "Error: can't read grammar file '" << CheckGrammar
+   << "': " << EC.message() << "\n";
+  return 1;
+}
+std::vector Diags;
+auto RSpecs = Grammar::parseBNF(Text.get()->getBuffer(), Diags);
+
+if (!Diags.empty()) {
+  llvm::errs() << llvm::join(Diags, "\n");
+  return 2;
+}
+llvm::errs() << llvm::formatv("grammar file {0} is parsed successfully\n",
+  CheckGrammar);
+return 0;
+  }
+  return 0;
+}
Index: clang/tools/clang-pseudo/CMakeLists.txt
===
--- /dev/null
+++ clang/tools/clang-pseudo/CMakeLists.txt
@@ -0,0 +1,15 @@
+set(LLVM_LINK_COMPONENTS support)
+
+add_clang_tool(clang-pseudo
+  ClangPseudo.cpp
+  )
+
+set(CLANG_PSEUDO_LIB_DEPS
+  clangBasic
+  clangSyntaxPseudo
+  )
+
+clang_target_link_libraries(clang-pseudo
+  PRIVATE
+  ${CLANG_PSEUDO_LIB_DEPS}
+  )
Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -13,6 +13,7 @@
 add_clang_subdirectory(clang-offload-wrapper)
 add_clang_subdirectory(clang-scan-deps)
 add_clang_subdirectory(clang-repl)
+add_clang_subdirectory(clang-pseudo)
 
 add_clang_subdirectory(c-index-test)
 
Index: clang/test/Syntax/lit.local.cfg
===
--- /dev/null
+++ clang/test/Syntax/lit.local.cfg
@@ -0,0 +1,4 @@
+cxx_bnf_file = os.path.join(config.clang_src_dir, 'lib', 'Tooling', 'Syntax',
+'Pseudo', 'cxx.bnf')
+config.substitutions.append(('%cxx-bnf-file',
+ '%s' % (cxx_bnf_file)))
Index: clang/test/Syntax/check-cxx-bnf.test
===
--- /dev/null
+++ clang/test/Syntax/check-cxx-bnf.test
@@ -0,0 +1,2 @@
+// verify clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
+// RUN: clang-pseudo -check-grammar=%cxx-bnf-file
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -76,6 +76,7 @@
   clang-repl
   clang-diff
   clang-scan-deps
+  clang-pseudo
   diagtool
   hmaptool
   )
Index: clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
===
--- /dev/null
+++ clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
@@ -0,0 +1,739 @@
+# This is a C++ grammar from the C++ standard [1].
+#
+# The grammar is a superset of the true grammar requring semantic constraints to
+# resolve ambiguties. The grammar is context-free and ambiguous (beyond the
+# limit of LR(k)). We use general parsing algorithm (e.g GLR) to handle the
+# grammar and generate a transition table which is used to drive the parsing.
+#
+# It aims to align with the ISO C++ grammar as much as possible. We adjust it
+# to fit the need for the grammar-based parser:
+#  - attributes are omitted, which will be handled as comments;
+#  - we don't allow nullable non-terminal symbols. There are few nullable
+#non-terminals in the spec grammar, they are adjusted t

[PATCH] D115856: [syntax][pseudo] Introduce the spec C++ grammar.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang/lib/Tooling/Syntax/Pseudo/cxx.bnf:27
+# FIXME:
+#   - support annotations (lazy parsing, contextual identifiers)
+#   - empty input should be parsed successfully (special-case it?)

sammccall wrote:
> I think we should spell out what this is, or leave out the FIXME
these FIXMEs probably should not live in the bnf grammar. removed them.



Comment at: clang/lib/Tooling/Syntax/Pseudo/cxx.bnf:30
+#
+# start symbols
+_ := translation-unit

sammccall wrote:
> Is this "default start symbol"?
> I believe we conceptually want to be able to start parsing at other symbols 
> too.
Technically, `_` is the augmented symbol with the *real* start symbols coming 
on the right hand side -- this is a technique to make LR parsing life easier. 



Comment at: clang/tools/clang-pseudo/ClangPseudo.cpp:1
+//===-- ClangPseudo.cpp - Clang pseudo parser tool 
===//
+//

sammccall wrote:
> Can we use this tool to drive lit tests?
good idea. Refined the tool, now it supports `check-grammar`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115856

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

[clang] 782c0dd - [IRBuilder] Migrate and-folding to value-based FoldAnd.

[Florian Hahn via cfe-commits]

Author: Florian Hahn
Date: 2022-01-20T10:22:21Z
New Revision: 782c0dd1a1c235afb09a34e7da4a1267ead14765

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

LOG: [IRBuilder] Migrate and-folding to value-based FoldAnd.

Similar to the migration of or-folding to FoldOr, there are a few cases
where the fold in IRBuilder::CreateAnd triggered directly. Those have
been updated.

Reviewed By: nikic

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

Added: 


Modified: 
clang/test/CodeGen/catch-nullptr-and-nonzero-offset.c
clang/test/CodeGen/catch-pointer-overflow.c
clang/test/CodeGen/cmse-clear-return.c
llvm/include/llvm/Analysis/InstSimplifyFolder.h
llvm/include/llvm/Analysis/TargetFolder.h
llvm/include/llvm/IR/ConstantFolder.h
llvm/include/llvm/IR/IRBuilder.h
llvm/include/llvm/IR/IRBuilderFolder.h
llvm/include/llvm/IR/NoFolder.h
llvm/test/Transforms/LoopIdiom/X86/left-shift-until-bittest.ll
llvm/test/Transforms/LoopVersioning/bound-check-partially-known.ll
polly/test/CodeGen/invariant_load_base_pointer_conditional.ll
polly/test/CodeGen/multidim_2d_parametric_array_static_loop_bounds.ll
polly/test/CodeGen/no-overflow-tracking.ll
polly/test/CodeGen/run-time-condition-with-scev-parameters.ll
polly/test/ScopInfo/allow-all-parameters-dereferencable.ll
polly/test/ScopInfo/invariant_load_zext_parameter.ll

Removed: 




diff  --git a/clang/test/CodeGen/catch-nullptr-and-nonzero-offset.c 
b/clang/test/CodeGen/catch-nullptr-and-nonzero-offset.c
index 1602bf94f8529..fc0fddce07ba6 100644
--- a/clang/test/CodeGen/catch-nullptr-and-nonzero-offset.c
+++ b/clang/test/CodeGen/catch-nullptr-and-nonzero-offset.c
@@ -89,7 +89,8 @@ char *var_zero(char *base) {
   // CHECK-SANITIZE-C-NEXT:   %[[COMPUTED_GEP_IS_NOT_NULL:.*]] = 
icmp ne i64 %[[COMPUTED_GEP]], 0, !nosanitize
   // CHECK-SANITIZE-C-NEXT: 
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL:.*]] = and i1 
%[[BASE_IS_NOT_NULLPTR]], %[[COMPUTED_GEP_IS_NOT_NULL]], !nosanitize
   // CHECK-SANITIZE-C-NEXT:   %[[COMPUTED_GEP_IS_UGE_BASE:.*]] = 
icmp uge i64 %[[COMPUTED_GEP]], %[[BASE_RELOADED_INT]], !nosanitize
-  // CHECK-SANITIZE-C-NEXT:   %[[GEP_IS_OKAY:.*]] = and i1 
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL]], %[[COMPUTED_GEP_IS_UGE_BASE]], 
!nosanitize
+  // CHECK-SANITIZE-C-NEXT:   %[[AND_TRUE:.*]] = and i1 
%[[COMPUTED_GEP_IS_UGE_BASE]], true, !nosanitize
+  // CHECK-SANITIZE-C-NEXT:   %[[GEP_IS_OKAY:.*]] = and i1 
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL]], %[[AND_TRUE]], !nosanitize
   // CHECK-SANITIZE-C-NEXT:   br i1 %[[GEP_IS_OKAY]], label 
%[[CONT:.*]], label %[[HANDLER_POINTER_OVERFLOW:[^,]+]],{{.*}} !nosanitize
   // CHECK-SANITIZE-C:  [[HANDLER_POINTER_OVERFLOW]]:
   // CHECK-SANITIZE-NORECOVER-C-NEXT: call void 
@__ubsan_handle_pointer_overflow_abort(i8* bitcast ({ {{{.*}}} }* @[[LINE_200]] 
to i8*), i64 %[[BASE_RELOADED_INT]], i64 %[[COMPUTED_GEP]])
@@ -117,7 +118,8 @@ char *var_one(char *base) {
   // CHECK-SANITIZE-C-NEXT: 
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL:.*]] = and i1 
%[[BASE_IS_NOT_NULLPTR]], %[[COMPUTED_GEP_IS_NOT_NULL]], !nosanitize
   // CHECK-SANITIZE-CPP-NEXT:   
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL:.*]] = icmp eq i1 
%[[BASE_IS_NOT_NULLPTR]], %[[COMPUTED_GEP_IS_NOT_NULL]], !nosanitize
   // CHECK-SANITIZE-NEXT:   %[[COMPUTED_GEP_IS_UGE_BASE:.*]] = 
icmp uge i64 %[[COMPUTED_GEP]], %[[BASE_RELOADED_INT]], !nosanitize
-  // CHECK-SANITIZE-NEXT:   %[[GEP_IS_OKAY:.*]] = and i1 
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL]], %[[COMPUTED_GEP_IS_UGE_BASE]], 
!nosanitize
+  // CHECK-SANITIZE-NEXT:   %[[AND_TRUE:.*]] = and i1 
%[[COMPUTED_GEP_IS_UGE_BASE]], true, !nosanitize
+  // CHECK-SANITIZE-NEXT:   %[[GEP_IS_OKAY:.*]] = and i1 
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL]], %[[AND_TRUE]], !nosanitize
   // CHECK-SANITIZE-NEXT:   br i1 %[[GEP_IS_OKAY]], label 
%[[CONT:.*]], label %[[HANDLER_POINTER_OVERFLOW:[^,]+]],{{.*}} !nosanitize
   // CHECK-SANITIZE:  [[HANDLER_POINTER_OVERFLOW]]:
   // CHECK-SANITIZE-NORECOVER-NEXT: call void 
@__ubsan_handle_pointer_overflow_abort(i8* bitcast ({ {{{.*}}} }* @[[LINE_300]] 
to i8*), i64 %[[BASE_RELOADED_INT]], i64 %[[COMPUTED_GEP]])
@@ -145,7 +147,8 @@ char *var_allones(char *base) {
   // CHECK-SANITIZE-C-NEXT: 
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL:.*]] = and i1 
%[[BASE_IS_NOT_NULLPTR]], %[[COMPUTED_GEP_IS_NOT_NULL]], !nosanitize
   // CHECK-SANITIZE-CPP-NEXT:   
%[[BOTH_POINTERS_ARE_NULL_OR_BOTH_ARE_NONNULL:.*]] = icmp eq i1 
%[[BASE_IS_NOT_NULLPTR]], %[[COMP

[PATCH] D117431: [IRBuilder] Migrate and-folding to value-based FoldAnd.

[Florian Hahn via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG782c0dd1a1c2: [IRBuilder] Migrate and-folding to value-based 
FoldAnd. (authored by fhahn).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117431

Files:
  clang/test/CodeGen/catch-nullptr-and-nonzero-offset.c
  clang/test/CodeGen/catch-pointer-overflow.c
  clang/test/CodeGen/cmse-clear-return.c
  llvm/include/llvm/Analysis/InstSimplifyFolder.h
  llvm/include/llvm/Analysis/TargetFolder.h
  llvm/include/llvm/IR/ConstantFolder.h
  llvm/include/llvm/IR/IRBuilder.h
  llvm/include/llvm/IR/IRBuilderFolder.h
  llvm/include/llvm/IR/NoFolder.h
  llvm/test/Transforms/LoopIdiom/X86/left-shift-until-bittest.ll
  llvm/test/Transforms/LoopVersioning/bound-check-partially-known.ll
  polly/test/CodeGen/invariant_load_base_pointer_conditional.ll
  polly/test/CodeGen/multidim_2d_parametric_array_static_loop_bounds.ll
  polly/test/CodeGen/no-overflow-tracking.ll
  polly/test/CodeGen/run-time-condition-with-scev-parameters.ll
  polly/test/ScopInfo/allow-all-parameters-dereferencable.ll
  polly/test/ScopInfo/invariant_load_zext_parameter.ll

Index: polly/test/ScopInfo/invariant_load_zext_parameter.ll
===
--- polly/test/ScopInfo/invariant_load_zext_parameter.ll
+++ polly/test/ScopInfo/invariant_load_zext_parameter.ll
@@ -25,10 +25,11 @@
 ; CODEGEN-NEXT:   store i32 %polly.access.I0.load, i32* %loadI1a.preload.s2a
 ; CODEGEN-NEXT:   %0 = sext i32 %polly.access.I0.load to i64
 ; CODEGEN-NEXT:   %1 = icmp eq i64 %0, 0
+; CODEGEN-NEXT:   %polly.preload.cond.result = and i1 %1, true
 ; CODEGEN-NEXT:   br label %polly.preload.cond
 ;
 ; CODEGEN:  polly.preload.cond:
-; CODEGEN-NEXT:   br i1 %1, label %polly.preload.exec, label %polly.preload.merge
+; CODEGEN-NEXT:   br i1 %polly.preload.cond.result, label %polly.preload.exec, label %polly.preload.merge
 ;
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 
Index: polly/test/ScopInfo/allow-all-parameters-dereferencable.ll
===
--- polly/test/ScopInfo/allow-all-parameters-dereferencable.ll
+++ polly/test/ScopInfo/allow-all-parameters-dereferencable.ll
@@ -25,7 +25,7 @@
 ; Check that without the option `-polly-allow-dereference-of-all-function-parameters`
 ; we do generate the runtime check.
 ; CODE-RTC: polly.preload.cond:   ; preds = %polly.preload.begin
-; CODE-RTC-NEXT: br i1 %{{[a-zA-Z0-9]*}}, label %polly.preload.exec, label %polly.preload.merge
+; CODE-RTC-NEXT: br i1 %{{[a-zA-Z0-9\.]*}}, label %polly.preload.exec, label %polly.preload.merge
 
 ; Check that we don't generate a runtime check because we treat all
 ; parameters as dereferencable.
Index: polly/test/CodeGen/run-time-condition-with-scev-parameters.ll
===
--- polly/test/CodeGen/run-time-condition-with-scev-parameters.ll
+++ polly/test/CodeGen/run-time-condition-with-scev-parameters.ll
@@ -15,7 +15,8 @@
 ; CHECK-NEXT:  %5 = sext i1 %4 to i64
 ; CHECK-NEXT:  %6 = icmp eq i64 0, %5
 ; CHECK-NEXT:  %7 = and i1 %2, %6
-; CHECK-NEXT:  br i1 %7, label %polly.start, label %for.body4
+; CHECK-NEXT:  %polly.rtc.result = and i1 %7, true
+; CHECK-NEXT:  br i1 %polly.rtc.result, label %polly.start, label %for.body4
 
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 
Index: polly/test/CodeGen/no-overflow-tracking.ll
===
--- polly/test/CodeGen/no-overflow-tracking.ll
+++ polly/test/CodeGen/no-overflow-tracking.ll
@@ -30,12 +30,13 @@
 ; IR-NEXT:   %21 = add nsw i64 %20, %19
 ; IR-NEXT:   %22 = icmp sge i64 %21, -2147483648
 ; IR-NEXT:   %23 = and i1 %18, %22
-; IR-NEXT:   br label %polly.preload.cond1
+; IR-NEXT:   %polly.preload.cond.result1 = and i1 %23, true
+; IR-NEXT:   br label %polly.preload.cond2
 ;
-; IR:  polly.preload.cond1:
-; IR-NEXT:   br i1 %23
+; IR:  polly.preload.cond2:
+; IR-NEXT:   br i1 %polly.preload.cond.result1
 ;
-; IR:  polly.preload.exec3:
+; IR:  polly.preload.exec4:
 ; IR-NEXT:   %polly.access.polly.preload.tmp1.merge = getelementptr i32, i32* %polly.preload.tmp1.merge, i64 0
 ; IR-NEXT:   %polly.access.polly.preload.tmp1.merge.load = load i32, i32* %polly.access.polly.preload.tmp1.merge, align 4
 ;
Index: polly/test/CodeGen/multidim_2d_parametric_array_static_loop_bounds.ll
===
--- polly/test/CodeGen/multidim_2d_parametric_array_static_loop_bounds.ll
+++ polly/test/CodeGen/multidim_2d_parametric_array_static_loop_bounds.ll
@@ -12,7 +12,8 @@
 ; CHECK: entry:
 ; CHECK: polly.split_new_and_old:
 ; CHECK: %0 = icmp sge i64 %m, 150
-; CHECK: br i1 %0, label %polly.start, label %for.i
+; CHECK: %polly.rtc.result = and i1 %0, true
+; CHECK: br i1 %polly.

[PATCH] D112987: [RISCV] Bump rvv-related extensions from 0.10 to 1.0

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD updated this revision to Diff 401564.
eopXD added a comment.

Update code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112987

Files:
  clang/test/Driver/riscv-arch.c
  clang/test/Preprocessor/riscv-target-features.c
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/attribute-arch.s

Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -35,8 +35,8 @@
 
 ## Experimental extensions require version string to be explicitly specified
 
-.attribute arch, "rv32iv0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl128b0p10_zvl32b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0_zvlsseg1p0"
 
 .attribute arch, "rv32izba1p0"
 # CHECK: attribute  5, "rv32i2p0_zba1p0"
@@ -74,56 +74,56 @@
 .attribute arch, "rv32ifzfh1p0"
 # CHECK: attribute  5, "rv32i2p0_f2p0_zfh1p0_zfhmin1p0"
 
-.attribute arch, "rv32iv0p10zvlsseg0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl128b0p10_zvl32b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvlsseg1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0_zvlsseg1p0"
 
-.attribute arch, "rv32iv0p10zvl32b0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl128b0p10_zvl32b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvl32b1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0_zvlsseg1p0"
 
-.attribute arch, "rv32iv0p10zvl64b0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl128b0p10_zvl32b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvl64b1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0_zvlsseg1p0"
 
-.attribute arch, "rv32iv0p10zvl128b0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl128b0p10_zvl32b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvl128b1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0_zvlsseg1p0"
 
-.attribute arch, "rv32iv0p10zvl256b0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl128b0p10_zvl256b0p10_zvl32b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvl256b1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl256b1p0_zvl32b1p0_zvl64b1p0_zvlsseg1p0"
 
-.attribute arch, "rv32iv0p10zvl512b0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl128b0p10_zvl256b0p10_zvl32b0p10_zvl512b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvl512b1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl256b1p0_zvl32b1p0_zvl512b1p0_zvl64b1p0_zvlsseg1p0"
 
-.attribute arch, "rv32iv0p10zvl1024b0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl1024b0p10_zvl128b0p10_zvl256b0p10_zvl32b0p10_zvl512b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvl1024b1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl1024b1p0_zvl128b1p0_zvl256b1p0_zvl32b1p0_zvl512b1p0_zvl64b1p0_zvlsseg1p0"
 
-.attribute arch, "rv32iv0p10zvl2048b0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl1024b0p10_zvl128b0p10_zvl2048b0p10_zvl256b0p10_zvl32b0p10_zvl512b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvl2048b1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl1024b1p0_zvl128b1p0_zvl2048b1p0_zvl256b1p0_zvl32b1p0_zvl512b1p0_zvl64b1p0_zvlsseg1p0"
 
-.attribute arch, "rv32iv0p10zvl4096b0p10"
-# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v0p10_zve32f0p10_zve32x0p10_zve64d0p10_zve64f0p10_zve64x0p10_zvl1024b0p10_zvl128b0p10_zvl2048b0p10_zvl256b0p10_zvl32b0p10_zvl4096b0p10_zvl512b0p10_zvl64b0p10_zvlsseg0p10"
+.attribute arch, "rv32iv1p0zvl4096b1p0"
+# CHECK: attribute  5, "rv32i2p0_f2p0_d2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_z

[PATCH] D117202: [ARM] Add Cortex-X1C Support for Clang and LLVM

[Ties Stuij via Phabricator via cfe-commits]

stuij updated this revision to Diff 401569.
stuij marked an inline comment as done.
stuij added a comment.

addressed review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117202

Files:
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm-cortex-cpus.c
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMSubtarget.cpp
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -334,6 +334,12 @@
  ARM::AEK_HWDIVARM | ARM::AEK_HWDIVTHUMB |
  ARM::AEK_DSP | ARM::AEK_CRC | ARM::AEK_RAS,
  "8.2-A"),
+ARMCPUTestParams("cortex-x1c", "armv8.2-a", "crypto-neon-fp-armv8",
+ ARM::AEK_RAS | ARM::AEK_SEC | ARM::AEK_MP |
+ ARM::AEK_VIRT | ARM::AEK_HWDIVARM |
+ ARM::AEK_HWDIVTHUMB | ARM::AEK_DSP | ARM::AEK_CRC |
+ ARM::AEK_RAS,
+ "8.2-A"),
 ARMCPUTestParams("neoverse-n1", "armv8.2-a", "crypto-neon-fp-armv8",
  ARM::AEK_CRC | ARM::AEK_SEC | ARM::AEK_MP |
  ARM::AEK_VIRT | ARM::AEK_HWDIVARM |
@@ -393,7 +399,7 @@
  ARM::AEK_HWDIVARM | ARM::AEK_HWDIVTHUMB | ARM::AEK_DSP,
  "7-S")));
 
-static constexpr unsigned NumARMCPUArchs = 87;
+static constexpr unsigned NumARMCPUArchs = 88;
 
 TEST(TargetParserTest, testARMCPUArchList) {
   SmallVector List;
@@ -1032,6 +1038,14 @@
  AArch64::AEK_DOTPROD | AArch64::AEK_RCPC |
  AArch64::AEK_SSBS,
  "8.2-A"),
+ARMCPUTestParams("cortex-x1c", "armv8.2-a", "crypto-neon-fp-armv8",
+ AArch64::AEK_CRC | AArch64::AEK_CRYPTO |
+ AArch64::AEK_FP | AArch64::AEK_RDM |
+ AArch64::AEK_SIMD | AArch64::AEK_RAS |
+ AArch64::AEK_LSE | AArch64::AEK_FP16 |
+ AArch64::AEK_DOTPROD | AArch64::AEK_RCPC |
+ AArch64::AEK_SSBS | AArch64::AEK_PAUTH,
+ "8.2-A"),
 ARMCPUTestParams("cortex-x2", "armv9-a", "neon-fp-armv8",
  AArch64::AEK_CRC | AArch64::AEK_FP |
  AArch64::AEK_SIMD | AArch64::AEK_RAS |
@@ -1232,7 +1246,7 @@
  AArch64::AEK_LSE | AArch64::AEK_RDM,
  "8.2-A")));
 
-static constexpr unsigned NumAArch64CPUArchs = 52;
+static constexpr unsigned NumAArch64CPUArchs = 53;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/lib/Target/ARM/ARMSubtarget.h
===
--- llvm/lib/Target/ARM/ARMSubtarget.h
+++ llvm/lib/Target/ARM/ARMSubtarget.h
@@ -77,6 +77,7 @@
 CortexR52,
 CortexR7,
 CortexX1,
+CortexX1C,
 Exynos,
 Krait,
 Kryo,
Index: llvm/lib/Target/ARM/ARMSubtarget.cpp
===
--- llvm/lib/Target/ARM/ARMSubtarget.cpp
+++ llvm/lib/Target/ARM/ARMSubtarget.cpp
@@ -304,6 +304,7 @@
   case CortexM7:
   case CortexR52:
   case CortexX1:
+  case CortexX1C:
 break;
   case Exynos:
 LdStMultipleTiming = SingleIssuePlusExtras;
Index: llvm/lib/Target/ARM/ARM.td
===
--- llvm/lib/Target/ARM/ARM.td
+++ llvm/lib/Target/ARM/ARM.td
@@ -657,6 +657,8 @@
"CortexA710", "Cortex-A710 ARM processors", []>;
 def ProcX1  : SubtargetFeature<"cortex-x1", "ARMProcFamily", "CortexX1",
"Cortex-X1 ARM processors", []>;
+def ProcX1C : SubtargetFeature<"cortex-x1c", "ARMProcFamily", "CortexX1C",
+   "Cortex-X1C ARM processors", []>;
 
 def ProcV1  : SubtargetFeature<"neoverse-v1", "ARMProcFamily",
"NeoverseV1", "Neoverse-V1 ARM processors", []>;
@@ -1441,6 +1443,13 @@
  FeatureFullFP16,
  FeatureDotProd]>;
 
+def : ProcNoItin<"cortex-x1c",  [ARMv82a,
+ F

[PATCH] D117759: [clang-format][NFC] Clean up tryMergeLessLess()

[Marek Kurdej via Phabricator via cfe-commits]

curdeius accepted this revision.
curdeius added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: clang/lib/Format/FormatTokenLexer.cpp:440-441
 
-  if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
-  First[0]->isNot(tok::less) || FourthTokenIsLess)
+  if (Y->is(tok::less) || First[1]->isNot(tok::less) ||
+  First[0]->isNot(tok::less) || (X && X->is(tok::less)))
 return false;

To go a bit further, could we move `First[1]->isNot(tok::less) || 
First[0]->isNot(tok::less)` into its own `if` around the top of the function?
Sth like:
```
  if (Tokens.size() < 3)
return false;

  auto First = Tokens.end() - 3;
  if (First[0]->isNot(tok::less) || First[1]->isNot(tok::less))
return false;
```
?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117759

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

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:49
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());

Are we sure that the memory addresses of CFGBlocks are stable enough for a 
deterministic order? Alternatively, we could use the block ids for the ordering.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

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

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:49
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());

xazax.hun wrote:
> Are we sure that the memory addresses of CFGBlocks are stable enough for a 
> deterministic order? Alternatively, we could use the block ids for the 
> ordering.
Also, could you describe where the flakiness is originated from? Naively, I'd 
expect that the order in which we process the predecessors should not change 
the results of the analysis.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

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

[PATCH] D117405: [AArch64] CodeGen for Armv8.8/9.3 MOPS

[Son Tuan Vu via Phabricator via cfe-commits]

tyb0807 added a comment.

Following Dave's comments above, this patch is now split to 4 different patches 
https://reviews.llvm.org/D117753
https://reviews.llvm.org/D117757
https://reviews.llvm.org/D117763
https://reviews.llvm.org/D117764
and may now be abandoned.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117405

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

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2535
 ArgAttrs[FirstIRArg + i] =
 llvm::AttributeSet::get(getLLVMContext(), Attrs);
 }

fhahn wrote:
> nlopes wrote:
> > fhahn wrote:
> > > nlopes wrote:
> > > > ab wrote:
> > > > > Hmm, if I'm reading this right, this overwrites the `nonnull 
> > > > > dereferenceable align` attributes separately computed for `this` 
> > > > > around l2335, right? (or `inalloca` and `sret` before that)
> > > > > 
> > > > > It sounds like an ancient bug, that's only exposed because `noundef` 
> > > > > ends up triggering this logic much more often?
> > > > > 
> > > > > Many of our downstream tests hit this. The hacked up patch seems to 
> > > > > do the job; ideally we'd feed the previously-computed attrs when 
> > > > > constructing the AttrBuilder (which would also fix the padding 
> > > > > argument), but we'd need to match up the IR args first.  Maybe that's 
> > > > > fine as a special-case for arg 0 though
> > > > nice catch! It's an ancient bug where arg 0 is overwritten.
> > > Is anybody looking into a fix or should we revert the patch until this 
> > > can be properly addressed?
> > I would recommend against reverting this patch because of all the followup 
> > patches. There were quite a few commits afterwards plus fixes to buildbot 
> > configurations, so it's a non-trivial overhead to revert everything.
> > I was assuming @ab would fix it as he already root-caused the bug..
> FWIW it seems a bit unfortunate that there are some clear regressions when 
> the tests got update, e.g. 
> https://github.com/llvm/llvm-project/commit/1b1c8d83d3567a60280291c0adb95d1d60335509#diff-7e80d593f26f6f6fb24765c6a169884d7350685d565ee970b0a7b9abaf0fb205L355
> 
> I'll work with @ab to fix this though rather than reverting, because another 
> revert would cause even more conflicts for us downstream.
> FWIW it seems a bit unfortunate that there are some clear regressions when 
> the tests got update, e.g. 
> https://github.com/llvm/llvm-project/commit/1b1c8d83d3567a60280291c0adb95d1d60335509#diff-7e80d593f26f6f6fb24765c6a169884d7350685d565ee970b0a7b9abaf0fb205L355
> 
> I'll work with @ab to fix this though rather than reverting, because another 
> revert would cause even more conflicts for us downstream.

Just a reminder that the 14 release is cut soon (1 feb: 
https://llvm.discourse.group/t/llvm-14-0-0-release-schedule/5846)

I don't know this code; if a clean fix is ready soon and unlikely to have a 
ripple effect then great. But it does seem risky to be treating such 
configuration changes as "too big to fail" at this point in the release cycle.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D116085: [clang-tidy] Performance improvements for NOLINTBEGIN/END blocks

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz updated this revision to Diff 401576.
salman-javed-nz edited the summary of this revision.
salman-javed-nz added a comment.

Update according to review (rename NoLintPragmaHandler class to 
NoLintDirectiveHandler)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116085

Files:
  clang-tools-extra/clang-tidy/CMakeLists.txt
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
  clang-tools-extra/clang-tidy/NoLintDirectiveHandler.h
  clang-tools-extra/clangd/ParsedAST.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/1st-translation-unit.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/2nd-translation-unit.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-LIFO.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-all-end-glob.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-all-end-specific.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-glob-end-all.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-glob-end-specific.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-global-end-specific.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-multiple-end-single.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-single-end-multiple.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-specific-end-all.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-specific-end-glob.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-specific-end-global.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-mismatched-check-names.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-mismatched-delims.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-multiple-TUs.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-typo-in-check-name.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp

Index: clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
@@ -58,30 +58,24 @@
 // NOLINTEND(some-other-check)
 // NOLINTEND(google-explicit-constructor)
 
-// NOLINTBEGIN(google-explicit-constructor)
-// NOLINTBEGIN(some-other-check)
-class C7 { C7(int i); };
-// NOLINTEND(google-explicit-constructor)
-// NOLINTEND(some-other-check)
-
 // NOLINTBEGIN(google-explicit-constructor)
 // NOLINTBEGIN
-class C8 { C8(int i); };
+class C7 { C7(int i); };
 // NOLINTEND
 // NOLINTEND(google-explicit-constructor)
 
 // NOLINTBEGIN
 // NOLINTBEGIN(google-explicit-constructor)
-class C9 { C9(int i); };
+class C8 { C8(int i); };
 // NOLINTEND(google-explicit-constructor)
 // NOLINTEND
 
 // NOLINTBEGIN(not-closed-bracket-is-treated-as-skip-all
-class C10 { C10(int i); };
+class C9 { C9(int i); };
 // NOLINTEND(not-closed-bracket-is-treated-as-skip-all
 
 // NOLINTBEGIN without-brackets-skip-all, another-check
-class C11 { C11(int i); };
+class C10 { C10(int i); };
 // NOLINTEND without-brackets-skip-all, another-check
 
 #define MACRO(X) class X { X(int i); };
@@ -114,28 +108,28 @@
 MACRO_NO_LINT_INSIDE_MACRO
 
 // NOLINTBEGIN(google*)
-class C12 { C12(int i); };
+class C11 { C11(int i); };
 // NOLINTEND(google*)
 
 // NOLINTBEGIN(*explicit-constructor)
-class C15 { C15(int i); };
+class C12 { C12(int i); };
 // NOLINTEND(*explicit-constructor)
 
 // NOLINTBEGIN(*explicit*)
-class C16 { C16(int i); };
+class C13 { C13(int i); };
 // NOLINTEND(*explicit*)
 
 // NOLINTBEGIN(-explicit-constructor)
-class C17 { C17(int x); };
+class C14 { C14(int x); };
 // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: single-argument constructors must be marked explicit
 // NOLINTEND(-explicit-constructor)
 
 // NOLINTBEGIN(google*,-google*)
-class C18 { C18(int x); };
+class C15 { C15(int x); };
 // NOLINTEND(google*,-google*)
 
 // NOLINTBEGIN(*,-google*)
-class C19 { C19(int x); };
+class C16 { C16(int x); };
 // NOLINTEND(*,-google*)
 
 int array1[10];
@@ -154,4 +148,4 @@
 int array4[10];
 // NOLINTEND(*-avoid-c-arrays)
 
-// CHECK-MESSAGES: Suppressed 27 warnings (27 NOLINT).
+// CHECK-MESSAGES: Suppressed 26 warnings (26 NOLINT).
Index: clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-typo-in-check-name.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/nolintb

[PATCH] D112613: [RISCV] Change TARGET_BUILTIN require to zve32x for vector instruction

[Fraser Cormack via Phabricator via cfe-commits]

frasercrmck added a comment.

LGTM but I don't have full scope on the builtins side of things. I'd also add a 
missing word to the title: "Change TARGET_BUILTIN //to// require ..."


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112613

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

[PATCH] D117769: [clang-format] Refactor: add FormatToken::hasWhitespaceBefore(). NFC.

[Marek Kurdej via Phabricator via cfe-commits]

curdeius created this revision.
curdeius added reviewers: MyDeveloperDay, HazardyKnusperkeks, owenpan.
curdeius requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This factors out a pattern that comes up from time to time.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117769

Files:
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineParser.cpp

Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1042,8 +1042,7 @@
 
   nextToken();
   if (FormatTok->Tok.getKind() == tok::l_paren &&
-  FormatTok->WhitespaceRange.getBegin() ==
-  FormatTok->WhitespaceRange.getEnd()) {
+  !FormatTok->hasWhitespaceBefore()) {
 parseParens();
   }
   if (Style.IndentPPDirectives != FormatStyle::PPDIS_None)
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3304,14 +3304,11 @@
 bool TokenAnnotator::spaceRequiredBefore(const AnnotatedLine &Line,
  const FormatToken &Right) {
   const FormatToken &Left = *Right.Previous;
-  auto HasExistingWhitespace = [&Right]() {
-return Right.WhitespaceRange.getBegin() != Right.WhitespaceRange.getEnd();
-  };
 
   // If the token is finalized don't touch it (as it could be in a
   // clang-format-off section).
   if (Left.Finalized)
-return HasExistingWhitespace();
+return Right.hasWhitespaceBefore();
 
   if (Right.Tok.getIdentifierInfo() && Left.Tok.getIdentifierInfo())
 return true; // Never ever merge two identifiers.
@@ -3373,7 +3370,7 @@
 // Preserve the existence of a space before a percent for cases like 0x%04x
 // and "%d %d"
 if (Left.is(tok::numeric_constant) && Right.is(tok::percent))
-  return HasExistingWhitespace();
+  return Right.hasWhitespaceBefore();
   } else if (Style.isJson()) {
 if (Right.is(tok::colon))
   return false;
@@ -3554,7 +3551,7 @@
   return true;
   }
   if (Left.is(TT_ImplicitStringLiteral))
-return HasExistingWhitespace();
+return Right.hasWhitespaceBefore();
   if (Line.Type == LT_ObjCMethodDecl) {
 if (Left.is(TT_ObjCMethodSpecifier))
   return true;
@@ -3639,11 +3636,11 @@
 return Style.SpaceAfterCStyleCast ||
Right.isOneOf(TT_BinaryOperator, TT_SelectorName);
 
-  auto ShouldAddSpacesInAngles = [this, &HasExistingWhitespace]() {
+  auto ShouldAddSpacesInAngles = [this, &Right]() {
 if (this->Style.SpacesInAngles == FormatStyle::SIAS_Always)
   return true;
 if (this->Style.SpacesInAngles == FormatStyle::SIAS_Leave)
-  return HasExistingWhitespace();
+  return Right.hasWhitespaceBefore();
 return false;
   };
 
@@ -3669,7 +3666,7 @@
 // Generally don't remove existing spaces between an identifier and "::".
 // The identifier might actually be a macro name such as ALWAYS_INLINE. If
 // this turns out to be too lenient, add analysis of the identifier itself.
-return HasExistingWhitespace();
+return Right.hasWhitespaceBefore();
   if (Right.is(tok::coloncolon) &&
   !Left.isOneOf(tok::l_brace, tok::comment, tok::l_paren))
 // Put a space between < and :: in vector< ::std::string >
Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -446,8 +446,7 @@
 return false;
 
   // Only merge if there currently is no whitespace between the two "<".
-  if (First[1]->WhitespaceRange.getBegin() !=
-  First[1]->WhitespaceRange.getEnd())
+  if (First[1]->hasWhitespaceBefore())
 return false;
 
   First[0]->Tok.setKind(tok::lessless);
@@ -468,8 +467,7 @@
 return false;
   unsigned AddLength = 0;
   for (unsigned i = 1; i < Kinds.size(); ++i) {
-if (!First[i]->is(Kinds[i]) || First[i]->WhitespaceRange.getBegin() !=
-   First[i]->WhitespaceRange.getEnd())
+if (!First[i]->is(Kinds[i]) || First[i]->hasWhitespaceBefore())
   return false;
 AddLength += First[i]->TokenText.size();
   }
Index: clang/lib/Format/FormatToken.h
===
--- clang/lib/Format/FormatToken.h
+++ clang/lib/Format/FormatToken.h
@@ -637,6 +637,12 @@
 return WhitespaceRange.getEnd();
   }
 
+  /// Returns \c true if the range of whitespace immediately preceding the \c
+  /// Token is not empty.
+  bool hasWhitespaceBefore() const {
+return WhitespaceRange.getBegin() != WhitespaceRange.getEnd();
+  }
+
   prec::Level getPrecedence() const {
 return ge

[PATCH] D117405: [AArch64] CodeGen for Armv8.8/9.3 MOPS

[Son Tuan Vu via Phabricator via cfe-commits]

tyb0807 marked 8 inline comments as done.
tyb0807 added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp:836
+  // inside a bundle to prevent other passes to moving things in between.
+  MIBundleBuilder Bundler(MBB, MBBI);
+  auto &MF = *MBB.getParent();

dmgreen wrote:
> It is probably better to expand the instruction later than to create a bundle.
Please see https://reviews.llvm.org/D117763, the instruction is now expanded as 
late as possible in the pipeline (i.e. during code emission)



Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:940
+  if (Subtarget->hasMOPS()) {
+// If we have MOPS, always use them
+MaxStoresPerMemsetOptSize = 0;

dmgreen wrote:
> Are you sure we should _always_ be using them? I would expect a `ldr+str` to 
> be better than a `mov #4; cpyfp; cpyfm; cpyfe`, for example.
Please see https://reviews.llvm.org/D117764, we are now conservative on when to 
use MOPS instructions instead of `ldr+str`



Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:11875
+Info.opc = ISD::INTRINSIC_W_CHAIN;
+Info.memVT = MVT::getVT(Val->getType());
+Info.ptrVal = Dst;

dmgreen wrote:
> Can this safely set memVT to the size of a single element? That would need to 
> be multiplied by the size of the memory being set, and if this is being used 
> for aliasing info will be too small.
Please see https://reviews.llvm.org/D117764, the size is set to unknown.



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:8350
+  let mayLoad = 1 in {
+def MOPSMemoryCopy : Pseudo<(outs GPR64common:$Rd_wb, GPR64common:$Rs_wb, 
GPR64:$Rn_wb),
+(ins GPR64common:$Rd, GPR64common:$Rs, 
GPR64:$Rn),

dmgreen wrote:
> These need to be marked as 96bit pseudos. They should also clobber NZCV (as 
> should the real instructions above, but that doesn't look like it was ever 
> changed after D116157)
Changes to make real instructions NZCV clobbering here 
https://reviews.llvm.org/D117757

Changes to make pseudos NZCV clobbering (and specifying their size) here 
https://reviews.llvm.org/D117764



Comment at: llvm/test/CodeGen/AArch64/aarch64-mops-mte.ll:3
+
+; RUN: llc %s -o - -mtriple=aarch64-arm-none-eabi -O2 -mattr=+mops,+mte  | 
FileCheck %s --check-prefix=SDAG
+; RUN: llc %s -o - -mtriple=aarch64-arm-none-eabi -O0 -global-isel=1 
-global-isel-abort=1 -mattr=+mops,+mte  | FileCheck %s --check-prefix=GISel

dmgreen wrote:
> You likely don't need the -O2 and -O0 for llc run commands.
Agreed, we can do this without. However, this will change the generated code 
(thus the  strings that these tests are looking for), hence I'm leaving those 
options. Please lmk if this is _really_ unwanted and I'll try to fix these 
tests 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117405

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

[PATCH] D117759: [clang-format][NFC] Clean up tryMergeLessLess()

[Owen Pan via Phabricator via cfe-commits]

owenpan updated this revision to Diff 401579.
owenpan added a comment.

Further cleanup.


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

https://reviews.llvm.org/D117759

Files:
  clang/lib/Format/FormatTokenLexer.cpp


Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -430,19 +430,7 @@
 return false;
 
   auto First = Tokens.end() - 3;
-  bool FourthTokenIsLess = false;
-
-  if (Tokens.size() > 3) {
-auto Fourth = (Tokens.end() - 4)[0];
-FourthTokenIsLess = Fourth->is(tok::less);
-
-// Do not remove a whitespace between the two "<" e.g. "operator< <>".
-if (First[2]->is(tok::greater) && Fourth->is(tok::kw_operator))
-  return false;
-  }
-
-  if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
-  First[0]->isNot(tok::less) || FourthTokenIsLess)
+  if (First[0]->isNot(tok::less) || First[1]->isNot(tok::less))
 return false;
 
   // Only merge if there currently is no whitespace between the two "<".
@@ -450,6 +438,15 @@
   First[1]->WhitespaceRange.getEnd())
 return false;
 
+  auto X = Tokens.size() > 3 ? First[-1] : nullptr;
+  auto Y = First[2];
+  if ((X && X->is(tok::less)) || Y->is(tok::less))
+return false;
+
+  // Do not remove a whitespace between the two "<" e.g. "operator< <>".
+  if (X && X->is(tok::kw_operator) && Y->is(tok::greater))
+return false;
+
   First[0]->Tok.setKind(tok::lessless);
   First[0]->TokenText = "<<";
   First[0]->ColumnWidth += 1;


Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -430,19 +430,7 @@
 return false;
 
   auto First = Tokens.end() - 3;
-  bool FourthTokenIsLess = false;
-
-  if (Tokens.size() > 3) {
-auto Fourth = (Tokens.end() - 4)[0];
-FourthTokenIsLess = Fourth->is(tok::less);
-
-// Do not remove a whitespace between the two "<" e.g. "operator< <>".
-if (First[2]->is(tok::greater) && Fourth->is(tok::kw_operator))
-  return false;
-  }
-
-  if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
-  First[0]->isNot(tok::less) || FourthTokenIsLess)
+  if (First[0]->isNot(tok::less) || First[1]->isNot(tok::less))
 return false;
 
   // Only merge if there currently is no whitespace between the two "<".
@@ -450,6 +438,15 @@
   First[1]->WhitespaceRange.getEnd())
 return false;
 
+  auto X = Tokens.size() > 3 ? First[-1] : nullptr;
+  auto Y = First[2];
+  if ((X && X->is(tok::less)) || Y->is(tok::less))
+return false;
+
+  // Do not remove a whitespace between the two "<" e.g. "operator< <>".
+  if (X && X->is(tok::kw_operator) && Y->is(tok::greater))
+return false;
+
   First[0]->Tok.setKind(tok::lessless);
   First[0]->TokenText = "<<";
   First[0]->ColumnWidth += 1;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117759: [clang-format][NFC] Clean up tryMergeLessLess()

[Owen Pan via Phabricator via cfe-commits]

owenpan requested review of this revision.
owenpan marked an inline comment as done.
owenpan added inline comments.



Comment at: clang/lib/Format/FormatTokenLexer.cpp:440-441
 
-  if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
-  First[0]->isNot(tok::less) || FourthTokenIsLess)
+  if (Y->is(tok::less) || First[1]->isNot(tok::less) ||
+  First[0]->isNot(tok::less) || (X && X->is(tok::less)))
 return false;

curdeius wrote:
> To go a bit further, could we move `First[1]->isNot(tok::less) || 
> First[0]->isNot(tok::less)` into its own `if` around the top of the function?
> Sth like:
> ```
>   if (Tokens.size() < 3)
> return false;
> 
>   auto First = Tokens.end() - 3;
>   if (First[0]->isNot(tok::less) || First[1]->isNot(tok::less))
> return false;
> ```
> ?
Good idea.


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

https://reviews.llvm.org/D117759

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

[PATCH] D117769: [clang-format] Refactor: add FormatToken::hasWhitespaceBefore(). NFC.

[Owen Pan via Phabricator via cfe-commits]

owenpan accepted this revision.
owenpan 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/D117769/new/

https://reviews.llvm.org/D117769

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

[PATCH] D114439: [Annotation] Allow parameter pack expansions in annotate attribute

[Steffen Larsen via Phabricator via cfe-commits]

steffenlarsen added a comment.

Thank you, @aaron.ballman ! I will update the revision in a moment with some of 
the suggested changes.




Comment at: clang/lib/Parse/ParseDecl.cpp:436-438
+// Interpret "kw_this" as an identifier if the attributed requests it.
+if (ChangeKWThisToIdent && Tok.is(tok::kw_this))
+  Tok.setKind(tok::identifier);

aaron.ballman wrote:
> I'm a bit surprised this logic moved -- are there no times when we'd need it 
> within the new `else` clause?
This is done because `ParseExpressionList` wouldn't know what to do with 
identifiers, so it keeps the old logic. This means that attributes that consist 
of a variadic identifier argument cannot parse packs and initializer lists. It 
shouldn't be a problem for now, but it does kill some generality.

An alternative is to split the individual expression parsing from 
`ParseExpressionList` and use that in here in a similar way to how it parsed 
before. Would that be preferred?



Comment at: clang/lib/Parse/ParseExpr.cpp:3360
+ llvm::function_ref ExpressionStarts,
+ bool FailImmediatelyOnInvalidExpr,
+ bool EarlyTypoCorrection) {

aaron.ballman wrote:
> or something along those lines (note, the logic has reversed meaning). "Fail 
> immediately" doesn't quite convey the behavior to me because we fail 
> immediately either way, it's more about whether we attempt to skip tokens to 
> get to the end of the expression list. I'm not strongly tied to the name I 
> suggested either, btw.
> "Fail immediately" doesn't quite convey the behavior to me because we fail 
> immediately either way

Am I misunderstanding `FailUntil` or is the intention of `SkipUntil(tok::comma, 
tok::r_paren, StopBeforeMatch)` to either stop at the next "," or ")"? If I am 
not misunderstanding, I believe it will continue parsing expressions after 
comma if `SkipUntil` stopped before it. As such I don't think 
`FailImmediatelyOnInvalidExpr` is inherently wrong, but I agree that skipping 
the skipping isn't very well conveyed by the name as is.



Comment at: clang/lib/Parse/ParseExpr.cpp:3374-3375
 
+if (EarlyTypoCorrection)
+  Expr = Actions.CorrectDelayedTyposInExpr(Expr);
+

aaron.ballman wrote:
> Not that I think this is a bad change, but it seems unrelated to the patch. 
> Can you explain why you made the change?
Admittedly I am not sure why it is needed, but in the previous version of the 
parsing for attribute parameters it does the typo-correction immediately after 
parsing the expression and if this isn't added a handful of tests fail.


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

https://reviews.llvm.org/D114439

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

[PATCH] D114439: [Annotation] Allow parameter pack expansions in annotate attribute

[Steffen Larsen via Phabricator via cfe-commits]

steffenlarsen updated this revision to Diff 401580.
steffenlarsen added a comment.

Applied suggestions.


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

https://reviews.llvm.org/D114439

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Parse/Parser.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/Parser/cxx0x-attributes.cpp
  clang/test/SemaTemplate/attributes.cpp
  clang/utils/TableGen/ClangAttrEmitter.cpp

Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -1164,10 +1164,12 @@
   };
 
   class VariadicExprArgument : public VariadicArgument {
+bool AllowPack = false;
+
   public:
 VariadicExprArgument(const Record &Arg, StringRef Attr)
-  : VariadicArgument(Arg, Attr, "Expr *")
-{}
+: VariadicArgument(Arg, Attr, "Expr *"),
+  AllowPack(Arg.getValueAsBit("AllowPack")) {}
 
 void writeASTVisitorTraversal(raw_ostream &OS) const override {
   OS << "  {\n";
@@ -2264,6 +2266,47 @@
   OS << "#endif // CLANG_ATTR_THIS_ISA_IDENTIFIER_ARG_LIST\n\n";
 }
 
+static void emitClangAttrNumArgs(RecordKeeper &Records, raw_ostream &OS) {
+  OS << "#if defined(CLANG_ATTR_NUM_ARGS)\n";
+  std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
+  for (const auto *A : Attrs) {
+std::vector Args = A->getValueAsListOfDefs("Args");
+forEachUniqueSpelling(*A, [&](const FlattenedSpelling &S) {
+  OS << ".Case(\"" << S.name() << "\", " << Args.size() << ")\n";
+});
+  }
+  OS << "#endif // CLANG_ATTR_NUM_ARGS\n\n";
+}
+
+static bool argSupportsParmPack(const Record *Arg) {
+  return !Arg->getSuperClasses().empty() &&
+ llvm::StringSwitch(
+ Arg->getSuperClasses().back().first->getName())
+ .Case("VariadicExprArgument", true)
+ .Default(false) &&
+ Arg->getValueAsBit("AllowPack");
+}
+
+static void emitClangAttrLastArgParmPackSupport(RecordKeeper &Records,
+raw_ostream &OS) {
+  OS << "#if defined(CLANG_ATTR_LAST_ARG_PARM_PACK_SUPPORT)\n";
+  std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
+  for (const auto *A : Attrs) {
+std::vector Args = A->getValueAsListOfDefs("Args");
+bool LastArgSupportsParmPack =
+!Args.empty() && argSupportsParmPack(Args.back());
+forEachUniqueSpelling(*A, [&](const FlattenedSpelling &S) {
+  OS << ".Case(\"" << S.name() << "\", " << LastArgSupportsParmPack
+ << ")\n";
+});
+  }
+  OS << "#endif // CLANG_ATTR_LAST_ARG_PARM_PACK_SUPPORT\n\n";
+}
+
+static bool isArgVariadic(const Record &R, StringRef AttrName) {
+  return createArgument(R, AttrName)->isVariadic();
+}
+
 static void emitAttributes(RecordKeeper &Records, raw_ostream &OS,
bool Header) {
   std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
@@ -2320,6 +2363,18 @@
 std::vector> Args;
 Args.reserve(ArgRecords.size());
 
+if (!ArgRecords.empty()) {
+  const bool LastArgSupportsPack = argSupportsParmPack(ArgRecords.back());
+  for (size_t I = 0; I < ArgRecords.size() - 1; ++I) {
+assert((!LastArgSupportsPack ||
+!isArgVariadic(*ArgRecords[I], R.getName())) &&
+   "Attributes supporting packs can only have the last "
+   "argument as variadic");
+assert(!argSupportsParmPack(ArgRecords[I]) &&
+   "Only the last argument can allow packs");
+  }
+}
+
 bool HasOptArg = false;
 bool HasFakeArg = false;
 for (const auto *ArgRecord : ArgRecords) {
@@ -3382,10 +3437,6 @@
   }
 }
 
-static bool isArgVariadic(const Record &R, StringRef AttrName) {
-  return createArgument(R, AttrName)->isVariadic();
-}
-
 static void emitArgInfo(const Record &R, raw_ostream &OS) {
   // This function will count the number of arguments specified for the
   // attribute and emit the number of required arguments followed by the
@@ -4219,6 +4270,8 @@
   emitClangAttrIdentifierArgList(Records, OS);
   emitClangAttrVariadicIdentifierArgList(Records, OS);
   emitClangAttrThisIsaIdentifierArgList(Records, OS);
+  emitClangAttrNumArgs(Records, OS);
+  emitClangAttrLastArgParmPackSupport(Records, OS);
   emitClangAttrTypeArgList(Records, OS);
   emitClangAttrLateParsedList(Records, OS);
 }
Index: clang/test/SemaTemplate/attributes.cpp
===
--- clang/test/SemaTemplate/attributes.cpp
+++ clang/test/SemaTemplate/attributes.cpp
@@ -64,6 +64,23 @@
 template [[clang::annotate("ANNOTATE_FOO"), clang::annotate("ANNOTATE_BAR")]] void HasAnnotations();
 void UseAnnotations() { HasAnnotations(); }
 
+// CHECK:  FunctionTemplateDecl {{.*}} HasPackAnnotation

[PATCH] D117613: [ASTMatchers] Add `isConsteval` matcher

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:5179
+///   consteval int bar();
+///   void baz() { if consteval {} }
+/// \endcode

Izaron wrote:
> aaron.ballman wrote:
> > It'd be good to show an example of:
> > ```
> > if ! consteval {}
> > 
> > if ! consteval {} else {}
> > ```
> > as well so users know what to expect.
> > 
> > Should there be a matcher so users can distinguish between `if consteval` 
> > and `if ! consteval`?
> > 
> > Test cases for these sort of things would also be appreciated.
> Thanks!
> > Should there be a matcher so users can distinguish between `if consteval` 
> > and `if ! consteval`?
> This is an interesting question. I wonder how intensively `if ! consteval` is 
> ever going to be used in real life to make a unique matcher for it? I can't 
> make up a hypothetical checker that would need it.
> 
> Let's see what other fellow reviewers think about it =)
That's a good question.
Maybe we can add it later if there is a need?
I suspect that if we need 2, we need 3, `hasConsteval`, `hasNegatedConsteval`, 
`hasNonNegatedConsteval`

Until a need present itself,  maybe one is enough


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117613

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

[PATCH] D117759: [clang-format][NFC] Clean up tryMergeLessLess()

[Marek Kurdej via Phabricator via cfe-commits]

curdeius accepted this revision.
curdeius added a comment.
This revision is now accepted and ready to land.

Great! Thanks.


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

https://reviews.llvm.org/D117759

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

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev updated this revision to Diff 401581.
sgatev marked an inline comment as done.
sgatev added a comment.

Address reviewers' comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1828,4 +1828,41 @@
   });
 }
 
+TEST_F(TransferTest, VarDeclInDoWhile) {
+  std::string Code = R"(
+void target(int *Foo) {
+  do {
+int Bar = *Foo;
+  } while (true);
+  (void)0;
+  /*[[p]]*/
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const auto *FooVal =
+cast(Env.getValue(*FooDecl, SkipPast::None));
+const auto *FooPointeeVal =
+cast(Env.getValue(FooVal->getPointeeLoc()));
+
+const auto *BarVal = dyn_cast_or_null(
+Env.getValue(*BarDecl, SkipPast::None));
+ASSERT_THAT(BarVal, NotNull());
+
+EXPECT_EQ(BarVal, FooPointeeVal);
+  });
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -12,6 +12,7 @@
 //===--===//
 
 #include 
+#include 
 #include 
 #include 
 
@@ -30,6 +31,16 @@
 namespace clang {
 namespace dataflow {
 
+struct CFGBlockPtrCompare {
+  bool operator()(const CFGBlock *LHS, const CFGBlock *RHS) const {
+if (LHS == nullptr)
+  return true;
+if (RHS == nullptr)
+  return false;
+return LHS->getBlockID() < RHS->getBlockID();
+  }
+};
+
 /// Computes the input state for a given basic block by joining the output
 /// states of its predecessors.
 ///
@@ -43,7 +54,9 @@
 std::vector> &BlockStates,
 const CFGBlock &Block, const Environment &InitEnv,
 TypeErasedDataflowAnalysis &Analysis) {
-  llvm::DenseSet Preds;
+  // Ensure the order of predecessor blocks is deterministic to avoid flakiness
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());
   if (Block.getTerminator().isTemporaryDtorsBranch()) {
 // This handles a special case where the code that produced the CFG includes
Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -83,6 +83,11 @@
   if (DeclToLocSizeBefore != DeclToLoc.size())
 Effect = LatticeJoinEffect::Changed;
 
+  const unsigned ExprToLocSizeBefore = ExprToLoc.size();
+  ExprToLoc = intersectDenseMaps(ExprToLoc, Other.ExprToLoc);
+  if (ExprToLocSizeBefore != ExprToLoc.size())
+Effect = LatticeJoinEffect::Changed;
+
   // FIXME: Add support for joining distinct values that are assigned to the
   // same storage locations in `LocToVal` and `Other.LocToVal`.
   const unsigned LocToValSizeBefore = LocToVal.size();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev marked an inline comment as done.
sgatev added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:49
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());

xazax.hun wrote:
> xazax.hun wrote:
> > Are we sure that the memory addresses of CFGBlocks are stable enough for a 
> > deterministic order? Alternatively, we could use the block ids for the 
> > ordering.
> Also, could you describe where the flakiness is originated from? Naively, I'd 
> expect that the order in which we process the predecessors should not change 
> the results of the analysis.
You're right, using block ids for ordering is better. I updated the code.

> Also, could you describe where the flakiness is originated from?

Say we have a block `B1` with predecessors `B2` and `B3`. Let the environment 
of `B2` after evaluating all of its statements is `B2Env = { Expr1 -> Loc1 }` 
and the environment of `B3` after evaluating all of its statement is `B3Env = { 
Expr2 -> Loc2 }` where `ExprX -> LocX` refers to a particular mapping of 
storage locations to expressions.

What we want for the input environment of `B1` is `{}` because `B2Env` and 
`B3Env` do not contain common assignments of storage locations to expressions. 
What we got before this patch is either `B2Env.join(B3Env) = { Expr1 -> Loc1 }` 
or `B3Env.join(B2Env) = { Expr2 -> Loc2 }`.

Without deterministic ordering of predecessors the test that I'm introducing in 
this patch is flaky.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

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

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:49
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());

sgatev wrote:
> xazax.hun wrote:
> > xazax.hun wrote:
> > > Are we sure that the memory addresses of CFGBlocks are stable enough for 
> > > a deterministic order? Alternatively, we could use the block ids for the 
> > > ordering.
> > Also, could you describe where the flakiness is originated from? Naively, 
> > I'd expect that the order in which we process the predecessors should not 
> > change the results of the analysis.
> You're right, using block ids for ordering is better. I updated the code.
> 
> > Also, could you describe where the flakiness is originated from?
> 
> Say we have a block `B1` with predecessors `B2` and `B3`. Let the environment 
> of `B2` after evaluating all of its statements is `B2Env = { Expr1 -> Loc1 }` 
> and the environment of `B3` after evaluating all of its statement is `B3Env = 
> { Expr2 -> Loc2 }` where `ExprX -> LocX` refers to a particular mapping of 
> storage locations to expressions.
> 
> What we want for the input environment of `B1` is `{}` because `B2Env` and 
> `B3Env` do not contain common assignments of storage locations to 
> expressions. What we got before this patch is either `B2Env.join(B3Env) = { 
> Expr1 -> Loc1 }` or `B3Env.join(B2Env) = { Expr2 -> Loc2 }`.
> 
> Without deterministic ordering of predecessors the test that I'm introducing 
> in this patch is flaky.
> What we got before this patch is either B2Env.join(B3Env) = { Expr1 -> Loc1 } 
> or B3Env.join(B2Env) = { Expr2 -> Loc2 }.

I think I'm still missing something. With this patch, wouldn't both 
B2Env.join(B3Env) and B3Env.join(B2Env) produce the empty environment? If that 
is the case, do we still care about a deterministic order?





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

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

[PATCH] D117232: [clang] Respect -Wdeclaration-after-statement with C99 or later

[Marco Elver via Phabricator via cfe-commits]

melver added a comment.

Hello,

A quick review would be much appreciated. I intend to submit this before Feb 1 
so it may be included in Clang 14.

In case I have not added the appropriate reviewer(s) of the modified code, 
please let me know.

Thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117232

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

[PATCH] D112613: [RISCV] Change TARGET_BUILTIN to require zve32x for vector instruction

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD added a comment.

Apply @frasercrmck 's suggested title, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112613

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

[PATCH] D112986: [RISCV] Restrict zvamo, zvlsseg with zve macro-s

[Yueh-Ting Chen via Phabricator via cfe-commits]

eopXD reclaimed this revision.
eopXD added a comment.

This was closed by my misunderstanding.
For clang we still need to do some restrictions based on ELEN.
Reopening.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112986

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

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen added a comment.

In D105169#3254757 , @nlopes wrote:

> In D105169#3254692 , @DavidSpickett 
> wrote:
>
>> Hi, this patch has caused a gcc test suite failure on our SVE bots: 
>> https://lab.llvm.org/buildbot/#/builders/184/builds/1941
>> (test source is 
>> https://github.com/llvm/llvm-test-suite/blob/main/SingleSource/Regression/C/gcc-c-torture/execute/pr79286.c)
>>
>> I've only just been made aware of the failure so we will spend some time to 
>> find out the reason before asking that anything be changed. Could be 
>> something specific to SVE in which case we'll handle it.
>
> Thanks!
> That test has UB in the printf class as it reads a non-initialized variable. 
> Can you check if changing line 6 to 'int e = 0;' solves the problem?

I can confirm that fixes the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D117773: [clang-tidy] added JSON output to clang-tidy-diff.py

[Christian Kühnel via Phabricator via cfe-commits]

kuhnel created this revision.
Herald added subscribers: carlosgalvezp, usaxena95, kadircet, xazax.hun.
kuhnel requested review of this revision.
Herald added subscribers: cfe-commits, ilya-biryukov.
Herald added a project: clang-tools-extra.

This makes it easier to process the clang-tidy output in other tools.
For far it's only parsing the findings, not the output on stderr.

For testing you can use:

  bash
  ninja clangd
  COMMIT=4dedd82cc99341d757a9cc07a8b7b22c8bb61d19
  git diff $COMMIT~ $COMMIT | python3 
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py -p1 -json -checks="*"

This is part of the effort towards re-enabling clang-tidy in
pre-merge testing. With JSON output, we can deprecate some local
code in pre-merge testing.

https://github.com/google/llvm-premerge-checks/issues/367


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117773

Files:
  clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py

Index: clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
===
--- clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
+++ clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
@@ -35,6 +35,7 @@
 import tempfile
 import threading
 import traceback
+from typing import Optional
 
 try:
   import yaml
@@ -49,7 +50,7 @@
 import queue as queue
 
 
-def run_tidy(task_queue, lock, timeout):
+def run_tidy(task_queue, lock, timeout, result_queue: Optional[queue.Queue]):
   watchdog = None
   while True:
 command = task_queue.get()
@@ -65,8 +66,11 @@
   stdout, stderr = proc.communicate()
 
   with lock:
-sys.stdout.write(stdout.decode('utf-8') + '\n')
-sys.stdout.flush()
+if result_queue:
+  parse_clang_tidy_output(result_queue, stdout.decode('utf-8'))
+else:
+  sys.stdout.write(stdout.decode('utf-8') + '\n')
+  sys.stdout.flush()
 if stderr:
   sys.stderr.write(stderr.decode('utf-8') + '\n')
   sys.stderr.flush()
@@ -83,9 +87,9 @@
   task_queue.task_done()
 
 
-def start_workers(max_tasks, tidy_caller, task_queue, lock, timeout):
+def start_workers(max_tasks, tidy_caller, task_queue, lock, timeout, result_queue):
   for _ in range(max_tasks):
-t = threading.Thread(target=tidy_caller, args=(task_queue, lock, timeout))
+t = threading.Thread(target=tidy_caller, args=(task_queue, lock, timeout, result_queue))
 t.daemon = True
 t.start()
 
@@ -115,6 +119,18 @@
 open(mergefile, 'w').close()
 
 
+def parse_clang_tidy_output(result_queue: queue, clang_tidy_output: str):
+  """Parse the clang-tidy output and add them to the result queue."""
+  _regex_pattern = r"^(?P/[^:]+):\W*(?P\d+):\W*(?P\d+):\W*(?P.*)$"
+  for finding in re.finditer(_regex_pattern, clang_tidy_output, re.MULTILINE):
+result_queue.put({
+'path': finding['path'],
+'line': int(finding['line']),
+'character': int(finding['character']),
+'check': finding['check'],
+})
+
+
 def main():
   parser = argparse.ArgumentParser(description=
'Run clang-tidy against changed files, and '
@@ -160,6 +176,8 @@
   'command line.')
   parser.add_argument('-quiet', action='store_true', default=False,
   help='Run clang-tidy in quiet mode')
+  parser.add_argument('-json', action='store_true', dest='json_output',
+  help='Output clang-tidy results in JSON format.')
   clang_tidy_args = []
   argv = sys.argv[1:]
   if '--' in argv:
@@ -214,8 +232,14 @@
   # A lock for console output.
   lock = threading.Lock()
 
+  # if we want JSON output: gather results
+  result_queue = None
+  if args.json_output:
+result_queue = queue.Queue()
+
   # Run a pool of clang-tidy workers.
-  start_workers(max_task_count, run_tidy, task_queue, lock, args.timeout)
+  start_workers(max_task_count, run_tidy, task_queue,
+lock, args.timeout, result_queue)
 
   # Form the common args list.
   common_clang_tidy_args = []
@@ -227,7 +251,7 @@
 common_clang_tidy_args.append('-quiet')
   if args.build_path is not None:
 common_clang_tidy_args.append('-p=%s' % args.build_path)
-  if args.use_color:
+  if args.use_color and not args.json_output:
 common_clang_tidy_args.append('--use-color')
   for arg in args.extra_arg:
 common_clang_tidy_args.append('-extra-arg=%s' % arg)
@@ -268,6 +292,8 @@
   if tmpdir:
 shutil.rmtree(tmpdir)
 
-
+  if args.json_output:
+json_output = {'findings': list(result_queue.queue)} 
+json.dump(json_output, sys.stdout, indent=2)
 if __name__ == '__main__':
   main()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107450: [clang-tidy] Fix wrong FixIt in performance-move-const-arg

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Do you need someone to commit on your behalf?


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

https://reviews.llvm.org/D107450

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

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Nuno Lopes via Phabricator via cfe-commits]

nlopes added a comment.

In D105169#3257849 , @sdesmalen wrote:

> In D105169#3254757 , @nlopes wrote:
>
>> In D105169#3254692 , 
>> @DavidSpickett wrote:
>>
>>> Hi, this patch has caused a gcc test suite failure on our SVE bots: 
>>> https://lab.llvm.org/buildbot/#/builders/184/builds/1941
>>> (test source is 
>>> https://github.com/llvm/llvm-test-suite/blob/main/SingleSource/Regression/C/gcc-c-torture/execute/pr79286.c)
>>>
>>> I've only just been made aware of the failure so we will spend some time to 
>>> find out the reason before asking that anything be changed. Could be 
>>> something specific to SVE in which case we'll handle it.
>>
>> Thanks!
>> That test has UB in the printf class as it reads a non-initialized variable. 
>> Can you check if changing line 6 to 'int e = 0;' solves the problem?
>
> I can confirm that fixes the issue.

Thank you! I've committed the fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Nuno Lopes via Phabricator via cfe-commits]

nlopes added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2535
 ArgAttrs[FirstIRArg + i] =
 llvm::AttributeSet::get(getLLVMContext(), Attrs);
 }

sammccall wrote:
> fhahn wrote:
> > nlopes wrote:
> > > fhahn wrote:
> > > > nlopes wrote:
> > > > > ab wrote:
> > > > > > Hmm, if I'm reading this right, this overwrites the `nonnull 
> > > > > > dereferenceable align` attributes separately computed for `this` 
> > > > > > around l2335, right? (or `inalloca` and `sret` before that)
> > > > > > 
> > > > > > It sounds like an ancient bug, that's only exposed because 
> > > > > > `noundef` ends up triggering this logic much more often?
> > > > > > 
> > > > > > Many of our downstream tests hit this. The hacked up patch seems to 
> > > > > > do the job; ideally we'd feed the previously-computed attrs when 
> > > > > > constructing the AttrBuilder (which would also fix the padding 
> > > > > > argument), but we'd need to match up the IR args first.  Maybe 
> > > > > > that's fine as a special-case for arg 0 though
> > > > > nice catch! It's an ancient bug where arg 0 is overwritten.
> > > > Is anybody looking into a fix or should we revert the patch until this 
> > > > can be properly addressed?
> > > I would recommend against reverting this patch because of all the 
> > > followup patches. There were quite a few commits afterwards plus fixes to 
> > > buildbot configurations, so it's a non-trivial overhead to revert 
> > > everything.
> > > I was assuming @ab would fix it as he already root-caused the bug..
> > FWIW it seems a bit unfortunate that there are some clear regressions when 
> > the tests got update, e.g. 
> > https://github.com/llvm/llvm-project/commit/1b1c8d83d3567a60280291c0adb95d1d60335509#diff-7e80d593f26f6f6fb24765c6a169884d7350685d565ee970b0a7b9abaf0fb205L355
> > 
> > I'll work with @ab to fix this though rather than reverting, because 
> > another revert would cause even more conflicts for us downstream.
> > FWIW it seems a bit unfortunate that there are some clear regressions when 
> > the tests got update, e.g. 
> > https://github.com/llvm/llvm-project/commit/1b1c8d83d3567a60280291c0adb95d1d60335509#diff-7e80d593f26f6f6fb24765c6a169884d7350685d565ee970b0a7b9abaf0fb205L355
> > 
> > I'll work with @ab to fix this though rather than reverting, because 
> > another revert would cause even more conflicts for us downstream.
> 
> Just a reminder that the 14 release is cut soon (1 feb: 
> https://llvm.discourse.group/t/llvm-14-0-0-release-schedule/5846)
> 
> I don't know this code; if a clean fix is ready soon and unlikely to have a 
> ripple effect then great. But it does seem risky to be treating such 
> configuration changes as "too big to fail" at this point in the release cycle.
Thank you Florian!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D116221: [AArch64][ARM][Clang] Unaligned Access Warning Added

[Pablo Barrio via Phabricator via cfe-commits]

pbarrio accepted this revision.
pbarrio added a comment.
This revision is now accepted and ready to land.

LGTM too.


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

https://reviews.llvm.org/D116221

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

[PATCH] D117647: [RISCV] Add destination operand for RVV nomask load intrinsics.

[Fraser Cormack via Phabricator via cfe-commits]

frasercrmck added a comment.

Is "destination operand" the terminology we want? I'd have thought "passthru" 
was more conventional.




Comment at: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:1194
 Operands.push_back(Node->getOperand(CurOp++));
+  if (Node->getOperand(CurOp).isUndef())
+CurOp++;

If I'm reading this right, isn't it possible that we could have a masked/tu 
intrinsic, so push back the passthru operand, increment `CurOp` then check 
whether the //pointer// operand is Undef, then wrongly increment `CurOp` a 
second time? So basically an undef base pointer has the potential to 
(presumably) crash the compiler somewhere later?

Don't we unconditionally want to increment `CurOp` (a single time) since we now 
always have a passthru operand that we want to skip over?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117647

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

[PATCH] D117520: [clang-format] Fix SeparateDefinitionBlocks issues

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added a comment.

In D117520#3251425 , @MyDeveloperDay 
wrote:

> For
>
>   class Test
>   {
>   public:
>   static void foo()
>   {
>   }
>   };
>
> F21703157: image.png 
>
>   $ clang-format -n test.cxx
>   test.cxx:3:8: warning: code should be clang-formatted 
> [-Wclang-format-violations
>   ]
>   public:
>  ^
>
>
>
>   $ clang-format --output-replacements-xml test.cxx
>   
>   
>   

>   
>
> but when I run it nothing changes
>
>   $ clang-format test.cxx
>   class Test
>   {
>   public:
>   static void foo()
>   {
>   }
>   };
>
> And no character change
>
> F21703226: image.png 

@MyDeveloperDay, @ksyx 
Is there a test for this?
If no, how can we test it? It happens only with `--dry-run`, right?


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

https://reviews.llvm.org/D117520

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

[PATCH] D112987: [RISCV] Bump rvv-related extensions from 0.10 to 1.0

[Fraser Cormack via Phabricator via cfe-commits]

frasercrmck added a comment.

If we're bumping it to 1.0, does that mean it's no longer "experimental"?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112987

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

[PATCH] D116786: [clangd] Add designator inlay hints for initializer lists.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

> Any ideas? :-(

I've got a feeling that, this should also be annoying in the case of function 
calls (especially when there's only one overload)? Maybe we should just 
debounce the inlayhint requests (by saying contents modified to the clients)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116786

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

[PATCH] D117776: [clangd] Fail inlayHints requests on content changes

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet created this revision.
kadircet added a reviewer: sammccall.
Herald added subscribers: usaxena95, arphaman.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

This should improve the overall UX by making the labels less jumpy.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117776

Files:
  clang-tools-extra/clangd/ClangdServer.cpp


Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -775,7 +775,7 @@
   return CB(InpAST.takeError());
 CB(clangd::inlayHints(InpAST->AST, std::move(RestrictRange)));
   };
-  WorkScheduler->runWithAST("InlayHints", File, std::move(Action));
+  WorkScheduler->runWithAST("InlayHints", File, std::move(Action), Transient);
 }
 
 void ClangdServer::onFileEvent(const DidChangeWatchedFilesParams &Params) {


Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -775,7 +775,7 @@
   return CB(InpAST.takeError());
 CB(clangd::inlayHints(InpAST->AST, std::move(RestrictRange)));
   };
-  WorkScheduler->runWithAST("InlayHints", File, std::move(Action));
+  WorkScheduler->runWithAST("InlayHints", File, std::move(Action), Transient);
 }
 
 void ClangdServer::onFileEvent(const DidChangeWatchedFilesParams &Params) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev marked 2 inline comments as done.
sgatev added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:49
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());

xazax.hun wrote:
> sgatev wrote:
> > xazax.hun wrote:
> > > xazax.hun wrote:
> > > > Are we sure that the memory addresses of CFGBlocks are stable enough 
> > > > for a deterministic order? Alternatively, we could use the block ids 
> > > > for the ordering.
> > > Also, could you describe where the flakiness is originated from? Naively, 
> > > I'd expect that the order in which we process the predecessors should not 
> > > change the results of the analysis.
> > You're right, using block ids for ordering is better. I updated the code.
> > 
> > > Also, could you describe where the flakiness is originated from?
> > 
> > Say we have a block `B1` with predecessors `B2` and `B3`. Let the 
> > environment of `B2` after evaluating all of its statements is `B2Env = { 
> > Expr1 -> Loc1 }` and the environment of `B3` after evaluating all of its 
> > statement is `B3Env = { Expr2 -> Loc2 }` where `ExprX -> LocX` refers to a 
> > particular mapping of storage locations to expressions.
> > 
> > What we want for the input environment of `B1` is `{}` because `B2Env` and 
> > `B3Env` do not contain common assignments of storage locations to 
> > expressions. What we got before this patch is either `B2Env.join(B3Env) = { 
> > Expr1 -> Loc1 }` or `B3Env.join(B2Env) = { Expr2 -> Loc2 }`.
> > 
> > Without deterministic ordering of predecessors the test that I'm 
> > introducing in this patch is flaky.
> > What we got before this patch is either B2Env.join(B3Env) = { Expr1 -> Loc1 
> > } or B3Env.join(B2Env) = { Expr2 -> Loc2 }.
> 
> I think I'm still missing something. With this patch, wouldn't both 
> B2Env.join(B3Env) and B3Env.join(B2Env) produce the empty environment? If 
> that is the case, do we still care about a deterministic order?
> 
> 
> 
That's right. With the patch in `DataflowEnvironment.cpp` the particular order 
of predecessors doesn't affect the result. However, one of the properties that 
I'm looking for in tests is being able to remove functionality from the code 
and have the tests that exercise this functionality fail. This won't 
necessarily be the case here if the order wasn't deterministic. I don't have a 
strong preference so please let me know if you have concerns about it. I should 
also note that we expect all of this to be removed once temporary destructors 
are handled better in the CFG.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

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

[clang] 69ecd24 - [clang-format] Indicate source location on test failure. NFC.

[Marek Kurdej via cfe-commits]

Author: Marek Kurdej
Date: 2022-01-20T14:10:59+01:00
New Revision: 69ecd2484f0d363537afc0157bd6a946fccf8453

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

LOG: [clang-format] Indicate source location on test failure. NFC.

Added: 


Modified: 
clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
clang/unittests/Format/FormatTestTextProto.cpp
clang/unittests/Format/SortImportsTestJS.cpp

Removed: 




diff  --git a/clang/unittests/Format/DefinitionBlockSeparatorTest.cpp 
b/clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
index 13054bcad1a96..69c87cb4b51fd 100644
--- a/clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
+++ b/clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
@@ -41,9 +41,10 @@ class DefinitionBlockSeparatorTest : public ::testing::Test {
 /*Ranges=*/{1, tooling::Range(0, Code.size())}, Style);
   }
 
-  static void verifyFormat(llvm::StringRef Code,
-   const FormatStyle &Style = getLLVMStyle(),
-   llvm::StringRef ExpectedCode = "") {
+  static void _verifyFormat(const char *File, int Line, llvm::StringRef Code,
+const FormatStyle &Style = getLLVMStyle(),
+llvm::StringRef ExpectedCode = "") {
+::testing::ScopedTrace t(File, Line, ::testing::Message() << Code.str());
 bool HasOriginalCode = true;
 if (ExpectedCode == "") {
   ExpectedCode = Code;
@@ -83,6 +84,8 @@ class DefinitionBlockSeparatorTest : public ::testing::Test {
   }
 };
 
+#define verifyFormat(...) _verifyFormat(__FILE__, __LINE__, __VA_ARGS__)
+
 TEST_F(DefinitionBlockSeparatorTest, Basic) {
   FormatStyle Style = getLLVMStyle();
   Style.SeparateDefinitionBlocks = FormatStyle::SDS_Always;

diff  --git a/clang/unittests/Format/FormatTestTextProto.cpp 
b/clang/unittests/Format/FormatTestTextProto.cpp
index 1e25948938416..44b67d275bcc3 100644
--- a/clang/unittests/Format/FormatTestTextProto.cpp
+++ b/clang/unittests/Format/FormatTestTextProto.cpp
@@ -34,18 +34,22 @@ class FormatTestTextProto : public ::testing::Test {
 return format(Code, 0, Code.size(), Style);
   }
 
-  static void verifyFormat(llvm::StringRef Code, const FormatStyle &Style) {
+  static void _verifyFormat(const char *File, int Line, llvm::StringRef Code,
+const FormatStyle &Style) {
+::testing::ScopedTrace t(File, Line, ::testing::Message() << Code.str());
 EXPECT_EQ(Code.str(), format(Code, Style)) << "Expected code is not 
stable";
 EXPECT_EQ(Code.str(), format(test::messUp(Code), Style));
   }
 
-  static void verifyFormat(llvm::StringRef Code) {
+  static void _verifyFormat(const char *File, int Line, llvm::StringRef Code) {
 FormatStyle Style = getGoogleStyle(FormatStyle::LK_TextProto);
 Style.ColumnLimit = 60; // To make writing tests easier.
-verifyFormat(Code, Style);
+_verifyFormat(File, Line, Code, Style);
   }
 };
 
+#define verifyFormat(...) _verifyFormat(__FILE__, __LINE__, __VA_ARGS__)
+
 TEST_F(FormatTestTextProto, KeepsTopLevelEntriesFittingALine) {
   verifyFormat("field_a: OK field_b: OK field_c: OK field_d: OK field_e: OK");
 }

diff  --git a/clang/unittests/Format/SortImportsTestJS.cpp 
b/clang/unittests/Format/SortImportsTestJS.cpp
index 4b426375cfea8..6fe8bba53549b 100644
--- a/clang/unittests/Format/SortImportsTestJS.cpp
+++ b/clang/unittests/Format/SortImportsTestJS.cpp
@@ -33,8 +33,10 @@ class SortImportsTestJS : public ::testing::Test {
 return *Formatted;
   }
 
-  void verifySort(llvm::StringRef Expected, llvm::StringRef Code,
-  unsigned Offset = 0, unsigned Length = 0) {
+  void _verifySort(const char *File, int Line, llvm::StringRef Expected,
+   llvm::StringRef Code, unsigned Offset = 0,
+   unsigned Length = 0) {
+::testing::ScopedTrace t(File, Line, ::testing::Message() << Code.str());
 std::string Result = sort(Code, Offset, Length);
 EXPECT_EQ(Expected.str(), Result) << "Expected:\n"
   << Expected << "\nActual:\n"
@@ -44,6 +46,8 @@ class SortImportsTestJS : public ::testing::Test {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_JavaScript);
 };
 
+#define verifySort(...) _verifySort(__FILE__, __LINE__, __VA_ARGS__)
+
 TEST_F(SortImportsTestJS, AlreadySorted) {
   verifySort("import {sym} from 'a';\n"
  "import {sym} from 'b';\n"



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

[PATCH] D117777: [OpenMP] Don't pass empty files to nvlink

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, ye-luo, lechenyu.
Herald added subscribers: guansong, yaxunl.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

This patch adds and exception to the nvlink wrapper tool to not pass
empty cubin files to the nvlink job. If an empty file is passed to
nvlink it will cause an error indicating that the file could not be
opened. This would occur if the user tried to link object files that
contained offloading code with a file that didnt. This will act as a 
workaround until the new OpenMP offloading driver becomes the default.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D11

Files:
  clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp


Index: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
===
--- clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
+++ clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
@@ -55,12 +55,22 @@
 static cl::list
 NVArgs(cl::Sink, cl::desc("..."));
 
+static bool isEmptyFile(StringRef Filename) {
+  ErrorOr> BufOrErr =
+  MemoryBuffer::getFileOrSTDIN(Filename, false, false);
+  if (std::error_code EC = BufOrErr.getError())
+return false;
+  return (*BufOrErr)->getBuffer().empty();
+}
+
 static Error runNVLink(std::string NVLinkPath,
SmallVectorImpl &Args) {
   std::vector NVLArgs;
   NVLArgs.push_back(NVLinkPath);
+  StringRef Output = *(llvm::find(Args, "-o") + 1);
   for (auto &Arg : Args) {
-NVLArgs.push_back(Arg);
+if (!(sys::fs::exists(Arg) && Arg != Output && isEmptyFile(Arg)))
+  NVLArgs.push_back(Arg);
   }
 
   if (sys::ExecuteAndWait(NVLinkPath, NVLArgs))


Index: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
===
--- clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
+++ clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
@@ -55,12 +55,22 @@
 static cl::list
 NVArgs(cl::Sink, cl::desc("..."));
 
+static bool isEmptyFile(StringRef Filename) {
+  ErrorOr> BufOrErr =
+  MemoryBuffer::getFileOrSTDIN(Filename, false, false);
+  if (std::error_code EC = BufOrErr.getError())
+return false;
+  return (*BufOrErr)->getBuffer().empty();
+}
+
 static Error runNVLink(std::string NVLinkPath,
SmallVectorImpl &Args) {
   std::vector NVLArgs;
   NVLArgs.push_back(NVLinkPath);
+  StringRef Output = *(llvm::find(Args, "-o") + 1);
   for (auto &Arg : Args) {
-NVLArgs.push_back(Arg);
+if (!(sys::fs::exists(Arg) && Arg != Output && isEmptyFile(Arg)))
+  NVLArgs.push_back(Arg);
   }
 
   if (sys::ExecuteAndWait(NVLinkPath, NVLArgs))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117613: [ASTMatchers] Add `isConsteval` matcher

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman requested changes to this revision.
aaron.ballman added inline comments.
This revision now requires changes to proceed.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:5179
+///   consteval int bar();
+///   void baz() { if consteval {} }
+/// \endcode

cor3ntin wrote:
> Izaron wrote:
> > aaron.ballman wrote:
> > > It'd be good to show an example of:
> > > ```
> > > if ! consteval {}
> > > 
> > > if ! consteval {} else {}
> > > ```
> > > as well so users know what to expect.
> > > 
> > > Should there be a matcher so users can distinguish between `if consteval` 
> > > and `if ! consteval`?
> > > 
> > > Test cases for these sort of things would also be appreciated.
> > Thanks!
> > > Should there be a matcher so users can distinguish between `if consteval` 
> > > and `if ! consteval`?
> > This is an interesting question. I wonder how intensively `if ! consteval` 
> > is ever going to be used in real life to make a unique matcher for it? I 
> > can't make up a hypothetical checker that would need it.
> > 
> > Let's see what other fellow reviewers think about it =)
> That's a good question.
> Maybe we can add it later if there is a need?
> I suspect that if we need 2, we need 3, `hasConsteval`, 
> `hasNegatedConsteval`, `hasNonNegatedConsteval`
> 
> Until a need present itself,  maybe one is enough
> This is an interesting question. I wonder how intensively if ! consteval is 
> ever going to be used in real life to make a unique matcher for it? I can't 
> make up a hypothetical checker that would need it.

That's not the salient question. I'm more worried that the current interface is 
confusing and not easy to extend. There's no motivation in the review for why 
this support is needed, and we tend to err on the side of being conservative 
with matcher interfaces (we only add them when they're necessary and generally 
useful, otherwise users can use local matchers).

I think the matcher isn't well designed for `IfStmt` and we should drop support 
for that initially, and only focus on support for `FunctionDecl` where the 
behavior is more clear. Then we can decide what the correct interface is for 
`IfStmt` once we have a better picture of how the matcher is expected to be 
used and a more general design for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117613

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

[PATCH] D112987: [RISCV] Bump rvv-related extensions from 0.10 to 1.0

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D112987#3257899 , @frasercrmck 
wrote:

> If we're bumping it to 1.0, does that mean it's no longer "experimental"?

Whether RVV is non-experimental or not is the big open question for 14.0. I've 
put it on the agenda for today's sync call.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112987

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

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:49
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());

sgatev wrote:
> xazax.hun wrote:
> > sgatev wrote:
> > > xazax.hun wrote:
> > > > xazax.hun wrote:
> > > > > Are we sure that the memory addresses of CFGBlocks are stable enough 
> > > > > for a deterministic order? Alternatively, we could use the block ids 
> > > > > for the ordering.
> > > > Also, could you describe where the flakiness is originated from? 
> > > > Naively, I'd expect that the order in which we process the predecessors 
> > > > should not change the results of the analysis.
> > > You're right, using block ids for ordering is better. I updated the code.
> > > 
> > > > Also, could you describe where the flakiness is originated from?
> > > 
> > > Say we have a block `B1` with predecessors `B2` and `B3`. Let the 
> > > environment of `B2` after evaluating all of its statements is `B2Env = { 
> > > Expr1 -> Loc1 }` and the environment of `B3` after evaluating all of its 
> > > statement is `B3Env = { Expr2 -> Loc2 }` where `ExprX -> LocX` refers to 
> > > a particular mapping of storage locations to expressions.
> > > 
> > > What we want for the input environment of `B1` is `{}` because `B2Env` 
> > > and `B3Env` do not contain common assignments of storage locations to 
> > > expressions. What we got before this patch is either `B2Env.join(B3Env) = 
> > > { Expr1 -> Loc1 }` or `B3Env.join(B2Env) = { Expr2 -> Loc2 }`.
> > > 
> > > Without deterministic ordering of predecessors the test that I'm 
> > > introducing in this patch is flaky.
> > > What we got before this patch is either B2Env.join(B3Env) = { Expr1 -> 
> > > Loc1 } or B3Env.join(B2Env) = { Expr2 -> Loc2 }.
> > 
> > I think I'm still missing something. With this patch, wouldn't both 
> > B2Env.join(B3Env) and B3Env.join(B2Env) produce the empty environment? If 
> > that is the case, do we still care about a deterministic order?
> > 
> > 
> > 
> That's right. With the patch in `DataflowEnvironment.cpp` the particular 
> order of predecessors doesn't affect the result. However, one of the 
> properties that I'm looking for in tests is being able to remove 
> functionality from the code and have the tests that exercise this 
> functionality fail. This won't necessarily be the case here if the order 
> wasn't deterministic. I don't have a strong preference so please let me know 
> if you have concerns about it. I should also note that we expect all of this 
> to be removed once temporary destructors are handled better in the CFG.
Strictly speaking, making this deterministic is not a requirement, it should 
not have any observable effect for the end user. On the other hand, we could 
think of this non-determinism as a feature. A well behaved analysis should 
produce the same answer regardless of the order in which we process the nodes. 
(This requirement follows from the algebraic properties of the join operation.) 
So in the future I would even anticipate a feature that deliberately randomize 
the order to ensure that the clients are well behaved.

I think eliminating this non-determinism could potentially mask bugs in the 
future and also it requires extra code. I think I prefer the original version 
until we see some evidence that determinism is desired. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

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

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2535
 ArgAttrs[FirstIRArg + i] =
 llvm::AttributeSet::get(getLLVMContext(), Attrs);
 }

nlopes wrote:
> sammccall wrote:
> > fhahn wrote:
> > > nlopes wrote:
> > > > fhahn wrote:
> > > > > nlopes wrote:
> > > > > > ab wrote:
> > > > > > > Hmm, if I'm reading this right, this overwrites the `nonnull 
> > > > > > > dereferenceable align` attributes separately computed for `this` 
> > > > > > > around l2335, right? (or `inalloca` and `sret` before that)
> > > > > > > 
> > > > > > > It sounds like an ancient bug, that's only exposed because 
> > > > > > > `noundef` ends up triggering this logic much more often?
> > > > > > > 
> > > > > > > Many of our downstream tests hit this. The hacked up patch seems 
> > > > > > > to do the job; ideally we'd feed the previously-computed attrs 
> > > > > > > when constructing the AttrBuilder (which would also fix the 
> > > > > > > padding argument), but we'd need to match up the IR args first.  
> > > > > > > Maybe that's fine as a special-case for arg 0 though
> > > > > > nice catch! It's an ancient bug where arg 0 is overwritten.
> > > > > Is anybody looking into a fix or should we revert the patch until 
> > > > > this can be properly addressed?
> > > > I would recommend against reverting this patch because of all the 
> > > > followup patches. There were quite a few commits afterwards plus fixes 
> > > > to buildbot configurations, so it's a non-trivial overhead to revert 
> > > > everything.
> > > > I was assuming @ab would fix it as he already root-caused the bug..
> > > FWIW it seems a bit unfortunate that there are some clear regressions 
> > > when the tests got update, e.g. 
> > > https://github.com/llvm/llvm-project/commit/1b1c8d83d3567a60280291c0adb95d1d60335509#diff-7e80d593f26f6f6fb24765c6a169884d7350685d565ee970b0a7b9abaf0fb205L355
> > > 
> > > I'll work with @ab to fix this though rather than reverting, because 
> > > another revert would cause even more conflicts for us downstream.
> > > FWIW it seems a bit unfortunate that there are some clear regressions 
> > > when the tests got update, e.g. 
> > > https://github.com/llvm/llvm-project/commit/1b1c8d83d3567a60280291c0adb95d1d60335509#diff-7e80d593f26f6f6fb24765c6a169884d7350685d565ee970b0a7b9abaf0fb205L355
> > > 
> > > I'll work with @ab to fix this though rather than reverting, because 
> > > another revert would cause even more conflicts for us downstream.
> > 
> > Just a reminder that the 14 release is cut soon (1 feb: 
> > https://llvm.discourse.group/t/llvm-14-0-0-release-schedule/5846)
> > 
> > I don't know this code; if a clean fix is ready soon and unlikely to have a 
> > ripple effect then great. But it does seem risky to be treating such 
> > configuration changes as "too big to fail" at this point in the release 
> > cycle.
> Thank you Florian!
should be fixed by 67aa314bcee7


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D117613: [ASTMatchers] Add `isConsteval` matcher

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:5179
+///   consteval int bar();
+///   void baz() { if consteval {} }
+/// \endcode

aaron.ballman wrote:
> cor3ntin wrote:
> > Izaron wrote:
> > > aaron.ballman wrote:
> > > > It'd be good to show an example of:
> > > > ```
> > > > if ! consteval {}
> > > > 
> > > > if ! consteval {} else {}
> > > > ```
> > > > as well so users know what to expect.
> > > > 
> > > > Should there be a matcher so users can distinguish between `if 
> > > > consteval` and `if ! consteval`?
> > > > 
> > > > Test cases for these sort of things would also be appreciated.
> > > Thanks!
> > > > Should there be a matcher so users can distinguish between `if 
> > > > consteval` and `if ! consteval`?
> > > This is an interesting question. I wonder how intensively `if ! 
> > > consteval` is ever going to be used in real life to make a unique matcher 
> > > for it? I can't make up a hypothetical checker that would need it.
> > > 
> > > Let's see what other fellow reviewers think about it =)
> > That's a good question.
> > Maybe we can add it later if there is a need?
> > I suspect that if we need 2, we need 3, `hasConsteval`, 
> > `hasNegatedConsteval`, `hasNonNegatedConsteval`
> > 
> > Until a need present itself,  maybe one is enough
> > This is an interesting question. I wonder how intensively if ! consteval is 
> > ever going to be used in real life to make a unique matcher for it? I can't 
> > make up a hypothetical checker that would need it.
> 
> That's not the salient question. I'm more worried that the current interface 
> is confusing and not easy to extend. There's no motivation in the review for 
> why this support is needed, and we tend to err on the side of being 
> conservative with matcher interfaces (we only add them when they're necessary 
> and generally useful, otherwise users can use local matchers).
> 
> I think the matcher isn't well designed for `IfStmt` and we should drop 
> support for that initially, and only focus on support for `FunctionDecl` 
> where the behavior is more clear. Then we can decide what the correct 
> interface is for `IfStmt` once we have a better picture of how the matcher is 
> expected to be used and a more general design for it.
That's not the salient question. I'm more worried that the current interface is 
confusing and not easy to extend. There's no motivation in the review for why 
this support is needed, and we tend to err on the side of being conservative 
with matcher interfaces (we only add them when they're necessary and generally 
useful, otherwise users can use local matchers).

Arguably, there is one for `if constexpr` and both of them should be symmetric. 
Introducing asymmetry for no good reason seems wrong. I assume that there was a 
motivation initially?
 
> I think the matcher isn't well designed for `IfStmt` and we should drop 
> support for that initially, and only focus on support for `FunctionDecl` 
> where the behavior is more clear. Then we can decide what the correct 
> interface is for `IfStmt` once we have a better picture of how the matcher is 
> expected to be used and a more general design for it.


This was initially my gut feeling, however there is no separate matcher for `if 
constexpr(false)` and `if constexpr (true)`, so I don't think that `if ! 
consteval` needs to be treated differently here.
Either way, i don't think adding one hurts






Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117613

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

[PATCH] D117769: [clang-format] Refactor: add FormatToken::hasWhitespaceBefore(). NFC.

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117769

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

[PATCH] D117759: [clang-format][NFC] Clean up tryMergeLessLess()

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

LGTM,  at first my head was confused with First[-1] but I think its ok.


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

https://reviews.llvm.org/D117759

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

[PATCH] D115060: [clang-format][NFC] Code Tidies in UnwrappedLineFormatter

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

LGTM


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

https://reviews.llvm.org/D115060

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

[PATCH] D117613: [ASTMatchers] Add `isConsteval` matcher

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:5179
+///   consteval int bar();
+///   void baz() { if consteval {} }
+/// \endcode

cor3ntin wrote:
> aaron.ballman wrote:
> > cor3ntin wrote:
> > > Izaron wrote:
> > > > aaron.ballman wrote:
> > > > > It'd be good to show an example of:
> > > > > ```
> > > > > if ! consteval {}
> > > > > 
> > > > > if ! consteval {} else {}
> > > > > ```
> > > > > as well so users know what to expect.
> > > > > 
> > > > > Should there be a matcher so users can distinguish between `if 
> > > > > consteval` and `if ! consteval`?
> > > > > 
> > > > > Test cases for these sort of things would also be appreciated.
> > > > Thanks!
> > > > > Should there be a matcher so users can distinguish between `if 
> > > > > consteval` and `if ! consteval`?
> > > > This is an interesting question. I wonder how intensively `if ! 
> > > > consteval` is ever going to be used in real life to make a unique 
> > > > matcher for it? I can't make up a hypothetical checker that would need 
> > > > it.
> > > > 
> > > > Let's see what other fellow reviewers think about it =)
> > > That's a good question.
> > > Maybe we can add it later if there is a need?
> > > I suspect that if we need 2, we need 3, `hasConsteval`, 
> > > `hasNegatedConsteval`, `hasNonNegatedConsteval`
> > > 
> > > Until a need present itself,  maybe one is enough
> > > This is an interesting question. I wonder how intensively if ! consteval 
> > > is ever going to be used in real life to make a unique matcher for it? I 
> > > can't make up a hypothetical checker that would need it.
> > 
> > That's not the salient question. I'm more worried that the current 
> > interface is confusing and not easy to extend. There's no motivation in the 
> > review for why this support is needed, and we tend to err on the side of 
> > being conservative with matcher interfaces (we only add them when they're 
> > necessary and generally useful, otherwise users can use local matchers).
> > 
> > I think the matcher isn't well designed for `IfStmt` and we should drop 
> > support for that initially, and only focus on support for `FunctionDecl` 
> > where the behavior is more clear. Then we can decide what the correct 
> > interface is for `IfStmt` once we have a better picture of how the matcher 
> > is expected to be used and a more general design for it.
> That's not the salient question. I'm more worried that the current interface 
> is confusing and not easy to extend. There's no motivation in the review for 
> why this support is needed, and we tend to err on the side of being 
> conservative with matcher interfaces (we only add them when they're necessary 
> and generally useful, otherwise users can use local matchers).
> 
> Arguably, there is one for `if constexpr` and both of them should be 
> symmetric. Introducing asymmetry for no good reason seems wrong. I assume 
> that there was a motivation initially?
>  
> > I think the matcher isn't well designed for `IfStmt` and we should drop 
> > support for that initially, and only focus on support for `FunctionDecl` 
> > where the behavior is more clear. Then we can decide what the correct 
> > interface is for `IfStmt` once we have a better picture of how the matcher 
> > is expected to be used and a more general design for it.
> 
> 
> This was initially my gut feeling, however there is no separate matcher for 
> `if constexpr(false)` and `if constexpr (true)`, so I don't think that `if ! 
> consteval` needs to be treated differently here.
> Either way, i don't think adding one hurts
> 
> 
> 
> 
You can match over the expression in `if constexpr` to determine whether it's 
true or false (at least in theory, we probably need some better matchers around 
constant expression value comparisons), but you cannot match over the syntax of 
`if ! consteval` vs `if consteval`, so I see them as being different cases in 
that regard.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117613

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

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev updated this revision to Diff 401615.
sgatev marked an inline comment as done.
sgatev added a comment.

Address reviewers' comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1828,4 +1828,41 @@
   });
 }
 
+TEST_F(TransferTest, VarDeclInDoWhile) {
+  std::string Code = R"(
+void target(int *Foo) {
+  do {
+int Bar = *Foo;
+  } while (true);
+  (void)0;
+  /*[[p]]*/
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const auto *FooVal =
+cast(Env.getValue(*FooDecl, SkipPast::None));
+const auto *FooPointeeVal =
+cast(Env.getValue(FooVal->getPointeeLoc()));
+
+const auto *BarVal = dyn_cast_or_null(
+Env.getValue(*BarDecl, SkipPast::None));
+ASSERT_THAT(BarVal, NotNull());
+
+EXPECT_EQ(BarVal, FooPointeeVal);
+  });
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -23,6 +23,7 @@
 #include "clang/Analysis/FlowSensitive/Transfer.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/raw_ostream.h"
Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -83,6 +83,11 @@
   if (DeclToLocSizeBefore != DeclToLoc.size())
 Effect = LatticeJoinEffect::Changed;
 
+  const unsigned ExprToLocSizeBefore = ExprToLoc.size();
+  ExprToLoc = intersectDenseMaps(ExprToLoc, Other.ExprToLoc);
+  if (ExprToLocSizeBefore != ExprToLoc.size())
+Effect = LatticeJoinEffect::Changed;
+
   // FIXME: Add support for joining distinct values that are assigned to the
   // same storage locations in `LocToVal` and `Other.LocToVal`.
   const unsigned LocToValSizeBefore = LocToVal.size();


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1828,4 +1828,41 @@
   });
 }
 
+TEST_F(TransferTest, VarDeclInDoWhile) {
+  std::string Code = R"(
+void target(int *Foo) {
+  do {
+int Bar = *Foo;
+  } while (true);
+  (void)0;
+  /*[[p]]*/
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const auto *FooVal =
+cast(Env.getValue(*FooDecl, SkipPast::None));
+const auto *FooPointeeVal =
+cast(Env.getValue(FooVal->getPointeeLoc()));
+
+const auto *BarVal = dyn_cast_or_null(
+Env.getValue(*BarDecl, SkipPast::None));
+ASSERT_THAT(BarVal, NotNull());
+
+EXPECT_EQ(BarVal, FooPointeeVal);
+  });
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
==

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev marked an inline comment as done.
sgatev added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:49
+  // in tests.
+  std::set Preds;
   Preds.insert(Block.pred_begin(), Block.pred_end());

xazax.hun wrote:
> sgatev wrote:
> > xazax.hun wrote:
> > > sgatev wrote:
> > > > xazax.hun wrote:
> > > > > xazax.hun wrote:
> > > > > > Are we sure that the memory addresses of CFGBlocks are stable 
> > > > > > enough for a deterministic order? Alternatively, we could use the 
> > > > > > block ids for the ordering.
> > > > > Also, could you describe where the flakiness is originated from? 
> > > > > Naively, I'd expect that the order in which we process the 
> > > > > predecessors should not change the results of the analysis.
> > > > You're right, using block ids for ordering is better. I updated the 
> > > > code.
> > > > 
> > > > > Also, could you describe where the flakiness is originated from?
> > > > 
> > > > Say we have a block `B1` with predecessors `B2` and `B3`. Let the 
> > > > environment of `B2` after evaluating all of its statements is `B2Env = 
> > > > { Expr1 -> Loc1 }` and the environment of `B3` after evaluating all of 
> > > > its statement is `B3Env = { Expr2 -> Loc2 }` where `ExprX -> LocX` 
> > > > refers to a particular mapping of storage locations to expressions.
> > > > 
> > > > What we want for the input environment of `B1` is `{}` because `B2Env` 
> > > > and `B3Env` do not contain common assignments of storage locations to 
> > > > expressions. What we got before this patch is either `B2Env.join(B3Env) 
> > > > = { Expr1 -> Loc1 }` or `B3Env.join(B2Env) = { Expr2 -> Loc2 }`.
> > > > 
> > > > Without deterministic ordering of predecessors the test that I'm 
> > > > introducing in this patch is flaky.
> > > > What we got before this patch is either B2Env.join(B3Env) = { Expr1 -> 
> > > > Loc1 } or B3Env.join(B2Env) = { Expr2 -> Loc2 }.
> > > 
> > > I think I'm still missing something. With this patch, wouldn't both 
> > > B2Env.join(B3Env) and B3Env.join(B2Env) produce the empty environment? If 
> > > that is the case, do we still care about a deterministic order?
> > > 
> > > 
> > > 
> > That's right. With the patch in `DataflowEnvironment.cpp` the particular 
> > order of predecessors doesn't affect the result. However, one of the 
> > properties that I'm looking for in tests is being able to remove 
> > functionality from the code and have the tests that exercise this 
> > functionality fail. This won't necessarily be the case here if the order 
> > wasn't deterministic. I don't have a strong preference so please let me 
> > know if you have concerns about it. I should also note that we expect all 
> > of this to be removed once temporary destructors are handled better in the 
> > CFG.
> Strictly speaking, making this deterministic is not a requirement, it should 
> not have any observable effect for the end user. On the other hand, we could 
> think of this non-determinism as a feature. A well behaved analysis should 
> produce the same answer regardless of the order in which we process the 
> nodes. (This requirement follows from the algebraic properties of the join 
> operation.) So in the future I would even anticipate a feature that 
> deliberately randomize the order to ensure that the clients are well behaved.
> 
> I think eliminating this non-determinism could potentially mask bugs in the 
> future and also it requires extra code. I think I prefer the original version 
> until we see some evidence that determinism is desired. 
Sure. Reverted that part.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

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

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added a comment.

Thanks, this looks good to me!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

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

[PATCH] D116786: [clangd] Add designator inlay hints for initializer lists.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D116786#3257932 , @kadircet wrote:

>> Any ideas? :-(
>
> I've got a feeling that, this should also be annoying in the case of function 
> calls (especially when there's only one overload)? Maybe we should just 
> debounce the inlayhint requests (by saying contents modified to the clients)?

This seems like the right track, but I'm not sure rejecting requests 
specifically is the right answer. Two reasons:

1. This requires careful impl on the client side. LSP has been amended to 
greatly discourage contentmodified. We still send it heuristically, but there's 
a capability to opt out of this and vscode sets it.

(As long as this is a custom protocol we can say what we want, but it won't be 
forever).

2. Choosing which requests to respond to is hard, stateful work.

This isn't the drop-for-efficiency situation where the queue is full, this 
behavior is most annoying when the server is able to keep up with keystrokes. 
And the errors that cause this may not be trivially brief "i'm in the middle of 
typing a word" anyway.
Really you want to work out if this is a "good" request based on the AST. And 
in fact the analysis you'll do looks a lot like actually generating the hints, 
and probably comparing with the last ones. Then we throw them all away?!

---

I'd suggest something slightly different: we compute inlay hints, heuristically 
merge with some previous state, and return the merged results.
Heuristics are something like:

- generally prefer freshly computed hints
- be willing to add old ones where newer ones are missing
- be willing to use older ones where code has changed near the hints (but not 
when they overlap!)

(There's not much here that's specific to inlay hints vs other decorations tied 
to ranges - certainly we could/should do this for semantictokens too, and 
documentSymbols, ...)

---

A variation on this idea is to compute these decorations frequently but 
"whenever we like" and always serve them from this cache, just patching them 
for changes in the source code.
This gives us more control of when the analyses run, maybe there's a lot of 
extra efficiency here. But I think the cache still needs stateful updates to 
solve this bug, unless we have *great* heuristics for "whenever we like".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116786

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

[clang] 35737df - [Clang][AArch64][ARM] Unaligned Access Warning Added

[Mubashar Ahmad via cfe-commits]

Author: Mubashar Ahmad
Date: 2022-01-20T14:12:49Z
New Revision: 35737df4dcd28534bd3090157c224c19b501278a

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

LOG: [Clang][AArch64][ARM] Unaligned Access Warning Added

Added warning for potential cases of
unaligned access when option
-mno-unaligned-access has been specified

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

Added: 
clang/test/Sema/test-wunaligned-access.c
clang/test/Sema/test-wunaligned-access.cpp

Modified: 
clang/include/clang/Basic/DiagnosticASTKinds.td
clang/include/clang/Basic/DiagnosticGroups.td
clang/lib/AST/RecordLayoutBuilder.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.h
clang/lib/Driver/ToolChains/Arch/ARM.cpp
clang/lib/Driver/ToolChains/Clang.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticASTKinds.td 
b/clang/include/clang/Basic/DiagnosticASTKinds.td
index d788c85179142..a89bdff1a10c2 100644
--- a/clang/include/clang/Basic/DiagnosticASTKinds.td
+++ b/clang/include/clang/Basic/DiagnosticASTKinds.td
@@ -590,4 +590,9 @@ def warn_padded_struct_size : Warning<
   InGroup, DefaultIgnore;
 def warn_unnecessary_packed : Warning<
   "packed attribute is unnecessary for %0">, InGroup, DefaultIgnore;
+
+// -Wunaligned-access
+def warn_unaligned_access : Warning<
+  "field %1 within %0 is less aligned than %2 and is usually due to %0 being "
+  "packed, which can lead to unaligned accesses">, InGroup, 
DefaultIgnore;
 }

diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index 1bc879a68a8c7..608e16147b1cd 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -543,6 +543,7 @@ def ExplicitInitializeCall : 
DiagGroup<"explicit-initialize-call">;
 def OrderedCompareFunctionPointers : 
DiagGroup<"ordered-compare-function-pointers">;
 def Packed : DiagGroup<"packed">;
 def Padded : DiagGroup<"padded">;
+def UnalignedAccess : DiagGroup<"unaligned-access">;
 
 def PessimizingMove : DiagGroup<"pessimizing-move">;
 def ReturnStdMove : DiagGroup<"return-std-move">;

diff  --git a/clang/lib/AST/RecordLayoutBuilder.cpp 
b/clang/lib/AST/RecordLayoutBuilder.cpp
index 3e39ec1c718d1..61a30ead165ef 100644
--- a/clang/lib/AST/RecordLayoutBuilder.cpp
+++ b/clang/lib/AST/RecordLayoutBuilder.cpp
@@ -2021,6 +2021,7 @@ void ItaniumRecordLayoutBuilder::LayoutField(const 
FieldDecl *D,
   CharUnits UnpackedFieldAlign =
   !DefaultsToAIXPowerAlignment ? FieldAlign : PreferredAlign;
   CharUnits UnpackedFieldOffset = FieldOffset;
+  CharUnits OriginalFieldAlign = UnpackedFieldAlign;
 
   if (FieldPacked) {
 FieldAlign = CharUnits::One();
@@ -2105,6 +2106,22 @@ void ItaniumRecordLayoutBuilder::LayoutField(const 
FieldDecl *D,
   // Remember max struct/class ABI-specified alignment.
   UnadjustedAlignment = std::max(UnadjustedAlignment, FieldAlign);
   UpdateAlignment(FieldAlign, UnpackedFieldAlign, PreferredAlign);
+
+  // For checking the alignment of inner fields against
+  // the alignment of its parent record.
+  if (const RecordDecl *RD = D->getParent()) {
+// Check if packed attribute or pragma pack is present.
+if (RD->hasAttr() || !MaxFieldAlignment.isZero())
+  if (FieldAlign < OriginalFieldAlign)
+if (D->getType()->isRecordType()) {
+  // If the offset is a multiple of the alignment of
+  // the type, raise the warning.
+  // TODO: Takes no account the alignment of the outer struct
+  if (FieldOffset % OriginalFieldAlign != 0)
+Diag(D->getLocation(), diag::warn_unaligned_access)
+<< Context.getTypeDeclType(RD) << D->getName() << D->getType();
+}
+  }
 }
 
 void ItaniumRecordLayoutBuilder::FinishLayout(const NamedDecl *D) {

diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index 9ffb5d73b2aad..89a77a368ef02 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -221,6 +221,7 @@ getAArch64MicroArchFeaturesFromMcpu(const Driver &D, 
StringRef Mcpu,
 void aarch64::getAArch64TargetFeatures(const Driver &D,
const llvm::Triple &Triple,
const ArgList &Args,
+   llvm::opt::ArgStringList &CmdArgs,
std::vector &Features,
bool ForAS) {
   Arg *A;
@@ -464,10 +465,16 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
 
   if (Arg *A = Args.getLastArg(options::OPT_mno_unaligned_access,
options::

[PATCH] D116221: [AArch64][ARM][Clang] Unaligned Access Warning Added

[Mubashar Ahmad 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 rG35737df4dcd2: [Clang][AArch64][ARM] Unaligned Access Warning 
Added (authored by mubashar_).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116221

Files:
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.h
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Sema/test-wunaligned-access.c
  clang/test/Sema/test-wunaligned-access.cpp

Index: clang/test/Sema/test-wunaligned-access.cpp
===
--- /dev/null
+++ clang/test/Sema/test-wunaligned-access.cpp
@@ -0,0 +1,274 @@
+// RUN: %clang_cc1 %s -triple=armv7-none-none-eabi -verify -Wunaligned-access -S -emit-llvm -o %t
+// REQUIRES: arm-registered-target
+//
+// This test suite tests the warning triggered by the -Wunaligned-access option.
+// The warning occurs when a struct or other type of record contains a field
+// that is itself a record. The outer record must be a packed structure, while
+// while the inner record must be unpacked. This is the fundamental condition
+// for the warning to be triggered. Some of these tests may have three layers.
+//
+// The command line option -fsyntax-only is not used as Clang needs to be
+// forced to layout the structs used in this test.
+// The triple in the command line above is used for the assumptions about
+// size and alignment of types.
+
+// Packed-Unpacked Tests (No Pragma)
+
+struct T1 {
+  char a;
+  int b;
+};
+
+struct __attribute__((packed)) U1 {
+  char a;
+  T1 b; // expected-warning {{field b within 'U1' is less aligned than 'T1' and is usually due to 'U1' being packed, which can lead to unaligned accesses}}
+  int c;
+};
+
+struct __attribute__((packed)) U2 {
+  char a;
+  T1 b __attribute__((aligned(4)));
+  int c;
+};
+
+struct __attribute__((packed)) U3 {
+  char a;
+  char b;
+  short c;
+  T1 d;
+};
+
+struct __attribute__((packed)) U4 {
+  T1 a;
+  int b;
+};
+
+struct __attribute__((aligned(4), packed)) U5 {
+  char a;
+  T1 b; // expected-warning {{field b within 'U5' is less aligned than 'T1' and is usually due to 'U5' being packed, which can lead to unaligned accesses}}
+  int c;
+};
+
+struct __attribute__((aligned(4), packed)) U6 {
+  char a;
+  char b;
+  short c;
+  T1 d;
+};
+
+// Packed-Unpacked Tests with Pragma
+
+#pragma pack(push, 1)
+
+struct __attribute__((packed)) U7 {
+  char a;
+  T1 b; // expected-warning {{field b within 'U7' is less aligned than 'T1' and is usually due to 'U7' being packed, which can lead to unaligned accesses}}
+  int c;
+};
+
+struct __attribute__((packed)) U8 {
+  char a;
+  T1 b __attribute__((aligned(4))); // expected-warning {{field b within 'U8' is less aligned than 'T1' and is usually due to 'U8' being packed, which can lead to unaligned accesses}}
+  int c;
+};
+
+struct __attribute__((aligned(4))) U9 {
+  char a;
+  T1 b; // expected-warning {{field b within 'U9' is less aligned than 'T1' and is usually due to 'U9' being packed, which can lead to unaligned accesses}}
+  int c;
+};
+
+struct U10 {
+  char a;
+  T1 b; // expected-warning {{field b within 'U10' is less aligned than 'T1' and is usually due to 'U10' being packed, which can lead to unaligned accesses}}
+  int c;
+};
+
+#pragma pack(pop)
+
+// Packed-Packed Tests
+
+struct __attribute__((packed)) T2 {
+  char a;
+  int b;
+};
+
+struct __attribute__((packed)) U11 {
+  char a;
+  T2 b;
+  int c;
+};
+
+#pragma pack(push, 1)
+struct U12 {
+  char a;
+  T2 b;
+  int c;
+};
+#pragma pack(pop)
+
+// Unpacked-Packed Tests
+
+struct U13 {
+  char a;
+  T2 b;
+  int c;
+};
+
+struct U14 {
+  char a;
+  T2 b __attribute__((aligned(4)));
+  int c;
+};
+
+// Unpacked-Unpacked Test
+
+struct T3 {
+  char a;
+  int b;
+};
+
+struct U15 {
+  char a;
+  T3 b;
+  int c;
+};
+
+// Packed-Packed-Unpacked Test (No pragma)
+
+struct __attribute__((packed)) A1 {
+  char a;
+  T1 b; // expected-warning {{field b within 'A1' is less aligned than 'T1' and is usually due to 'A1' being packed, which can lead to unaligned accesses}}
+};
+
+struct __attribute__((packed)) U16 {
+  char a;
+  A1 b;
+  int c;
+};
+
+struct __attribute__((packed)) A2 {
+  char a;
+  T1 b __attribute__((aligned(4)));
+};
+
+struct __attribute__((packed)) U17 {
+  char a;
+  A2 b; // expected-warning {{field b within 'U17' is less aligned than 'A2' and is usually due to 'U17' being packed, which can lead to unaligned accesses}}
+  int c;
+};
+
+// Packed-Unpacked-Packed tests
+
+struct A3 {
+  char a;
+  T2 b;
+};
+
+struct __attribute__((packed)) U18 {
+  char a;
+  A3 b;
+  int c;
+};
+
+struct A4 {
+  char a;
+  T2 b;
+  int c;
+

[PATCH] D116088: [compiler-rt] Implement ARM atomic operations for architectures without SMP support

[Pavel Kosov via Phabricator via cfe-commits]

kpdev42 added a comment.

In D116088#3254400 , @joerg wrote:

> Correct me if I'm wrong, but I don't think this stubs are async signal safe 
> nor will they work for preemptive multitasking systems?

Those stubs are basically cas loops 
(https://en.wikipedia.org/wiki/Compare-and-swap) which are not much different 
from their SMP counterparts, except memory sync ops are not used. This should 
work normally in case of preemption (preempting thread will spend its quota in 
busy-wait). Signal can be a problem if it preempt a thread executing atomic op, 
but I wonder if SMP code handles this


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116088

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

[PATCH] D117613: [ASTMatchers] Add `isConsteval` matcher

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM with a minor adjustment to the documentation.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:5173
 
+/// Matches consteval function declarations and if consteval.
+///

Needs to be re-wrapped to 80-col, mostly wanting to call out the `if ! 
consteval` bit more explicitly.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:5179
+///   consteval int bar();
+///   void baz() { if consteval {} }
+/// \endcode

aaron.ballman wrote:
> cor3ntin wrote:
> > aaron.ballman wrote:
> > > cor3ntin wrote:
> > > > Izaron wrote:
> > > > > aaron.ballman wrote:
> > > > > > It'd be good to show an example of:
> > > > > > ```
> > > > > > if ! consteval {}
> > > > > > 
> > > > > > if ! consteval {} else {}
> > > > > > ```
> > > > > > as well so users know what to expect.
> > > > > > 
> > > > > > Should there be a matcher so users can distinguish between `if 
> > > > > > consteval` and `if ! consteval`?
> > > > > > 
> > > > > > Test cases for these sort of things would also be appreciated.
> > > > > Thanks!
> > > > > > Should there be a matcher so users can distinguish between `if 
> > > > > > consteval` and `if ! consteval`?
> > > > > This is an interesting question. I wonder how intensively `if ! 
> > > > > consteval` is ever going to be used in real life to make a unique 
> > > > > matcher for it? I can't make up a hypothetical checker that would 
> > > > > need it.
> > > > > 
> > > > > Let's see what other fellow reviewers think about it =)
> > > > That's a good question.
> > > > Maybe we can add it later if there is a need?
> > > > I suspect that if we need 2, we need 3, `hasConsteval`, 
> > > > `hasNegatedConsteval`, `hasNonNegatedConsteval`
> > > > 
> > > > Until a need present itself,  maybe one is enough
> > > > This is an interesting question. I wonder how intensively if ! 
> > > > consteval is ever going to be used in real life to make a unique 
> > > > matcher for it? I can't make up a hypothetical checker that would need 
> > > > it.
> > > 
> > > That's not the salient question. I'm more worried that the current 
> > > interface is confusing and not easy to extend. There's no motivation in 
> > > the review for why this support is needed, and we tend to err on the side 
> > > of being conservative with matcher interfaces (we only add them when 
> > > they're necessary and generally useful, otherwise users can use local 
> > > matchers).
> > > 
> > > I think the matcher isn't well designed for `IfStmt` and we should drop 
> > > support for that initially, and only focus on support for `FunctionDecl` 
> > > where the behavior is more clear. Then we can decide what the correct 
> > > interface is for `IfStmt` once we have a better picture of how the 
> > > matcher is expected to be used and a more general design for it.
> > That's not the salient question. I'm more worried that the current 
> > interface is confusing and not easy to extend. There's no motivation in the 
> > review for why this support is needed, and we tend to err on the side of 
> > being conservative with matcher interfaces (we only add them when they're 
> > necessary and generally useful, otherwise users can use local matchers).
> > 
> > Arguably, there is one for `if constexpr` and both of them should be 
> > symmetric. Introducing asymmetry for no good reason seems wrong. I assume 
> > that there was a motivation initially?
> >  
> > > I think the matcher isn't well designed for `IfStmt` and we should drop 
> > > support for that initially, and only focus on support for `FunctionDecl` 
> > > where the behavior is more clear. Then we can decide what the correct 
> > > interface is for `IfStmt` once we have a better picture of how the 
> > > matcher is expected to be used and a more general design for it.
> > 
> > 
> > This was initially my gut feeling, however there is no separate matcher for 
> > `if constexpr(false)` and `if constexpr (true)`, so I don't think that `if 
> > ! consteval` needs to be treated differently here.
> > Either way, i don't think adding one hurts
> > 
> > 
> > 
> > 
> You can match over the expression in `if constexpr` to determine whether it's 
> true or false (at least in theory, we probably need some better matchers 
> around constant expression value comparisons), but you cannot match over the 
> syntax of `if ! consteval` vs `if consteval`, so I see them as being 
> different cases in that regard.
I spoke with @cor3ntin off-list a bit about this and am now more comfortable. 
What was bothering me was that:
```
if consteval {
}

if ! consteval {
}
```
are both matched by `ifStmt(isConsteval())` and matching on the second case 
looks downright odd to me. However, that is the interface of our AST. We can 
add `isNonNegatedConsteval()` and `isNegatedConsteval()` as matchers when we 
need to distinguish between t

[clang] c95cb4d - [clang][dataflow] Intersect ExprToLoc when joining environments

[Stanislav Gatev via cfe-commits]

Author: Stanislav Gatev
Date: 2022-01-20T14:30:17Z
New Revision: c95cb4de1b6674e52aebdb7d02c6431843001282

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

LOG: [clang][dataflow] Intersect ExprToLoc when joining environments

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

Reviewed-by: xazax.hun

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

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index e1d420fb55b82..6fbc3ec42465c 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -83,6 +83,11 @@ LatticeJoinEffect Environment::join(const Environment 
&Other) {
   if (DeclToLocSizeBefore != DeclToLoc.size())
 Effect = LatticeJoinEffect::Changed;
 
+  const unsigned ExprToLocSizeBefore = ExprToLoc.size();
+  ExprToLoc = intersectDenseMaps(ExprToLoc, Other.ExprToLoc);
+  if (ExprToLocSizeBefore != ExprToLoc.size())
+Effect = LatticeJoinEffect::Changed;
+
   // FIXME: Add support for joining distinct values that are assigned to the
   // same storage locations in `LocToVal` and `Other.LocToVal`.
   const unsigned LocToValSizeBefore = LocToVal.size();

diff  --git a/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp 
b/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
index 538cdce206b2f..3782f0f5f69ac 100644
--- a/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ b/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -23,6 +23,7 @@
 #include "clang/Analysis/FlowSensitive/Transfer.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/raw_ostream.h"

diff  --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index 5979870f858b1..c1eaf281ddc49 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1828,4 +1828,41 @@ TEST_F(TransferTest, 
VarDeclInitAssignConditionalOperator) {
   });
 }
 
+TEST_F(TransferTest, VarDeclInDoWhile) {
+  std::string Code = R"(
+void target(int *Foo) {
+  do {
+int Bar = *Foo;
+  } while (true);
+  (void)0;
+  /*[[p]]*/
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const auto *FooVal =
+cast(Env.getValue(*FooDecl, SkipPast::None));
+const auto *FooPointeeVal =
+cast(Env.getValue(FooVal->getPointeeLoc()));
+
+const auto *BarVal = dyn_cast_or_null(
+Env.getValue(*BarDecl, SkipPast::None));
+ASSERT_THAT(BarVal, NotNull());
+
+EXPECT_EQ(BarVal, FooPointeeVal);
+  });
+}
+
 } // namespace



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

[PATCH] D117754: [clang][dataflow] Intersect ExprToLoc when joining environments

[Stanislav Gatev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc95cb4de1b66: [clang][dataflow] Intersect ExprToLoc when 
joining environments (authored by sgatev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117754

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1828,4 +1828,41 @@
   });
 }
 
+TEST_F(TransferTest, VarDeclInDoWhile) {
+  std::string Code = R"(
+void target(int *Foo) {
+  do {
+int Bar = *Foo;
+  } while (true);
+  (void)0;
+  /*[[p]]*/
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const auto *FooVal =
+cast(Env.getValue(*FooDecl, SkipPast::None));
+const auto *FooPointeeVal =
+cast(Env.getValue(FooVal->getPointeeLoc()));
+
+const auto *BarVal = dyn_cast_or_null(
+Env.getValue(*BarDecl, SkipPast::None));
+ASSERT_THAT(BarVal, NotNull());
+
+EXPECT_EQ(BarVal, FooPointeeVal);
+  });
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -23,6 +23,7 @@
 #include "clang/Analysis/FlowSensitive/Transfer.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/raw_ostream.h"
Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -83,6 +83,11 @@
   if (DeclToLocSizeBefore != DeclToLoc.size())
 Effect = LatticeJoinEffect::Changed;
 
+  const unsigned ExprToLocSizeBefore = ExprToLoc.size();
+  ExprToLoc = intersectDenseMaps(ExprToLoc, Other.ExprToLoc);
+  if (ExprToLocSizeBefore != ExprToLoc.size())
+Effect = LatticeJoinEffect::Changed;
+
   // FIXME: Add support for joining distinct values that are assigned to the
   // same storage locations in `LocToVal` and `Other.LocToVal`.
   const unsigned LocToValSizeBefore = LocToVal.size();


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1828,4 +1828,41 @@
   });
 }
 
+TEST_F(TransferTest, VarDeclInDoWhile) {
+  std::string Code = R"(
+void target(int *Foo) {
+  do {
+int Bar = *Foo;
+  } while (true);
+  (void)0;
+  /*[[p]]*/
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const auto *FooVal =
+cast(Env.getValue(*FooDecl, SkipPast::None));
+const auto *FooPointeeVal =
+cast(Env.getValue(FooVal->getPointeeLoc()));
+
+const auto *BarVal = dyn_cast_or_null(
+Env.getValue(*BarDecl, SkipPast::None));
+ASSERT_THAT(BarVal, NotNull());
+
+EXPECT_EQ(BarVal, FooPointeeVal);
+  });
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalys

[PATCH] D112613: [Clang][RISCV] Change TARGET_BUILTIN to require zve32x for vector instruction

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng accepted this revision.
kito-cheng 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/D112613/new/

https://reviews.llvm.org/D112613

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

[PATCH] D117717: [clang] Ignore -fconserve-stack

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added reviewers: steakhal, NoQ, martong, Szelethus.
aaron.ballman added a comment.
Herald added a subscriber: rnkovacs.

Adding some reviewers from the Clang Static Analyzer side of things.

In D117717#3256243 , @nathanchance 
wrote:

> Should we just tell people to run `scan-build` only with `clang`? How 
> `ccc-analyzer` works seems weird to me but I assume some of the flag 
> machinery that is present here is for that reason?

FWIW, I don't have good impressions of using scan-build. It attempts to 
interpose the analysis compilation with the real execution of the compiler, but 
it has effectively no intelligence with that interposition and ends up passing 
along all the options to Clang. Other tools I've worked on in this realm do far 
more complicated modelling of compiler options to make that interposition work 
for arbitrary compilers. I'm not convinced scan-build works for anything but 
Clang or extremely simple GCC invocations (but doesn't work very well at all 
with other compilers like ICC, etc because the compiler options get farther 
away from what Clang understands).

I'm not certain whether that warrants telling people it only works with Clang 
or not, but I (personally) wouldn't be opposed to that. (I also wouldn't be 
opposed to ridding ourselves of this script -- it's the only Perl script we 
have in the project which is a significant pain for those of us on Windows.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117717

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

[clang] 14c5fd9 - [Clang][RISCV] Change TARGET_BUILTIN to require zve32x for vector instruction

[via cfe-commits]

Author: eopXD
Date: 2022-01-20T06:53:48-08:00
New Revision: 14c5fd920b0e4e05c5deed358af47707e579dd6d

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

LOG: [Clang][RISCV] Change TARGET_BUILTIN to require zve32x for vector 
instruction

According to v-spec v1.0, `zve-32x` is the new minimum extension to include
to have vector instructions.

Reviewed By: kito-cheng

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

Added: 


Modified: 
clang/utils/TableGen/RISCVVEmitter.cpp

Removed: 




diff  --git a/clang/utils/TableGen/RISCVVEmitter.cpp 
b/clang/utils/TableGen/RISCVVEmitter.cpp
index 08724fb35397..d3f1d63185f4 100644
--- a/clang/utils/TableGen/RISCVVEmitter.cpp
+++ b/clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@ void RVVEmitter::createBuiltins(raw_ostream &OS) {
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =



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

[PATCH] D112613: [Clang][RISCV] Change TARGET_BUILTIN to require zve32x for vector instruction

[Yueh-Ting Chen via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG14c5fd920b0e: [Clang][RISCV] Change TARGET_BUILTIN to 
require zve32x for vector instruction (authored by eopXD).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112613

Files:
  clang/utils/TableGen/RISCVVEmitter.cpp


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1027,7 +1027,7 @@
 
   OS << "#if defined(TARGET_BUILTIN) && !defined(RISCVV_BUILTIN)\n";
   OS << "#define RISCVV_BUILTIN(ID, TYPE, ATTRS) TARGET_BUILTIN(ID, TYPE, "
-"ATTRS, \"experimental-v\")\n";
+"ATTRS, \"experimental-zve32x\")\n";
   OS << "#endif\n";
   for (auto &Def : Defs) {
 auto P =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117777: [OpenMP] Don't pass empty files to nvlink

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D11

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

[PATCH] D117232: [clang] Respect -Wdeclaration-after-statement with C99 or later

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Can you also add a release note about the change?




Comment at: clang/test/Sema/warn-mixed-decls-code.c:1-3
+// RUN: %clang_cc1 -std=c89 -fsyntax-only -verify -Wall -Wno-comment -DSILENCE 
%s
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -verify -Wall -pedantic -DSILENCE %s
+// RUN: %clang_cc1 -std=c11 -fsyntax-only -verify -Wall -pedantic -DSILENCE %s





Comment at: clang/test/Sema/warn-mixed-decls-code.c:7
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -verify 
-Wdeclaration-after-statement %s
+// RUN: %clang_cc1 -std=c11 -fsyntax-only -verify 
-Wdeclaration-after-statement %s
+





Comment at: clang/test/Sema/warn-mixed-decls-code.c:9-11
+#ifdef SILENCE
+  // expected-no-diagnostics
+#endif





Comment at: clang/test/Sema/warn-mixed-decls-code.c:18-21
+  int b;
+#ifndef SILENCE
+  // expected-warning@-2 {{mixing declarations and code}}
+#endif




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117232

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

[PATCH] D117787: [NVPTX] abs, neg, min, max intrinsics for half types

[Jakub Chlanda via Phabricator via cfe-commits]

jchlanda created this revision.
jchlanda added reviewers: jholewinski, steffenlarsen, asavonic, sebastian-ne.
Herald added a subscriber: hiraditya.
jchlanda requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, jdoerfert.
Herald added projects: clang, LLVM.

This patch extends `abs` and `neg` intrinsics to support `bf16` and `bf16x2` 
data formats.
Extends `min` and `max` to support `.NaN` modifier and `f16`, `f16x2`, `bf16` 
and `bf16x2` data formats.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117787

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGen/builtins-nvptx-native-half-type.c
  clang/test/CodeGen/builtins-nvptx.c
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/lib/Target/NVPTX/NVPTXInstrInfo.td
  llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
  llvm/lib/Target/NVPTX/NVPTXTargetTransformInfo.cpp
  llvm/test/CodeGen/NVPTX/math-intrins-sm80-ptx70-instcombine.ll
  llvm/test/CodeGen/NVPTX/math-intrins-sm80-ptx70.ll

Index: llvm/test/CodeGen/NVPTX/math-intrins-sm80-ptx70.ll
===
--- /dev/null
+++ llvm/test/CodeGen/NVPTX/math-intrins-sm80-ptx70.ll
@@ -0,0 +1,260 @@
+; RUN: llc < %s -march=nvptx64 -mcpu=sm_80 -mattr=+ptx70 | FileCheck %s
+
+declare i16 @llvm.nvvm.abs.bf16(i16)
+declare i32 @llvm.nvvm.abs.bf16x2(i32)
+declare i16 @llvm.nvvm.neg.bf16(i16)
+declare i32 @llvm.nvvm.neg.bf16x2(i32)
+
+declare float @llvm.nvvm.fmin.nan.f(float, float)
+declare float @llvm.nvvm.fmin.ftz.nan.f(float, float)
+declare half @llvm.nvvm.fmin.f16(half, half)
+declare half @llvm.nvvm.fmin.ftz.f16(half, half)
+declare half @llvm.nvvm.fmin.nan.f16(half, half)
+declare half @llvm.nvvm.fmin.ftz.nan.f16(half, half)
+declare <2 x half> @llvm.nvvm.fmin.f16x2(<2 x half>, <2 x half>)
+declare <2 x half> @llvm.nvvm.fmin.ftz.f16x2(<2 x half>, <2 x half>)
+declare <2 x half> @llvm.nvvm.fmin.nan.f16x2(<2 x half>, <2 x half>)
+declare <2 x half> @llvm.nvvm.fmin.ftz.nan.f16x2(<2 x half>, <2 x half>)
+declare i16 @llvm.nvvm.fmin.bf16(i16, i16)
+declare i16 @llvm.nvvm.fmin.nan.bf16(i16, i16)
+declare i32 @llvm.nvvm.fmin.bf16x2(i32, i32)
+declare i32 @llvm.nvvm.fmin.nan.bf16x2(i32, i32)
+
+declare float @llvm.nvvm.fmax.nan.f(float, float)
+declare float @llvm.nvvm.fmax.ftz.nan.f(float, float)
+declare half @llvm.nvvm.fmax.f16(half, half)
+declare half @llvm.nvvm.fmax.ftz.f16(half, half)
+declare half @llvm.nvvm.fmax.nan.f16(half, half)
+declare half @llvm.nvvm.fmax.ftz.nan.f16(half, half)
+declare <2 x half> @llvm.nvvm.fmax.f16x2(<2 x half>, <2 x half>)
+declare <2 x half> @llvm.nvvm.fmax.ftz.f16x2(<2 x half>, <2 x half>)
+declare <2 x half> @llvm.nvvm.fmax.nan.f16x2(<2 x half>, <2 x half>)
+declare <2 x half> @llvm.nvvm.fmax.ftz.nan.f16x2(<2 x half>, <2 x half>)
+declare i16 @llvm.nvvm.fmax.bf16(i16, i16)
+declare i16 @llvm.nvvm.fmax.nan.bf16(i16, i16)
+declare i32 @llvm.nvvm.fmax.bf16x2(i32, i32)
+declare i32 @llvm.nvvm.fmax.nan.bf16x2(i32, i32)
+
+; CHECK-LABEL: abs_bf16
+define i16 @abs_bf16(i16 %0) {
+  ; CHECK: abs.bf16
+  %res = call i16 @llvm.nvvm.abs.bf16(i16 %0);
+  ret i16 %res
+}
+
+; CHECK-LABEL: abs_bf16x2
+define i32 @abs_bf16x2(i32 %0) {
+  ; CHECK: abs.bf16x2
+  %res = call i32 @llvm.nvvm.abs.bf16x2(i32 %0);
+  ret i32 %res
+}
+
+; CHECK-LABEL: neg_bf16
+define i16 @neg_bf16(i16 %0) {
+  ; CHECK: neg.bf16
+  %res = call i16 @llvm.nvvm.neg.bf16(i16 %0);
+  ret i16 %res
+}
+
+; CHECK-LABEL: neg_bf16x2
+define i32 @neg_bf16x2(i32 %0) {
+  ; CHECK: neg.bf16x2
+  %res = call i32 @llvm.nvvm.neg.bf16x2(i32 %0);
+  ret i32 %res
+}
+
+; CHECK-LABEL: fmin_nan_f
+define float @fmin_nan_f(float %0, float %1) {
+  ; CHECK: min.NaN.f32
+  %res = call float @llvm.nvvm.fmin.nan.f(float %0, float %1);
+  ret float %res
+}
+
+; CHECK-LABEL: fmin_ftz_nan_f
+define float @fmin_ftz_nan_f(float %0, float %1) {
+  ; CHECK: min.ftz.NaN.f32
+  %res = call float @llvm.nvvm.fmin.ftz.nan.f(float %0, float %1);
+  ret float %res
+}
+
+; CHECK-LABEL: fmin_f16
+define half @fmin_f16(half %0, half %1) {
+  ; CHECK: min.f16
+  %res = call half @llvm.nvvm.fmin.f16(half %0, half %1)
+  ret half %res
+}
+
+; CHECK-LABEL: fmin_ftz_f16
+define half @fmin_ftz_f16(half %0, half %1) {
+  ; CHECK: min.ftz.f16
+  %res = call half @llvm.nvvm.fmin.ftz.f16(half %0, half %1)
+  ret half %res
+}
+
+; CHECK-LABEL: fmin_nan_f16
+define half @fmin_nan_f16(half %0, half %1) {
+  ; CHECK: min.NaN.f16
+  %res = call half @llvm.nvvm.fmin.nan.f16(half %0, half %1)
+  ret half %res
+}
+
+; CHECK-LABEL: fmin_ftz_nan_f16
+define half @fmin_ftz_nan_f16(half %0, half %1) {
+  ; CHECK: min.ftz.NaN.f16
+  %res = call half @llvm.nvvm.fmin.ftz.nan.f16(half %0, half %1)
+  ret half %res
+}
+
+; CHECK-LABEL: fmin_f16x2
+define <2 x half> @fmin_f16x2(<2 x half> %0, <2 x half> %1) {
+  ; CHECK: min.f16x2
+  %res = call <2 x half> @llvm.nvvm.fmin.f16x2(<2 x half> %0, <2 x half> %1)
+  ret <2 x half> %res
+}
+
+; CHECK-LABEL: fmin_ftz_f16x2
+define <2 x h

[clang] 3da69fb - [Clang][AArch64][ARM] Unaligned Access Test Fix

[Mubashar Ahmad via cfe-commits]

Author: Mubashar Ahmad
Date: 2022-01-20T15:29:53Z
New Revision: 3da69fb5a26c7bf83320b3b4ad0859be9b47b3fb

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

LOG: [Clang][AArch64][ARM] Unaligned Access Test Fix

Test fixed for the unaligned access warning.

Added: 


Modified: 
clang/test/Sema/test-wunaligned-access.c

Removed: 




diff  --git a/clang/test/Sema/test-wunaligned-access.c 
b/clang/test/Sema/test-wunaligned-access.c
index 55c2149634d1a..909cda45f489b 100644
--- a/clang/test/Sema/test-wunaligned-access.c
+++ b/clang/test/Sema/test-wunaligned-access.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -triple=armv7-none-none-eabi -verify -Wunaligned-access 
-S -emit-llvm
+// RUN: %clang_cc1 %s -triple=armv7-none-none-eabi -verify -Wunaligned-access 
-S -emit-llvm -o %t
 // REQUIRES: arm-registered-target
 //
 // This test suite tests the warning triggered by the -Wunaligned-access 
option.



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

[PATCH] D117566: [clang][lex] Introduce `SearchDirIterator`

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 updated this revision to Diff 401640.
jansvoboda11 added a comment.

Rename the new iterator type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117566

Files:
  clang/include/clang/Lex/HeaderSearch.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/lib/Lex/PPMacroExpansion.cpp

Index: clang/lib/Lex/PPMacroExpansion.cpp
===
--- clang/lib/Lex/PPMacroExpansion.cpp
+++ clang/lib/Lex/PPMacroExpansion.cpp
@@ -1157,9 +1157,9 @@
 /// EvaluateHasIncludeCommon - Process a '__has_include("path")'
 /// or '__has_include_next("path")' expression.
 /// Returns true if successful.
-static bool EvaluateHasIncludeCommon(Token &Tok,
- IdentifierInfo *II, Preprocessor &PP,
- const DirectoryLookup *LookupFrom,
+static bool EvaluateHasIncludeCommon(Token &Tok, IdentifierInfo *II,
+ Preprocessor &PP,
+ SearchDirIterator LookupFrom,
  const FileEntry *LookupFromFile) {
   // Save the location of the current token.  If a '(' is later found, use
   // that location.  If not, use the end of this location instead.
@@ -1260,7 +1260,7 @@
   // issue a diagnostic.
   // FIXME: Factor out duplication with
   // Preprocessor::HandleIncludeNextDirective.
-  const DirectoryLookup *Lookup = PP.GetCurDirLookup();
+  SearchDirIterator Lookup = PP.GetCurDirLookup();
   const FileEntry *LookupFromFile = nullptr;
   if (PP.isInPrimaryFile() && PP.getLangOpts().IsHeaderFile) {
 // If the main file is a header, then it's either for PCH/AST generation,
Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -66,7 +66,7 @@
 
 /// EnterSourceFile - Add a source file to the top of the include stack and
 /// start lexing tokens from it instead of the current buffer.
-bool Preprocessor::EnterSourceFile(FileID FID, const DirectoryLookup *CurDir,
+bool Preprocessor::EnterSourceFile(FileID FID, SearchDirIterator CurDir,
SourceLocation Loc,
bool IsFirstIncludeOfFile) {
   assert(!CurTokenLexer && "Cannot #include a file inside a macro!");
@@ -100,7 +100,7 @@
 /// EnterSourceFileWithLexer - Add a source file to the top of the include stack
 ///  and start lexing tokens from it instead of the current buffer.
 void Preprocessor::EnterSourceFileWithLexer(Lexer *TheLexer,
-const DirectoryLookup *CurDir) {
+SearchDirIterator CurDir) {
 
   // Add the current lexer to the include stack.
   if (CurPPLexer || CurTokenLexer)
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -817,13 +817,13 @@
 
 Optional Preprocessor::LookupFile(
 SourceLocation FilenameLoc, StringRef Filename, bool isAngled,
-const DirectoryLookup *FromDir, const FileEntry *FromFile,
-const DirectoryLookup **CurDirArg, SmallVectorImpl *SearchPath,
+SearchDirIterator FromDir, const FileEntry *FromFile,
+SearchDirIterator *CurDirArg, SmallVectorImpl *SearchPath,
 SmallVectorImpl *RelativePath,
 ModuleMap::KnownHeader *SuggestedModule, bool *IsMapped,
 bool *IsFrameworkFound, bool SkipCache) {
-  const DirectoryLookup *CurDirLocal = nullptr;
-  const DirectoryLookup *&CurDir = CurDirArg ? *CurDirArg : CurDirLocal;
+  SearchDirIterator CurDirLocal = nullptr;
+  SearchDirIterator &CurDir = CurDirArg ? *CurDirArg : CurDirLocal;
 
   Module *RequestingModule = getModuleForLocation(FilenameLoc);
   bool RequestingModuleIsModuleInterface = !SourceMgr.isInMainFile(FilenameLoc);
@@ -877,8 +877,8 @@
   if (FromFile) {
 // We're supposed to start looking from after a particular file. Search
 // the include path until we find that file or run out of files.
-const DirectoryLookup *TmpCurDir = CurDir;
-const DirectoryLookup *TmpFromDir = nullptr;
+SearchDirIterator TmpCurDir = CurDir;
+SearchDirIterator TmpFromDir = nullptr;
 while (Optional FE = HeaderInfo.LookupFile(
Filename, FilenameLoc, isAngled, TmpFromDir, &TmpCurDir,
Includers, SearchPath, RelativePath, RequestingModule,
@@ -1785,7 +1785,7 @@
 /// specifies the file to start searching from.
 void Preprocessor::HandleIncludeDirective(SourceLocation HashLoc,
   Token &IncludeTok,
-  const DirectoryLookup *LookupFrom,
+

[PATCH] D117753: [AArch64] Support for memset tagged intrinsic

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/lib/Headers/arm_acle.h:734
+/* Memory Operations Intrinsics */
+#if __ARM_FEATURE_MOPS && __ARM_FEATURE_MEMORY_TAGGING
+#define __arm_mops_memset_tag(tagged_address, value, size) 
\

Why does this also need MTE? I think the ACLE specifies this intrinsic to be 
available when __ARM_FEATURE_MOPS is defined?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117753

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

[PATCH] D117569: Constexpr not supported with __declspec(dllimport).

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D117569#3257121 , @majnemer wrote:

> I have a question regarding how this work with respect to the dllimport 
> semantics known by the linker.
> IIUC, we will now allow a program like:
>
>   extern int __declspec(dllimport) dll_import_int;
>   constexpr int& dll_import_constexpr_ref = dll_import_int;
>   int& get() {
>   return dll_import_constexpr_ref;
>   }
>
> Here, `get` will load `dll_import_constexpr_ref`. However, what will 
> `dll_import_constexpr_ref` hold? It ought to hold the contents of 
> `__imp_?dll_import_int@@3HA`. However, we can't dereference 
> `__imp_?dll_import_int@@3HA` to get to its contents.

@majnemer Thanks for the review.

This test case doesn't link with MSVC. It will generate this error:
Microsoft (R) Incremental Linker Version 14.29.30133.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test1.exe
test1.obj
test1.obj : error LNK2001: unresolved external symbol "int dll_import_int" 
(?dll_import_int@@3HA)
test1.exe : fatal error LNK1120: 1 unresolved externals

The symbols generated with MSVC are:
07  UNDEF  notype   External | ?dll_import_int@@3HA (int 
dll_import_int)
015  SECT6  notype   Static   | 
?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)

Without this patch this test case errors. With this patch clang will generate 
these symbols:

010  UNDEF  notype   External | __imp_?dll_import_int@@3HA 
(__declspec(dllimport) int dll_import_int)
012  SECT5  notype   External | 
?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)
013  UNDEF  notype   External | ?dll_import_int@@3HA (int 
dll_import_int)

and will error at link time with this error:
test1-f1f63b.o : error LNK2019: unresolved external symbol 
"__declspec(dllimport) int dll_import_int" (__imp_?dll_import_int@@3HA) 
referenced in function "int & __cdecl get(void)" (?get@@YAAEAHXZ)
test1-f1f63b.o : error LNK2001: unresolved external symbol "int dll_import_int" 
(?dll_import_int@@3HA)
a.exe : fatal error LNK1120: 2 unresolved externals

I think that's the behavior expected, right?


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

https://reviews.llvm.org/D117569

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

[PATCH] D117232: [clang] Respect -Wdeclaration-after-statement with C99 or later

[Marco Elver via Phabricator via cfe-commits]

melver added a comment.

Looks like https://reviews.llvm.org/D114787 does the same thing and was 
submitted a week ago.

I'll try to integrate the additional testing you suggested and change this 
patch to improve the implementation to not do the checking if not required as 
it doesn't look entirely cheap.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117232

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

[PATCH] D117787: [NVPTX] abs, neg, min, max intrinsics for half types

[Jakub Chlanda via Phabricator via cfe-commits]

jchlanda abandoned this revision.
jchlanda added a comment.

I need to update this to the upstream, as it was based on intel's fork. 
Abandoning for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117787

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

[PATCH] D117232: [clang] Respect -Wdeclaration-after-statement with C99 or later

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D117232#3258309 , @melver wrote:

> Looks like https://reviews.llvm.org/D114787 does the same thing and was 
> submitted a week ago.
>
> I'll try to integrate the additional testing you suggested and change this 
> patch to improve the implementation to not do the checking if not required as 
> it doesn't look entirely cheap.

I *knew* this seemed super familiar! Sorry that my search through my email 
missed that. :-D Yes, please rebase on trunk and add the improved `isIgnored()` 
check. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117232

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

[PATCH] D117569: Constexpr not supported with __declspec(dllimport).

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 401644.

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

https://reviews.llvm.org/D117569

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/CodeGenCXX/PR19955.cpp
  clang/test/CodeGenCXX/dllimport.cpp
  clang/test/SemaCXX/PR19955.cpp
  clang/test/SemaCXX/dllimport-constexpr.cpp


Index: clang/test/SemaCXX/dllimport-constexpr.cpp
===
--- clang/test/SemaCXX/dllimport-constexpr.cpp
+++ clang/test/SemaCXX/dllimport-constexpr.cpp
@@ -40,7 +40,6 @@
 // constexpr initialization doesn't work for dllimport things.
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (*constexpr_import_func)() = &imported_func;
-// expected-error@+1{{must be initialized by a constant expression}}
 constexpr int *constexpr_import_int = &imported_int;
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (Foo::*constexpr_memptr)() = &Foo::imported_method;
@@ -60,3 +59,8 @@
   // expected-note@+1 {{requested here}}
   StaticConstexpr::g_fp();
 }
+
+void foo() {
+  extern int __declspec(dllimport) dll_import_int;
+  constexpr int& dll_import_constexpr_ref = dll_import_int;
+}
Index: clang/test/SemaCXX/PR19955.cpp
===
--- clang/test/SemaCXX/PR19955.cpp
+++ clang/test/SemaCXX/PR19955.cpp
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -triple i686-mingw32 -verify -std=c++11 %s
 
 extern int __attribute__((dllimport)) var;
-constexpr int *varp = &var; // expected-error {{must be initialized by a 
constant expression}}
+constexpr int *varp = &var;
 
 extern __attribute__((dllimport)) void fun();
 constexpr void (*funp)(void) = &fun; // expected-error {{must be initialized 
by a constant expression}}
Index: clang/test/CodeGenCXX/dllimport.cpp
===
--- clang/test/CodeGenCXX/dllimport.cpp
+++ clang/test/CodeGenCXX/dllimport.cpp
@@ -98,8 +98,8 @@
 USE(inlineStaticLocalsFunc);
 
 // The address of a dllimport global cannot be used in constant initialization.
-// M32-DAG: @"?arr@?1??initializationFunc@@YAPAHXZ@4QBQAHB" = internal global 
[1 x i32*] zeroinitializer
-// GNU-DAG: @_ZZ18initializationFuncvE3arr = internal global [1 x i32*] 
zeroinitializer
+// M32-DAG: @"?arr@?1??initializationFunc@@YAPAHXZ@4QBQAHB" = internal 
constant [1 x i32*] [i32* @"?ExternGlobalDecl@@3HA"]
+// GNU-DAG: @_ZZ18initializationFuncvE3arr = internal constant [1 x i32*] 
[i32* @ExternGlobalDecl]
 int *initializationFunc() {
   static int *const arr[] = {&ExternGlobalDecl};
   return arr[0];
Index: clang/test/CodeGenCXX/PR19955.cpp
===
--- clang/test/CodeGenCXX/PR19955.cpp
+++ clang/test/CodeGenCXX/PR19955.cpp
@@ -6,20 +6,16 @@
 
 extern int *varp;
 int *varp = &var;
-// CHECK-DAG: @"?varp@@3PAHA" = dso_local global i32* null
-// X64-DAG: @"?varp@@3PEAHEA" = dso_local global i32* null
+// CHECK-DAG: @"?var@@3HA" = external dllimport global i32
+// CHECK-DAG: @"?varp@@3PAHA" = dso_local global i32* @"?var@@3HA"
+// X64-DAG: @"?var@@3HA" = external dllimport global i32, align 4
+// X64-DAG: @"?varp@@3PEAHEA" = dso_local global i32* @"?var@@3HA"
 
 extern void (*funp)();
 void (*funp)() = &fun;
 // CHECK-DAG: @"?funp@@3P6AXXZA" = dso_local global void ()* null
 // X64-DAG: @"?funp@@3P6AXXZEA" = dso_local global void ()* null
 
-// CHECK-LABEL: @"??__Evarp@@YAXXZ"
-// CHECK-DAG: store i32* @"?var@@3HA", i32** @"?varp@@3PAHA"
-
-// X64-LABEL: @"??__Evarp@@YAXXZ"
-// X64-DAG: store i32* @"?var@@3HA", i32** @"?varp@@3PEAHEA"
-
 // CHECK-LABEL: @"??__Efunp@@YAXXZ"()
 // CHECK-DAG: store void ()* @"?fun@@YAXXZ", void ()** @"?funp@@3P6AXXZA"
 
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -2211,9 +2211,12 @@
 // FIXME: Diagnostic!
 return false;
 
-  // A dllimport variable never acts like a constant, unless we're
+  // A dllimport/dllexport variable never acts like a constant, unless 
we're
   // evaluating a value for use only in name mangling.
-  if (!isForManglingOnly(Kind) && Var->hasAttr())
+  if (Info.getLangOpts().C99 && !isForManglingOnly(Kind) &&
+  Var->hasAttr() ||
+  Info.getLangOpts().CPlusPlus && !isForManglingOnly(Kind) &&
+  Var->hasAttr())
 // FIXME: Diagnostic!
 return false;
 }


Index: clang/test/SemaCXX/dllimport-constexpr.cpp
===
--- clang/test/SemaCXX/dllimport-constexpr.cpp
+++ clang/test/SemaCXX/dllimport-constexpr.cpp
@@ -40,7 +40,6 @@
 // constexpr initialization doesn't work for dllimport things.
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (*constexpr_import_func)()