[PATCH] D109260: [RISCV] Add SiFive cores E and S series

2021-09-09 Thread Alexander Pivovarov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4bc8dbe0cae3: [RISCV] Add SiFive cores E and S series 
(authored by apivovarov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109260

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/Driver/riscv-cpus.c
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/include/llvm/Support/RISCVTargetParser.def
  llvm/lib/Target/RISCV/RISCV.td

Index: llvm/lib/Target/RISCV/RISCV.td
===
--- llvm/lib/Target/RISCV/RISCV.td
+++ llvm/lib/Target/RISCV/RISCV.td
@@ -250,27 +250,63 @@
 def : ProcessorModel<"sifive-7-rv32", SiFive7Model, []>;
 def : ProcessorModel<"sifive-7-rv64", SiFive7Model, [Feature64Bit]>;
 
+def : ProcessorModel<"sifive-e20", RocketModel, [FeatureStdExtM,
+ FeatureStdExtC]>;
+
+def : ProcessorModel<"sifive-e21", RocketModel, [FeatureStdExtM,
+ FeatureStdExtA,
+ FeatureStdExtC]>;
+
+def : ProcessorModel<"sifive-e24", RocketModel, [FeatureStdExtM,
+ FeatureStdExtA,
+ FeatureStdExtF,
+ FeatureStdExtC]>;
+
 def : ProcessorModel<"sifive-e31", RocketModel, [FeatureStdExtM,
  FeatureStdExtA,
  FeatureStdExtC]>;
 
+def : ProcessorModel<"sifive-e34", RocketModel, [FeatureStdExtM,
+ FeatureStdExtA,
+ FeatureStdExtF,
+ FeatureStdExtC]>;
+
+def : ProcessorModel<"sifive-e76", SiFive7Model, [FeatureStdExtM,
+  FeatureStdExtA,
+  FeatureStdExtF,
+  FeatureStdExtC]>;
+
+def : ProcessorModel<"sifive-s21", RocketModel, [Feature64Bit,
+ FeatureStdExtM,
+ FeatureStdExtA,
+ FeatureStdExtC]>;
+
 def : ProcessorModel<"sifive-s51", RocketModel, [Feature64Bit,
  FeatureStdExtM,
  FeatureStdExtA,
  FeatureStdExtC]>;
 
-def : ProcessorModel<"sifive-u54", RocketModel, [Feature64Bit,
+def : ProcessorModel<"sifive-s54", RocketModel, [Feature64Bit,
  FeatureStdExtM,
  FeatureStdExtA,
  FeatureStdExtF,
  FeatureStdExtD,
  FeatureStdExtC]>;
 
-def : ProcessorModel<"sifive-e76", SiFive7Model, [FeatureStdExtM,
+def : ProcessorModel<"sifive-s76", SiFive7Model, [Feature64Bit,
+  FeatureStdExtM,
   FeatureStdExtA,
   FeatureStdExtF,
+  FeatureStdExtD,
   FeatureStdExtC]>;
 
+def : ProcessorModel<"sifive-u54", RocketModel, [Feature64Bit,
+ FeatureStdExtM,
+ FeatureStdExtA,
+ FeatureStdExtF,
+ FeatureStdExtD,
+ FeatureStdExtC]>;
+
 def : ProcessorModel<"sifive-u74", SiFive7Model, [Feature64Bit,
   FeatureStdExtM,
   FeatureStdExtA,
Index: llvm/include/llvm/Support/RISCVTargetParser.def
===
--- llvm/include/llvm/Support/RISCVTargetParser.def
+++ llvm/include/llvm/Support/RISCVTargetParser.def
@@ -19,10 +19,17 @@
 PROC(ROCKET_RV64, {"rocket-rv64"}, FK_64BIT, {""})
 PROC(SIFIVE_732, {"sifive-7-rv32"}, FK_NONE, {""})
 PROC(SIFIVE_764, {"sifive-7-rv64"}, FK_64BIT, {""})
+PROC(SIFIVE_E20, {"sifive-e20"}, FK_NONE, {"rv32imc"})
+PROC(SIFIVE_E21, {"sifive-e21"}, FK_NONE, {"rv32imac"})
+PROC(SIFIVE_E24, {"sifive-e24"}, FK_NONE, {"rv32imafc"})
 PROC(SIFIVE_E31, {"sifive-e31"}, FK_NONE, {"rv32imac"})
+PROC(SIFIVE_E34, {"sifive-e34"}, FK_NONE, {"rv32imafc"})
+PROC(SIFIVE_E76, {"sifive-e76"}, FK_NONE, {"rv32imafc"})

[PATCH] D109487: [X86] Support *_set1_pch(Float16 _Complex h)

2021-09-09 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei created this revision.
pengfei added reviewers: LuoYuanke, FreddyYe, craig.topper, RKSimon.
pengfei 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/D109487

Files:
  clang/lib/Headers/avx512fp16intrin.h
  clang/lib/Headers/avx512vlfp16intrin.h
  clang/test/CodeGen/X86/avx512fp16-builtins.c
  clang/test/CodeGen/X86/avx512vlfp16-builtins.c

Index: clang/test/CodeGen/X86/avx512vlfp16-builtins.c
===
--- clang/test/CodeGen/X86/avx512vlfp16-builtins.c
+++ clang/test/CodeGen/X86/avx512vlfp16-builtins.c
@@ -61,6 +61,32 @@
   return _mm256_set1_ph(h);
 }
 
+__m128h test_mm_set1_pch(_Float16 _Complex h) {
+  // CHECK-LABEL: @test_mm_set1_pch
+  // CHECK: bitcast { half, half }{{.*}} to float
+  // CHECK: insertelement <4 x float> {{.*}}, i32 0
+  // CHECK: insertelement <4 x float> {{.*}}, i32 1
+  // CHECK: insertelement <4 x float> {{.*}}, i32 2
+  // CHECK: insertelement <4 x float> {{.*}}, i32 3
+  // CHECK: bitcast <4 x float>{{.*}} to <8 x half>
+  return _mm_set1_pch(h);
+}
+
+__m256h test_mm256_set1_pch(_Float16 _Complex h) {
+  // CHECK-LABEL: @test_mm256_set1_pch
+  // CHECK: bitcast { half, half }{{.*}} to float
+  // CHECK: insertelement <8 x float> {{.*}}, i32 0
+  // CHECK: insertelement <8 x float> {{.*}}, i32 1
+  // CHECK: insertelement <8 x float> {{.*}}, i32 2
+  // CHECK: insertelement <8 x float> {{.*}}, i32 3
+  // CHECK: insertelement <8 x float> {{.*}}, i32 4
+  // CHECK: insertelement <8 x float> {{.*}}, i32 5
+  // CHECK: insertelement <8 x float> {{.*}}, i32 6
+  // CHECK: insertelement <8 x float> {{.*}}, i32 7
+  // CHECK: bitcast <8 x float>{{.*}} to <16 x half>
+  return _mm256_set1_pch(h);
+}
+
 __m128h test_mm_set_ph(_Float16 __h1, _Float16 __h2, _Float16 __h3, _Float16 __h4,
_Float16 __h5, _Float16 __h6, _Float16 __h7, _Float16 __h8) {
   // CHECK-LABEL: @test_mm_set_ph
Index: clang/test/CodeGen/X86/avx512fp16-builtins.c
===
--- clang/test/CodeGen/X86/avx512fp16-builtins.c
+++ clang/test/CodeGen/X86/avx512fp16-builtins.c
@@ -81,6 +81,29 @@
   return _mm512_set1_ph(h);
 }
 
+__m512h test_mm512_set1_pch(_Float16 _Complex h) {
+  // CHECK-LABEL: @test_mm512_set1_pch
+  // CHECK: bitcast { half, half }{{.*}} to float
+  // CHECK: insertelement <16 x float> {{.*}}, i32 0
+  // CHECK: insertelement <16 x float> {{.*}}, i32 1
+  // CHECK: insertelement <16 x float> {{.*}}, i32 2
+  // CHECK: insertelement <16 x float> {{.*}}, i32 3
+  // CHECK: insertelement <16 x float> {{.*}}, i32 4
+  // CHECK: insertelement <16 x float> {{.*}}, i32 5
+  // CHECK: insertelement <16 x float> {{.*}}, i32 6
+  // CHECK: insertelement <16 x float> {{.*}}, i32 7
+  // CHECK: insertelement <16 x float> {{.*}}, i32 8
+  // CHECK: insertelement <16 x float> {{.*}}, i32 9
+  // CHECK: insertelement <16 x float> {{.*}}, i32 10
+  // CHECK: insertelement <16 x float> {{.*}}, i32 11
+  // CHECK: insertelement <16 x float> {{.*}}, i32 12
+  // CHECK: insertelement <16 x float> {{.*}}, i32 13
+  // CHECK: insertelement <16 x float> {{.*}}, i32 14
+  // CHECK: insertelement <16 x float> {{.*}}, i32 15
+  // CHECK: bitcast <16 x float>{{.*}} to <32 x half>
+  return _mm512_set1_pch(h);
+}
+
 __m512h test_mm512_set_ph(_Float16 __h1, _Float16 __h2, _Float16 __h3, _Float16 __h4,
   _Float16 __h5, _Float16 __h6, _Float16 __h7, _Float16 __h8,
   _Float16 __h9, _Float16 __h10, _Float16 __h11, _Float16 __h12,
Index: clang/lib/Headers/avx512vlfp16intrin.h
===
--- clang/lib/Headers/avx512vlfp16intrin.h
+++ clang/lib/Headers/avx512vlfp16intrin.h
@@ -51,6 +51,16 @@
   return (__m128h)(__v8hf){__h8, __h7, __h6, __h5, __h4, __h3, __h2, __h1};
 }
 
+static __inline__ __m256h __DEFAULT_FN_ATTRS256
+_mm256_set1_pch(_Float16 _Complex h) {
+  return (__m256h)_mm256_set1_ps(__builtin_bit_cast(float, h));
+}
+
+static __inline__ __m128h __DEFAULT_FN_ATTRS128
+_mm_set1_pch(_Float16 _Complex h) {
+  return (__m128h)_mm_set1_ps(__builtin_bit_cast(float, h));
+}
+
 static __inline __m256h __DEFAULT_FN_ATTRS256
 _mm256_set_ph(_Float16 __h1, _Float16 __h2, _Float16 __h3, _Float16 __h4,
   _Float16 __h5, _Float16 __h6, _Float16 __h7, _Float16 __h8,
Index: clang/lib/Headers/avx512fp16intrin.h
===
--- clang/lib/Headers/avx512fp16intrin.h
+++ clang/lib/Headers/avx512fp16intrin.h
@@ -97,6 +97,11 @@
 (h14), (h13), (h12), (h11), (h10), (h9), (h8), (h7), (h6), \
 (h5), (h4), (h3), (h2), (h1))
 
+static __inline __m512h __DEFAULT_FN_ATTRS512
+_mm512_set1_pch(_Float16 _Complex h) {
+  return (__m512h)_mm512_set1_ps(__builtin_bit_cast(float, h));
+}
+
 stati

[PATCH] D109489: [OptParser] NFC: Remove unused template arg 'name' from bool opt

2021-09-09 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes created this revision.
c-rhodes added a reviewer: jansvoboda11.
Herald added a subscriber: dang.
c-rhodes requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: cfe-commits.

Identified in D109359 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109489

Files:
  clang/include/clang/Driver/Options.td
  llvm/include/llvm/Option/OptParser.td


Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -214,7 +214,7 @@
 }
 
 // Implementation detail of BoolOption.
-class MarshallingInfoBooleanFlag
   : MarshallingInfoFlag {
   code Normalizer = "makeBooleanOptionNormalizer("#value#", "#other_value#", 
OPT_"#other_name#")";
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -407,8 +407,7 @@
 Default default>
   : Flag<["-"], flag.Spelling>, Flags, HelpText,
 MarshallingInfoBooleanFlag,
+   other.ValueAsCode, other.RecordName>,
 ImpliedByAnyOf {}
 
 // Generates TableGen records for two command line flags that control the same


Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -214,7 +214,7 @@
 }
 
 // Implementation detail of BoolOption.
-class MarshallingInfoBooleanFlag
   : MarshallingInfoFlag {
   code Normalizer = "makeBooleanOptionNormalizer("#value#", "#other_value#", OPT_"#other_name#")";
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -407,8 +407,7 @@
 Default default>
   : Flag<["-"], flag.Spelling>, Flags, HelpText,
 MarshallingInfoBooleanFlag,
+   other.ValueAsCode, other.RecordName>,
 ImpliedByAnyOf {}
 
 // Generates TableGen records for two command line flags that control the same
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109489: [OptParser] NFC: Remove unused template arg 'name' from bool opt

2021-09-09 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes added a comment.

@jansvoboda11 this came up in D109359  with 
warning:

  llvm/include/llvm/Option/OptParser.td:217:91: warning: unused template 
argument: MarshallingInfoBooleanFlag:name

I see you've changed worked on this in the past, wasn't sure if it's intended 
for `name` not to be used so thought I'd post the patch and let you take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109489

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


[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

2021-09-09 Thread Ryan Beltran via Phabricator via cfe-commits
rpbeltran added a comment.

Sorry for the late reply on this. I ran the warning against ChromeOS and 
actually found very few false positives and a couple interesting findings to 
file bugs for. I actually saw about an equal number of cases caught for `&` and 
`|`.

https://source.chromium.org/chromium/chromium/src/+/main:third_party/perfetto/src/perfetto_cmd/perfetto_cmd.cc;l=492?q=%22(is_attach()%20%7C%20is_detach()%20%7C%7C%20query_service_%20%7C%7C%20has_config_options))%22

https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/kernel/v4.4/drivers/gpu/drm/i915/i915_drv.h?q=%22i915_reset_in_progress(error)%20%7C%20i915_terminally_wedged(error)%22

https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform2/power_manager/powerd/policy/charge_controller.cc?q=%22ApplyPeakShiftChange(policy)%20%26%20ApplyBootOnAcChange(policy)%20%26%22

https://source.chromium.org/chromium/chromium/src/+/main:third_party/angle/src/libANGLE/renderer/gl/VertexArrayGL.cpp?q=%22const%20bool%20enabled%20%3D%20mState.getVertexAttribute(attribIndex).enabled%20%26%22

https://source.chromium.org/chromium/chromium/src/+/main:third_party/harfbuzz-ng/src/src/hb-ot-layout-gpos-table.hh?q=%22if%20(valueFormats%5B0%5D.apply_value%20(c,%20this,%20%26record-%3Evalues%5B0%5D,%20buffer-%3Ecur_pos())%20%7C%22

https://source.chromium.org/chromium/chromium/src/+/main:third_party/harfbuzz-ng/src/src/hb-ot-layout-gpos-table.hh?q=%22if%20(valueFormat1.apply_value%20(c,%20this,%20v,%20buffer-%3Ecur_pos())%20%7C%22


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

https://reviews.llvm.org/D108003

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


[PATCH] D109485: [clang-scan-deps] Add an API for clang dependency scanner to perform module lookup by name alone

2021-09-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 accepted this revision.
jansvoboda11 added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109485

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


[PATCH] D109492: [OpenCL] Test case for C++ for OpenCL 2021 in OpenCL C header test

2021-09-09 Thread Justas Janickas via Phabricator via cfe-commits
Topotuna created this revision.
Topotuna added a reviewer: Anastasia.
Herald added subscribers: ldrumm, yaxunl.
Topotuna requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

RUN line representing C++ for OpenCL 2021 added to the test. This
should have been done as part of earlier commit fb321c2ea274 
 but
was missed during rebasing.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109492

Files:
  clang/test/Headers/opencl-c-header.cl


Index: clang/test/Headers/opencl-c-header.cl
===
--- clang/test/Headers/opencl-c-header.cl
+++ clang/test/Headers/opencl-c-header.cl
@@ -1,8 +1,9 @@
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify | FileCheck %s
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL1.1 
| FileCheck %s
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL1.2 
| FileCheck %s
-// RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=clc++ 
| FileCheck %s --check-prefix=CHECK20
+// RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify 
-cl-std=clc++1.0 | FileCheck %s --check-prefix=CHECK20
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL3.0 
| FileCheck %s
+// RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem 
../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify 
-cl-std=clc++2021 | FileCheck %s
 
 // Test including the default header as a module.
 // The module should be compiled only once and loaded from cache afterwards.
@@ -57,7 +58,7 @@
 // CHECK20: _Z16convert_char_rtec
 char f(char x) {
 // Check functionality from OpenCL 2.0 onwards
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
+#if (__OPENCL_CPP_VERSION__ == 100) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
   ndrange_t t;
   x = ctz(x);
 #endif //__OPENCL_C_VERSION__
@@ -82,7 +83,7 @@
 #endif
 
 // Verify that ATOMIC_VAR_INIT is defined.
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
+#if (__OPENCL_CPP_VERSION__ == 100) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
 global atomic_int z = ATOMIC_VAR_INIT(99);
 #endif //__OPENCL_C_VERSION__
 // CHECK-MOD: Reading modules


Index: clang/test/Headers/opencl-c-header.cl
===
--- clang/test/Headers/opencl-c-header.cl
+++ clang/test/Headers/opencl-c-header.cl
@@ -1,8 +1,9 @@
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem ../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify | FileCheck %s
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem ../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL1.1 | FileCheck %s
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem ../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL1.2 | FileCheck %s
-// RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem ../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=clc++ | FileCheck %s --check-prefix=CHECK20
+// RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem ../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=clc++1.0 | FileCheck %s --check-prefix=CHECK20
 // RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem ../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=CL3.0 | FileCheck %s
+// RUN: %clang_cc1 -O0 -triple spir-unknown-unknown -internal-isystem ../../lib/Headers -include opencl-c.h -emit-llvm -o - %s -verify -cl-std=clc++2021 | FileCheck %s
 
 // Test including the default header as a module.
 // The module should be compiled only once and loaded from cache afterwards.
@@ -57,7 +58,7 @@
 // CHECK20: _Z16convert_char_rtec
 char f(char x) {
 // Check functionality from OpenCL 2.0 onwards
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
+#if (__OPENCL_CPP_VERSION__ == 100) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
   ndrange_t t;
   x = ctz(x);
 #endif //__OPENCL_C_VERSION__
@@ -82,7 +83,7 @@
 #endif
 
 // Verify that ATOMIC_VAR_INIT is defined.
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
+#if (__OPENCL_CPP_VERSION__ == 100) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
 global atomic_int z = ATOMIC_VAR_INIT(99);
 #endif //__OPENCL_C_V

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

2021-09-09 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added inline comments.



Comment at: clang/test/Driver/openmp-offload-gpu.c:153
-/// bitcode library and add it to the LIBRARY_PATH.
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp 
-fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   -Xopenmp-target -march=sm_35 
--cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \

tianshilei1992 wrote:
> Seems like we don't have a test for the fallback version now?
Yes, indeed. That seemed reasonable to me, but can add some more stub files and 
check they can be found. I'll do that today - would really like this to go in 
soon enough that it can make it to the llvm-13 branch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

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


[PATCH] D102325: [clang-tidy] cppcoreguidelines-virtual-base-class-destructor: a new check

2021-09-09 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.

In D102325#2981760 , @mgartmann wrote:

> @whisperity Thanks a lot for helping me out!

Sorry I got busy with a few official business and then got deeply distracted by 
what I'm working on, but I'll get to committing this ASAP. ETA 1 hr. 🙂


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102325

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


[clang] 55d9396 - [X86] Move _mm256_set_m128* intrinsics before _mm256_loadu2_m128* intrinsics. NFC.

2021-09-09 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2021-09-09T11:23:50+01:00
New Revision: 55d939627823a196f78f0e6279fa0ca14d0ae0f8

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

LOG: [X86] Move _mm256_set_m128* intrinsics before _mm256_loadu2_m128* 
intrinsics. NFC.

This is necessary for PR51796 where we'll update _mm256_loadu2_m128* to use  
_mm256_set_m128*

Added: 


Modified: 
clang/lib/Headers/avxintrin.h

Removed: 




diff  --git a/clang/lib/Headers/avxintrin.h b/clang/lib/Headers/avxintrin.h
index 7f4e9761f1e2c..8709d753dced1 100644
--- a/clang/lib/Headers/avxintrin.h
+++ b/clang/lib/Headers/avxintrin.h
@@ -4748,6 +4748,135 @@ _mm256_zextsi128_si256(__m128i __a)
 #define _mm256_extractf128_si256(V, M) \
   ((__m128i)__builtin_ia32_vextractf128_si256((__v8si)(__m256i)(V), (int)(M)))
 
+/// Constructs a 256-bit floating-point vector of [8 x float] by
+///concatenating two 128-bit floating-point vectors of [4 x float].
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the  VINSERTF128  instruction.
+///
+/// \param __hi
+///A 128-bit floating-point vector of [4 x float] to be copied to the upper
+///128 bits of the result.
+/// \param __lo
+///A 128-bit floating-point vector of [4 x float] to be copied to the lower
+///128 bits of the result.
+/// \returns A 256-bit floating-point vector of [8 x float] containing the
+///concatenated result.
+static __inline __m256 __DEFAULT_FN_ATTRS
+_mm256_set_m128 (__m128 __hi, __m128 __lo)
+{
+  return (__m256) __builtin_shufflevector((__v4sf)__lo, (__v4sf)__hi, 0, 1, 2, 
3, 4, 5, 6, 7);
+}
+
+/// Constructs a 256-bit floating-point vector of [4 x double] by
+///concatenating two 128-bit floating-point vectors of [2 x double].
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the  VINSERTF128  instruction.
+///
+/// \param __hi
+///A 128-bit floating-point vector of [2 x double] to be copied to the 
upper
+///128 bits of the result.
+/// \param __lo
+///A 128-bit floating-point vector of [2 x double] to be copied to the 
lower
+///128 bits of the result.
+/// \returns A 256-bit floating-point vector of [4 x double] containing the
+///concatenated result.
+static __inline __m256d __DEFAULT_FN_ATTRS
+_mm256_set_m128d (__m128d __hi, __m128d __lo)
+{
+  return (__m256d) __builtin_shufflevector((__v2df)__lo, (__v2df)__hi, 0, 1, 
2, 3);
+}
+
+/// Constructs a 256-bit integer vector by concatenating two 128-bit
+///integer vectors.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the  VINSERTF128  instruction.
+///
+/// \param __hi
+///A 128-bit integer vector to be copied to the upper 128 bits of the
+///result.
+/// \param __lo
+///A 128-bit integer vector to be copied to the lower 128 bits of the
+///result.
+/// \returns A 256-bit integer vector containing the concatenated result.
+static __inline __m256i __DEFAULT_FN_ATTRS
+_mm256_set_m128i (__m128i __hi, __m128i __lo)
+{
+  return (__m256i) __builtin_shufflevector((__v2di)__lo, (__v2di)__hi, 0, 1, 
2, 3);
+}
+
+/// Constructs a 256-bit floating-point vector of [8 x float] by
+///concatenating two 128-bit floating-point vectors of [4 x float]. This is
+///similar to _mm256_set_m128, but the order of the input parameters is
+///swapped.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the  VINSERTF128  instruction.
+///
+/// \param __lo
+///A 128-bit floating-point vector of [4 x float] to be copied to the lower
+///128 bits of the result.
+/// \param __hi
+///A 128-bit floating-point vector of [4 x float] to be copied to the upper
+///128 bits of the result.
+/// \returns A 256-bit floating-point vector of [8 x float] containing the
+///concatenated result.
+static __inline __m256 __DEFAULT_FN_ATTRS
+_mm256_setr_m128 (__m128 __lo, __m128 __hi)
+{
+  return _mm256_set_m128(__hi, __lo);
+}
+
+/// Constructs a 256-bit floating-point vector of [4 x double] by
+///concatenating two 128-bit floating-point vectors of [2 x double]. This 
is
+///similar to _mm256_set_m128d, but the order of the input parameters is
+///swapped.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the  VINSERTF128  instruction.
+///
+/// \param __lo
+///A 128-bit floating-point vector of [2 x double] to be copied to the 
lower
+///128 bits of the result.
+/// \param __hi
+///A 128-bit floating-point vector of [2 x double] to be copied to the 
upper
+///128 bits of the result.
+/// \returns A 256-bit floating-point vector of [4 x double] containing the
+///concatenated result.
+static __inline __m256d __DEFAULT_FN_ATTRS
+_mm256_setr_m128d (__m128d __lo, __m128d __hi)
+{
+  return (__m256d)_mm256_set_m128d(__hi, __lo);
+}
+
+/// Constructs a 

[PATCH] D109327: [OpenCL][Docs] Release 13 notes

2021-09-09 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 371536.
Anastasia added a comment.

- Addressed review comments from @Topotuna
- Reordered items to group features and fixes


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

https://reviews.llvm.org/D109327

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -150,10 +150,85 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+
+Command-line interface changes:
+
+- All builtin types, macros and function declarations are now added by default
+  without any command-line flags. A flag is provided ``-cl-no-stdinc`` to
+  suppress the default declarations non-native to the compiler.
+
+- Clang now compiles using OpenCL C version 1.2 by default if no version is
+  specified explicitly from the command line.
+
+- Clang now supports ``.clcpp`` file extension for sources written in
+  C++ for OpenCL.
+
+- Clang now accepts ``-cl-std=clc++1.0`` that sets C++ for OpenCL to
+  the version 1.0 explicitly.
+
+Misc common changes:
+
+- Added ``NULL`` definition in internal headers for standards prior to the
+  version 2.0.
+
+- Simplified use of pragma in extensions for ``double``, images, atomics,
+  subgroups, Arm dot product extension. There are less cases where extension
+  pragma is now required by clang to compile kernel sources.
+
+- Added missing ``as_size``/``as_ptrdiff``/``as_intptr``/``as_uintptr_t``
+  operators to internal headers.
+
+- Added new builtin function for ndrange, ``cl_khr_subgroup_extended_types``,
+  ``cl_khr_subgroup_non_uniform_vote``, ``cl_khr_subgroup_ballot``,
+  ``cl_khr_subgroup_non_uniform_arithmetic``, ``cl_khr_subgroup_shuffle``,
+  ``cl_khr_subgroup_shuffle_relative``, ``cl_khr_subgroup_clustered_reduce``
+  into the default Tablegen-based header.
+
+- Added online documentation for Tablegen-based header, OpenCL 3.0 support,
+  new clang extensions.
+
+- Fixed OpenCL C language version and SPIR address space reporting in DWARF.
+
+New extensions:
+
+- ``cl_khr_integer_dot_product`` for dedicated support of dot product.
+
+- ``cl_khr_extended_bit_ops`` for dedicated support of extra binary operations.
+
+- ``__cl_clang_bitfields`` for use of bit-fields in the kernel code.
+
+- ``__cl_clang_non_portable_kernel_param_types`` for relaxing some restrictions
+  to types of kernel parameters.
+
+OpenCL C 3.0 related changes:
+
+- Added parsing support for the optionality of generic address space, images 
+  (including 3d writes and ``read_write`` access qualifier), pipes, program
+  scope variables, double-precision floating-point support. 
+
+- Added optionality support for builtin functions (in ``opencl-c.h`` header)
+  for generic address space, C11 atomics.  
+
+- Added ``memory_scope_all_devices`` enum for the atomics in internal headers.
+
+- Enabled use of ``.rgba`` vector components.
+
+C++ for OpenCL related changes:
+
+- Added ``__remove_address_space`` metaprogramming utility in internal headers
+  to allow removing address spaces from types.
+
+- Improved overloads resolution logic for constructors wrt address spaces.
+
+- Improved diagnostics of OpenCL specific types and address space qualified
+  types in ``reinterpret_cast`` and template functions.
+
+- Fixed ``NULL`` macro in internal headers to be compatible with C++.
+
+- Fixed use of ``half`` type.
 
 ABI Changes in Clang
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -150,10 +150,85 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+
+Command-line interface changes:
+
+- All builtin types, macros and function declarations are now added by default
+  without any command-line flags. A flag is provided ``-cl-no-stdinc`` to
+  suppress the default declarations non-native to the compiler.
+
+- Clang now compiles using OpenCL C version 1.2 by default if no version is
+  specified explicitly from the command line.
+
+- Clang now supports ``.clcpp`` file extension for sources written in
+  C++ for OpenCL.
+
+- Clang now accepts ``-cl-std=clc++1.0`` that sets C++ for OpenCL to
+  the version 1.0 explicitly.
+
+Misc common changes:
+
+- Added ``NULL`` definition in internal headers for standards prior to the
+  version 2.0.
+
+- Simplified use of pragma in extensions for ``double``, images, atomics,
+  subgroups, Arm dot product extension. There are less cases where extension
+  pragma is now re

[PATCH] D109497: [X86][AVX] Update _mm256_loadu2_m128* intrinsics to use _mm256_set_m128* (PR51796)

2021-09-09 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon created this revision.
RKSimon added reviewers: craig.topper, pengfei, spatel.
RKSimon requested review of this revision.
Herald added a project: clang.

As reported on PR51796, the _mm256_loadu2_m128i in particular was inserting 
bitcasts and shuffles with different types making it trickier for some 
combines, and prevented the value tracker from identifying the shuffle 
sequences as a single insert_subvector style concat_vectors pattern.

This patch instead concatenate the 128-bit unaligned loads with 
_mm256_set_m128*, which was written to avoid the unnecessary bitcasts and only 
emits a single shuffle.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109497

Files:
  clang/lib/Headers/avxintrin.h
  clang/test/CodeGen/X86/avx-builtins.c


Index: clang/test/CodeGen/X86/avx-builtins.c
===
--- clang/test/CodeGen/X86/avx-builtins.c
+++ clang/test/CodeGen/X86/avx-builtins.c
@@ -1233,30 +1233,24 @@
 __m256 test_mm256_loadu2_m128(float* A, float* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128
   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 

   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> poison, <8 x i32> 

-  // CHECK: shufflevector <8 x float> %{{.*}}, <8 x float> %{{.*}}, <8 x i32> 

+  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 

   return _mm256_loadu2_m128(A, B);
 }
 
 __m256d test_mm256_loadu2_m128d(double* A, double* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128d
   // CHECK: load <2 x double>, <2 x double>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x 
i32> 
   // CHECK: load <2 x double>, <2 x double>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> poison, <4 x i32> 

-  // CHECK: shufflevector <4 x double> %{{.*}}, <4 x double> %{{.*}}, <4 x 
i32> 
+  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x 
i32> 
   return _mm256_loadu2_m128d(A, B);
 }
 
 __m256i test_mm256_loadu2_m128i(__m128i* A, __m128i* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128i
   // CHECK: load <2 x i64>, <2 x i64>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
   // CHECK: load <2 x i64>, <2 x i64>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x i32> %{{.*}}, <4 x i32> poison, <8 x i32> 
-  // CHECK: shufflevector <8 x i32> %{{.*}}, <8 x i32> %{{.*}}, <8 x i32> 
+  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
   return _mm256_loadu2_m128i(A, B);
 }
 
Index: clang/lib/Headers/avxintrin.h
===
--- clang/lib/Headers/avxintrin.h
+++ clang/lib/Headers/avxintrin.h
@@ -4902,8 +4902,7 @@
 static __inline __m256 __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128(float const *__addr_hi, float const *__addr_lo)
 {
-  __m256 __v256 = _mm256_castps128_ps256(_mm_loadu_ps(__addr_lo));
-  return _mm256_insertf128_ps(__v256, _mm_loadu_ps(__addr_hi), 1);
+  return _mm256_set_m128(_mm_loadu_ps(__addr_hi), _mm_loadu_ps(__addr_lo));
 }
 
 /// Loads two 128-bit floating-point vectors of [2 x double] from
@@ -4930,8 +4929,7 @@
 static __inline __m256d __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128d(double const *__addr_hi, double const *__addr_lo)
 {
-  __m256d __v256 = _mm256_castpd128_pd256(_mm_loadu_pd(__addr_lo));
-  return _mm256_insertf128_pd(__v256, _mm_loadu_pd(__addr_hi), 1);
+  return _mm256_set_m128d(_mm_loadu_pd(__addr_hi), _mm_loadu_pd(__addr_lo));
 }
 
 /// Loads two 128-bit integer vectors from unaligned memory locations and
@@ -4955,8 +4953,7 @@
 static __inline __m256i __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128i(__m128i_u const *__addr_hi, __m128i_u const *__addr_lo)
 {
-  __m256i __v256 = _mm256_castsi128_si256(_mm_loadu_si128(__addr_lo));
-  return _mm256_insertf128_si256(__v256, _mm_loadu_si128(__addr_hi), 1);
+   return _mm256_set_m128i(_mm_loadu_si128(__addr_hi), 
_mm_loadu_si128(__addr_lo));
 }
 
 /* SIMD store ops (unaligned) */


Index: clang/test/CodeGen/X86/avx-builtins.c
===
--- clang/test/CodeGen/X86/avx-builtins.c
+++ clang/test/CodeGen/X86/avx-builtins.c
@@ -1233,30 +1233,24 @@
 __m256 test_mm256_loadu2_m128(float* A, float* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128
   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 
   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> poison, <8 x i32> 
-  // CHECK: shufflevector <8 x float> %{{.*}}, <8 x float> %{{.*}}, <8 x i32> 
+  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 
   return _mm2

[PATCH] D109366: [OpenCL] Tests C++ for OpenCL 2021 version macros

2021-09-09 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/test/Preprocessor/predefined-macros.c:138
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-FRM
-// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++ \
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++1.0 \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP10

I think we should add one extra line with `-cl-std=clc++` because this is 
probably the only way we can test that it now maps to version 1.0.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109366

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


[PATCH] D109370: [OpenCL] Enables .rgba vector extension in C++ for OpenCL 2021

2021-09-09 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109370

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


[PATCH] D109498: [clang][deps] Stop using `ClangTool` for virtual files

2021-09-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith, ahatanak.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch changes how the dependency scanner creates the fake input file when 
scanning dependencies of a single module (introduced in D109485 
). The scanner now has its own 
`InMemoryFilesystem` which sits under the minimizing FS (when that's 
requested). This makes it possible to drop the duplicate work in 
`DependencyScanningActions::runInvocation` that sets up the main file ID. 
Besides that, this patch makes it possible to land D108979 
, where we drop `ClangTool` entirely.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109498

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -141,11 +141,10 @@
   StringRef WorkingDirectory, DependencyConsumer &Consumer,
   llvm::IntrusiveRefCntPtr DepFS,
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings,
-  ScanningOutputFormat Format, llvm::Optional ModuleName = None,
-  llvm::Optional FakeMemBuffer = None)
+  ScanningOutputFormat Format, llvm::Optional ModuleName = None)
   : WorkingDirectory(WorkingDirectory), Consumer(Consumer),
 DepFS(std::move(DepFS)), PPSkipMappings(PPSkipMappings), Format(Format),
-ModuleName(ModuleName), FakeMemBuffer(FakeMemBuffer) {}
+ModuleName(ModuleName) {}
 
   bool runInvocation(std::shared_ptr Invocation,
  FileManager *FileMgr,
@@ -215,16 +214,6 @@
 .ExcludedConditionalDirectiveSkipMappings = PPSkipMappings;
 }
 
-if (ModuleName.hasValue()) {
-  SmallString<128> FullPath(*ModuleName);
-  llvm::sys::fs::make_absolute(WorkingDirectory, FullPath);
-  SourceManager &SrcMgr = Compiler.getSourceManager();
-  FileMgr->getVirtualFile(FullPath.c_str(), FakeMemBuffer->getBufferSize(),
-  0);
-  FileID MainFileID = SrcMgr.createFileID(*FakeMemBuffer);
-  SrcMgr.setMainFileID(MainFileID);
-}
-
 // Create the dependency collector that will collect the produced
 // dependencies.
 //
@@ -280,7 +269,6 @@
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings;
   ScanningOutputFormat Format;
   llvm::Optional ModuleName;
-  llvm::Optional FakeMemBuffer;
 };
 
 } // end anonymous namespace
@@ -298,7 +286,12 @@
   PCHContainerOps->registerWriter(
   std::make_unique());
 
-  RealFS = llvm::vfs::createPhysicalFileSystem();
+  auto OverlayFS = llvm::makeIntrusiveRefCnt(
+  llvm::vfs::createPhysicalFileSystem());
+  MemoryFS = llvm::makeIntrusiveRefCnt();
+  OverlayFS->pushOverlay(MemoryFS);
+  RealFS = OverlayFS;
+
   if (Service.canSkipExcludedPPRanges())
 PPSkipMappings =
 std::make_unique();
@@ -329,13 +322,10 @@
 const CompilationDatabase &CDB, DependencyConsumer &Consumer,
 llvm::Optional ModuleName) {
   RealFS->setCurrentWorkingDirectory(WorkingDirectory);
-  std::unique_ptr FakeMemBuffer =
-  ModuleName.hasValue() ? llvm::MemoryBuffer::getMemBuffer(" ") : nullptr;
   return runWithDiags(DiagOpts.get(), [&](DiagnosticConsumer &DC) {
 /// Create the tool that uses the underlying file system to ensure that any
 /// file system requests that are made by the driver do not go through the
 /// dependency scanning filesystem.
-SmallString<128> FullPath;
 tooling::ClangTool Tool(CDB,
 ModuleName.hasValue() ? ModuleName->str() : Input,
 PCHContainerOps, RealFS, Files);
@@ -343,21 +333,15 @@
 Tool.setRestoreWorkingDir(false);
 Tool.setPrintErrorMessage(false);
 Tool.setDiagnosticConsumer(&DC);
-DependencyScanningAction Action(
-WorkingDirectory, Consumer, DepFS, PPSkipMappings.get(), Format,
-ModuleName,
-FakeMemBuffer
-? llvm::Optional(*FakeMemBuffer.get())
-: None);
+DependencyScanningAction Action(WorkingDirectory, Consumer, DepFS,
+PPSkipMappings.get(), Format, ModuleName);
 
 if (ModuleName.hasValue()) {
-  Tool.mapVirtualFile(*ModuleName, FakeMemBuffer->getBuffer());
-  FullPath = *ModuleName;
-  llvm::sys::fs::make_absolute(WorkingDirectory, FullPath);
+  MemoryFS->addFile(*ModuleName, 0, llvm::MemoryBuffer::getMemBuffer(" "));
   Tool.appendArgumentsAdjuster(
   [&](const tooling::CommandLineArguments &Args, StringRef FileName) {
 tooling::Com

[PATCH] D109424: [OpenCL] Supports atomics in C++ for OpenCL 2021

2021-09-09 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109424

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


[PATCH] D109492: [OpenCL] Test case for C++ for OpenCL 2021 in OpenCL C header test

2021-09-09 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109492

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


[PATCH] D109489: [OptParser] NFC: Remove unused template arg 'name' from bool opt

2021-09-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 accepted this revision.
jansvoboda11 added a comment.
This revision is now accepted and ready to land.

LGTM.

To give more background, I think my intention was to add an assertion that 
`name` and `other_name` are the same (except for the `no_` part) and I was 
waiting for TableGen assertions to land. But I don't think that's too valuable, 
since the callers already ensure that by some other mechanism. This should be 
fine to remove.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109489

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


[PATCH] D109366: [OpenCL] Tests C++ for OpenCL version macros

2021-09-09 Thread Justas Janickas via Phabricator via cfe-commits
Topotuna updated this revision to Diff 371544.
Topotuna retitled this revision from "[OpenCL] Tests C++ for OpenCL 2021 
version macros" to "[OpenCL] Tests C++ for OpenCL version macros".
Topotuna edited the summary of this revision.
Topotuna added a comment.

Test case added for command line flag `-cl-std=clc++`


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

https://reviews.llvm.org/D109366

Files:
  clang/test/Preprocessor/predefined-macros.c


Index: clang/test/Preprocessor/predefined-macros.c
===
--- clang/test/Preprocessor/predefined-macros.c
+++ clang/test/Preprocessor/predefined-macros.c
@@ -136,7 +136,11 @@
 // RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-fast-relaxed-math \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-FRM
 // RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++ \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++1.0 \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP10
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++2021 \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP2021
 // CHECK-CL10: #define CL_VERSION_1_0 100
 // CHECK-CL10: #define CL_VERSION_1_1 110
 // CHECK-CL10: #define CL_VERSION_1_2 120
@@ -173,10 +177,21 @@
 // CHECK-CL30: #define __OPENCL_C_VERSION__ 300
 // CHECK-CL30-NOT: #define __FAST_RELAXED_MATH__ 1
 // CHECK-FRM: #define __FAST_RELAXED_MATH__ 1
+// CHECK-CLCPP: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP: #define __CL_CPP_VERSION_2021__ 202100
+// CHECK-CLCPP: #define __OPENCL_CPP_VERSION__ 100
+// CHECK-CLCPP-NOT: #define __FAST_RELAXED_MATH__ 1
+// CHECK-CLCPP-NOT: #define __ENDIAN_LITTLE__ 1
 // CHECK-CLCPP10: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP10: #define __CL_CPP_VERSION_2021__ 202100
 // CHECK-CLCPP10: #define __OPENCL_CPP_VERSION__ 100
 // CHECK-CLCPP10-NOT: #define __FAST_RELAXED_MATH__ 1
 // CHECK-CLCPP10-NOT: #define __ENDIAN_LITTLE__ 1
+// CHECK-CLCPP2021: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP2021: #define __CL_CPP_VERSION_2021__ 202100
+// CHECK-CLCPP2021: #define __OPENCL_CPP_VERSION__ 202100
+// CHECK-CLCPP2021-NOT: #define __FAST_RELAXED_MATH__ 1
+// CHECK-CLCPP2021-NOT: #define __ENDIAN_LITTLE__ 1
 
 // RUN: %clang_cc1 %s -E -dM -o - -x cl \
 // RUN:   | FileCheck %s --check-prefix=MSCOPE


Index: clang/test/Preprocessor/predefined-macros.c
===
--- clang/test/Preprocessor/predefined-macros.c
+++ clang/test/Preprocessor/predefined-macros.c
@@ -136,7 +136,11 @@
 // RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-fast-relaxed-math \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-FRM
 // RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++ \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++1.0 \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP10
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++2021 \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP2021
 // CHECK-CL10: #define CL_VERSION_1_0 100
 // CHECK-CL10: #define CL_VERSION_1_1 110
 // CHECK-CL10: #define CL_VERSION_1_2 120
@@ -173,10 +177,21 @@
 // CHECK-CL30: #define __OPENCL_C_VERSION__ 300
 // CHECK-CL30-NOT: #define __FAST_RELAXED_MATH__ 1
 // CHECK-FRM: #define __FAST_RELAXED_MATH__ 1
+// CHECK-CLCPP: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP: #define __CL_CPP_VERSION_2021__ 202100
+// CHECK-CLCPP: #define __OPENCL_CPP_VERSION__ 100
+// CHECK-CLCPP-NOT: #define __FAST_RELAXED_MATH__ 1
+// CHECK-CLCPP-NOT: #define __ENDIAN_LITTLE__ 1
 // CHECK-CLCPP10: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP10: #define __CL_CPP_VERSION_2021__ 202100
 // CHECK-CLCPP10: #define __OPENCL_CPP_VERSION__ 100
 // CHECK-CLCPP10-NOT: #define __FAST_RELAXED_MATH__ 1
 // CHECK-CLCPP10-NOT: #define __ENDIAN_LITTLE__ 1
+// CHECK-CLCPP2021: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP2021: #define __CL_CPP_VERSION_2021__ 202100
+// CHECK-CLCPP2021: #define __OPENCL_CPP_VERSION__ 202100
+// CHECK-CLCPP2021-NOT: #define __FAST_RELAXED_MATH__ 1
+// CHECK-CLCPP2021-NOT: #define __ENDIAN_LITTLE__ 1
 
 // RUN: %clang_cc1 %s -E -dM -o - -x cl \
 // RUN:   | FileCheck %s --check-prefix=MSCOPE
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info

2021-09-09 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/test/CodeGenOpenCL/spirv32_target.cl:12
+kernel void foo(global long *arg) {
+  int res1[sizeof(my_st)  == 12 ? 1 : -1];
+  int res2[sizeof(void *) ==  4 ? 1 : -1];

Are these lines tested somehow? You could change this into C++ for OpenCL test 
and use `static_assert` or find some other ways to test this...

However, this testing seems to overlap with the lines at the end... Could you 
please elaborate on the intent of this test?

Also if you don't plan this to be fundamentally different from testing of 64bit 
triple I think this should be merged with `spirv64_target.cl`. It will make 
things easier for the maintenance and further evolution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109144

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


[PATCH] D109345: MemoryBuffer: Migrate to Expected/llvm::Error from ErrorOr/std::error_code

2021-09-09 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D109345#2987565 , @dexonsmith 
wrote:

> This seems like the right direction to me! Especially like the 
> look-through-the-ErrorInfo change for `FileError` -- I hit this before and 
> found it annoying.

Thanks for taking a look!

> IMO, it'd be valuable to split out the consequential functional changes:
>
> - Improvements/changes you made to FileError could be committed ahead of time

Sure sure, can be committed and unit tested separately for sure.

> - Other improvements you discussed to avoid regressions in (e.g.) 
> llvm-symbolizer (seems potentially important?)

I didn't think the yaml symbolizer output was that important - but turned out 
not to be super hard to fix, so I've done that. (were there other regressions I 
mentioned/should think about?)

> I agree the other changes are mostly mechanical and don't all need careful 
> review-by-subcomponents.
>
> That said, it looks very painful for downstream clients of the LLVM C++ API 
> since it's structured as an all-or-nothing change.

Yeah, certainly crossed my mind.

> Especially for managing cherry-picks to long-lived stable branches. It's 
> painful because clients will have code like this:
>
>   if (auto MaybeFile = MemoryBuffer::getFileOrSTDIN()) {
> // Do something with MaybeFile
>   }
>   // Else path doesn't care about the specific error code.
>
> that will suddenly start crashing at runtime. I even wonder if there like 
> that introduced in-tree by your current all-in-one patch, since I think our 
> filesystem-error paths are often missing test coverage. (It'd be difficult to 
> do a thorough audit.)

Yeah, that came up in a handful of cases that used 'auto' (without using auto 
it's a compile failure).

> I thought through a potential staging that could mitigate the pain:
>
> 1. Add `using MemoryBufferCompat = MemoryBuffer` and search/replace all 
> static `MemoryBuffer::` API calls over to `MemoryBufferCompat::`. No direct 
> impact on downstreams.

Yeah, that's some of the extra churn I was thinking of/hoping to avoid - but 
yeah, it's probably worthwhile.

What's the benefit of having the extra step where everything's renamed twice? 
(if it's going to be a monolithic commit - as mentioned in (3)) Compared to 
doing the mass change while keeping the (1 & 2) pieces for backwards 
compatibility if needed?

> 2. Change `MemoryBuffer` to use `Error` and `Expected`, leaving behind 
> `std::error_code` and `ErrorOr` wrappers in a no-longer-just-a-typedef 
> `MemoryBufferCompat`. Easy for downstreams to temporarily revert, and 
> cherry-pick once they've finished adapting in the example of (1).
> 3. Update all code to use the new APIs. Could be done all at once since it's 
> mostly mechanical, as you said. Also an option to split up by component 
> (e.g., maybe the llvm-symbolizer regression is okay, but it could be nice to 
> get that reviewed separately / in isolation).
> 4. Delete `MemoryBufferCompat`. Downstreams can temporarily revert while they 
> follow the example of on (3).
>
> (Given that (1) and (2) are easy to write, you already have `tree` state for 
> (4), and (3) is easy to create from (4), then I //think// you could construct 
> the above commit sequence without having to redo all the work... then if you 
> wanted to split (3) up from there it'd be easy enough.)
>
> (2) seems like the commit mostly likely to cause functional regressions, and 
> it'd be isolated and easy to revert/reapply (downstream and/or upstream) 
> without much churn.

(3) would be more likely to cause regression? Presumably (2) is really 
uninteresting because it adds a new API (re-adding MemoryBuffer, but unused 
since everything's using MemoryBufferCompat) without any usage, yeah?

Plausible, though a fair bit more churn - I'd probably be up for it, though.

- Dave


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109345

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


[PATCH] D109345: MemoryBuffer: Migrate to Expected/llvm::Error from ErrorOr/std::error_code

2021-09-09 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

In D109345#2990527 , @dblaikie wrote:

> (were there other regressions I mentioned/should think about?)

I don't have specific concerns; I was just reading between the lines of your 
description...

>> 1. Add `using MemoryBufferCompat = MemoryBuffer` and search/replace all 
>> static `MemoryBuffer::` API calls over to `MemoryBufferCompat::`. No direct 
>> impact on downstreams.
>
> Yeah, that's some of the extra churn I was thinking of/hoping to avoid - but 
> yeah, it's probably worthwhile.
>
> What's the benefit of having the extra step where everything's renamed twice? 
> (if it's going to be a monolithic commit - as mentioned in (3)) Compared to 
> doing the mass change while keeping the (1 & 2) pieces for backwards 
> compatibility if needed?

Benefits I was seeing of splitting (1-3) up are:

- makes (2) easy for downstreams to integrate separately from (1) and (3) (see 
below for why (2) is interesting)
- prevents any reverts of (3) on main from resulting in churn in downstream 
efforts to migrate in response to (1-2)
- enables (3) to NOT be monolithic -- still debatable how useful it is, but if 
split up then individual pieces can run through buildbots separately (and be 
reverted separately)

>> 2. Change `MemoryBuffer` to use `Error` and `Expected`, leaving behind 
>> `std::error_code` and `ErrorOr` wrappers in a no-longer-just-a-typedef 
>> `MemoryBufferCompat`. Easy for downstreams to temporarily revert, and 
>> cherry-pick once they've finished adapting in the example of (1).
>> 3. Update all code to use the new APIs. Could be done all at once since it's 
>> mostly mechanical, as you said. Also an option to split up by component 
>> (e.g., maybe the llvm-symbolizer regression is okay, but it could be nice to 
>> get that reviewed separately / in isolation).
>> 4. Delete `MemoryBufferCompat`. Downstreams can temporarily revert while 
>> they follow the example of on (3).
>>
>> (Given that (1) and (2) are easy to write, you already have `tree` state for 
>> (4), and (3) is easy to create from (4), then I //think// you could 
>> construct the above commit sequence without having to redo all the work... 
>> then if you wanted to split (3) up from there it'd be easy enough.)
>>
>> (2) seems like the commit mostly likely to cause functional regressions, and 
>> it'd be isolated and easy to revert/reapply (downstream and/or upstream) 
>> without much churn.
>
> (3) would be more likely to cause regression? Presumably (2) is really 
> uninteresting because it adds a new API (re-adding MemoryBuffer, but unused 
> since everything's using MemoryBufferCompat) without any usage, yeah?

(2) changes all downstream clients of MemoryBuffer APIs from `std::error_code` 
to `Error`

- Mostly will cause build failures
- Also runtime regressions, due to `auto`, etc.

The fix is to do a search/replace of `MemoryBuffer::` to `MemoryBufferCompat::` 
on only the downstream code.

- Splitting from (1) means you can sequence this change between (1) and (2) — 
code always builds.
- Splitting from (3) means you can do a simple search/replace. If (2) is packed 
up with (3) it seems a lot more awkward, since you have to avoid accidentally 
undoing (3) during the search/replace. Then if somehow (3) gets reverted you 
need to start over when it relands.

> Plausible, though a fair bit more churn - I'd probably be up for it, though.
>
> - Dave




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109345

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


[PATCH] D109345: MemoryBuffer: Migrate to Expected/llvm::Error from ErrorOr/std::error_code

2021-09-09 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D109345#2990577 , @dexonsmith 
wrote:

> In D109345#2990527 , @dblaikie 
> wrote:
>
>> (were there other regressions I mentioned/should think about?)
>
> I don't have specific concerns; I was just reading between the lines of your 
> description...

Fair - probably my own hedging there.

>>> 1. Add `using MemoryBufferCompat = MemoryBuffer` and search/replace all 
>>> static `MemoryBuffer::` API calls over to `MemoryBufferCompat::`. No direct 
>>> impact on downstreams.
>>
>> Yeah, that's some of the extra churn I was thinking of/hoping to avoid - but 
>> yeah, it's probably worthwhile.
>>
>> What's the benefit of having the extra step where everything's renamed 
>> twice? (if it's going to be a monolithic commit - as mentioned in (3)) 
>> Compared to doing the mass change while keeping the (1 & 2) pieces for 
>> backwards compatibility if needed?
>
> Benefits I was seeing of splitting (1-3) up are:
>
> - makes (2) easy for downstreams to integrate separately from (1) and (3) 
> (see below for why (2) is interesting)
> - prevents any reverts of (3) on main from resulting in churn in downstream 
> efforts to migrate in response to (1-2)
> - enables (3) to NOT be monolithic -- still debatable how useful it is, but 
> if split up then individual pieces can run through buildbots separately (and 
> be reverted separately)
>
>>> 2. Change `MemoryBuffer` to use `Error` and `Expected`, leaving behind 
>>> `std::error_code` and `ErrorOr` wrappers in a no-longer-just-a-typedef 
>>> `MemoryBufferCompat`. Easy for downstreams to temporarily revert, and 
>>> cherry-pick once they've finished adapting in the example of (1).
>>> 3. Update all code to use the new APIs. Could be done all at once since 
>>> it's mostly mechanical, as you said. Also an option to split up by 
>>> component (e.g., maybe the llvm-symbolizer regression is okay, but it could 
>>> be nice to get that reviewed separately / in isolation).
>>> 4. Delete `MemoryBufferCompat`. Downstreams can temporarily revert while 
>>> they follow the example of on (3).
>>>
>>> (Given that (1) and (2) are easy to write, you already have `tree` state 
>>> for (4), and (3) is easy to create from (4), then I //think// you could 
>>> construct the above commit sequence without having to redo all the work... 
>>> then if you wanted to split (3) up from there it'd be easy enough.)
>>>
>>> (2) seems like the commit mostly likely to cause functional regressions, 
>>> and it'd be isolated and easy to revert/reapply (downstream and/or 
>>> upstream) without much churn.
>>
>> (3) would be more likely to cause regression? Presumably (2) is really 
>> uninteresting because it adds a new API (re-adding MemoryBuffer, but unused 
>> since everything's using MemoryBufferCompat) without any usage, yeah?
>
> (2) changes all downstream clients of MemoryBuffer APIs from 
> `std::error_code` to `Error`
>
> - Mostly will cause build failures
> - Also runtime regressions, due to `auto`, etc.

Oooh, right. Good point - thanks for walking me through it!

> The fix is to do a search/replace of `MemoryBuffer::` to 
> `MemoryBufferCompat::` on only the downstream code.
>
> - Splitting from (1) means you can sequence this change between (1) and (2) — 
> code always builds.
> - Splitting from (3) means you can do a simple search/replace. If (2) is 
> packed up with (3) it seems a lot more awkward, since you have to avoid 
> accidentally undoing (3) during the search/replace. Then if somehow (3) gets 
> reverted you need to start over when it relands.

Yeah, think I'm with you.

Given the amount of churn this means, though - reckon it's worth it? Reckon it 
needs more llvm-dev thread/buy-in/etc? Any other bike-shedding for 
MemoryBufferCompat? (MemoryBufferDeprecated? but I don't really mind)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109345

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


[PATCH] D109483: [APInt] Normalize naming on keep constructors / predicate methods.

2021-09-09 Thread Chris Lattner via Phabricator via cfe-commits
lattner added a comment.

This patch has a lot of noise, the important part is APInt.h


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109483

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


[PATCH] D109483: [APInt] Normalize naming on keep constructors / predicate methods.

2021-09-09 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/include/llvm/ADT/APInt.h:384
   /// value for the APInt's bit width.
   bool isMaxValue() const { return isAllOnesValue(); }
 

isAllOnes()?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109483

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


[PATCH] D109483: [APInt] Normalize naming on keep constructors / predicate methods.

2021-09-09 Thread Chris Lattner via Phabricator via cfe-commits
lattner marked an inline comment as done.
lattner added inline comments.



Comment at: llvm/include/llvm/ADT/APInt.h:384
   /// value for the APInt's bit width.
   bool isMaxValue() const { return isAllOnesValue(); }
 

craig.topper wrote:
> isAllOnes()?
Yep, good catch, fixed thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109483

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


[PATCH] D109483: [APInt] Normalize naming on keep constructors / predicate methods.

2021-09-09 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

I think I read this patch too closely. I'll leave it up to you how much of this 
you want to do.




Comment at: llvm/include/llvm/IR/Constants.h:206
   /// Determine if the value is all ones.
   bool isMinusOne() const { return Val.isAllOnesValue(); }
 

isAllOnes()



Comment at: llvm/include/llvm/Transforms/InstCombine/InstCombiner.h:171
   TrueIfSigned = true;
   return RHS.isAllOnesValue();
 case ICmpInst::ICMP_SGT: // True if LHS s> -1

isAllOnes since you're already in the area



Comment at: llvm/include/llvm/Transforms/InstCombine/InstCombiner.h:174
   TrueIfSigned = false;
   return RHS.isAllOnesValue();
 case ICmpInst::ICMP_SGE: // True if LHS s>= 0

isAllOnes



Comment at: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3243
"Don't know how to expand this subtraction!");
-Tmp1 = DAG.getNode(ISD::XOR, dl, VT, Node->getOperand(1),
-   DAG.getConstant(APInt::getAllOnesValue(VT.getSizeInBits()), dl,
-   VT));
+Tmp1 = DAG.getNode(
+ISD::XOR, dl, VT, Node->getOperand(1),

This could use DAG.getNOT if you're willing to make that change.



Comment at: llvm/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp:965
+  DAG.getConstant(APInt::getAllOnes(BitTy.getSizeInBits()), DL, MaskTy);
   SDValue NotMask = DAG.getNode(ISD::XOR, DL, MaskTy, Mask, AllOnes);
 

I think this could also be DAG.getNOT but I'm less sure.



Comment at: llvm/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp:1212
+  DAG.getConstant(APInt::getAllOnes(VT.getScalarSizeInBits()), DL, VT);
   SDValue NotMask = DAG.getNode(ISD::XOR, DL, VT, Mask, AllOnes);
 

This could be DAG.getNOT



Comment at: llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:4021
   // (X & (C l>>/<< Y)) ==/!= 0  -->  ((X <> Y) & C) ==/!= 0
   if (C1.isNullValue())
 if (SDValue CC = optimizeSetCCByHoistingAndByConstFromLogicalShift(

isZero()



Comment at: llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:4030
   // all bits set:   (X | (Y<<32)) == -1 --> (X & Y) == -1
   bool CmpZero = N1C->getAPIntValue().isNullValue();
+  bool CmpNegOne = N1C->getAPIntValue().isAllOnes();

isNullValue() -> isZero(). I was going to say you could use N1C->isZero() but I 
think it would have to be N1C->isNullValue() because that is the ConstantSDNode 
interface.



Comment at: llvm/lib/Target/ARM/ARMISelLowering.cpp:12185
 else
-  OtherOp = DAG.getConstant(APInt::getAllOnesValue(VT.getSizeInBits()), dl,
-VT);
+  OtherOp = DAG.getConstant(APInt::getAllOnes(VT.getSizeInBits()), dl, VT);
 return true;

I think we have DAG.getAllOnesConstant if you want to use it



Comment at: llvm/lib/Target/Lanai/LanaiISelLowering.cpp:1403
 else
-  OtherOp =
-  DAG.getConstant(APInt::getAllOnesValue(VT.getSizeInBits()), dl, VT);
+  OtherOp = DAG.getConstant(APInt::getAllOnes(VT.getSizeInBits()), dl, VT);
 return true;

I think we have DAG.getAllOnesConstant if you want to use it



Comment at: llvm/lib/Target/M68k/M68kISelLowering.cpp:1983
   Carry = DAG.getNode(M68kISD::ADD, DL, DAG.getVTList(CarryVT, MVT::i32), 
Carry,
   DAG.getConstant(NegOne, DL, CarryVT));
 

This is also getAllOnesConstant



Comment at: llvm/unittests/ADT/APIntTest.cpp:29
 TEST(APIntTest, ShiftLeftByZero) {
-  APInt One = APInt::getNullValue(65) + 1;
+  APInt One = APInt::getZero(65) + 1;
   APInt Shl = One.shl(0);

That's a strange way to write APInt(64, 1) unless there was some specific bug.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109483

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


[PATCH] D109489: [OptParser] NFC: Remove unused template arg 'name' from bool opt

2021-09-09 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes added a comment.

In D109489#2991261 , @jansvoboda11 
wrote:

> LGTM.
>
> To give more background, I think my intention was to add an assertion that 
> `name` and `other_name` are the same (except for the `no_` part) and I was 
> waiting for TableGen assertions to land. But I don't think that's too 
> valuable, since the callers already ensure that by some other mechanism. This 
> should be fine to remove.

No worries thanks for clarifying!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109489

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


[clang-tools-extra] c58c7a6 - [clang-tidy] cppcoreguidelines-virtual-base-class-destructor: a new check

2021-09-09 Thread via cfe-commits

Author: Marco Gartmann
Date: 2021-09-09T13:23:38+02:00
New Revision: c58c7a6ea0535a75e382752b37cb68ccea43cde3

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

LOG: [clang-tidy] cppcoreguidelines-virtual-base-class-destructor: a new check

Finds base classes and structs whose destructor is neither public and
virtual nor protected and non-virtual.
A base class's destructor should be specified in one of these ways to
prevent undefined behaviour.

Fixes are available for user-declared and implicit destructors that are
either public and non-virtual or protected and virtual.

This check implements C.35 [1] from the CppCoreGuidelines.

Reviewed By: aaron.ballman, njames93

Differential Revision: http://reviews.llvm.org/D102325

  [1]: 
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-dtor-virtual

Added: 

clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.h

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-virtual-class-destructor.rst

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp

Modified: 
clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt

clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
index a9f5b3e0c15bc..745eeb8d49f7b 100644
--- a/clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
@@ -26,6 +26,7 @@ add_clang_library(clangTidyCppCoreGuidelinesModule
   ProTypeVarargCheck.cpp
   SlicingCheck.cpp
   SpecialMemberFunctionsCheck.cpp
+  VirtualClassDestructorCheck.cpp
 
   LINK_LIBS
   clangTidy

diff  --git 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
index a16c2d53b56a2..c7b73dd675792 100644
--- 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
+++ 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
@@ -35,6 +35,7 @@
 #include "ProTypeVarargCheck.h"
 #include "SlicingCheck.h"
 #include "SpecialMemberFunctionsCheck.h"
+#include "VirtualClassDestructorCheck.h"
 
 namespace clang {
 namespace tidy {
@@ -94,6 +95,8 @@ class CppCoreGuidelinesModule : public ClangTidyModule {
 CheckFactories.registerCheck("cppcoreguidelines-slicing");
 CheckFactories.registerCheck(
 "cppcoreguidelines-c-copy-assignment-signature");
+CheckFactories.registerCheck(
+"cppcoreguidelines-virtual-class-destructor");
   }
 
   ClangTidyOptions getModuleOptions() override {

diff  --git 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
new file mode 100644
index 0..d9c8ecf9d033a
--- /dev/null
+++ 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
@@ -0,0 +1,200 @@
+//===--- VirtualClassDestructorCheck.cpp - clang-tidy -===//
+//
+// 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 "VirtualClassDestructorCheck.h"
+#include "../utils/LexerUtils.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
+#include 
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace cppcoreguidelines {
+
+void VirtualClassDestructorCheck::registerMatchers(MatchFinder *Finder) {
+  ast_matchers::internal::Matcher InheritsVirtualMethod =
+  hasAnyBase(hasType(cxxRecordDecl(has(cxxMethodDecl(isVirtual());
+
+  Finder->addMatcher(
+  cxxRecordDecl(
+  anyOf(has(cxxMethodDecl(isVirtual())), InheritsVirtualMethod),
+  unless(anyOf(
+  has(cxxDestructorDecl(isPublic(), isVirtual())),
+  has(cxxDestructorDecl(isProtected(), unless(isVirtual()))
+  .bind("ProblematicClassOrStruct"),
+  this);
+}
+
+static CharSourceRange
+getVirtualKeywordRange(const CXXDestructorDecl &Destructor,
+   const SourceManager &SM, const LangOptions &LangOpts) {
+  SourceLocation VirtualBeginLoc = Destructor.get

[PATCH] D102325: [clang-tidy] cppcoreguidelines-virtual-base-class-destructor: a new check

2021-09-09 Thread Whisperity via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc58c7a6ea053: [clang-tidy] 
cppcoreguidelines-virtual-base-class-destructor: a new check (authored by 
mgartmann, committed by whisperity).

Changed prior to commit:
  https://reviews.llvm.org/D102325?vs=365161&id=371551#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102325

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-virtual-class-destructor.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp
@@ -0,0 +1,204 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-virtual-class-destructor %t -- --fix-notes
+
+// CHECK-MESSAGES: :[[@LINE+4]]:8: warning: destructor of 'PrivateVirtualBaseStruct' is private and prevents using the type [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+3]]:8: note: make it public and virtual
+// CHECK-MESSAGES: :[[@LINE+2]]:8: note: make it protected
+// As we have 2 conflicting fixes in notes, no fix is applied.
+struct PrivateVirtualBaseStruct {
+  virtual void f();
+
+private:
+  virtual ~PrivateVirtualBaseStruct() {}
+};
+
+struct PublicVirtualBaseStruct { // OK
+  virtual void f();
+  virtual ~PublicVirtualBaseStruct() {}
+};
+
+// CHECK-MESSAGES: :[[@LINE+2]]:8: warning: destructor of 'ProtectedVirtualBaseStruct' is protected and virtual [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+1]]:8: note: make it protected and non-virtual
+struct ProtectedVirtualBaseStruct {
+  virtual void f();
+
+protected:
+  virtual ~ProtectedVirtualBaseStruct() {}
+  // CHECK-FIXES: ~ProtectedVirtualBaseStruct() {}
+};
+
+// CHECK-MESSAGES: :[[@LINE+2]]:8: warning: destructor of 'ProtectedVirtualDefaultBaseStruct' is protected and virtual [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+1]]:8: note: make it protected and non-virtual
+struct ProtectedVirtualDefaultBaseStruct {
+  virtual void f();
+
+protected:
+  virtual ~ProtectedVirtualDefaultBaseStruct() = default;
+  // CHECK-FIXES: ~ProtectedVirtualDefaultBaseStruct() = default;
+};
+
+// CHECK-MESSAGES: :[[@LINE+4]]:8: warning: destructor of 'PrivateNonVirtualBaseStruct' is private and prevents using the type [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+3]]:8: note: make it public and virtual
+// CHECK-MESSAGES: :[[@LINE+2]]:8: note: make it protected
+// As we have 2 conflicting fixes in notes, no fix is applied.
+struct PrivateNonVirtualBaseStruct {
+  virtual void f();
+
+private:
+  ~PrivateNonVirtualBaseStruct() {}
+};
+
+// CHECK-MESSAGES: :[[@LINE+2]]:8: warning: destructor of 'PublicNonVirtualBaseStruct' is public and non-virtual [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+1]]:8: note: make it public and virtual
+struct PublicNonVirtualBaseStruct {
+  virtual void f();
+  ~PublicNonVirtualBaseStruct() {}
+  // CHECK-FIXES: virtual ~PublicNonVirtualBaseStruct() {}
+};
+
+struct PublicNonVirtualNonBaseStruct { // OK according to C.35, since this struct does not have any virtual methods.
+  void f();
+  ~PublicNonVirtualNonBaseStruct() {}
+};
+
+// CHECK-MESSAGES: :[[@LINE+4]]:8: warning: destructor of 'PublicImplicitNonVirtualBaseStruct' is public and non-virtual [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+3]]:8: note: make it public and virtual
+// CHECK-FIXES: struct PublicImplicitNonVirtualBaseStruct {
+// CHECK-FIXES-NEXT: virtual ~PublicImplicitNonVirtualBaseStruct() = default;
+struct PublicImplicitNonVirtualBaseStruct {
+  virtual void f();
+};
+
+// CHECK-MESSAGES: :[[@LINE+5]]:8: warning: destructor of 'PublicASImplicitNonVirtualBaseStruct' is public and non-virtual [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+4]]:8: note: make it public and virtual
+// CHECK-FIXES: struct PublicASImplicitNonVirtualBaseStruct {
+// CHECK-FIXES-NEXT: virtual ~PublicASImplicitNonVirtualBaseStruct() = default;
+// CHECK-FIXES-NEXT: private:
+struct PublicASImplicitNonVirtualBaseStruct {
+private:
+  virtual void f();
+};
+
+struct ProtectedNonVirtualBaseStruct { // OK
+  virtual void f();
+
+protected:
+  ~ProtectedNonVirtualBaseStruct() {}
+};
+
+//

[PATCH] D109460: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

2021-09-09 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

This is a nice idea.

One drawback is that if you don't pass `-isysroot`, things just wouldn't work 
before but now every clang invocation will call xcrun, so things will work but 
will be slower than if you passed `-isysroot`. But the convenience for one-off 
invocations is probably worth this subtlety.

Tests must be hermetic, so we should have some flag to disable this behavior 
and expand `%clang` and `%clang_cc1` to pass the disable flag, to make sure 
tests don't rely on this.

Independent of tests, can we make the driver look at the triple and pass a 
matching `-sdk` flag to xcrun?

Also, on my system xcrun prints different paths depending on if I pass `-sdk` 
for some reason:

  % xcrun -show-sdk-path
  /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
  % xcrun -show-sdk-path -sdk macosx
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk

I have to do `-isysroot $(xcrun -show-sdk-path -sdk macosx)` for things to 
work. That's another point in favor of passing an `-sdk` flag.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109460

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


[PATCH] D106804: [test-suite] Add tests for FP classification intrinsics

2021-09-09 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff added a comment.

In D106804#2956881 , @RKSimon wrote:

> Something I noticed is that we don't have much test coverage in 
> clang/test/codegen for the fpclass intrinsics - including no constexpr 
> testing afaict (although I don't think __builtin_fpclassify is constexpr yet) 
> - is that something you'd be willing to take a look at?

They present and are in `clang/test/Sema/constant-builtins-2.c`. This is C file 
but the constant evaluator is the same for C++. The tested functions are 
`fpclassify`, `isinf`, `isnan`, `isfinite` and `isnormal`. And yes, 
`fpclassify` is constexpr.


Repository:
  rT test-suite

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

https://reviews.llvm.org/D106804

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


[clang] 6c8ff40 - [OptParser] NFC: Remove unused template arg 'name' from bool opt

2021-09-09 Thread Cullen Rhodes via cfe-commits

Author: Cullen Rhodes
Date: 2021-09-09T12:04:40Z
New Revision: 6c8ff4032e2bcf7dd381633b7e6294f23f0173a9

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

LOG: [OptParser] NFC: Remove unused template arg 'name' from bool opt

Identified in D109359.

Reviewed By: jansvoboda11

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
llvm/include/llvm/Option/OptParser.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8ab3a5156e075..d4d1fdd388d92 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -407,8 +407,7 @@ class MarshalledFlagRec
   : Flag<["-"], flag.Spelling>, Flags, HelpText,
 MarshallingInfoBooleanFlag,
+   other.ValueAsCode, other.RecordName>,
 ImpliedByAnyOf {}
 
 // Generates TableGen records for two command line flags that control the same

diff  --git a/llvm/include/llvm/Option/OptParser.td 
b/llvm/include/llvm/Option/OptParser.td
index 96014b505d0f3..9c73f478db5e0 100644
--- a/llvm/include/llvm/Option/OptParser.td
+++ b/llvm/include/llvm/Option/OptParser.td
@@ -214,7 +214,7 @@ class MarshallingInfoBitfieldFlag
 }
 
 // Implementation detail of BoolOption.
-class MarshallingInfoBooleanFlag
   : MarshallingInfoFlag {
   code Normalizer = "makeBooleanOptionNormalizer("#value#", "#other_value#", 
OPT_"#other_name#")";



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


[PATCH] D109489: [OptParser] NFC: Remove unused template arg 'name' from bool opt

2021-09-09 Thread Cullen Rhodes via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6c8ff4032e2b: [OptParser] NFC: Remove unused template arg 
'name' from bool opt (authored by c-rhodes).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109489

Files:
  clang/include/clang/Driver/Options.td
  llvm/include/llvm/Option/OptParser.td


Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -214,7 +214,7 @@
 }
 
 // Implementation detail of BoolOption.
-class MarshallingInfoBooleanFlag
   : MarshallingInfoFlag {
   code Normalizer = "makeBooleanOptionNormalizer("#value#", "#other_value#", 
OPT_"#other_name#")";
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -407,8 +407,7 @@
 Default default>
   : Flag<["-"], flag.Spelling>, Flags, HelpText,
 MarshallingInfoBooleanFlag,
+   other.ValueAsCode, other.RecordName>,
 ImpliedByAnyOf {}
 
 // Generates TableGen records for two command line flags that control the same


Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -214,7 +214,7 @@
 }
 
 // Implementation detail of BoolOption.
-class MarshallingInfoBooleanFlag
   : MarshallingInfoFlag {
   code Normalizer = "makeBooleanOptionNormalizer("#value#", "#other_value#", OPT_"#other_name#")";
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -407,8 +407,7 @@
 Default default>
   : Flag<["-"], flag.Spelling>, Flags, HelpText,
 MarshallingInfoBooleanFlag,
+   other.ValueAsCode, other.RecordName>,
 ImpliedByAnyOf {}
 
 // Generates TableGen records for two command line flags that control the same
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D106804: [test-suite] Add tests for FP classification intrinsics

2021-09-09 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added a comment.

I've no objections to this - it seems to be orthogonal to the isnan ir 
intrinsic conversation.

Do we have test-suite buildbot coverage on anything other than x86? Cross 
platform uses of long double is always fun

Any other comments?


Repository:
  rT test-suite

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

https://reviews.llvm.org/D106804

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


[PATCH] D109366: [OpenCL] Tests C++ for OpenCL version macros

2021-09-09 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/test/Preprocessor/predefined-macros.c:139
 // RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++ \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++1.0 \

let's just reuse `--check-prefix=CHECK-CLCPP10` to avoid duplication. This will 
always need to map to some other version so it is unlikely we will ever need 
separate check lines for it.


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

https://reviews.llvm.org/D109366

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


[PATCH] D108526: [clang][nfc] Mark as P0692R1 as implemented.

2021-09-09 Thread 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!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108526

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


[clang] 7fc743f - Mark as P0692R1 as implemented; NFC

2021-09-09 Thread Aaron Ballman via cfe-commits

Author: Corentin Jabot
Date: 2021-09-09T08:45:47-04:00
New Revision: 7fc743ff84f60b12bb12f47d48ceb6f268106e45

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

LOG: Mark as P0692R1 as implemented; NFC

P0692R1 was implemented in https://reviews.llvm.org/D92024
but the status page was not updated.

Added: 


Modified: 
clang/www/cxx_status.html

Removed: 




diff  --git a/clang/www/cxx_status.html b/clang/www/cxx_status.html
index 308648ab5aa4a..9ded88755836d 100755
--- a/clang/www/cxx_status.html
+++ b/clang/www/cxx_status.html
@@ -1003,7 +1003,7 @@ C++20 implementation status
 
   Access checking on specializations
   https://wg21.link/p0692r1";>P0692R1
-  Partial
+  Clang 14
 
 
   Default constructible and assignable stateless lambdas



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


[PATCH] D108526: [clang][nfc] Mark as P0692R1 as implemented.

2021-09-09 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman closed this revision.
aaron.ballman added a comment.

I committed this on your behalf in 7fc743ff84f60b12bb12f47d48ceb6f268106e45 
, thank 
you for the patch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108526

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


[PATCH] D108366: [clang][deps] Make resource directory deduction configurable

2021-09-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 371568.
jansvoboda11 added a comment.

Attempt to fix CI again


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108366

Files:
  clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
  clang/test/ClangScanDeps/Inputs/resource_directory/compiler
  clang/test/ClangScanDeps/Inputs/resource_directory/mod.h
  clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
  clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
  clang/test/ClangScanDeps/resource_directory.c
  clang/tools/clang-scan-deps/ClangScanDeps.cpp


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -194,6 +194,25 @@
 "until reaching the end directive."),
 llvm::cl::init(true), llvm::cl::cat(DependencyScannerCategory));
 
+enum ResourceDirRecipeKind {
+  RDRK_ModifyCompilerPath,
+  RDRK_InvokeCompiler,
+};
+
+static llvm::cl::opt ResourceDirRecipe(
+"resource-dir-recipe",
+llvm::cl::desc("How to produce missing '-resource-dir' argument"),
+llvm::cl::values(
+clEnumValN(RDRK_ModifyCompilerPath, "modify-compiler-path",
+   "Construct the resource directory from the compiler path in 
"
+   "the compilation database. This assumes it's part of the "
+   "same toolchain as this clang-scan-deps. (default)"),
+clEnumValN(RDRK_InvokeCompiler, "invoke-compiler",
+   "Invoke the compiler with '-print-resource-dir' and use the 
"
+   "reported path as the resource directory. (deprecated)")),
+llvm::cl::init(RDRK_ModifyCompilerPath),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt Verbose("v", llvm::cl::Optional,
 llvm::cl::desc("Use verbose output."),
 llvm::cl::init(false),
@@ -485,7 +504,7 @@
   AdjustedArgs.push_back("/clang:" + LastO);
 }
 
-if (!HasResourceDir) {
+if (!HasResourceDir && ResourceDirRecipe == RDRK_InvokeCompiler) {
   StringRef ResourceDir =
   ResourceDirCache.findResourceDir(Args, ClangCLMode);
   if (!ResourceDir.empty()) {
Index: clang/test/ClangScanDeps/resource_directory.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/resource_directory.c
@@ -0,0 +1,23 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: cp %S/Inputs/resource_directory/* %t
+
+// Deduce the resource directory from the compiler path.
+//
+// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%/t|g" \
+// RUN:   %S/Inputs/resource_directory/cdb.json.template > %t/cdb_path.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_path.json --format 
experimental-full \
+// RUN:   --resource-dir-recipe modify-compiler-path > %t/result_path.json
+// RUN: cat %t/result_path.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-PATH
+// CHECK-PATH:  "-resource-dir"
+// CHECK-PATH-NEXT: "/our/custom/lib{{.*}}"
+
+// Run the compiler and ask it for the resource directory.
+//
+// RUN: chmod +x %t/compiler
+// RUN: sed -e "s|CLANG|%t/compiler|g" -e "s|DIR|%/t|g" \
+// RUN:   %S/Inputs/resource_directory/cdb.json.template > 
%t/cdb_invocation.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_invocation.json --format 
experimental-full \
+// RUN:   --resource-dir-recipe invoke-compiler > %t/result_invocation.json
+// RUN: cat %t/result_invocation.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-INVOCATION
+// CHECK-INVOCATION:  "-resource-dir"
+// CHECK-INVOCATION-NEXT: "/custom/compiler/resources"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
@@ -0,0 +1 @@
+#include "mod.h"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
@@ -0,0 +1 @@
+module mod { header "mod.h" }
Index: clang/test/ClangScanDeps/Inputs/resource_directory/compiler
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/compiler
@@ -0,0 +1,2 @@
+#!/usr/bin/env python3
+print("/custom/compiler/resources")
Index: clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
@@ -0,0 +1,7 @@
+[
+  {
+"directory": "DIR",
+"command": "CLANG -fmodules -gmodules -

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

2021-09-09 Thread Shilei Tian via Phabricator via cfe-commits
tianshilei1992 added inline comments.



Comment at: clang/test/Driver/openmp-offload-gpu.c:153
-/// bitcode library and add it to the LIBRARY_PATH.
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp 
-fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   -Xopenmp-target -march=sm_35 
--cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \

JonChesterfield wrote:
> tianshilei1992 wrote:
> > Seems like we don't have a test for the fallback version now?
> Yes, indeed. That seemed reasonable to me, but can add some more stub files 
> and check they can be found. I'll do that today - would really like this to 
> go in soon enough that it can make it to the llvm-13 branch.
Yeah, please do. If we provide one feature, it’s better to be tested.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

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


[PATCH] D109498: [clang][deps] Stop using `ClangTool` for virtual files

2021-09-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 371570.
jansvoboda11 added a comment.

Updating diff to re-trigger CI...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109498

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -141,11 +141,10 @@
   StringRef WorkingDirectory, DependencyConsumer &Consumer,
   llvm::IntrusiveRefCntPtr DepFS,
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings,
-  ScanningOutputFormat Format, llvm::Optional ModuleName = None,
-  llvm::Optional FakeMemBuffer = None)
+  ScanningOutputFormat Format, llvm::Optional ModuleName = None)
   : WorkingDirectory(WorkingDirectory), Consumer(Consumer),
 DepFS(std::move(DepFS)), PPSkipMappings(PPSkipMappings), Format(Format),
-ModuleName(ModuleName), FakeMemBuffer(FakeMemBuffer) {}
+ModuleName(ModuleName) {}
 
   bool runInvocation(std::shared_ptr Invocation,
  FileManager *FileMgr,
@@ -215,16 +214,6 @@
 .ExcludedConditionalDirectiveSkipMappings = PPSkipMappings;
 }
 
-if (ModuleName.hasValue()) {
-  SmallString<128> FullPath(*ModuleName);
-  llvm::sys::fs::make_absolute(WorkingDirectory, FullPath);
-  SourceManager &SrcMgr = Compiler.getSourceManager();
-  FileMgr->getVirtualFile(FullPath.c_str(), FakeMemBuffer->getBufferSize(),
-  0);
-  FileID MainFileID = SrcMgr.createFileID(*FakeMemBuffer);
-  SrcMgr.setMainFileID(MainFileID);
-}
-
 // Create the dependency collector that will collect the produced
 // dependencies.
 //
@@ -280,7 +269,6 @@
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings;
   ScanningOutputFormat Format;
   llvm::Optional ModuleName;
-  llvm::Optional FakeMemBuffer;
 };
 
 } // end anonymous namespace
@@ -298,7 +286,12 @@
   PCHContainerOps->registerWriter(
   std::make_unique());
 
-  RealFS = llvm::vfs::createPhysicalFileSystem();
+  auto OverlayFS = llvm::makeIntrusiveRefCnt(
+  llvm::vfs::createPhysicalFileSystem());
+  MemoryFS = llvm::makeIntrusiveRefCnt();
+  OverlayFS->pushOverlay(MemoryFS);
+  RealFS = OverlayFS;
+
   if (Service.canSkipExcludedPPRanges())
 PPSkipMappings =
 std::make_unique();
@@ -329,13 +322,10 @@
 const CompilationDatabase &CDB, DependencyConsumer &Consumer,
 llvm::Optional ModuleName) {
   RealFS->setCurrentWorkingDirectory(WorkingDirectory);
-  std::unique_ptr FakeMemBuffer =
-  ModuleName.hasValue() ? llvm::MemoryBuffer::getMemBuffer(" ") : nullptr;
   return runWithDiags(DiagOpts.get(), [&](DiagnosticConsumer &DC) {
 /// Create the tool that uses the underlying file system to ensure that any
 /// file system requests that are made by the driver do not go through the
 /// dependency scanning filesystem.
-SmallString<128> FullPath;
 tooling::ClangTool Tool(CDB,
 ModuleName.hasValue() ? ModuleName->str() : Input,
 PCHContainerOps, RealFS, Files);
@@ -343,21 +333,15 @@
 Tool.setRestoreWorkingDir(false);
 Tool.setPrintErrorMessage(false);
 Tool.setDiagnosticConsumer(&DC);
-DependencyScanningAction Action(
-WorkingDirectory, Consumer, DepFS, PPSkipMappings.get(), Format,
-ModuleName,
-FakeMemBuffer
-? llvm::Optional(*FakeMemBuffer.get())
-: None);
+DependencyScanningAction Action(WorkingDirectory, Consumer, DepFS,
+PPSkipMappings.get(), Format, ModuleName);
 
 if (ModuleName.hasValue()) {
-  Tool.mapVirtualFile(*ModuleName, FakeMemBuffer->getBuffer());
-  FullPath = *ModuleName;
-  llvm::sys::fs::make_absolute(WorkingDirectory, FullPath);
+  MemoryFS->addFile(*ModuleName, 0, llvm::MemoryBuffer::getMemBuffer(" "));
   Tool.appendArgumentsAdjuster(
   [&](const tooling::CommandLineArguments &Args, StringRef FileName) {
 tooling::CommandLineArguments AdjustedArgs(Args);
-AdjustedArgs.push_back(std::string(FullPath));
+AdjustedArgs.emplace_back(*ModuleName);
 return AdjustedArgs;
   });
 }
Index: clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
===
--- clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
+++ clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
@@ -92,7 +92,10 @@
   std::shared_ptr PCHContainerOps;
   std::unique_ptr PPSk

[PATCH] D109506: [RFC] Print current request context along with the stack trance in clangd

2021-09-09 Thread Emma Blink via Phabricator via cfe-commits
0x1eaf created this revision.
0x1eaf added reviewers: sammccall, ilya-biryukov, nridge.
0x1eaf added projects: clang, clang-tools-extra.
Herald added subscribers: usaxena95, kadircet, arphaman, javed.absar, mgorny.
0x1eaf requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.

Motivation:

At the moment it is hard to attribute a clangd crash to a specific request out 
of all in-flight requests that might be processed concurrently. So before we 
can act on production clangd crashes, we have to do quite some digging through 
the log tables populated by our in-house VSCode extension or sometimes even 
directly reach out to the affected developer. Having all the details needed to 
reproduce a crash printed alongside its stack trace has a potential to save us 
quite some time, that could better be spent on fixing the actual problems.

Implementation approach:

- introduce `ThreadSignalHandler` class that allows to set a temporary signal 
handler for the current thread
- follow RAII pattern to simplify printing context for crashes occurring within 
a particular scope
- hold `std::function` as a handler to allow capturing context to print
- set local `ThreadSignalHandler` within `JSONTransport::loop()` to print 
request JSON for main thread crashes, and in `ASTWorker::run()` to print the 
file paths, arguments and contents for worker thread crashes

`ThreadSignalHandler` currently allows only one active handler per thread, but 
the approach can be extended to support stacked handlers printing context 
incrementally.

Example output for main thread crashes:

  ...
  #15 0x7f7ddc819493 __libc_start_main (/lib64/libc.so.6+0x23493)
  #16 0x0249775e _start 
(/home/emmablink/local/llvm-project/build/bin/clangd+0x249775e)
  Signalled while processing message:
  {"jsonrpc": "2.0", "method": "textDocument/didOpen", "params": 
{"textDocument": {"uri": "file:///home/emmablink/test.cpp", "languageId": 
"cpp", "version": 1, "text": "template \nclass Bar {\n  Bar 
*variables_to_modify;\n  foo() {\nfor (auto *c : *variables_to_modify)\n
  delete c;\n  }\n};\n"}}}


Example output for AST worker crashes:

  ...
  #41 0x7fb18304c14a start_thread pthread_create.c:0:0
  #42 0x7fb181bfcdc3 clone (/lib64/libc.so.6+0xfcdc3)
  Signalled during AST action:
  Filename: test.cpp
  Directory: /home/emmablink
  Command Line: /usr/bin/clang 
-resource-dir=/data/users/emmablink/llvm-project/build/lib/clang/14.0.0 -- 
/home/emmablink/test.cpp
  Version: 1
  Contents:
  template 
  class Bar {
Bar *variables_to_modify;
foo() {
  for (auto *c : *variables_to_modify)
delete c;
}
  };


Testing:

I’m not sure what is the best way to automatically test signal handling and 
would welcome suggestions. One way could be to introduce a unit test that would 
set up a `ThreadSignalHandler` and just signal itself. Another way might be to 
set up a lit test that would spawn clangd, send a message to it, signal it 
immediately and check the standard output, although this might be prone to race 
conditions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109506

Files:
  clang-tools-extra/clangd/JSONTransport.cpp
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/support/CMakeLists.txt
  clang-tools-extra/clangd/support/ThreadSignalHandler.cpp
  clang-tools-extra/clangd/support/ThreadSignalHandler.h

Index: clang-tools-extra/clangd/support/ThreadSignalHandler.h
===
--- /dev/null
+++ clang-tools-extra/clangd/support/ThreadSignalHandler.h
@@ -0,0 +1,31 @@
+//===--- ThreadSignalHandler.h - Thread local signal handling *- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include 
+
+namespace clang {
+namespace clangd {
+
+using ThreadSignalHandlerCallback = std::function;
+
+class ThreadSignalHandler {
+public:
+  ThreadSignalHandler(const ThreadSignalHandlerCallback &ThreadLocalCallback);
+  ~ThreadSignalHandler();
+
+  ThreadSignalHandler(ThreadSignalHandler &&);
+  ThreadSignalHandler(const ThreadSignalHandler &) = delete;
+  ThreadSignalHandler &operator=(ThreadSignalHandler &&) = delete;
+  ThreadSignalHandler &operator=(const ThreadSignalHandler &) = delete;
+
+private:
+  ThreadSignalHandlerCallback Callback;
+};
+
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/support/ThreadSignalHandler.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/support/ThreadSignalHandler.cpp
@@ -0,0 +1,50 @@
+//===--- ThreadSignalHandler.cpp - Thread local signal handling --*- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License 

[PATCH] D109225: [clang-nvlink-wrapper] Add documentation in clang docs

2021-09-09 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added inline comments.



Comment at: clang/docs/ClangNvlinkWrapper.rst:17
+files. It reads each input archive file to extract the archived cubin files as
+temporary files. These temporary (*.cubin) files are passed to ``nvlink``.
+

@saiislam The "(*.cubin)" appears to be causing a buildbot failure as it treats 
sphinx warnings as errors: 
https://lab.llvm.org/buildbot/#/builders/92/builds/14751


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109225

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


[PATCH] D106809: [clang-offload-bundler] Make Bundle Entry ID backward compatible

2021-09-09 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added inline comments.



Comment at: clang/test/Driver/clang-offload-bundler.c:405
+// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
+// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
+// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]

@saiislam This is causing an issue on a thinlto buildbot: 
https://lab.llvm.org/buildbot/#/builders/67/builds/4148


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106809

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


[PATCH] D108366: [clang][deps] Make resource directory deduction configurable

2021-09-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 371597.
jansvoboda11 added a comment.

Fix CI pls?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108366

Files:
  clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
  clang/test/ClangScanDeps/Inputs/resource_directory/compiler
  clang/test/ClangScanDeps/Inputs/resource_directory/mod.h
  clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
  clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
  clang/test/ClangScanDeps/resource_directory.c
  clang/tools/clang-scan-deps/ClangScanDeps.cpp


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -194,6 +194,25 @@
 "until reaching the end directive."),
 llvm::cl::init(true), llvm::cl::cat(DependencyScannerCategory));
 
+enum ResourceDirRecipeKind {
+  RDRK_ModifyCompilerPath,
+  RDRK_InvokeCompiler,
+};
+
+static llvm::cl::opt ResourceDirRecipe(
+"resource-dir-recipe",
+llvm::cl::desc("How to produce missing '-resource-dir' argument"),
+llvm::cl::values(
+clEnumValN(RDRK_ModifyCompilerPath, "modify-compiler-path",
+   "Construct the resource directory from the compiler path in 
"
+   "the compilation database. This assumes it's part of the "
+   "same toolchain as this clang-scan-deps. (default)"),
+clEnumValN(RDRK_InvokeCompiler, "invoke-compiler",
+   "Invoke the compiler with '-print-resource-dir' and use the 
"
+   "reported path as the resource directory. (deprecated)")),
+llvm::cl::init(RDRK_ModifyCompilerPath),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt Verbose("v", llvm::cl::Optional,
 llvm::cl::desc("Use verbose output."),
 llvm::cl::init(false),
@@ -485,7 +504,7 @@
   AdjustedArgs.push_back("/clang:" + LastO);
 }
 
-if (!HasResourceDir) {
+if (!HasResourceDir && ResourceDirRecipe == RDRK_InvokeCompiler) {
   StringRef ResourceDir =
   ResourceDirCache.findResourceDir(Args, ClangCLMode);
   if (!ResourceDir.empty()) {
Index: clang/test/ClangScanDeps/resource_directory.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/resource_directory.c
@@ -0,0 +1,23 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: cp %S/Inputs/resource_directory/* %t
+
+// Deduce the resource directory from the compiler path.
+//
+// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%/t|g" \
+// RUN:   %S/Inputs/resource_directory/cdb.json.template > %t/cdb_path.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_path.json --format 
experimental-full \
+// RUN:   --resource-dir-recipe modify-compiler-path > %t/result_path.json
+// RUN: cat %t/result_path.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-PATH
+// CHECK-PATH:  "-resource-dir"
+// CHECK-PATH-NEXT: "/our/custom/lib{{.*}}"
+
+// Run the compiler and ask it for the resource directory.
+//
+// RUN: chmod +x %t/compiler
+// RUN: sed -e "s|CLANG|%/t/compiler|g" -e "s|DIR|%/t|g" \
+// RUN:   %S/Inputs/resource_directory/cdb.json.template > 
%t/cdb_invocation.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_invocation.json --format 
experimental-full \
+// RUN:   --resource-dir-recipe invoke-compiler > %t/result_invocation.json
+// RUN: cat %t/result_invocation.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-INVOCATION
+// CHECK-INVOCATION:  "-resource-dir"
+// CHECK-INVOCATION-NEXT: "/custom/compiler/resources"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
@@ -0,0 +1 @@
+#include "mod.h"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
@@ -0,0 +1 @@
+module mod { header "mod.h" }
Index: clang/test/ClangScanDeps/Inputs/resource_directory/compiler
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/compiler
@@ -0,0 +1,2 @@
+#!/usr/bin/env python3
+print("/custom/compiler/resources")
Index: clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
@@ -0,0 +1,7 @@
+[
+  {
+"directory": "DIR",
+"command": "CLANG -fmodules -gmodules -fimplicit-m

[clang] bb3f5f5 - [clang] Array list initialization (pre-p0388)

2021-09-09 Thread Nathan Sidwell via cfe-commits

Author: Nathan Sidwell
Date: 2021-09-09T08:30:04-07:00
New Revision: bb3f5f5d788dd9375ab260f77612fab4a707a1ac

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

LOG: [clang] Array list initialization (pre-p0388)

Extends handling of list initialization of bounded array parameters.
This adds the missing checks on converting each initializer for both
std::initializer_list and arrays. And extends
CompareImplicitConversionSequence to compares array size, for two
conversions to array type.

As noted in this patch, there's a defect in the std concerning the
partial orderability of conversion sequences.  DR2492 has a suggested
direction that will be simple to add once it (hopefully) is accepted.

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

Added: 
clang/test/SemaCXX/overload-ary-bind.cpp

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Overload.h
clang/lib/Sema/SemaOverload.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index f8e89549f0503..824d9bf469360 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -4483,7 +4483,8 @@ def note_ovl_candidate_bad_conv_incomplete : Note<
 "; remove &}7">;
 def note_ovl_candidate_bad_list_argument : Note<
 "candidate %sub{select_ovl_candidate_kind}0,1,2 not viable: "
-"cannot convert initializer list argument to %4">;
+"%select{cannot convert initializer list|too few initializers in list"
+"|too many initializers in list}7 argument to %4">;
 def note_ovl_candidate_bad_overload : Note<
 "candidate %sub{select_ovl_candidate_kind}0,1,2 not viable: "
 "no overload of %4 matching %3 for %ordinal5 argument">;

diff  --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index 82661cb3d12ac..f16595c3319cd 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -469,7 +469,9 @@ class Sema;
   unrelated_class,
   bad_qualifiers,
   lvalue_ref_to_rvalue,
-  rvalue_ref_to_lvalue
+  rvalue_ref_to_lvalue,
+  too_few_initializers,
+  too_many_initializers,
 };
 
 // This can be null, e.g. for implicit object arguments.
@@ -533,11 +535,14 @@ class Sema;
 };
 
 /// ConversionKind - The kind of implicit conversion sequence.
-unsigned ConversionKind : 30;
+unsigned ConversionKind;
 
-/// Whether the target is really a std::initializer_list, and the
-/// sequence only represents the worst element conversion.
-unsigned StdInitializerListElement : 1;
+/// When initializing an array or std::initializer_list from an
+/// initializer-list, this is the array or std::initializer_list type being
+/// initialized. The remainder of the conversion sequence, including 
ToType,
+/// describe the worst conversion of an initializer to an element of the
+/// array or std::initializer_list. (Note, 'worst' is not well defined.)
+QualType InitializerListContainerType;
 
 void setKind(Kind K) {
   destruct();
@@ -568,13 +573,13 @@ class Sema;
 };
 
 ImplicitConversionSequence()
-: ConversionKind(Uninitialized), StdInitializerListElement(false) {
+: ConversionKind(Uninitialized), InitializerListContainerType() {
   Standard.setAsIdentityConversion();
 }
 
 ImplicitConversionSequence(const ImplicitConversionSequence &Other)
 : ConversionKind(Other.ConversionKind),
-  StdInitializerListElement(Other.StdInitializerListElement) {
+  InitializerListContainerType(Other.InitializerListContainerType) {
   switch (ConversionKind) {
   case Uninitialized: break;
   case StandardConversion: Standard = Other.Standard; break;
@@ -670,14 +675,18 @@ class Sema;
   Standard.setAllToTypes(T);
 }
 
-/// Whether the target is really a std::initializer_list, and the
-/// sequence only represents the worst element conversion.
-bool isStdInitializerListElement() const {
-  return StdInitializerListElement;
+// True iff this is a conversion sequence from an initializer list to an
+// array or std::initializer.
+bool hasInitializerListContainerType() const {
+  return !InitializerListContainerType.isNull();
 }
-
-void setStdInitializerListElement(bool V = true) {
-  StdInitializerListElement = V;
+void setInitializerListContainerType(QualType T) {
+  InitializerListContainerType = T;
+}
+QualType getInitializerListContainerType() const {
+  assert(hasInitializerListContainerType() &&
+ "not initializer list container");
+  return InitializerListContainerType;
 

[PATCH] D103088: [clang] pre-0388 array parm list initialization

2021-09-09 Thread Nathan Sidwell via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbb3f5f5d788d: [clang] Array list initialization (pre-p0388) 
(authored by urnathan).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103088

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Overload.h
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCXX/overload-ary-bind.cpp

Index: clang/test/SemaCXX/overload-ary-bind.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/overload-ary-bind.cpp
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s
+
+namespace One {
+char (&b(int(&&)[1]))[1]; // #1 expected-note{{too many initializers}}
+char (&b(int(&&)[2]))[2]; // #2 expected-note{{too many initializers}}
+
+void f() {
+  static_assert(sizeof(b({1})) == 1);// #1
+  static_assert(sizeof(b({1, 2})) == 2); // #2
+
+  b({1, 2, 3}); // expected-error{{no matching function}}
+}
+} // namespace One
+
+namespace Two {
+struct Bob {
+  Bob(int = 1);
+};
+
+char (&b(Bob(&&)[1]))[1]; // #1
+char (&b(Bob(&&)[2]))[2]; // #2
+
+void f() {
+  static_assert(sizeof(b({})) == 1); // #1
+  static_assert(sizeof(b({Bob()})) == 1);// #1
+  static_assert(sizeof(b({2, Bob()})) == 2); // #2
+}
+} // namespace Two
+
+namespace Three {
+struct Kevin {
+  Kevin(int);
+};
+
+char (&b(Kevin(&&)[2]))[2]; // #2 expected-note{{too few initializers}}
+
+void f() {
+  b({2}); // #1 expected-error{{no matching function}}
+}
+} // namespace Three
+
+namespace Four {
+char (&b(int(&&)[1], float))[1];  // #1 expected-note{{candidate}}
+char (&b(int(&&)[1], double))[2]; // #2 expected-note{{candidate}}
+
+char (&c(float, int(&&)[1]))[1];  // #1 expected-note{{candidate}}
+char (&c(double, int(&&)[1]))[2]; // #2 expected-note{{candidate}}
+
+void f() {
+  b({1}, 0); // expected-error{{is ambiguous}}
+  c(0, {1}); // expected-error{{is ambiguous}}
+}
+} // namespace Four
+
+typedef decltype(sizeof(char)) size_t;
+namespace std {
+// sufficient initializer list
+template 
+class initializer_list {
+  const _E *__begin_;
+  size_t __size_;
+
+  constexpr initializer_list(const _E *__b, size_t __s)
+  : __begin_(__b),
+__size_(__s) {}
+
+public:
+  typedef _E value_type;
+  typedef const _E &reference;
+  typedef const _E &const_reference;
+  typedef size_t size_type;
+
+  typedef const _E *iterator;
+  typedef const _E *const_iterator;
+
+  constexpr initializer_list() : __begin_(nullptr), __size_(0) {}
+
+  constexpr size_t size() const { return __size_; }
+  constexpr const _E *begin() const { return __begin_; }
+  constexpr const _E *end() const { return __begin_ + __size_; }
+};
+} // namespace std
+
+namespace Five {
+struct ugly {
+  ugly(char *);
+  ugly(int);
+};
+char (&f(std::initializer_list))[1]; // #1
+char (&f(std::initializer_list))[2];   // #2
+void g() {
+  // Pick #2 as #1 not viable (3->char * fails).
+  static_assert(sizeof(f({"hello", 3})) == 2); // expected-warning{{not allow}}
+}
+
+} // namespace Five
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -541,8 +541,8 @@
 /// error. Useful for debugging overloading issues.
 void ImplicitConversionSequence::dump() const {
   raw_ostream &OS = llvm::errs();
-  if (isStdInitializerListElement())
-OS << "Worst std::initializer_list element conversion: ";
+  if (hasInitializerListContainerType())
+OS << "Worst list element conversion: ";
   switch (ConversionKind) {
   case StandardConversion:
 OS << "Standard conversion: ";
@@ -3777,7 +3777,9 @@
 
   if (S.getLangOpts().CPlusPlus11 && !S.getLangOpts().WritableStrings &&
   hasDeprecatedStringLiteralToCharPtrConversion(ICS1) !=
-  hasDeprecatedStringLiteralToCharPtrConversion(ICS2))
+  hasDeprecatedStringLiteralToCharPtrConversion(ICS2) &&
+  // Ill-formedness must not differ
+  ICS1.isBad() == ICS2.isBad())
 return hasDeprecatedStringLiteralToCharPtrConversion(ICS1)
? ImplicitConversionSequence::Worse
: ImplicitConversionSequence::Better;
@@ -3803,16 +3805,35 @@
   // list-initialization sequence L2 if:
   // - L1 converts to std::initializer_list for some X and L2 does not, or,
   //   if not that,
-  // - L1 converts to type "array of N1 T", L2 converts to type "array of N2 T",
-  //   and N1 is smaller than N2.,
+  // — L1 and L2 convert to arrays of the same element type, and either the
+  //   number of elements n_1 initialized by L1 is less than the number of
+  //   elements n_2 initialized by L2, or (unimplemented:C++20) n_1 = n_2 a

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

2021-09-09 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield updated this revision to Diff 371605.
JonChesterfield added a comment.

- Add test checking LIBRARY_PATH is used


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc
  clang/test/Driver/Inputs/libomptarget/subdir/libomptarget-nvptx-sm_35.bc
  clang/test/Driver/amdgpu-openmp-toolchain.c
  clang/test/Driver/openmp-offload-gpu.c
  openmp/libomptarget/test/lit.cfg

Index: openmp/libomptarget/test/lit.cfg
===
--- openmp/libomptarget/test/lit.cfg
+++ openmp/libomptarget/test/lit.cfg
@@ -89,9 +89,10 @@
 config.test_flags += " -Wl,-rpath," + config.omp_host_rtl_directory
 if config.cuda_libdir:
 config.test_flags += " -Wl,-rpath," + config.cuda_libdir
-append_dynamic_library_path('LIBRARY_PATH', config.library_dir, ":")
-append_dynamic_library_path('LIBRARY_PATH', \
-config.omp_host_rtl_directory, ":")
+if config.libomptarget_current_target.startswith('amdgcn'):
+config.test_flags += " --libomptarget-amdgcn-bc-path=" + config.library_dir
+if config.libomptarget_current_target.startswith('nvptx'):
+config.test_flags += " --libomptarget-nvptx-bc-path=" + config.library_dir
 
 # substitutions
 # - for targets that exist in the system create the actual command.
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -148,28 +148,48 @@
 
 /// ###
 
-/// Check that the runtime bitcode library is part of the compile line. Create a bogus
-/// bitcode library and add it to the LIBRARY_PATH.
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+/// Check that the runtime bitcode library is part of the compile line.
+/// Create a bogus bitcode library and specify it with libomptarget-nvptx-bc-path
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime -save-temps -no-canonical-prefixes %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-BCLIB %s
+
+/// Specify the directory containing the bitcode lib, check clang picks the right one
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget \
+// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
+// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-DIR %s
+
 /// Check with the new runtime enabled
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-new-nvptx-test.bc \
+// RUN:   -save-temps -no-canonical-prefixes %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW %s
-/// The user can override default detection using --libomptarget-nvptx-bc-path=.
+
+/// Check with new runtime and specifying the directory
 // RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB-USER %s
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget -save-temps \
+// RUN:   -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW-DIR %s
 
-// CHK-BCLIB: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-nvptx-sm_35.bc
-// CHK-BCLIB-NEW: clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}libomptarget-new-nvptx-sm_35.bc
-// CHK-BCLIB-USER: clang{{.*}}-triple{{.*}}nvptx6

[PATCH] D109498: [clang][deps] Stop using `ClangTool` for virtual files

2021-09-09 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith accepted this revision.
dexonsmith added a comment.
This revision is now accepted and ready to land.

LGTM, with one nit.




Comment at: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h:98
+  /// The in-memory filesystem laid on top the physical filesystem in `RealFS`.
+  llvm::IntrusiveRefCntPtr MemoryFS;
   /// The file system that is used by each worker when scanning for

Nit: I suggest "InMemoryFS", which sounds a bit more clear to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109498

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


[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

2021-09-09 Thread Shilei Tian via Phabricator via cfe-commits
tianshilei1992 accepted this revision.
tianshilei1992 added a comment.
This revision is now accepted and ready to land.

LGTM. It's good to go if the test is green.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

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


[PATCH] D108366: [clang][deps] Make resource directory deduction configurable

2021-09-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/test/ClangScanDeps/resource_directory.c:3
+// RUN: cp %S/Inputs/resource_directory/* %t
+// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%/t|g" 
%S/Inputs/resource_directory/cdb_tu.json > %t/cdb.json
+

dexonsmith wrote:
> I don't love this hardcoded path to clang which //could// exist on some 
> machine.
> 
> Could you use `/dev/null` for the path to clang?
> Or `/dev/null/bin/clang`?
This is not a concern anymore. It used to be, since the deduction of resource 
directory based on the compiler path was only kicking in if the 
`-print-resource-dir` invocation failed (e.g. the compiler executable didn't 
exist). Since we're now explicitly passing `--resource-dir-recipe 
modify-compiler-path`, it doesn't matter if the compiler executable exists on 
the filesystem or not. We're always going to do simple string manipulation in 
this case.

For the other test-case (`--resource-dir-recipe invoke-compiler`), we're 
actually using an executable that does exist on the filesystem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108366

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


[PATCH] D108366: [clang][deps] Make resource directory deduction configurable

2021-09-09 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith accepted this revision.
dexonsmith added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: clang/test/ClangScanDeps/resource_directory.c:3
+// RUN: cp %S/Inputs/resource_directory/* %t
+// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%/t|g" 
%S/Inputs/resource_directory/cdb_tu.json > %t/cdb.json
+

jansvoboda11 wrote:
> dexonsmith wrote:
> > I don't love this hardcoded path to clang which //could// exist on some 
> > machine.
> > 
> > Could you use `/dev/null` for the path to clang?
> > Or `/dev/null/bin/clang`?
> This is not a concern anymore. It used to be, since the deduction of resource 
> directory based on the compiler path was only kicking in if the 
> `-print-resource-dir` invocation failed (e.g. the compiler executable didn't 
> exist). Since we're now explicitly passing `--resource-dir-recipe 
> modify-compiler-path`, it doesn't matter if the compiler executable exists on 
> the filesystem or not. We're always going to do simple string manipulation in 
> this case.
> 
> For the other test-case (`--resource-dir-recipe invoke-compiler`), we're 
> actually using an executable that does exist on the filesystem.
Okay. As long as existence on disk of `/custom/compiler/resources` and/or 
`/our/custom/clang` won't change behaviour of the test, I think the test is 
fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108366

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


[PATCH] D103088: [clang] pre-0388 array parm list initialization

2021-09-09 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

Commited without approval?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103088

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


[clang] 17c2948 - [clang-scan-deps] Add an API for clang dependency scanner to perform

2021-09-09 Thread Akira Hatanaka via cfe-commits

Author: Akira Hatanaka
Date: 2021-09-09T08:52:50-07:00
New Revision: 17c2948d04431e94376e8d7883b5d89fbe705b5e

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

LOG: [clang-scan-deps] Add an API for clang dependency scanner to perform
module lookup by name alone

This removes the need to create a fake source file that imports a
module.

rdar://64538073

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

Added: 
clang/test/ClangScanDeps/Inputs/modules_cdb_by_mod_name.json
clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl_by_mod_name.json
clang/test/ClangScanDeps/modules-full-by-mod-name.cpp

Modified: 
clang/include/clang/Frontend/FrontendActions.h
clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
clang/lib/Frontend/FrontendActions.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
clang/tools/clang-scan-deps/ClangScanDeps.cpp

Removed: 




diff  --git a/clang/include/clang/Frontend/FrontendActions.h 
b/clang/include/clang/Frontend/FrontendActions.h
index ff8d4417eaa49..545a7e842c4ff 100644
--- a/clang/include/clang/Frontend/FrontendActions.h
+++ b/clang/include/clang/Frontend/FrontendActions.h
@@ -299,6 +299,15 @@ class PrintPreprocessedAction : public 
PreprocessorFrontendAction {
   bool hasPCHSupport() const override { return true; }
 };
 
+class GetDependenciesByModuleNameAction : public PreprocessOnlyAction {
+  StringRef ModuleName;
+  void ExecuteAction() override;
+
+public:
+  GetDependenciesByModuleNameAction(StringRef ModuleName)
+  : ModuleName(ModuleName) {}
+};
+
 }  // end namespace clang
 
 #endif

diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
index f88dc472c80b1..c26b6e91d90ce 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
@@ -77,16 +77,18 @@ class DependencyScanningTool {
 
   /// Print out the dependency information into a string using the dependency
   /// file format that is specified in the options (-MD is the default) and
-  /// return it.
+  /// return it. If \p ModuleName isn't empty, this function returns the
+  /// dependency information of module \p ModuleName.
   ///
   /// \returns A \c StringError with the diagnostic output if clang errors
   /// occurred, dependency file contents otherwise.
   llvm::Expected
   getDependencyFile(const tooling::CompilationDatabase &Compilations,
-StringRef CWD);
+StringRef CWD, llvm::Optional ModuleName = 
None);
 
   /// Collect the full module dependency graph for the input, ignoring any
-  /// modules which have already been seen.
+  /// modules which have already been seen. If \p ModuleName isn't empty, this
+  /// function returns the full dependency information of module \p ModuleName.
   ///
   /// \param AlreadySeen This stores modules which have previously been
   ///reported. Use the same instance for all calls to this
@@ -98,7 +100,8 @@ class DependencyScanningTool {
   /// occurred, \c FullDependencies otherwise.
   llvm::Expected
   getFullDependencies(const tooling::CompilationDatabase &Compilations,
-  StringRef CWD, const llvm::StringSet<> &AlreadySeen);
+  StringRef CWD, const llvm::StringSet<> &AlreadySeen,
+  llvm::Optional ModuleName = None);
 
 private:
   DependencyScanningWorker Worker;

diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
index c6f7d239b8eb5..3ae3bcda72392 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
@@ -76,14 +76,16 @@ class DependencyScanningWorker {
 
   /// Run the dependency scanning tool for a given clang driver invocation (as
   /// specified for the given Input in the CDB), and report the discovered
-  /// dependencies to the provided consumer.
+  /// dependencies to the provided consumer. If \p ModuleName isn't empty, this
+  /// function reports the dependencies of module \p ModuleName.
   ///
   /// \returns A \c StringError with the diagnostic output if clang errors
   /// occurred, success otherwise.
   llvm::Error computeDependencies(const std::string &Input,
   StringRef WorkingDirectory,
   const Comp

[PATCH] D109485: [clang-scan-deps] Add an API for clang dependency scanner to perform module lookup by name alone

2021-09-09 Thread Akira Hatanaka via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG17c2948d0443: [clang-scan-deps] Add an API for clang 
dependency scanner to perform (authored by ahatanak).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109485

Files:
  clang/include/clang/Frontend/FrontendActions.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/test/ClangScanDeps/Inputs/modules_cdb_by_mod_name.json
  clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl_by_mod_name.json
  clang/test/ClangScanDeps/modules-full-by-mod-name.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -194,6 +194,11 @@
 "until reaching the end directive."),
 llvm::cl::init(true), llvm::cl::cat(DependencyScannerCategory));
 
+llvm::cl::opt ModuleName(
+"module-name", llvm::cl::Optional,
+llvm::cl::desc("the module of which the dependencies are to be computed"),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt Verbose("v", llvm::cl::Optional,
 llvm::cl::desc("Use verbose output."),
 llvm::cl::init(false),
@@ -544,13 +549,20 @@
 }
 // Run the tool on it.
 if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile = WorkerTools[I]->getDependencyFile(*Input, CWD);
+  auto MaybeFile = WorkerTools[I]->getDependencyFile(
+  *Input, CWD,
+  ModuleName.empty()
+  ? None
+  : llvm::Optional(ModuleName.c_str()));
   if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
  Errs))
 HadErrors = true;
 } else {
   auto MaybeFullDeps = WorkerTools[I]->getFullDependencies(
-  *Input, CWD, AlreadySeenModules);
+  *Input, CWD, AlreadySeenModules,
+  ModuleName.empty()
+  ? None
+  : llvm::Optional(ModuleName.c_str()));
   if (handleFullDependencyToolResult(Filename, MaybeFullDeps, FD,
  LocalIndex, DependencyOS, Errs))
 HadErrors = true;
Index: clang/test/ClangScanDeps/modules-full-by-mod-name.cpp
===
--- /dev/null
+++ clang/test/ClangScanDeps/modules-full-by-mod-name.cpp
@@ -0,0 +1,79 @@
+// RUN: rm -rf %t.dir
+// RUN: rm -rf %t.cdb
+// RUN: mkdir -p %t.dir
+// RUN: cp %s %t.dir/modules_cdb_input.cpp
+// RUN: cp %s %t.dir/modules_cdb_input2.cpp
+// RUN: mkdir %t.dir/Inputs
+// RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
+// RUN: cp %S/Inputs/header2.h %t.dir/Inputs/header2.h
+// RUN: cp %S/Inputs/module.modulemap %t.dir/Inputs/module.modulemap
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/modules_cdb_by_mod_name.json > %t.cdb
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/modules_cdb_clangcl_by_mod_name.json > %t_clangcl.cdb
+//
+// RUN: echo %t.dir > %t.result
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 4 -format experimental-full \
+// RUN:   -mode preprocess-minimized-sources -module-name=header1 >> %t.result
+// RUN: cat %t.result | sed 's:\?:/:g' | FileCheck --check-prefixes=CHECK %s
+//
+// RUN: echo %t.dir > %t_clangcl.result
+// RUN: clang-scan-deps -compilation-database %t_clangcl.cdb -j 4 -format experimental-full \
+// RUN:   -mode preprocess-minimized-sources -module-name=header1 >> %t_clangcl.result
+// RUN: cat %t_clangcl.result | sed 's:\?:/:g' | FileCheck --check-prefixes=CHECK %s
+
+// CHECK: [[PREFIX:.*]]
+// CHECK-NEXT: {
+// CHECK-NEXT:   "modules": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "clang-module-deps": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "context-hash": "[[HASH_H2_DINCLUDE:[A-Z0-9]+]]",
+// CHECK-NEXT:   "module-name": "header2"
+// CHECK-NEXT: }
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "clang-modulemap-file": "[[PREFIX]]/Inputs/module.modulemap",
+// CHECK-NEXT:   "command-line": [
+// CHECK-NEXT: "-cc1"
+// CHECK:  "-emit-module"
+// CHECK:  "-fmodule-name=header1"
+// CHECK:  "-fno-implicit-modules"
+// CHECK:],
+// CHECK-NEXT:   "context-hash": "[[HASH_H1_DINCLUDE:[A-Z0-9]+]]",
+// CHECK-NEXT:   "file-deps": [
+// CHECK-NEXT: "[[PREFIX]]/Inputs/header.h",
+// CHECK-NEXT: "[[PREFIX]]/Inputs/module.modulemap"

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

2021-09-09 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield updated this revision to Diff 371614.
JonChesterfield added a comment.

- rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc
  clang/test/Driver/Inputs/libomptarget/subdir/libomptarget-nvptx-sm_35.bc
  clang/test/Driver/amdgpu-openmp-toolchain.c
  clang/test/Driver/openmp-offload-gpu.c
  openmp/libomptarget/test/lit.cfg

Index: openmp/libomptarget/test/lit.cfg
===
--- openmp/libomptarget/test/lit.cfg
+++ openmp/libomptarget/test/lit.cfg
@@ -89,9 +89,10 @@
 config.test_flags += " -Wl,-rpath," + config.omp_host_rtl_directory
 if config.cuda_libdir:
 config.test_flags += " -Wl,-rpath," + config.cuda_libdir
-append_dynamic_library_path('LIBRARY_PATH', config.library_dir, ":")
-append_dynamic_library_path('LIBRARY_PATH', \
-config.omp_host_rtl_directory, ":")
+if config.libomptarget_current_target.startswith('amdgcn'):
+config.test_flags += " --libomptarget-amdgcn-bc-path=" + config.library_dir
+if config.libomptarget_current_target.startswith('nvptx'):
+config.test_flags += " --libomptarget-nvptx-bc-path=" + config.library_dir
 
 # substitutions
 # - for targets that exist in the system create the actual command.
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -148,34 +148,49 @@
 
 /// ###
 
-/// Check that the runtime bitcode library is part of the compile line. Create a bogus
-/// bitcode library and add it to the LIBRARY_PATH.
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+/// Check that the runtime bitcode library is part of the compile line.
+/// Create a bogus bitcode library and specify it with libomptarget-nvptx-bc-path
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime -save-temps -no-canonical-prefixes %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-BCLIB %s
+
+/// Specify the directory containing the bitcode lib, check clang picks the right one
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget \
+// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
+// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-DIR %s
+
 /// Check with the new runtime enabled
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-new-nvptx-test.bc \
+// RUN:   -save-temps -no-canonical-prefixes %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW %s
-/// The user can override default detection using --libomptarget-nvptx-bc-path=.
+
+/// Check with new runtime and specifying the directory
 // RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB-USER %s
-/// The user can also pass the path to the directory containing the bitcode lib
-// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget \
+
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget -save-temps \
+// RUN:   -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW-DIR %s
+
+/// Create a bogus bitcode library and find it with LIBRARY_PATH
+// RUN:   env LIBRARY_PATH=%S/Inputs/

[PATCH] D109517: [Clang][ARM][AArch64] Add support for Armv9-A, Armv9.1-A and Armv9.2-A

2021-09-09 Thread Victor Campos via Phabricator via cfe-commits
vhscampos created this revision.
Herald added subscribers: dexonsmith, hiraditya, kristof.beyls.
vhscampos requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

armv9-a, armv9.1-a and armv9.2-a can be targeted using the -march option
both in ARM and AArch64.

The Armv9-A architecture is described in the Arm® Architecture Reference
Manual Supplement Armv9, for Armv9-A architecture profile
(https://developer.arm.com/documentation/ddi0608/latest).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109517

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm-cortex-cpus.c
  clang/test/Preprocessor/aarch64-target-features.c
  clang/test/Preprocessor/arm-target-features.c
  llvm/include/llvm/ADT/Triple.h
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/lib/Support/ARMTargetParser.cpp
  llvm/lib/Support/Triple.cpp
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
  llvm/test/MC/AArch64/SME/directives-negative.s
  llvm/test/MC/AArch64/SME/directives.s
  llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
  llvm/test/MC/AArch64/SVE2/directive-arch.s
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -492,6 +492,15 @@
   EXPECT_TRUE(
   testARMArch("armv8.7-a", "generic", "v8.7a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9-a", "generic", "v9a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9.1-a", "generic", "v9.1a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9.2-a", "generic", "v9.2a",
+  ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(
   testARMArch("armv8-r", "cortex-r52", "v8r",
   ARMBuildAttrs::CPUArch::v8_R));
@@ -821,6 +830,9 @@
 case ARM::ArchKind::ARMV8_5A:
 case ARM::ArchKind::ARMV8_6A:
 case ARM::ArchKind::ARMV8_7A:
+case ARM::ArchKind::ARMV9A:
+case ARM::ArchKind::ARMV9_1A:
+case ARM::ArchKind::ARMV9_2A:
   EXPECT_EQ(ARM::ProfileKind::A, ARM::parseArchProfile(ARMArch[i]));
   break;
 default:
@@ -1204,6 +1216,12 @@
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testAArch64Arch("armv8.7-a", "generic", "v8.7a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9-a", "generic", "v9a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9.1-a", "generic", "v9.1a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9.2-a", "generic", "v9.2a",
+  ARMBuildAttrs::CPUArch::v8_A));
 }
 
 bool testAArch64Extension(StringRef CPUName, AArch64::ArchKind AK,
Index: llvm/test/MC/AArch64/SVE2/directive-arch.s
===
--- llvm/test/MC/AArch64/SVE2/directive-arch.s
+++ llvm/test/MC/AArch64/SVE2/directive-arch.s
@@ -1,21 +1,21 @@
 // RUN: llvm-mc -triple aarch64 -filetype asm -o - %s 2>&1 | FileCheck %s
 
-.arch armv8-a+sve2
+.arch armv9-a+sve2
 tbx z0.b, z1.b, z2.b
 // CHECK: tbx z0.b, z1.b, z2.b
 
-.arch armv8-a+sve2-aes
+.arch armv9-a+sve2-aes
 aesd z23.b, z23.b, z13.b
 // CHECK: aesd z23.b, z23.b, z13.b
 
-.arch armv8-a+sve2-sm4
+.arch armv9-a+sve2-sm4
 sm4e z0.s, z0.s, z0.s
 // CHECK: sm4e z0.s, z0.s, z0.s
 
-.arch armv8-a+sve2-sha3
+.arch armv9-a+sve2-sha3
 rax1 z0.d, z0.d, z0.d
 // CHECK: rax1 z0.d, z0.d, z0.d
 
-.arch armv8-a+sve2-bitperm
+.arch armv9-a+sve2-bitperm
 bgrp z21.s, z10.s, z21.s
 // CHECK: bgrp z21.s, z10.s, z21.s
Index: llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
===
--- llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
+++ llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
@@ -1,31 +1,31 @@
 // RUN: not llvm-mc -triple aarch64 -filetype asm -o - %s 2>&1 | FileCheck %s
 
-.arch armv8-a+sve2
-.arch armv8-a+nosve2
+.arch armv9-a+sve2
+.arch armv9-a+nosve2
 tbx z0.b, z1.b, z2.b
 // CHECK: error: instruction requires: streaming-sve or sve2
 // CHECK-NEXT: tbx z0.b, z1.b, z2.b
 
-.arch armv8-a+sve2-aes
-.arch ar

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

2021-09-09 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a reviewer: hjl.tools.
aaron.ballman added a subscriber: hjl.tools.
aaron.ballman added a comment.

In D108643#2965852 , @rjmccall wrote:

> In D108643#2964740 , @aaron.ballman 
> wrote:
>
>> In D108643#2964190 , @rjmccall 
>> wrote:
>>
>>> I agree with James; I know you've reached out to the Itanium ABI group 
>>> about mangling, but ABI involvement needs to mean also reaching out and 
>>> getting psABI agreement about representation.  I would suggest proposing a 
>>> generic ABI, getting consensus on that generic ABI with other implementors, 
>>> and then running that generic ABI past as many platform ABI groups as you 
>>> can get in touch with.
>>
>> I've already reached out to the psABI maintainers and have started those 
>> discussions before ever considering the mangling questions: 
>> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/21622785649f2cbacb596d135a417171f52ad539
>
> Okay.  To be clear, that's not "the psABI maintainers", that's specifically 
> the x86_64 psABI group.

Heh, you can see how out of my depths I am on the ABI topic. :-D

> Is your expectation that other psABI groups would more or less copy the 
> wording from the x86_64 psABI, potentially replacing 64 with 32 as 
> appropriate, or would you want to host a generic ABI document somewhere else? 
>  If the latter, I think the Clang repository wouldn't be an unreasonable 
> place to do that; we do something similar with blocks.

I was expecting the ABI groups to determine what's best for their respective 
ABIs; I imagined the x86-64 ABI was sufficient as a template, but I wasn't 
certain if that's appropriate. We could host a generic ABI document similar to 
what we do for blocks if that's what people felt was a good approach.

> I would be happy to put you in touch with some other psABI groups when you're 
> ready to talk to them.

Thanks! I'm kind of hoping to avoid being responsible for driving the ABI 
process with all the different ABI groups because I have no idea how much 
effort I would be signing myself up for. TBH, I was hoping a "this is a newly 
standardized type that needs ABI considerations" note would be sufficient 
because I don't have an opinion on what's best for any given ABI.

>> Note that there are some changes expected to that wording (the "bit-aligned" 
>> stuff should say "byte-aligned" and we're missing information about 
>> bit-fields), so if there are additional changes we'd like to see made, now's 
>> a good time to make them.
>
> The choice that high bits are unspecified rather than extended is an 
> interesting one.  Can you speak to that?  That's good for +, -, *, &, |, ^, 
> <<, and narrowing conversions, but bad for ==, <, /, >>, and widening 
> conversions.

I've added @hjl.tools to the review for his opinions, as he was the primary 
driver for the x64 ABI proposal. HJ, can you help me out here?

> One advantage of having a generic ABI is that you can give a rationale in the 
> document, which would be out of scope for a psABI.

Ah, good point.

>>> You can't have bit-fields of `_BitInt` type, can you?  If people want that, 
>>> or want a truly packed `_BitInt` where `sizeof(_BitInt(56)) == 7`, it's 
>>> going to add a lot of complexity.
>>
>> You can have bit-fields of _BitInt type (and we even tell you when you do 
>> dumb things with it https://godbolt.org/z/sTKKdb1o1), but I'm not seeing 
>> where the complexity comes in from that
>
> What is your expectation of how a `_BitInt` bit-field interacts with adjacent 
> bit-fields?

It's implementation-defined because the type isn't `_Bool`, `signed int`, or 
`unsigned int`, but the current behavior is that it combines at the type 
boundary rather than packing.

> Does `unsigned a: 1; _BitInt(8) b: 7;` only use 8 bits?



  sizeof(struct S {
  unsigned a: 1;
  _BitInt(8) b: 7;
});

is 4 bytes (on x64).

> Does `unsigned a: 1; _BitInt(95) b: 95;` only use 96?



  sizeof(struct S {
  unsigned a: 1;
  _BitInt(95) b: 95;
});

is 16 bytes (on x64).

> Does the latter change based on whether this is a 32-bit or 64-bit target?

It does; then it's 12 bytes.

> Does it change if the type is `_BitInt(128)` instead?

128-bit is: 24 bytes (x64) and 20 bytes (x86)
127-bit is: 16 bytes on both x64 and x86

> What is the "storage unit" of a `_BitInt` for the purposes of ABIs that are 
> sensitive to such things?

My understanding is that it's the `_BitInt` itself.

> Also, C requires the width of a bit-field to be no larger than the width of 
> the underlying type, but C++ allows "wide" bit-fields, and psABIs are 
> inconsistent about giving rules for their layout.  Does this match that where 
> supported, or is a different set of rules?

It should be the same set of rules. At least: https://godbolt.org/z/1n9qn38b7

(I should note, I've been describing the behavior Clang currently has using 
`_E

[clang] 2a58171 - [openmp] No longer use LIBRARY_PATH to find devicertl

2021-09-09 Thread Jon Chesterfield via cfe-commits

Author: Jon Chesterfield
Date: 2021-09-09T17:16:41+01:00
New Revision: 2a581710c1942b265b271e230368b1596132f242

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

LOG: [openmp] No longer use LIBRARY_PATH to find devicertl

Given D109057, change test runner to use the libomptarget-x-bc-path
argument instead of the LIBRARY_PATH environment variable to find the device
library.

Also drop the use of LIBRARY_PATH environment variable as it is far
too easy to pull in the device library from an unrelated toolchain by accident
with the current setup. No loss in flexibility to developers as the clang
commandline used here is still available.

Reviewed By: jdoerfert, tianshilei1992

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

Added: 
clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc
clang/test/Driver/Inputs/libomptarget/subdir/libomptarget-nvptx-sm_35.bc

Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/test/Driver/amdgpu-openmp-toolchain.c
clang/test/Driver/openmp-offload-gpu.c
openmp/libomptarget/test/lit.cfg

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index ca426955b7f9a..f440fd4ca33d3 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1689,6 +1689,12 @@ void tools::addOpenMPDeviceRTL(const Driver &D,
StringRef BitcodeSuffix,
const llvm::Triple &Triple) {
   SmallVector LibraryPaths;
+
+  // Add path to clang lib / lib64 folder.
+  SmallString<256> DefaultLibPath = llvm::sys::path::parent_path(D.Dir);
+  llvm::sys::path::append(DefaultLibPath, Twine("lib") + CLANG_LIBDIR_SUFFIX);
+  LibraryPaths.emplace_back(DefaultLibPath.c_str());
+
   // Add user defined library paths from LIBRARY_PATH.
   llvm::Optional LibPath =
   llvm::sys::Process::GetEnv("LIBRARY_PATH");
@@ -1700,11 +1706,6 @@ void tools::addOpenMPDeviceRTL(const Driver &D,
   LibraryPaths.emplace_back(Path.trim());
   }
 
-  // Add path to lib / lib64 folder.
-  SmallString<256> DefaultLibPath = llvm::sys::path::parent_path(D.Dir);
-  llvm::sys::path::append(DefaultLibPath, Twine("lib") + CLANG_LIBDIR_SUFFIX);
-  LibraryPaths.emplace_back(DefaultLibPath.c_str());
-
   OptSpecifier LibomptargetBCPathOpt =
   Triple.isAMDGCN() ? options::OPT_libomptarget_amdgcn_bc_path_EQ
 : options::OPT_libomptarget_nvptx_bc_path_EQ;

diff  --git 
a/clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc 
b/clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc
new file mode 100644
index 0..8b137891791fe
--- /dev/null
+++ b/clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc
@@ -0,0 +1 @@
+

diff  --git 
a/clang/test/Driver/Inputs/libomptarget/subdir/libomptarget-nvptx-sm_35.bc 
b/clang/test/Driver/Inputs/libomptarget/subdir/libomptarget-nvptx-sm_35.bc
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/amdgpu-openmp-toolchain.c 
b/clang/test/Driver/amdgpu-openmp-toolchain.c
index c21de4819a809..78fee12a5a98c 100644
--- a/clang/test/Driver/amdgpu-openmp-toolchain.c
+++ b/clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -1,6 +1,6 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: amdgpu-registered-target
-// RUN:   env LIBRARY_PATH=%S/Inputs/hip_dev_lib %clang -### 
--target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s 2>&1 \
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx906 --libomptarget-amdgcn-bc-path=%S/Inputs/hip_dev_lib %s 2>&1 \
 // RUN:   | FileCheck %s
 
 // verify the tools invocations
@@ -56,13 +56,13 @@
 // CHECK-PRINT-BINDINGS: "x86_64-unknown-linux-gnu" - "GNU::Linker", inputs: 
["[[HOST_O]]", "[[OFFLOAD_O]]"], output:
 
 // verify the llc is invoked for textual assembly output
-// RUN:   env LIBRARY_PATH=%S/Inputs/hip_dev_lib %clang -### 
--target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 -save-temps %s 2>&1 \
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx906 --libomptarget-amdgcn-bc-path=%S/Inputs/hip_dev_lib -save-temps 
%s 2>&1 \
 // RUN:   | FileCheck %s --check-prefix=CHECK-SAVE-ASM
 // CHECK-SAVE-ASM: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked.bc" 
"-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=asm" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906.s"
 // CHECK-SAVE-ASM: llc{{.*}}am

[PATCH] D109061: [openmp] No longer use LIBRARY_PATH to find devicertl

2021-09-09 Thread Jon Chesterfield 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 rG2a581710c194: [openmp] No longer use LIBRARY_PATH to find 
devicertl (authored by JonChesterfield).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109061

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/Inputs/libomptarget/libomptarget-new-nvptx-test.bc
  clang/test/Driver/Inputs/libomptarget/subdir/libomptarget-nvptx-sm_35.bc
  clang/test/Driver/amdgpu-openmp-toolchain.c
  clang/test/Driver/openmp-offload-gpu.c
  openmp/libomptarget/test/lit.cfg

Index: openmp/libomptarget/test/lit.cfg
===
--- openmp/libomptarget/test/lit.cfg
+++ openmp/libomptarget/test/lit.cfg
@@ -89,9 +89,10 @@
 config.test_flags += " -Wl,-rpath," + config.omp_host_rtl_directory
 if config.cuda_libdir:
 config.test_flags += " -Wl,-rpath," + config.cuda_libdir
-append_dynamic_library_path('LIBRARY_PATH', config.library_dir, ":")
-append_dynamic_library_path('LIBRARY_PATH', \
-config.omp_host_rtl_directory, ":")
+if config.libomptarget_current_target.startswith('amdgcn'):
+config.test_flags += " --libomptarget-amdgcn-bc-path=" + config.library_dir
+if config.libomptarget_current_target.startswith('nvptx'):
+config.test_flags += " --libomptarget-nvptx-bc-path=" + config.library_dir
 
 # substitutions
 # - for targets that exist in the system create the actual command.
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -148,34 +148,49 @@
 
 /// ###
 
-/// Check that the runtime bitcode library is part of the compile line. Create a bogus
-/// bitcode library and add it to the LIBRARY_PATH.
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+/// Check that the runtime bitcode library is part of the compile line.
+/// Create a bogus bitcode library and specify it with libomptarget-nvptx-bc-path
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime -save-temps -no-canonical-prefixes %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-BCLIB %s
+
+/// Specify the directory containing the bitcode lib, check clang picks the right one
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget \
+// RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
+// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BCLIB-DIR %s
+
 /// Check with the new runtime enabled
-// RUN:   env LIBRARY_PATH=%S/Inputs/libomptarget %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-new-nvptx-test.bc \
+// RUN:   -save-temps -no-canonical-prefixes %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-BCLIB-NEW %s
-/// The user can override default detection using --libomptarget-nvptx-bc-path=.
+
+/// Check with new runtime and specifying the directory
 // RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget/libomptarget-nvptx-test.bc \
 // RUN:   -Xopenmp-target -march=sm_35 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda \
-// RUN:   -fopenmp-relocatable-target -save-temps -no-canonical-prefixes %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-BCLIB-USER %s
-/// The user can also pass the path to the directory containing the bitcode lib
-// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget \
+
+// RUN:   -fopenmp-relocatable-target -fopenmp-target-new-runtime \
+// RUN:   --libomptarget-nvptx-bc-path=%S/Inputs/libomptarget -save-temps \
+// RUN:   -no-canonical-prefixes %s 2>&1 \
+// RUN:   | 

[PATCH] D109497: [X86][AVX] Update _mm256_loadu2_m128* intrinsics to use _mm256_set_m128* (PR51796)

2021-09-09 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper 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/D109497/new/

https://reviews.llvm.org/D109497

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


[PATCH] D104285: [analyzer] Retrieve a value from list initialization of constant array declaration in a global scope.

2021-09-09 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1692-1694
+const bool IsOneDimensionalArray =
+!isa(CAT->getElementType());
+if (IsOneDimensionalArray) {

aaron.ballman wrote:
> 
+1 for Aaron's suggestion, but then it would be really helpful to have an 
explanatory comment. E.g.:
```
if (!isa(CAT->getElementType())) { // This is a one 
dimensional array.
```



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1696
+  const llvm::APSInt &Idx = CI->getValue();
+  const uint64_t I = static_cast(Idx.getExtValue());
+  // Use `getZExtValue` because array extent can not be negative.

aaron.ballman wrote:
> 
This `static_cast` seems to be dangerous to me, it might overflow. Can't we 
compare `Idx` directly to `Extent`? I see that `Idx` is an `APSint` and 
`Extent` is an `APInt`, but  I think we should be able to handle the comparison 
on the APInt level b/c that takes care of the signedness. And the overflow 
situation should be handled as well properly with `APInt`, given from it's name 
"arbitrary precision int". In this sense I don't see why do we need `I` at all.



Comment at: clang/test/Analysis/initialization.c:1
-// RUN: %clang_cc1 -triple i386-apple-darwin10 -analyze 
-analyzer-checker=core.builtin,debug.ExprInspection -verify %s
+// RUN: %clang_cc1 -triple i386-apple-darwin10 -analyze -analyzer-config 
eagerly-assume=false  
-analyzer-checker=core.uninitialized.Assign,debug.ExprInspection -verify %s
 

I don't see how this change is related.  How could the tests work before having 
the `uninitialized.Assign` enabled before?


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

https://reviews.llvm.org/D104285

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


[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

2021-09-09 Thread H.J Lu via Phabricator via cfe-commits
hjl.tools added a comment.

>> The choice that high bits are unspecified rather than extended is an 
>> interesting one.  Can you speak to that?  That's good for +, -, *, &, |, ^, 
>> <<, and narrowing conversions, but bad for ==, <, /, >>, and widening 
>> conversions.
>
> I've added @hjl.tools to the review for his opinions, as he was the primary 
> driver for the x64 ABI proposal. HJ, can you help me out here?

Please follow up x86-64 psABI proposal with any feedbacks:

https://groups.google.com/g/x86-64-abi/c/XQiSj-zU3w8


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

https://reviews.llvm.org/D108643

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


[PATCH] D109483: [APInt] Normalize naming on keep constructors / predicate methods.

2021-09-09 Thread Chris Lattner via Phabricator via cfe-commits
lattner added inline comments.



Comment at: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3243
"Don't know how to expand this subtraction!");
-Tmp1 = DAG.getNode(ISD::XOR, dl, VT, Node->getOperand(1),
-   DAG.getConstant(APInt::getAllOnesValue(VT.getSizeInBits()), dl,
-   VT));
+Tmp1 = DAG.getNode(
+ISD::XOR, dl, VT, Node->getOperand(1),

craig.topper wrote:
> This could use DAG.getNOT if you're willing to make that change.
I'd prefer to keep this one separate, it isn't related to APInt.



Comment at: llvm/lib/Target/ARM/ARMISelLowering.cpp:12185
 else
-  OtherOp = DAG.getConstant(APInt::getAllOnesValue(VT.getSizeInBits()), dl,
-VT);
+  OtherOp = DAG.getConstant(APInt::getAllOnes(VT.getSizeInBits()), dl, VT);
 return true;

craig.topper wrote:
> I think we have DAG.getAllOnesConstant if you want to use it
Will do this in a followup



Comment at: llvm/lib/Target/Lanai/LanaiISelLowering.cpp:1403
 else
-  OtherOp =
-  DAG.getConstant(APInt::getAllOnesValue(VT.getSizeInBits()), dl, VT);
+  OtherOp = DAG.getConstant(APInt::getAllOnes(VT.getSizeInBits()), dl, VT);
 return true;

craig.topper wrote:
> I think we have DAG.getAllOnesConstant if you want to use it
Likewise



Comment at: llvm/unittests/ADT/APIntTest.cpp:29
 TEST(APIntTest, ShiftLeftByZero) {
-  APInt One = APInt::getNullValue(65) + 1;
+  APInt One = APInt::getZero(65) + 1;
   APInt Shl = One.shl(0);

craig.topper wrote:
> That's a strange way to write APInt(64, 1) unless there was some specific bug.
I agree, assume that this was testing some former bug.  Unit tests are designed 
to be weird ;-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109483

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


[PATCH] D109517: [Clang][ARM][AArch64] Add support for Armv9-A, Armv9.1-A and Armv9.2-A

2021-09-09 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added reviewers: t.p.northover, ab.
SjoerdMeijer added a comment.

Some first comments after just looking at the plumbing for these new options. 
Didn't check yet the architecture extensions for the different version.




Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:82
 
 // +sve implies +f32mm if the base architecture is v8.6A or v8.7A
 // it isn't the case in general that sve implies both f64mm and f32mm

This comment needs to be updated for v9a?



Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:413
 
-  auto V8_6Pos = llvm::find(Features, "+v8.6a");
-  if (V8_6Pos != std::end(Features))
-V8_6Pos = Features.insert(std::next(V8_6Pos), {"+i8mm", "+bf16"});
+  const char *Archs[] = {"+v8.6a", "+v8.7a", "+v9.1a", "+v9.2a"};
+  auto Pos = std::find_first_of(Features.begin(), Features.end(),

How about `+v9a`?



Comment at: clang/test/Preprocessor/aarch64-target-features.c:180
 
 // The following tests may need to be revised in the future since
 // SVE2 is currently still part of Future Architecture Technologies

Comment out of date?



Comment at: llvm/lib/Target/AArch64/AArch64.td:468
FeatureSSBS, FeatureSB, FeaturePredRes, FeatureCacheDeepPersist,
-   FeatureBranchTargetId]>;
+   FeatureBranchTargetId, FeatureRME]>;
 

Is this an unrelated change? Can this be done separately?



Comment at: llvm/unittests/Support/TargetParserTest.cpp:495
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9-a", "generic", "v9a",

I haven't looked, but in these target parser tests, do we also not need to 
check the architecture descriptions?
Copied this for example from the target parser def file:

 (ARM::AEK_SEC | ARM::AEK_MP | ARM::AEK_VIRT | ARM::AEK_HWDIVARM |
  ARM::AEK_HWDIVTHUMB | ARM::AEK_DSP | ARM::AEK_CRC | ARM::AEK_RAS |
  ARM::AEK_DOTPROD)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109517

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


[PATCH] D109526: [OpenCL][Docs] Added ref to libclcxx

2021-09-09 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia created this revision.
Anastasia added a reviewer: olestrohm.
Herald added subscribers: ebevhan, yaxunl.
Anastasia requested review of this revision.

Linked in libclcxx GitHub project page with C++ libraries for OpenCL on 
OpenCLSupport page.


https://reviews.llvm.org/D109526

Files:
  clang/docs/OpenCLSupport.rst


Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -456,3 +456,7 @@
 Note that `type_traits` is a header only library and therefore no extra
 linking step against the standard libraries is required. See full example
 in `Compiler Explorer `_.
+
+More OpenCL specific C++ library implementations built on top of libcxx
+are available in `libclcxx `_
+project.


Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -456,3 +456,7 @@
 Note that `type_traits` is a header only library and therefore no extra
 linking step against the standard libraries is required. See full example
 in `Compiler Explorer `_.
+
+More OpenCL specific C++ library implementations built on top of libcxx
+are available in `libclcxx `_
+project.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109483: [APInt] Normalize naming on keep constructors / predicate methods.

2021-09-09 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper 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/D109483/new/

https://reviews.llvm.org/D109483

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


[PATCH] D109483: [APInt] Normalize naming on keep constructors / predicate methods.

2021-09-09 Thread Chris Lattner via Phabricator via cfe-commits
lattner added a comment.

Thank you for the detailed review Craig!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109483

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


[PATCH] D109483: [APInt] Normalize naming on keep constructors / predicate methods.

2021-09-09 Thread Chris Lattner via Phabricator via cfe-commits
lattner added a comment.

I'll take care of the DAG.getAllOnesConstant change, but i'd appreciate it if 
you could look at the NOT cases.  Running tests on the DAG.getAllOnesConstant 
patch now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109483

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


[PATCH] D109526: [OpenCL][Docs] Added ref to libclcxx

2021-09-09 Thread Ole Strohm via Phabricator via cfe-commits
olestrohm accepted this revision.
olestrohm added a comment.
This revision is now accepted and ready to land.

Looks good!


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

https://reviews.llvm.org/D109526

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


[PATCH] D109470: Add "profiling" to the list of absl libraries.

2021-09-09 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel accepted this revision.
ymandel added a comment.
This revision is now accepted and ready to land.

Any idea if there's a test for this matcher that should be updated?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109470

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


[PATCH] D109470: Add "profiling" to the list of absl libraries.

2021-09-09 Thread Nilay Vaish via Phabricator via cfe-commits
nilayvaish added a comment.

In D109470#2992119 , @ymandel wrote:

> Any idea if there's a test for this matcher that should be updated?

I looked at the commit that most recently added a directory to this file: 
114c9fa0e46f7bf1d05d92da70da116b19f16911 
.  That 
one also did not update any tests.  I also looked for `isInAbseilFile` in the 
`clang-tools-extra` directory.  I did not find the function being used in any 
of the tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109470

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


[PATCH] D109506: [RFC] Print current request context along with the stack trance in clangd

2021-09-09 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Thanks for doing this, I think this is incredibly useful for debugging.
But also subtle, so please forgive a bunch of comments!

I don't think we're strictly in defined-behavior territory in much of what 
these signal handlers are doing, but neither is clang's existing crash handlers 
and they seem to work well (main difference is the thread-local access)

Also discussed this a bunch with @kadircet offline.




Comment at: clang-tools-extra/clangd/JSONTransport.cpp:114
   if (readRawMessage(JSON)) {
+ThreadSignalHandler ScopedHandler([JSON]() {
+  auto &OS = llvm::errs();

this is capturing by value, I don't think it needs to



Comment at: clang-tools-extra/clangd/JSONTransport.cpp:117
+  OS << "Signalled while processing message:\n";
+  OS << JSON << "\r\n";
+});

why \r?



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:596
+  /// Called by thread local signal handler.
+  void printRequestContextOnSignal() const;
 

naming: "context" is a bit vague (and overloaded in clangd), and we often use 
"dump" for things in a debugging context.

Maybe `dumpCurrentRequest()`?



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1380
+void ASTWorker::printRequestContextOnSignal() const {
+  auto &OS = llvm::errs();
+  OS << "Signalled during AST action:\n";

i'd probably pass this in as a param, just to move the "we're printing to 
stderr" and "we're running in a signal handler" decisions closer together.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1381
+  auto &OS = llvm::errs();
+  OS << "Signalled during AST action:\n";
+  auto &Command = FileInputs.CompileCommand;

the name of the action is available as CurrentRequest->Action, which I think is 
safe to either pass into this function or read directly here.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1383
+  auto &Command = FileInputs.CompileCommand;
+  OS << "Filename: " << Command.Filename << "\n";
+  OS << "Directory: " << Command.Directory << "\n";

nit: please indent the lines after the first to set this apart from other crash 
output a bit



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1392
+  OS << "Contents:\n";
+  OS << FileInputs.Contents << "\n";
+}

hmm, this is potentially really useful (could gather full reproducers) but also 
is going to dominate the output and make it annoying to see the stack 
traces/other details. I'm worried this may make this feature net-negative for a 
majority of users, who won't find the right parts of the output to report...

How critical do you think this is for debugging crashes in practice? (I suspect 
fairly important!)
Since we're taking liberties with async-signal-safety anyway, it might be 
possible to get this sent to a tempfile, which might be more useful. In any 
case, we might want full file dumps to be off by default outside of 
environments where anyone is likely to actually try to get the reproducers.

I'd probably suggest leaving this out of the initial patch entirely so we can 
focus on getting the rest of the mechanism right.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1392
+  OS << "Contents:\n";
+  OS << FileInputs.Contents << "\n";
+}

sammccall wrote:
> hmm, this is potentially really useful (could gather full reproducers) but 
> also is going to dominate the output and make it annoying to see the stack 
> traces/other details. I'm worried this may make this feature net-negative for 
> a majority of users, who won't find the right parts of the output to report...
> 
> How critical do you think this is for debugging crashes in practice? (I 
> suspect fairly important!)
> Since we're taking liberties with async-signal-safety anyway, it might be 
> possible to get this sent to a tempfile, which might be more useful. In any 
> case, we might want full file dumps to be off by default outside of 
> environments where anyone is likely to actually try to get the reproducers.
> 
> I'd probably suggest leaving this out of the initial patch entirely so we can 
> focus on getting the rest of the mechanism right.
another thought along the lines of reproducers (but nothing for this patch)...

If we're working on a file and have a preamble, then the headers that make up 
the preamble are relevant. In practice it's hard to reproduce bug reports we 
get because we need all their headers. If we're using a preamble then just 
dumping all the filenames it includes would make it possible for some tool to 
take the crash report and zip up a reproducer.

(This probably needs the ability to run all of the handlers for the current 
thread, not just the top of the stack, since we acquire the relevant preamble 
later)



Comment at: clang

[PATCH] D109470: Add "profiling" to the list of absl libraries.

2021-09-09 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

In D109470#2992161 , @nilayvaish 
wrote:

> In D109470#2992119 , @ymandel wrote:
>
>> Any idea if there's a test for this matcher that should be updated?
>
> I looked at the commit that most recently added a directory to this file: 
> 114c9fa0e46f7bf1d05d92da70da116b19f16911 
> .  That 
> one also did not update any tests.  I also looked for `isInAbseilFile` in the 
> `clang-tools-extra` directory.  I did not find the function being used in any 
> of the tests.

Yeah, that was my impression as well. Alas. In that case, I think it's fine to 
commit as is. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109470

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


[PATCH] D109506: [RFC] Print current request context along with the stack trance in clangd

2021-09-09 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Oops, forgot one thing: you probably want to instrument the preamble-building 
in TUScheduler (or in Preamble.cpp?), the background indexing, and code 
completion. Those all run the clang parser and should be a rich source of clang 
bugs.

Testing idea: `yes '[' | head -n 5000 | clangd --input-style=delimited` crashes 
the main thread, because the JSON parser is recursive...




Comment at: clang-tools-extra/clangd/support/ThreadSignalHandler.cpp:15
+
+static llvm::sys::ThreadLocal CurrentCallback;
+

sammccall wrote:
> sammccall wrote:
> > we assume `thread_local` in clangd (see support/Context.ccp)
> > 
> > It's possible that llvm::sys::ThreadLocal happens to play nicer with signal 
> > handlers in practice (none of these are completely safe!), but unless we've 
> > seen some concrete evidence I'd rather just have `static thread_local 
> > ThreadSignalHandlerCallback*` here
> we can quite easily support a stack of handlers, such that we dump *all* 
> living handlers on the crashing thread.
> 
> just give each ThreadSignalHandler a `ThreadSignalHandler* Next = nullptr` 
> member, and both the constructor and destructor `swap(Next, 
> CurrentCallback)`. Then CurrentCallback points to the head of a linked list 
> of handlers.
> 
> Not sure if you want to have that in this patch, but it's pretty simple so I 
> wouldn't object.
Sorry, just realized you already suggested the stacking in the patch 
description!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109506

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


[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-09-09 Thread Petr Hosek via Phabricator via cfe-commits
phosek added inline comments.



Comment at: clang/include/clang/Basic/LangOptions.def:431
 
+VALUE_LANGOPT(FuchsiaVersion, 32, 0, "Fuchsia Version")
+

This is more consistent with other options.



Comment at: clang/lib/Basic/Targets/OSTargets.h:888
   Builder.defineMacro("_GNU_SOURCE");
+
+this->PlatformName = "fuchsia";

We also want to define a `__FUCHSIA_VERSION__` so the version can be read at 
compile time.



Comment at: clang/test/Frontend/attr-availability-fuchsia.c:4
+//
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on

Would this also set the availability attribute? Can we test it? If not then 
this isn't particularly useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108592

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


[PATCH] D109470: Add "profiling" to the list of absl libraries.

2021-09-09 Thread Nilay Vaish via Phabricator via cfe-commits
nilayvaish added a comment.

ymandel@, I do not have commit access to the repo.  Can you commit this for me? 
 Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109470

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


[clang] ea685e1 - [X86][AVX] Update _mm256_loadu2_m128* intrinsics to use _mm256_set_m128* (PR51796)

2021-09-09 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2021-09-09T19:15:48+01:00
New Revision: ea685e1028c6fe9e2b0f9eb5858bcb867f75bdc8

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

LOG: [X86][AVX] Update _mm256_loadu2_m128* intrinsics to use _mm256_set_m128* 
(PR51796)

As reported on PR51796, the _mm256_loadu2_m128i in particular was inserting 
bitcasts and shuffles with different types making it trickier for some 
combines, and prevented the value tracker from identifying the shuffle 
sequences as a single insert_subvector style concat_vectors pattern.

This patch instead concatenate the 128-bit unaligned loads with 
_mm256_set_m128*, which was written to avoid the unnecessary bitcasts and only 
emits a single shuffle.

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

Added: 


Modified: 
clang/lib/Headers/avxintrin.h
clang/test/CodeGen/X86/avx-builtins.c

Removed: 




diff  --git a/clang/lib/Headers/avxintrin.h b/clang/lib/Headers/avxintrin.h
index 8709d753dced..17fe63691177 100644
--- a/clang/lib/Headers/avxintrin.h
+++ b/clang/lib/Headers/avxintrin.h
@@ -4902,8 +4902,7 @@ _mm256_setr_m128i (__m128i __lo, __m128i __hi)
 static __inline __m256 __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128(float const *__addr_hi, float const *__addr_lo)
 {
-  __m256 __v256 = _mm256_castps128_ps256(_mm_loadu_ps(__addr_lo));
-  return _mm256_insertf128_ps(__v256, _mm_loadu_ps(__addr_hi), 1);
+  return _mm256_set_m128(_mm_loadu_ps(__addr_hi), _mm_loadu_ps(__addr_lo));
 }
 
 /// Loads two 128-bit floating-point vectors of [2 x double] from
@@ -4930,8 +4929,7 @@ _mm256_loadu2_m128(float const *__addr_hi, float const 
*__addr_lo)
 static __inline __m256d __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128d(double const *__addr_hi, double const *__addr_lo)
 {
-  __m256d __v256 = _mm256_castpd128_pd256(_mm_loadu_pd(__addr_lo));
-  return _mm256_insertf128_pd(__v256, _mm_loadu_pd(__addr_hi), 1);
+  return _mm256_set_m128d(_mm_loadu_pd(__addr_hi), _mm_loadu_pd(__addr_lo));
 }
 
 /// Loads two 128-bit integer vectors from unaligned memory locations and
@@ -4955,8 +4953,7 @@ _mm256_loadu2_m128d(double const *__addr_hi, double const 
*__addr_lo)
 static __inline __m256i __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128i(__m128i_u const *__addr_hi, __m128i_u const *__addr_lo)
 {
-  __m256i __v256 = _mm256_castsi128_si256(_mm_loadu_si128(__addr_lo));
-  return _mm256_insertf128_si256(__v256, _mm_loadu_si128(__addr_hi), 1);
+   return _mm256_set_m128i(_mm_loadu_si128(__addr_hi), 
_mm_loadu_si128(__addr_lo));
 }
 
 /* SIMD store ops (unaligned) */

diff  --git a/clang/test/CodeGen/X86/avx-builtins.c 
b/clang/test/CodeGen/X86/avx-builtins.c
index 4118d6c00b37..261beb3b0d25 100644
--- a/clang/test/CodeGen/X86/avx-builtins.c
+++ b/clang/test/CodeGen/X86/avx-builtins.c
@@ -1233,30 +1233,24 @@ __m256i test_mm256_loadu_si256(__m256i* A) {
 __m256 test_mm256_loadu2_m128(float* A, float* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128
   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 

   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> poison, <8 x i32> 

-  // CHECK: shufflevector <8 x float> %{{.*}}, <8 x float> %{{.*}}, <8 x i32> 

+  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 

   return _mm256_loadu2_m128(A, B);
 }
 
 __m256d test_mm256_loadu2_m128d(double* A, double* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128d
   // CHECK: load <2 x double>, <2 x double>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x 
i32> 
   // CHECK: load <2 x double>, <2 x double>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> poison, <4 x i32> 

-  // CHECK: shufflevector <4 x double> %{{.*}}, <4 x double> %{{.*}}, <4 x 
i32> 
+  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x 
i32> 
   return _mm256_loadu2_m128d(A, B);
 }
 
 __m256i test_mm256_loadu2_m128i(__m128i* A, __m128i* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128i
   // CHECK: load <2 x i64>, <2 x i64>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
   // CHECK: load <2 x i64>, <2 x i64>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x i32> %{{.*}}, <4 x i32> poison, <8 x i32> 
-  // CHECK: shufflevector <8 x i32> %{{.*}}, <8 x i32> %{{.*}}, <8 x i32> 
+  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
   return _mm256_loadu2_m128i(A, B);
 }
 



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


[PATCH] D109497: [X86][AVX] Update _mm256_loadu2_m128* intrinsics to use _mm256_set_m128* (PR51796)

2021-09-09 Thread Simon Pilgrim 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 rGea685e1028c6: [X86][AVX] Update _mm256_loadu2_m128* 
intrinsics to use _mm256_set_m128*… (authored by RKSimon).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109497

Files:
  clang/lib/Headers/avxintrin.h
  clang/test/CodeGen/X86/avx-builtins.c


Index: clang/test/CodeGen/X86/avx-builtins.c
===
--- clang/test/CodeGen/X86/avx-builtins.c
+++ clang/test/CodeGen/X86/avx-builtins.c
@@ -1233,30 +1233,24 @@
 __m256 test_mm256_loadu2_m128(float* A, float* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128
   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 

   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> poison, <8 x i32> 

-  // CHECK: shufflevector <8 x float> %{{.*}}, <8 x float> %{{.*}}, <8 x i32> 

+  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 

   return _mm256_loadu2_m128(A, B);
 }
 
 __m256d test_mm256_loadu2_m128d(double* A, double* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128d
   // CHECK: load <2 x double>, <2 x double>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x 
i32> 
   // CHECK: load <2 x double>, <2 x double>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> poison, <4 x i32> 

-  // CHECK: shufflevector <4 x double> %{{.*}}, <4 x double> %{{.*}}, <4 x 
i32> 
+  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x 
i32> 
   return _mm256_loadu2_m128d(A, B);
 }
 
 __m256i test_mm256_loadu2_m128i(__m128i* A, __m128i* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128i
   // CHECK: load <2 x i64>, <2 x i64>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
   // CHECK: load <2 x i64>, <2 x i64>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x i32> %{{.*}}, <4 x i32> poison, <8 x i32> 
-  // CHECK: shufflevector <8 x i32> %{{.*}}, <8 x i32> %{{.*}}, <8 x i32> 
+  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
   return _mm256_loadu2_m128i(A, B);
 }
 
Index: clang/lib/Headers/avxintrin.h
===
--- clang/lib/Headers/avxintrin.h
+++ clang/lib/Headers/avxintrin.h
@@ -4902,8 +4902,7 @@
 static __inline __m256 __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128(float const *__addr_hi, float const *__addr_lo)
 {
-  __m256 __v256 = _mm256_castps128_ps256(_mm_loadu_ps(__addr_lo));
-  return _mm256_insertf128_ps(__v256, _mm_loadu_ps(__addr_hi), 1);
+  return _mm256_set_m128(_mm_loadu_ps(__addr_hi), _mm_loadu_ps(__addr_lo));
 }
 
 /// Loads two 128-bit floating-point vectors of [2 x double] from
@@ -4930,8 +4929,7 @@
 static __inline __m256d __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128d(double const *__addr_hi, double const *__addr_lo)
 {
-  __m256d __v256 = _mm256_castpd128_pd256(_mm_loadu_pd(__addr_lo));
-  return _mm256_insertf128_pd(__v256, _mm_loadu_pd(__addr_hi), 1);
+  return _mm256_set_m128d(_mm_loadu_pd(__addr_hi), _mm_loadu_pd(__addr_lo));
 }
 
 /// Loads two 128-bit integer vectors from unaligned memory locations and
@@ -4955,8 +4953,7 @@
 static __inline __m256i __DEFAULT_FN_ATTRS
 _mm256_loadu2_m128i(__m128i_u const *__addr_hi, __m128i_u const *__addr_lo)
 {
-  __m256i __v256 = _mm256_castsi128_si256(_mm_loadu_si128(__addr_lo));
-  return _mm256_insertf128_si256(__v256, _mm_loadu_si128(__addr_hi), 1);
+   return _mm256_set_m128i(_mm_loadu_si128(__addr_hi), 
_mm_loadu_si128(__addr_lo));
 }
 
 /* SIMD store ops (unaligned) */


Index: clang/test/CodeGen/X86/avx-builtins.c
===
--- clang/test/CodeGen/X86/avx-builtins.c
+++ clang/test/CodeGen/X86/avx-builtins.c
@@ -1233,30 +1233,24 @@
 __m256 test_mm256_loadu2_m128(float* A, float* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128
   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 
   // CHECK: load <4 x float>, <4 x float>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> poison, <8 x i32> 
-  // CHECK: shufflevector <8 x float> %{{.*}}, <8 x float> %{{.*}}, <8 x i32> 
+  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 
   return _mm256_loadu2_m128(A, B);
 }
 
 __m256d test_mm256_loadu2_m128d(double* A, double* B) {
   // CHECK-LABEL: test_mm256_loadu2_m128d
   // CHECK: load <2 x double>, <2 x double>* %{{.*}}, align 1{{$}}
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x i32> 
   // CHECK: load 

[PATCH] D109345: MemoryBuffer: Migrate to Expected/llvm::Error from ErrorOr/std::error_code

2021-09-09 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

In D109345#2992274 , @dexonsmith 
wrote:

> 4. One or more commits:
>   1. Migrate in-tree callers to MemoryBuffer.
>   2. Delete MemoryBufferErrorAPI alias.
> 5. Delete MemoryBufferErrorCodeAPI wrappers.

(Potentially MemoryBufferErrorAPI and MemoryBufferErrorAPI could be kept across 
an LLVM release branch boundary to help LLVM clients that use those... not sure 
how useful that'd be?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109345

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


[PATCH] D109345: MemoryBuffer: Migrate to Expected/llvm::Error from ErrorOr/std::error_code

2021-09-09 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

In D109345#2990612 , @dblaikie wrote:

> Given the amount of churn this means, though - reckon it's worth it? Reckon 
> it needs more llvm-dev thread/buy-in/etc?

I think the churn is worth since my intuition is that it has high value for 
downstreams/clients (in terms of mitigating risk/etc.). (For example, the Swift 
compiler also uses MemoryBuffer and uses `auto` quite heavily.)

Not sure if this needs more buy-in, but probably worth communicating the plan 
on llvm-dev. If nothing else, makes it easy for relevant commits to point to it 
on lists.llvm.org. Could even add a working `sed -e` or `perl` command for the 
renames?

> Any other bike-shedding for MemoryBufferCompat? (MemoryBufferDeprecated? but 
> I don't really mind)



- MemoryBufferDeprecated SGTM (more descriptive than "compat"), 
MemoryBufferLegacy would work too
- MemoryBufferErrorCodeAPI is even more descriptive -- see related idea below
- could also rename all the (relevant) functions instead of the class... but 
since these are all `static` anyway renaming the class feels easier?

Thinking the names through gave me an idea for a refined staging:

1. Add MemoryBufferErrorAPI (wrapping APIs with errorOrToExpected) and 
MemoryBufferErrorCodeAPI (alias for MemoryBuffer) in the same commit.
2. Migrate in-tree callers to MemoryBufferErrorCodeAPI (via mass rename). 
(Could even move some to MemoryBufferErrorAPI?)
3. Update MemoryBuffer to use Error/Expected APIs, change MemoryBufferErrorAPI 
to an alias of it, and leave behind MemoryBufferErrorCodeAPI (wrapping APIs 
with expectedToErrorOr).
4. One or more commits:
  1. Migrate in-tree callers to MemoryBuffer.
  2. Delete MemoryBufferErrorAPI alias.
5. Delete MemoryBufferErrorCodeAPI wrappers.

The refinement is that the new (1) is better designed for cherry-picking to a 
stable branch:

- Isolated to MemoryBuffer (no changes to callers), making conflict resolution 
trivial.
- Downstreams / clients can migrate to MemoryBufferError without integrating 
the change to the default behaviour of MemoryBuffer.
- Particularly useful for clients that want to cherry-pick/merge changes 
between a branch that builds against ToT LLVM and one that builds against a 
"stable" version that predates the transition.

The new (3) and (5) are the same as the old (2) and (4) -- isolated changes 
that are easy to revert.

(But if you're not convinced, I think my previous idea for staging would still 
be a huge help.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109345

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


[clang] 543604f - [clang-nvlink-wrapper][docs][NFC] Fix sphinx warning about asterisk

2021-09-09 Thread Saiyedul Islam via cfe-commits

Author: Saiyedul Islam
Date: 2021-09-09T23:55:15+05:30
New Revision: 543604f30eddc5c9390d0fb01b0ac67937cbba0e

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

LOG: [clang-nvlink-wrapper][docs][NFC] Fix sphinx warning about asterisk

Sphinx was giving warning on unescaped special symbol *. It was
an issue on systems treating warning as error.

Added: 


Modified: 
clang/docs/ClangNvlinkWrapper.rst

Removed: 




diff  --git a/clang/docs/ClangNvlinkWrapper.rst 
b/clang/docs/ClangNvlinkWrapper.rst
index 193c0d420a21..0505d5f678c1 100644
--- a/clang/docs/ClangNvlinkWrapper.rst
+++ b/clang/docs/ClangNvlinkWrapper.rst
@@ -14,7 +14,7 @@ This tool works as a wrapper over the ``nvlink`` program. It 
is required
 because ``nvlink`` does not support linking of archive files implicitly. It
 transparently passes every input option and object to ``nvlink`` except archive
 files. It reads each input archive file to extract the archived cubin files as
-temporary files. These temporary (*.cubin) files are passed to ``nvlink``.
+temporary files. These temporary (\*.cubin) files are passed to ``nvlink``.
 
 Use Case
 



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


[PATCH] D109225: [clang-nvlink-wrapper] Add documentation in clang docs

2021-09-09 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam marked an inline comment as done.
saiislam added inline comments.



Comment at: clang/docs/ClangNvlinkWrapper.rst:17
+files. It reads each input archive file to extract the archived cubin files as
+temporary files. These temporary (*.cubin) files are passed to ``nvlink``.
+

RKSimon wrote:
> @saiislam The "(*.cubin)" appears to be causing a buildbot failure as it 
> treats sphinx warnings as errors: 
> https://lab.llvm.org/buildbot/#/builders/92/builds/14751
Thank you!
Fixed with [[ 
https://github.com/llvm/llvm-project/commit/543604f30eddc5c9390d0fb01b0ac67937cbba0e
 | [clang-nvlink-wrapper][docs][NFC] Fix sphinx warning about asterisk ]]


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109225

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


[PATCH] D109531: [CSSPGO] Enable pseudo probe instrumentation in O0 mode.

2021-09-09 Thread Hongtao Yu via Phabricator via cfe-commits
hoy created this revision.
Herald added subscribers: modimo, wenlei, hiraditya.
hoy requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Pseudo probe instrumentation was missing from O0 build. It is needed in cases 
where some source files are built in O0 while the others are built in optimize 
mode.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109531

Files:
  clang/test/CodeGen/pseudo-probe-emit.c
  llvm/lib/Passes/PassBuilder.cpp


Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -1924,6 +1924,11 @@
 
   ModulePassManager MPM;
 
+  // Place pseudo probe instrumentation as the first pass of the pipeline to
+  // minimize the impact of optimization changes.
+  if (PGOOpt && PGOOpt->PseudoProbeForProfiling)
+MPM.addPass(SampleProfileProbePass(TM));
+
   if (PGOOpt && (PGOOpt->Action == PGOOptions::IRInstr ||
  PGOOpt->Action == PGOOptions::IRUse))
 addPGOInstrPassesForO0(
Index: clang/test/CodeGen/pseudo-probe-emit.c
===
--- clang/test/CodeGen/pseudo-probe-emit.c
+++ clang/test/CodeGen/pseudo-probe-emit.c
@@ -1,3 +1,4 @@
+// RUN: %clang_cc1 -O0 -fno-legacy-pass-manager -fpseudo-probe-for-profiling 
-debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -O2 -fno-legacy-pass-manager -fpseudo-probe-for-profiling 
-debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
 
 // Check the generation of pseudoprobe intrinsic call


Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -1924,6 +1924,11 @@
 
   ModulePassManager MPM;
 
+  // Place pseudo probe instrumentation as the first pass of the pipeline to
+  // minimize the impact of optimization changes.
+  if (PGOOpt && PGOOpt->PseudoProbeForProfiling)
+MPM.addPass(SampleProfileProbePass(TM));
+
   if (PGOOpt && (PGOOpt->Action == PGOOptions::IRInstr ||
  PGOOpt->Action == PGOOptions::IRUse))
 addPGOInstrPassesForO0(
Index: clang/test/CodeGen/pseudo-probe-emit.c
===
--- clang/test/CodeGen/pseudo-probe-emit.c
+++ clang/test/CodeGen/pseudo-probe-emit.c
@@ -1,3 +1,4 @@
+// RUN: %clang_cc1 -O0 -fno-legacy-pass-manager -fpseudo-probe-for-profiling -debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -O2 -fno-legacy-pass-manager -fpseudo-probe-for-profiling -debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
 
 // Check the generation of pseudoprobe intrinsic call
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109225: [clang-nvlink-wrapper] Add documentation in clang docs

2021-09-09 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added inline comments.



Comment at: clang/docs/ClangNvlinkWrapper.rst:17
+files. It reads each input archive file to extract the archived cubin files as
+temporary files. These temporary (*.cubin) files are passed to ``nvlink``.
+

saiislam wrote:
> RKSimon wrote:
> > @saiislam The "(*.cubin)" appears to be causing a buildbot failure as it 
> > treats sphinx warnings as errors: 
> > https://lab.llvm.org/buildbot/#/builders/92/builds/14751
> Thank you!
> Fixed with [[ 
> https://github.com/llvm/llvm-project/commit/543604f30eddc5c9390d0fb01b0ac67937cbba0e
>  | [clang-nvlink-wrapper][docs][NFC] Fix sphinx warning about asterisk ]]
Awesome - and thanks for the quick response.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109225

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


[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-09-09 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/Frontend/attr-availability-fuchsia.c:2
+// Test that `-mfuchsia-version` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -mfuchsia-version=16 -c %s -### 
|& FileCheck %s
+//

Is `|&` intentional? I think that's causing shell parse errors on Windows (same 
for the other test).

Also should this test be in `Driver` instead as it's testing the driver 
functionality?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108592

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


[PATCH] D109470: Add "profiling" to the list of absl libraries.

2021-09-09 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

In D109470#2992275 , @nilayvaish 
wrote:

> ymandel@, I do not have commit access to the repo.  Can you commit this for 
> me?  Thanks!

Sure!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109470

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


[PATCH] D109531: [CSSPGO] Enable pseudo probe instrumentation in O0 mode.

2021-09-09 Thread Lei Wang via Phabricator via cfe-commits
wlei accepted this revision.
wlei added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109531

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


[PATCH] D109315: [clang] Check unsupported types in expressions

2021-09-09 Thread Andrew Savonichev via Phabricator via cfe-commits
asavonic updated this revision to Diff 371693.
asavonic added a comment.

- Reworded the diagnostic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109315

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/OpenMP/nvptx_unsupported_type_messages.cpp
  clang/test/SemaSYCL/float128.cpp
  clang/test/SemaSYCL/int128.cpp

Index: clang/test/SemaSYCL/int128.cpp
===
--- clang/test/SemaSYCL/int128.cpp
+++ clang/test/SemaSYCL/int128.cpp
@@ -26,19 +26,22 @@
   // expected-note@+1 3{{'A' defined here}}
   __int128 A;
   Z<__int128> C;
-  // expected-error@+2 {{'A' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
-  // expected-error@+1 {{'field1' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+  // expected-error@+3 2{{expression requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
+  // expected-error@+2 {{'A' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
+  // expected-error@+1 {{'field1' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
   C.field1 = A;
-  // expected-error@+1 {{'bigfield' requires 128 bit size 'Z::BIGTYPE' (aka '__int128') type support, but device 'spir64' does not support it}}
+  // expected-error@+2 {{expression requires 128 bit size 'Z::BIGTYPE' (aka '__int128') type support, but target 'spir64' does not support it}}
+  // expected-error@+1 {{'bigfield' requires 128 bit size 'Z::BIGTYPE' (aka '__int128') type support, but target 'spir64' does not support it}}
   C.bigfield += 1.0;
 
-  // expected-error@+1 {{'A' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+  // expected-error@+1 {{'A' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
   auto foo1 = [=]() {
 __int128 AA;
 // expected-note@+2 {{'BB' defined here}}
-// expected-error@+1 {{'A' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+1 {{'A' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
 auto BB = A;
-// expected-error@+1 {{'BB' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+2 {{expression requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
+// expected-error@+1 {{'BB' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
 BB += 1;
   };
 
@@ -50,7 +53,7 @@
 void foo2(){};
 
 // expected-note@+3 {{'P' defined here}}
-// expected-error@+2 {{'P' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+2 {{'P' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
 // expected-note@+1 2{{'foo' defined here}}
 __int128 foo(__int128 P) { return P; }
 
@@ -58,7 +61,8 @@
   // expected-note@+1 {{'operator __int128' defined here}}
   struct X { operator  __int128() const; } x;
   bool a = false;
-  // expected-error@+1 {{'operator __int128' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+  // expected-error@+2 2{{expression requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
+  // expected-error@+1 {{'operator __int128' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
   a = x == __int128(0);
 }
 
@@ -74,12 +78,14 @@
   host_ok();
   kernel([=]() {
 decltype(CapturedToDevice) D;
-// expected-error@+1 {{'CapturedToDevice' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+1 {{'CapturedToDevice' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
 auto C = CapturedToDevice;
 Z<__int128> S;
-// expected-error@+1 {{'field1' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+2 {{expression requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
+// expected-error@+1 {{'field1' requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
 S.field1 += 1;
-// expected-error@+1 {{'field' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+2 {{expression requires 128 bit size '__int128' type support, but target 'spir64' does not support it}}
+// expected-error@+1 {{'field' requires 128 bit size '__int128' type su

[PATCH] D106674: Runtime for Interop directive

2021-09-09 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

We need a runtime test.

Synchronizing the asyn info object and signal out dependences will happen in 
the next revision.
So will minor edits as requested.

I commented below on some things.




Comment at: openmp/libomptarget/src/interop.cpp:13
+static omp_interop_rc_t
+__kmpc_interop_get_property_err_type(omp_interop_property_t property) {
+  switch (property) {

tianshilei1992 wrote:
> tianshilei1992 wrote:
> > tianshilei1992 wrote:
> > > There are some conventions in current `libomptarget`.
> > > 1. If a function is internal, use LLVM code style.
> > > 2. If a function is exported and exposed to compiler, it should be 
> > > `extern "C"` and use code style similar to existing functions whose name 
> > > prefix with `__tgt`.
> > > 
> > > So basically, if these functions are only visible to this file, please 
> > > format it with LLVM code style, and use anonymous name space.
> > I mean, this function doesn't have to start with `__tgt` because it is 
> > internal. Functions starting with `__tgt` are usually interface functions. 
> > From my perspective, it is better to name it as `getPropertyErrorType`, 
> > a.k.a. to use LLVM code style.
> Looks better. Can you check https://llvm.org/docs/CodingStandards.html for 
> the code style?
It's unclear given the mixed nature. Let's go with this and figure out if we 
need to rename vars later or not.



Comment at: openmp/libomptarget/src/interop.cpp:198-201
+  if (interop_type == kmp_interop_type_tasksync) {
+__kmpc_omp_wait_deps(loc_ref, gtid, ndeps, dep_list, ndeps_noalias,
+ noalias_dep_list);
+  }

RaviNarayanaswamy wrote:
> Interop object does not wait for any task from libomp.  
> Init just initializes the interop object.
> The initialization of interop object should  be done by the plugin as only 
> the plugin knows what properties are supported
> Interop object does not wait for any task from libomp. 

I don't know why you think we would not wait for libomp tasks. If we have 
dependences we need to wait for them.

> The initialization of interop object should be done by the plugin as only the 
> plugin knows what properties are supported.

It is, below. This is the generic part that then redirects to the plugin.



Comment at: openmp/libomptarget/src/interop.cpp:260-263
+  if (interop_val->interop_type == kmp_interop_type_tasksync) {
+__kmpc_omp_wait_deps(loc_ref, gtid, ndeps, dep_list, ndeps_noalias,
+ noalias_dep_list);
+  }

RaviNarayanaswamy wrote:
> You don't wait for the omp tasks.  Need to flush the queue associated with 
> the interop through the plugin
Waiting for omp task is necessary and the above should do it. Flushing and 
signaling out dependences will be added in the next revision.



Comment at: openmp/runtime/src/kmp_ftn_entry.h:1449-1494
+/// TODO: Include the `omp.h` of the current build
+/* OpenMP 5.1 interop */
+typedef intptr_t omp_intptr_t;
+
+/* 0..omp_get_num_interop_properties()-1 are reserved for 
implementation-defined
+ * properties */
+typedef enum omp_interop_property {

RaviNarayanaswamy wrote:
> Why do you have all this in openmp/runtime.  Openmp should call libomptarget 
> to get interop properties. if libomptarget is not loaded it should return 0
That is exactly what this code does, no? Look for libomptarget and redirect to 
that one, otherwise return 0.
Unsure I see your point. FWIW, this is copied from other functions we duplicate 
in libomp but that actually are part of libomptarget.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106674

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


[PATCH] D105876: OMPIRBuilder for Interop directive

2021-09-09 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LGTM,

please rebase on top of trunk and use ` ConstantInt::get(Int32, 0)` instead of 
the APInt way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105876

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


[PATCH] D109496: [clang] deprecate frelaxed-template-template-args, make it on by default

2021-09-09 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov created this revision.
Herald added subscribers: dexonsmith, dang.
mizvekov updated this revision to Diff 371538.
mizvekov edited the summary of this revision.
mizvekov added a comment.
mizvekov updated this revision to Diff 371539.
mizvekov edited the summary of this revision.
mizvekov updated this revision to Diff 371673.
mizvekov published this revision for review.
mizvekov added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

.


mizvekov added a comment.

.


mizvekov added a comment.

.


A resolution to the ambiguity issues created by P0522, which is a DR solving
CWG 150, did not come as expected, so we are just going to accept the change,
and watch how users digest it.

For now we deprecate the flag with a warning, and make it on by default.
We don't remove the flag completely in order to give users a chance to
work around any problems by disabling it.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109496

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
  clang/test/Driver/frelaxed-template-template-args.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/SemaTemplate/deduction.cpp
  clang/test/SemaTemplate/default-arguments.cpp
  clang/test/SemaTemplate/instantiate-template-template-parm.cpp
  clang/test/SemaTemplate/nested-template.cpp
  clang/test/SemaTemplate/temp_arg_template.cpp
  clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -814,7 +814,7 @@
 
   Matching template template parameters to compatible arguments
   https://wg21.link/p0522r0";>P0522R0
-  Partial (10)
+  Clang 14
 
 
   Removing deprecated dynamic exception specifications
@@ -841,14 +841,6 @@
 functions using expression syntax are no longer guaranteed to be destroyed in
 reverse construction order in that ABI.
 This is not fully supported during constant expression evaluation until Clang 12.
-
-(10): Despite being the resolution to a Defect Report, this
-feature is disabled by default in all language versions, and can be enabled
-explicitly with the flag -frelaxed-template-template-args in Clang 4
-onwards.
-The change to the standard lacks a corresponding change for template partial
-ordering, resulting in ambiguity errors for reasonable and previously-valid
-code. This issue is expected to be rectified soon.
 
 
 
Index: clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++1z -frelaxed-template-template-args %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++1z %s
 
 // expected-note@temp_arg_template_cxx1z.cpp:* 1+{{}}
 
Index: clang/test/SemaTemplate/temp_arg_template.cpp
===
--- clang/test/SemaTemplate/temp_arg_template.cpp
+++ clang/test/SemaTemplate/temp_arg_template.cpp
@@ -6,11 +6,11 @@
 
 template class X> struct B; // expected-note{{previous template template parameter is here}}
 
-template class X> struct C;  // expected-note 2{{previous non-type template parameter with type 'int' is here}}
+template class X> struct C;  // expected-note {{previous non-type template parameter with type 'int' is here}}
 
 template struct X; // expected-note{{too few template parameters in template template argument}}
 template struct Y; // expected-note{{template parameter has a different kind in template argument}}
-template struct Ylong; // expected-note{{template non-type parameter has a different type 'long' in template argument}}
+template struct Ylong;
 template struct Yref; // expected-note{{template non-type parameter has a different type 'const int &' in template argument}}
 
 namespace N {
@@ -27,7 +27,7 @@
 A *a5; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 B *a6; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 C *a7;
-C *a8; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
+C *a8;
 C *a9; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 
 template

[PATCH] D109541: Increase expected line number for ExtDebugInfo.cpp

2021-09-09 Thread Jake Egan via Phabricator via cfe-commits
Jake-Egan created this revision.
Jake-Egan 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/D109541

Files:
  clang/test/Modules/ExtDebugInfo.cpp


Index: clang/test/Modules/ExtDebugInfo.cpp
===
--- clang/test/Modules/ExtDebugInfo.cpp
+++ clang/test/Modules/ExtDebugInfo.cpp
@@ -24,6 +24,7 @@
 @import DebugCXX;
 #endif
 
+#line 50
 using DebugCXX::Struct;
 
 Struct s;
@@ -204,8 +205,7 @@
 // CHECK: ![[GLOBAL_ANON]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME:  name: "InAnonymousNamespace", {{.*}}DIFlagFwdDecl)
 
-
-// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
!{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 27)
+// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
!{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 50)
 
 // CHECK: !DICompileUnit(
 // CHECK-SAME:   splitDebugFilename:


Index: clang/test/Modules/ExtDebugInfo.cpp
===
--- clang/test/Modules/ExtDebugInfo.cpp
+++ clang/test/Modules/ExtDebugInfo.cpp
@@ -24,6 +24,7 @@
 @import DebugCXX;
 #endif
 
+#line 50
 using DebugCXX::Struct;
 
 Struct s;
@@ -204,8 +205,7 @@
 // CHECK: ![[GLOBAL_ANON]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME:  name: "InAnonymousNamespace", {{.*}}DIFlagFwdDecl)
 
-
-// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 27)
+// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 50)
 
 // CHECK: !DICompileUnit(
 // CHECK-SAME:   splitDebugFilename:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] e976fc6 - Add "profiling" to the list of absl libraries.

2021-09-09 Thread Yitzhak Mandelbaum via cfe-commits

Author: Nilay Vaish
Date: 2021-09-09T20:31:06Z
New Revision: e976fc61ecd9c789783129c1294e096f8b4b11b0

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

LOG: Add "profiling" to the list of absl libraries.

Reviewed By: ymandel

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h 
b/clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
index 335c333573f43..576cbc5711f4f 100644
--- a/clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
+++ b/clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
@@ -47,15 +47,11 @@ AST_POLYMORPHIC_MATCHER(
   if (PrefixPosition == StringRef::npos)
 return false;
   Path = Path.drop_front(PrefixPosition + AbslPrefix.size());
-  static const char *AbseilLibraries[] = {"algorithm", "base",
-  "container", "debugging",
-  "flags", "hash",
-  "iterator",  "memory",
-  "meta",  "numeric",
-  "random","status",
-  "strings",   "synchronization",
-  "time",  "types",
-  "utility"};
+  static const char *AbseilLibraries[] = {
+  "algorithm", "base", "container", "debugging", "flags",
+  "hash",  "iterator", "memory","meta",  "numeric",
+  "profiling", "random",   "status","strings",   "synchronization",
+  "time",  "types","utility"};
   return llvm::any_of(AbseilLibraries, [&](const char *Library) {
 return Path.startswith(Library);
   });



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


[PATCH] D109470: Add "profiling" to the list of absl libraries.

2021-09-09 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe976fc61ecd9: Add "profiling" to the list of absl 
libraries. (authored by nilayvaish, committed by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109470

Files:
  clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h


Index: clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
===
--- clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
+++ clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
@@ -47,15 +47,11 @@
   if (PrefixPosition == StringRef::npos)
 return false;
   Path = Path.drop_front(PrefixPosition + AbslPrefix.size());
-  static const char *AbseilLibraries[] = {"algorithm", "base",
-  "container", "debugging",
-  "flags", "hash",
-  "iterator",  "memory",
-  "meta",  "numeric",
-  "random","status",
-  "strings",   "synchronization",
-  "time",  "types",
-  "utility"};
+  static const char *AbseilLibraries[] = {
+  "algorithm", "base", "container", "debugging", "flags",
+  "hash",  "iterator", "memory","meta",  "numeric",
+  "profiling", "random",   "status","strings",   "synchronization",
+  "time",  "types","utility"};
   return llvm::any_of(AbseilLibraries, [&](const char *Library) {
 return Path.startswith(Library);
   });


Index: clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
===
--- clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
+++ clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
@@ -47,15 +47,11 @@
   if (PrefixPosition == StringRef::npos)
 return false;
   Path = Path.drop_front(PrefixPosition + AbslPrefix.size());
-  static const char *AbseilLibraries[] = {"algorithm", "base",
-  "container", "debugging",
-  "flags", "hash",
-  "iterator",  "memory",
-  "meta",  "numeric",
-  "random","status",
-  "strings",   "synchronization",
-  "time",  "types",
-  "utility"};
+  static const char *AbseilLibraries[] = {
+  "algorithm", "base", "container", "debugging", "flags",
+  "hash",  "iterator", "memory","meta",  "numeric",
+  "profiling", "random",   "status","strings",   "synchronization",
+  "time",  "types","utility"};
   return llvm::any_of(AbseilLibraries, [&](const char *Library) {
 return Path.startswith(Library);
   });
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109544: [OpenMP] Add flag for setting debug in the offloading device

2021-09-09 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 created this revision.
jhuber6 added a reviewer: jdoerfert.
Herald added subscribers: dexonsmith, dang, guansong, hiraditya, yaxunl.
jhuber6 requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

This patch introduces the flags `-fopenmp-target-debug` and
`-fopenmp-target-debug=` to set the value of a global in the device.
This will be used to enable or disable debugging features statically in
the device runtime library.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109544

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/OpenMP/target_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -244,6 +244,16 @@
   assert(OutlineInfos.empty() && "There must be no outstanding outlinings");
 }
 
+GlobalValue *OpenMPIRBuilder::createDebugKind(unsigned DebugKind) {
+  IntegerType *I32Ty = Type::getInt32Ty(M.getContext());
+  auto *GV = new GlobalVariable(
+  M, I32Ty,
+  /* isConstant = */ true, GlobalValue::PrivateLinkage,
+  ConstantInt::get(I32Ty, DebugKind), "__omp_rtl_debug_kind");
+
+  return GV;
+}
+
 Value *OpenMPIRBuilder::getOrCreateIdent(Constant *SrcLocStr,
  IdentFlag LocFlags,
  unsigned Reserve2Flags) {
Index: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
===
--- llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
+++ llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
@@ -683,6 +683,10 @@
   omp::IdentFlag Flags = omp::IdentFlag(0),
   unsigned Reserve2Flags = 0);
 
+  /// Create a global value containing the \p DebugLevel to control debuggin in
+  /// the module.
+  GlobalValue *createDebugKind(unsigned DebugLevel);
+
   /// Generate control flow and cleanup for cancellation.
   ///
   /// \param CancelFlag Flag indicating if the cancellation is performed.
Index: clang/test/OpenMP/target_debug_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/target_debug_codegen.cpp
@@ -0,0 +1,51 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --check-globals --replace-value-regex "__omp_offloading_[0-9a-z]+_[0-9a-z]+"
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-target-debug -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-target-debug=111 -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix=CHECK-EQ
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+//.
+// CHECK: @__omp_rtl_debug_kind = private constant i32 1
+// CHECK: @0 = private unnamed_addr constant [23 x i8] c"
+// CHECK: @1 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @0, i32 0, i32 0) }, align 8
+// CHECK: @__omp_offloading_fd02_6044f55e__Z3foov_l25_exec_mode = weak constant i8 1
+// CHECK: @llvm.compiler.used = appending global [1 x i8*] [i8* @__omp_offloading_fd02_6044f55e__Z3foov_l25_exec_mode], section "llvm.metadata"
+//.
+// CHECK-EQ: @__omp_rtl_debug_kind = private constant i32 111
+// CHECK-EQ: @0 = private unnamed_addr constant [23 x i8] c"
+// CHECK-EQ: @1 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @0, i32 0, i32 0) }, align 8
+// CHECK-EQ: @__omp_offloading_fd02_6044f55e__Z3foov_l25_exec_mode = weak constant i8 1
+// CHECK-EQ: @llvm.compiler.used = appending global [1 x i8*] [i8* @__omp_offloading_fd02_6044f55e__Z3foov_l25_exec_mode], section "llvm.metadata"
+//.
+void foo() {
+#pragma omp target
+  { }
+}
+
+#endif
+//
+//
+//
+//.
+// CHECK: attributes #0 = { convergent noinline norecurse nounwind optnone "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-features"="+ptx32,+sm_20" }
+//.
+

[PATCH] D109544: [OpenMP] Add flag for setting debug in the offloading device

2021-09-09 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3895
+  Opts.OpenMPTargetDebug = 1;
+  }
+

CUDANumSMs? 

Don't check for NVPTX/AMDGCN but only if the new runtime is used, if not emit a 
warning that the flag is useless and ignored without the new runtime.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:254
+
+  return GV;
+}

Linkage cannot be private, I think. It might be ok if we put it in the 
llvm.used global otherwise we should just make it external, which is probably 
best.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109544

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


[PATCH] D109531: [CSSPGO] Enable pseudo probe instrumentation in O0 mode.

2021-09-09 Thread Wenlei He via Phabricator via cfe-commits
wenlei added a comment.

The change makes sense given instr PGO also happens for O0. But practically, if 
a file is being built with O0, do we care about its profile given we're not 
really optimizing it anyways? Functions from O0 modules are not supposed to be 
inlined into O1 + modules either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109531

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


[PATCH] D109411: [clang] Enable the special enable_if_t diagnostics for libc++'s __enable_if_t as well.

2021-09-09 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

In D109411#2990494 , @dblaikie wrote:

> Looks like most of the testing for the enable_if custom dialog was added in 
> `clang/test/SemaTemplate/overload-candidates.cpp` in 
> rG6f8d2c6c9c3451effdf075a7034bbe77045bfeba 
> . 
> (improved in rG00fa10b43f25d98e88cc81b653dfe8d49327722d 
>  - 
> though no substantially novel test coverage added, just updating the improved 
> diagnostic text) - maybe pull that test coverage over into this new dedicated 
> test file? But no big deal.

Yeah, I noticed those changed-but-not-really-added tests over there. I did 
deliberately make a new file because I wanted it to explicitly test alias 
templates like `enable_if_t`, whereas `overload-candidates.cpp` runs in C++98 
and thus cannot contain alias templates. I don't know if the existing tests are 
adding super much value, but I don't think it would add any //more// value to 
pull them over into this new file (in fact we'd have to stop running them in 
C++98 mode), and I'm not confident enough that they add //zero// value to go 
entirely remove them. So, status quo is I just left them alone.

Anyone particularly want to jump in here? because otherwise I think I'll land 
this tomorrow-ish.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109411

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


  1   2   >