[PATCH] D89972: Add pipeline model for HiSilicon's TSV110

2020-10-29 Thread Bryan Chan via Phabricator via cfe-commits
bryanpkc added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64SchedTSV110.td:9
+//
+// This file defines the machine model for ARM Huawei TSV110 to support
+// instruction scheduling and other instruction cost heuristics.

I suggest deleting the word `ARM` here to avoid confusion.



Comment at: llvm/lib/Target/AArch64/AArch64SchedTSV110.td:28
+  list UnsupportedFeatures = !listconcat(SVEUnsupported.F,
+   PAUnsupported.F);
+}

Indent to align with the previous argument?



Comment at: llvm/lib/Target/AArch64/AArch64SchedTSV110.td:53
+
+//Integer ALU
+def : WriteRes { let Latency = 1; }

Nit: Leave a space after the `//` delimiter.



Comment at: llvm/lib/Target/AArch64/AArch64SchedTSV110.td:128
+
+// Detailed Refinedments
+//===--===//

Type: `Refinements`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89972

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


[PATCH] D84604: Thread safety analysis: Consider global variables in scope

2020-10-29 Thread Jordan Rupprecht via Phabricator via cfe-commits
rupprecht added a comment.

In D84604#2363445 , @aaronpuchert 
wrote:

> Pushed a fix in rGbbed8cfe80cd27d3a47d877c7608d9be4e487d97 
> . For 
> now we just consider all static members as inaccessible, so we'll treat them 
> as we did before this change.

I can confirm this fixes the breakage -- thanks!

> I have proposed making the check stronger for non-static members in D87194 
> , perhaps it makes sense to extend this to 
> static members as well so that it fires on `DoStuff()` again.

I applied D87194  locally and rebuilt the 
original source, and not only am I seeing the original issue (also firing on 
`DoThings()` when it should only be on `DoStuff()`), I'm also seeing: `error: 
acquiring mutex 'lock' requires negative capability '!lock' 
[-Werror,-Wthread-safety-negative]`, where `lock` is a local variable, defined 
as `MutexLock lock(mutex_)`.

I'll work on getting a better repro for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84604

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


[clang] edd6ed3 - [NFC] Don't run clang/bindings/python/tests with msan

2020-10-29 Thread Vitaly Buka via cfe-commits

Author: Vitaly Buka
Date: 2020-10-29T22:29:25-07:00
New Revision: edd6ed364151adf3f0eede3d6d22db1018bfd601

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

LOG: [NFC] Don't run clang/bindings/python/tests with msan

Fixes check-all with LLVM_USE_SANITIZER=Memory

Added: 


Modified: 
clang/bindings/python/tests/CMakeLists.txt

Removed: 




diff  --git a/clang/bindings/python/tests/CMakeLists.txt 
b/clang/bindings/python/tests/CMakeLists.txt
index 3f58c4bde8e7..46dafa57dea1 100644
--- a/clang/bindings/python/tests/CMakeLists.txt
+++ b/clang/bindings/python/tests/CMakeLists.txt
@@ -15,14 +15,13 @@ if(NOT LLVM_ENABLE_PIC)
   set(RUN_PYTHON_TESTS FALSE)
 endif()
 
-# Do not try to run if libclang was built with ASan because
+# Do not try to run if libclang was built with ASan/MSan because
 # the sanitizer library will likely be loaded too late to perform
 # interception and will then fail.
 # We could use LD_PRELOAD/DYLD_INSERT_LIBRARIES but this isn't
 # portable so its easier just to not run the tests when building
 # with ASan.
-list(FIND LLVM_USE_SANITIZER "Address" LLVM_USE_ASAN_INDEX)
-if(NOT LLVM_USE_ASAN_INDEX EQUAL -1)
+if(LLVM_USE_SANITIZER MATCHES ".*(Memory|Address).*")
   set(RUN_PYTHON_TESTS FALSE)
 endif()
 



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


[PATCH] D88295: [Sema] Fix volatile check when test if a return object can be implicitly move

2020-10-29 Thread Yang Fan via Phabricator via cfe-commits
nullptr.cpp added a comment.

In D88295#2358845 , @aaronpuchert 
wrote:

> Could you perhaps integrate this into the existing test 
> `clang/test/CXX/special/class.copy/implicit-move.cpp` instead? 
> Whenever you have something that closely corresponds to the standard, CXX is 
> probably the right place for a test.

`clang/test/CXX/special/class.copy/implicit-move.cpp` and 
`clang/test/CXX/special/class.copy/implicit-move-def.cpp` are tests for 
implicit (non-)declaration of move constructor and assignment, they have 
nothing to do with this patch.
Because `copy/move elision` is defined in section [class.copy.elision] in 
standard, so I put the test in 
`clang/test/CXX/special/class.copy/copy-elision.cpp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88295

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


[PATCH] D88295: [Sema] Fix volatile check when test if a return object can be implicitly move

2020-10-29 Thread Yang Fan via Phabricator via cfe-commits
nullptr.cpp updated this revision to Diff 301810.
nullptr.cpp added a comment.

make test more clearly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88295

Files:
  clang/lib/Sema/SemaStmt.cpp
  clang/test/CXX/special/class.copy/copy-elision.cpp


Index: clang/test/CXX/special/class.copy/copy-elision.cpp
===
--- /dev/null
+++ clang/test/CXX/special/class.copy/copy-elision.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -std=c++20 -emit-llvm -triple x86_64-unknown-linux-gnu -o - 
%s | FileCheck %s
+// RUN: %clang_cc1 -std=c++17 -emit-llvm -triple x86_64-unknown-linux-gnu -o - 
%s | FileCheck %s
+// RUN: %clang_cc1 -std=c++14 -emit-llvm -triple x86_64-unknown-linux-gnu -o - 
%s | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -emit-llvm -triple x86_64-unknown-linux-gnu -o - 
%s | FileCheck %s
+
+// - volatile object in return statement don't match the rule for using move
+//   operation instead of copy operation. Thus should call the copy constructor
+//   A(const volatile A &).
+//
+// - volatile object in return statement also don't match the rule for copy
+//   elision. Thus the copy constructor A(const volatile A &) cannot be elided.
+namespace test_volatile {
+class A {
+public:
+  A() {}
+  ~A() {}
+  A(const volatile A &);
+  A(volatile A &&);
+};
+
+A test() {
+  volatile A a_copy;
+  // CHECK: call void @_ZN13test_volatile1AC1ERVKS0_
+  return a_copy;
+}
+} // namespace test_volatile
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3059,12 +3059,13 @@
   // variable will no longer be used.
   if (VD->hasAttr()) return false;
 
+  // ...non-volatile...
+  if (VD->getType().isVolatileQualified())
+return false;
+
   if (CESK & CES_AllowDifferentTypes)
 return true;
 
-  // ...non-volatile...
-  if (VD->getType().isVolatileQualified()) return false;
-
   // Variables with higher required alignment than their type's ABI
   // alignment cannot use NRVO.
   if (!VD->getType()->isDependentType() && VD->hasAttr() &&


Index: clang/test/CXX/special/class.copy/copy-elision.cpp
===
--- /dev/null
+++ clang/test/CXX/special/class.copy/copy-elision.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -std=c++20 -emit-llvm -triple x86_64-unknown-linux-gnu -o - %s | FileCheck %s
+// RUN: %clang_cc1 -std=c++17 -emit-llvm -triple x86_64-unknown-linux-gnu -o - %s | FileCheck %s
+// RUN: %clang_cc1 -std=c++14 -emit-llvm -triple x86_64-unknown-linux-gnu -o - %s | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -emit-llvm -triple x86_64-unknown-linux-gnu -o - %s | FileCheck %s
+
+// - volatile object in return statement don't match the rule for using move
+//   operation instead of copy operation. Thus should call the copy constructor
+//   A(const volatile A &).
+//
+// - volatile object in return statement also don't match the rule for copy
+//   elision. Thus the copy constructor A(const volatile A &) cannot be elided.
+namespace test_volatile {
+class A {
+public:
+  A() {}
+  ~A() {}
+  A(const volatile A &);
+  A(volatile A &&);
+};
+
+A test() {
+  volatile A a_copy;
+  // CHECK: call void @_ZN13test_volatile1AC1ERVKS0_
+  return a_copy;
+}
+} // namespace test_volatile
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3059,12 +3059,13 @@
   // variable will no longer be used.
   if (VD->hasAttr()) return false;
 
+  // ...non-volatile...
+  if (VD->getType().isVolatileQualified())
+return false;
+
   if (CESK & CES_AllowDifferentTypes)
 return true;
 
-  // ...non-volatile...
-  if (VD->getType().isVolatileQualified()) return false;
-
   // Variables with higher required alignment than their type's ABI
   // alignment cannot use NRVO.
   if (!VD->getType()->isDependentType() && VD->hasAttr() &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D90441: [X86] Add support for vex, vex2, vex3, and evex for MASM

2020-10-29 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei added inline comments.



Comment at: clang/test/CodeGen/X86/ms-inline-asm-prefix.c:1
+// RUN:%clang_cc1 %s -ferror-limit 0 -triple=x86_64-pc-widows-msvc 
-target-feature +avx512f -target-feature +avx2 -target-feature +avx512vl 
-fasm-blocks -mllvm -x86-asm-syntax=intel -S -o -  | FileCheck %s -check-prefix 
CHECK
+

Maybe need `// REQUIRES: x86-registered-target`



Comment at: clang/test/CodeGen/X86/ms-inline-asm-prefix.c:1
+// RUN:%clang_cc1 %s -ferror-limit 0 -triple=x86_64-pc-widows-msvc 
-target-feature +avx512f -target-feature +avx2 -target-feature +avx512vl 
-fasm-blocks -mllvm -x86-asm-syntax=intel -S -o -  | FileCheck %s -check-prefix 
CHECK
+

pengfei wrote:
> Maybe need `// REQUIRES: x86-registered-target`
You may need add att check too since you modified the att code.



Comment at: clang/test/CodeGen/X86/ms-inline-asm-prefix.c:1
+// RUN:%clang_cc1 %s -ferror-limit 0 -triple=x86_64-pc-widows-msvc 
-target-feature +avx512f -target-feature +avx2 -target-feature +avx512vl 
-fasm-blocks -mllvm -x86-asm-syntax=intel -S -o -  | FileCheck %s -check-prefix 
CHECK
+

pengfei wrote:
> pengfei wrote:
> > Maybe need `// REQUIRES: x86-registered-target`
> You may need add att check too since you modified the att code.
Should it be avalible only when `-fms-compatibility`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90441

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


[PATCH] D90441: [X86] Add support for vex, vex2, vex3, and evex for MASM

2020-10-29 Thread LiuChen via Phabricator via cfe-commits
LiuChen3 created this revision.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya.
Herald added projects: clang, LLVM.
LiuChen3 requested review of this revision.

For MASM syntax, the prefixes are not enclosed in braces.
The assembly code should like:

  "evex vcvtps2pd xmm0, xmm1"

There are still some avx512 tests need to be improved with 'evex'
prefix. But I think it's better to discuss this syntax first.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90441

Files:
  clang/test/CodeGen/X86/ms-inline-asm-prefix.c
  llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
  llvm/lib/Target/X86/MCTargetDesc/X86ATTInstPrinter.cpp
  llvm/lib/Target/X86/MCTargetDesc/X86InstPrinterCommon.cpp
  llvm/lib/Target/X86/MCTargetDesc/X86IntelInstPrinter.cpp

Index: llvm/lib/Target/X86/MCTargetDesc/X86IntelInstPrinter.cpp
===
--- llvm/lib/Target/X86/MCTargetDesc/X86IntelInstPrinter.cpp
+++ llvm/lib/Target/X86/MCTargetDesc/X86IntelInstPrinter.cpp
@@ -42,6 +42,17 @@
 raw_ostream ) {
   printInstFlags(MI, OS);
 
+  unsigned Flags = MI->getFlags();
+  // These all require a pseudo prefix
+  if (Flags & X86::IP_USE_VEX)
+OS << "\tvex";
+  else if (Flags & X86::IP_USE_VEX2)
+OS << "\tvex2";
+  else if (Flags & X86::IP_USE_VEX3)
+OS << "\tvex3";
+  else if (Flags & X86::IP_USE_EVEX)
+OS << "\tevex";
+
   // In 16-bit mode, print data16 as data32.
   if (MI->getOpcode() == X86::DATA16_PREFIX &&
   STI.getFeatureBits()[X86::Mode16Bit]) {
Index: llvm/lib/Target/X86/MCTargetDesc/X86InstPrinterCommon.cpp
===
--- llvm/lib/Target/X86/MCTargetDesc/X86InstPrinterCommon.cpp
+++ llvm/lib/Target/X86/MCTargetDesc/X86InstPrinterCommon.cpp
@@ -346,21 +346,6 @@
 O << "\trepne\t";
   else if (Flags & X86::IP_HAS_REPEAT)
 O << "\trep\t";
-
-  // These all require a pseudo prefix
-  if (Flags & X86::IP_USE_VEX)
-O << "\t{vex}";
-  else if (Flags & X86::IP_USE_VEX2)
-O << "\t{vex2}";
-  else if (Flags & X86::IP_USE_VEX3)
-O << "\t{vex3}";
-  else if (Flags & X86::IP_USE_EVEX)
-O << "\t{evex}";
-
-  if (Flags & X86::IP_USE_DISP8)
-O << "\t{disp8}";
-  else if (Flags & X86::IP_USE_DISP32)
-O << "\t{disp32}";
 }
 
 void X86InstPrinterCommon::printVKPair(const MCInst *MI, unsigned OpNo,
Index: llvm/lib/Target/X86/MCTargetDesc/X86ATTInstPrinter.cpp
===
--- llvm/lib/Target/X86/MCTargetDesc/X86ATTInstPrinter.cpp
+++ llvm/lib/Target/X86/MCTargetDesc/X86ATTInstPrinter.cpp
@@ -48,6 +48,22 @@
 
   printInstFlags(MI, OS);
 
+  unsigned Flags = MI->getFlags();
+  // These all require a pseudo prefix
+  if (Flags & X86::IP_USE_VEX)
+OS << "\t{vex}";
+  else if (Flags & X86::IP_USE_VEX2)
+OS << "\t{vex2}";
+  else if (Flags & X86::IP_USE_VEX3)
+OS << "\t{vex3}";
+  else if (Flags & X86::IP_USE_EVEX)
+OS << "\t{evex}";
+
+  if (Flags & X86::IP_USE_DISP8)
+OS << "\t{disp8}";
+  else if (Flags & X86::IP_USE_DISP32)
+OS << "\t{disp32}";
+
   // Output CALLpcrel32 as "callq" in 64-bit mode.
   // In Intel annotation it's always emitted as "call".
   //
Index: llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
===
--- llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
+++ llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
@@ -2847,7 +2847,30 @@
   }
   continue;
 }
-
+// Parse MASM style pseudo prefixes.
+if (isParsingIntelSyntax()) {
+  bool IsPrefix = false;
+  if (Name == "vex" || Name == "vex2") {
+ForcedVEXEncoding = VEXEncoding_VEX;
+IsPrefix = true;
+  }
+  else if (Name == "vex3") {
+ForcedVEXEncoding = VEXEncoding_VEX3;
+IsPrefix = true;
+  }
+  else if (Name == "evex") {
+ForcedVEXEncoding = VEXEncoding_EVEX;
+IsPrefix = true;
+  }
+  if (IsPrefix) {
+NameLoc = Parser.getTok().getLoc();
+if (getLexer().isNot(AsmToken::Identifier))
+  return Error(Parser.getTok().getLoc(), "Expected identifier");
+// FIXME: The mnemonic won't match correctly if its not in lower case.
+Name = Parser.getTok().getString();
+Parser.Lex();
+  }
+}
 break;
   }
 
@@ -4146,10 +4169,16 @@
 
   MCInst Inst;
 
-  // If VEX3 encoding is forced, we need to pass the USE_VEX3 flag to the
-  // encoder.
-  if (ForcedVEXEncoding == VEXEncoding_VEX3)
+  // If VEX/EVEX encoding is forced, we need to pass the USE_* flag to the
+  // encoder and printer.
+  if (ForcedVEXEncoding == VEXEncoding_VEX)
+Prefixes |= X86::IP_USE_VEX;
+  else if (ForcedVEXEncoding == VEXEncoding_VEX2)
+Prefixes |= X86::IP_USE_VEX2;
+  else if (ForcedVEXEncoding == VEXEncoding_VEX3)
 Prefixes |= X86::IP_USE_VEX3;
+  else if (ForcedVEXEncoding == VEXEncoding_EVEX)
+

Re: [clang] 552c6c2 - PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.

2020-10-29 Thread Richard Smith via cfe-commits
On Thu, 29 Oct 2020 at 19:32, Nico Weber  wrote:

> On Thu, Oct 29, 2020 at 6:10 PM Richard Smith 
> wrote:
>
>> On Thu, 29 Oct 2020 at 08:07, Nico Weber  wrote:
>>
>>> Hi Richard,
>>>
>>> this fires on
>>>
>>> thakis@thakis:~/src/llvm-project$ cat foo.m
>>> static const int gSignals[] = { 0, 1, 2, 3, 4 };
>>> static const int kNumSignals = sizeof(gSignals) / sizeof(gSignals[0]);
>>> static int gPreviousSignalHandlers[kNumSignals];
>>>
>>> thakis@thakis:~/src/llvm-project$ out/gn/bin/clang -c foo.m
>>> foo.m:3:12: warning: variable length array folded to constant array as
>>> an extension [-Wgnu-folding-constant]
>>> static int gPreviousSignalHandlers[kNumSignals];
>>>^
>>> 1 warning generated.
>>>
>>>
>>> Is that intentional? I don't see the VLA there.
>>>
>>
>> gPreviousSignalHandlers is a VLA. Unlike C++, C doesn't permit the use of
>> a 'const int' variable in a constant expression.
>>
>
> What's the suggested alternative?
>

This should work reliably:

-static const int kNumSignals = sizeof(gSignals) / sizeof(gSignals[0]);
+enum { kNumSignals = sizeof(gSignals) / sizeof(gSignals[0]) };


> On Fri, Oct 16, 2020 at 5:34 PM Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>

 Author: Richard Smith
 Date: 2020-10-16T14:34:35-07:00
 New Revision: 552c6c2328723a248c2b4d2765f75d49129dff20

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

 LOG: PR44406: Follow behavior of array bound constant folding in more
 recent versions of GCC.

 Old GCC used to aggressively fold VLAs to constant-bound arrays at block
 scope in GNU mode. That's non-conforming, and more modern versions of
 GCC only do this at file scope. Update Clang to do the same.

 Also promote the warning for this from off-by-default to on-by-default
 in all cases; more recent versions of GCC likewise warn on this by
 default.

 This is still slightly more permissive than GCC, as pointed out in
 PR44406, as we still fold VLAs to constant arrays in structs, but that
 seems justifiable given that we don't support VLA-in-struct (and don't
 intend to ever support it), but GCC does.

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

 Added:


 Modified:
 clang/docs/UsersManual.rst
 clang/include/clang/Basic/DiagnosticSemaKinds.td
 clang/lib/Sema/SemaDecl.cpp
 clang/lib/Sema/SemaType.cpp
 clang/test/CXX/basic/basic.types/p10.cpp
 clang/test/CXX/drs/dr3xx.cpp
 clang/test/CodeGen/vla.c
 clang/test/Misc/warning-flags.c
 clang/test/PCH/cxx-constexpr.cpp
 clang/test/Profile/misexpect-switch-default.c
 clang/test/Profile/misexpect-switch-nonconst.c
 clang/test/Profile/misexpect-switch-only-default-case.c
 clang/test/Profile/misexpect-switch.c
 clang/test/Sema/builtin-assume.c
 clang/test/Sema/builtins.c
 clang/test/Sema/complex-int.c
 clang/test/Sema/const-eval-64.c
 clang/test/Sema/const-eval.c
 clang/test/Sema/darwin-align-cast.c
 clang/test/Sema/decl-in-prototype.c
 clang/test/Sema/gnu-flags.c
 clang/test/Sema/i-c-e.c
 clang/test/Sema/offsetof-64.c
 clang/test/Sema/rounding-math.c
 clang/test/Sema/struct-decl.c
 clang/test/Sema/typedef-variable-type.c
 clang/test/Sema/vla.c
 clang/test/SemaCXX/anonymous-struct.cpp
 clang/test/SemaCXX/constant-expression.cpp
 clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
 clang/test/SemaCXX/i-c-e-cxx.cpp
 clang/test/SemaObjC/gcc-cast-ext.m

 Removed:




 
 diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
 index 473fbb6d8d04..9726a25f7f63 100644
 --- a/clang/docs/UsersManual.rst
 +++ b/clang/docs/UsersManual.rst
 @@ -2502,10 +2502,6 @@ Differences between all ``c*`` and ``gnu*``
 modes:
  -  The Apple "blocks" extension is recognized by default in ``gnu*``
 modes
 on some platforms; it can be enabled in any mode with the
 ``-fblocks``
 option.
 --  Arrays that are VLA's according to the standard, but which can be
 -   constant folded by the frontend are treated as fixed size arrays.
 -   This occurs for things like "int X[(1, 2)];", which is technically a
 -   VLA. ``c*`` modes are strictly compliant and treat these as VLAs.

  Differences between ``*89`` and ``*94`` modes:

 @@ -2594,10 +2590,12 @@ Intentionally unsupported GCC extensions
 the extension appears to be rarely used. Note that clang *does*
 support flexible array members 

Re: [clang] 552c6c2 - PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.

2020-10-29 Thread Nico Weber via cfe-commits
On Thu, Oct 29, 2020 at 6:10 PM Richard Smith  wrote:

> On Thu, 29 Oct 2020 at 08:07, Nico Weber  wrote:
>
>> Hi Richard,
>>
>> this fires on
>>
>> thakis@thakis:~/src/llvm-project$ cat foo.m
>> static const int gSignals[] = { 0, 1, 2, 3, 4 };
>> static const int kNumSignals = sizeof(gSignals) / sizeof(gSignals[0]);
>> static int gPreviousSignalHandlers[kNumSignals];
>>
>> thakis@thakis:~/src/llvm-project$ out/gn/bin/clang -c foo.m
>> foo.m:3:12: warning: variable length array folded to constant array as an
>> extension [-Wgnu-folding-constant]
>> static int gPreviousSignalHandlers[kNumSignals];
>>^
>> 1 warning generated.
>>
>>
>> Is that intentional? I don't see the VLA there.
>>
>
> gPreviousSignalHandlers is a VLA. Unlike C++, C doesn't permit the use of
> a 'const int' variable in a constant expression.
>

What's the suggested alternative?


>
>
>> On Fri, Oct 16, 2020 at 5:34 PM Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> Author: Richard Smith
>>> Date: 2020-10-16T14:34:35-07:00
>>> New Revision: 552c6c2328723a248c2b4d2765f75d49129dff20
>>>
>>> URL:
>>> https://github.com/llvm/llvm-project/commit/552c6c2328723a248c2b4d2765f75d49129dff20
>>> DIFF:
>>> https://github.com/llvm/llvm-project/commit/552c6c2328723a248c2b4d2765f75d49129dff20.diff
>>>
>>> LOG: PR44406: Follow behavior of array bound constant folding in more
>>> recent versions of GCC.
>>>
>>> Old GCC used to aggressively fold VLAs to constant-bound arrays at block
>>> scope in GNU mode. That's non-conforming, and more modern versions of
>>> GCC only do this at file scope. Update Clang to do the same.
>>>
>>> Also promote the warning for this from off-by-default to on-by-default
>>> in all cases; more recent versions of GCC likewise warn on this by
>>> default.
>>>
>>> This is still slightly more permissive than GCC, as pointed out in
>>> PR44406, as we still fold VLAs to constant arrays in structs, but that
>>> seems justifiable given that we don't support VLA-in-struct (and don't
>>> intend to ever support it), but GCC does.
>>>
>>> Differential Revision: https://reviews.llvm.org/D89523
>>>
>>> Added:
>>>
>>>
>>> Modified:
>>> clang/docs/UsersManual.rst
>>> clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> clang/lib/Sema/SemaDecl.cpp
>>> clang/lib/Sema/SemaType.cpp
>>> clang/test/CXX/basic/basic.types/p10.cpp
>>> clang/test/CXX/drs/dr3xx.cpp
>>> clang/test/CodeGen/vla.c
>>> clang/test/Misc/warning-flags.c
>>> clang/test/PCH/cxx-constexpr.cpp
>>> clang/test/Profile/misexpect-switch-default.c
>>> clang/test/Profile/misexpect-switch-nonconst.c
>>> clang/test/Profile/misexpect-switch-only-default-case.c
>>> clang/test/Profile/misexpect-switch.c
>>> clang/test/Sema/builtin-assume.c
>>> clang/test/Sema/builtins.c
>>> clang/test/Sema/complex-int.c
>>> clang/test/Sema/const-eval-64.c
>>> clang/test/Sema/const-eval.c
>>> clang/test/Sema/darwin-align-cast.c
>>> clang/test/Sema/decl-in-prototype.c
>>> clang/test/Sema/gnu-flags.c
>>> clang/test/Sema/i-c-e.c
>>> clang/test/Sema/offsetof-64.c
>>> clang/test/Sema/rounding-math.c
>>> clang/test/Sema/struct-decl.c
>>> clang/test/Sema/typedef-variable-type.c
>>> clang/test/Sema/vla.c
>>> clang/test/SemaCXX/anonymous-struct.cpp
>>> clang/test/SemaCXX/constant-expression.cpp
>>> clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
>>> clang/test/SemaCXX/i-c-e-cxx.cpp
>>> clang/test/SemaObjC/gcc-cast-ext.m
>>>
>>> Removed:
>>>
>>>
>>>
>>>
>>> 
>>> diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
>>> index 473fbb6d8d04..9726a25f7f63 100644
>>> --- a/clang/docs/UsersManual.rst
>>> +++ b/clang/docs/UsersManual.rst
>>> @@ -2502,10 +2502,6 @@ Differences between all ``c*`` and ``gnu*`` modes:
>>>  -  The Apple "blocks" extension is recognized by default in ``gnu*``
>>> modes
>>> on some platforms; it can be enabled in any mode with the
>>> ``-fblocks``
>>> option.
>>> --  Arrays that are VLA's according to the standard, but which can be
>>> -   constant folded by the frontend are treated as fixed size arrays.
>>> -   This occurs for things like "int X[(1, 2)];", which is technically a
>>> -   VLA. ``c*`` modes are strictly compliant and treat these as VLAs.
>>>
>>>  Differences between ``*89`` and ``*94`` modes:
>>>
>>> @@ -2594,10 +2590,12 @@ Intentionally unsupported GCC extensions
>>> the extension appears to be rarely used. Note that clang *does*
>>> support flexible array members (arrays with a zero or unspecified
>>> size at the end of a structure).
>>> --  clang does not have an equivalent to gcc's "fold"; this means that
>>> -   clang doesn't accept some constructs gcc might accept in contexts
>>> -   where a constant expression is required, like "x-x" where x is a
>>> -   variable.
>>> +-  GCC accepts many 

[PATCH] D89184: Support complex target features combinations

2020-10-29 Thread LiuChen via Phabricator via cfe-commits
LiuChen3 added a comment.

In D89184#2363591 , @echristo wrote:

> Let's go ahead and unblock you, but getting a lot of this refactored would be 
> great if you can. I think it's hitting the limits of the original design. :)

Thanks!  :)


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

https://reviews.llvm.org/D89184

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


[PATCH] D89158: [NewPM] Run callbacks added via registerPipelineStartEPCallback under -O0

2020-10-29 Thread Eric Christopher via Phabricator via cfe-commits
echristo added a comment.

In D89158#2363220 , @aeubanks wrote:

> Looking at BackendUtil.cpp in Clang as well as the Rust code, I'm back to 
> thinking that we should provide a way to to all callbacks. Then in the case 
> of passes added via TargetMachine, we should extend 
> `TargetMachine::registerPassBuilderCallbacks` to also take a 
> `PassBuilder::OptimizationLevel`. Then targets can skip adding optional 
> optimization passes at -O0. Does that make sense? It would allow us to clean 
> up Clang and Rust.
>
> In fact I see in `AMDGPUTargetMachine::adjustPassManager` a check for an 
> optimization level, so some targets are already doing this, although it looks 
> like it's more for codegen and not IR passes.

This sounds great. I'd love to see this.

-eric


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89158

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


[PATCH] D89184: Support complex target features combinations

2020-10-29 Thread Eric Christopher via Phabricator via cfe-commits
echristo accepted this revision.
echristo added a comment.
This revision is now accepted and ready to land.

Let's go ahead and unblock you, but getting a lot of this refactored would be 
great if you can. I think it's hitting the limits of the original design. :)


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

https://reviews.llvm.org/D89184

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


[PATCH] D89158: [NewPM] Run callbacks added via registerPipelineStartEPCallback under -O0

2020-10-29 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

I'm more convinced now that my initial direction was the cleanest way. It would 
simplify users of `PassBuilder` quite a bit.

I don't want to include PassManager.h into TargetMachine.h just to get 
`PassBuilder::OptimizationLevel`, so either we could factor out 
`OptimizationLevel` into its own header file so that we can pass an 
`OptimizationLevel` to `TargetMachine::registerPassBuilderCallbacks`, or we 
could just pass a `OnlyAddRequiredPasses` bool to 
`TargetMachine::registerPassBuilderCallbacks`. But either way, that can happen 
in a future change when the need arises (such as when we implement 
`AMDGPUTargetMachine::registerPassBuilderCallbacks`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89158

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


[PATCH] D90437: [NFC] Clean up PassBuilder

2020-10-29 Thread Alina Sbirlea via Phabricator via cfe-commits
asbirlea accepted this revision.
asbirlea added a comment.
This revision is now accepted and ready to land.

Neat!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90437

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


[clang-tools-extra] f1e0944 - clang-tidy: Make tests more hermetic

2020-10-29 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-10-29T20:14:57-04:00
New Revision: f1e0944fe5bbafd99e7cddb0892d6396a7eba01f

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

LOG: clang-tidy: Make tests more hermetic

Make check_clang_tidy.py not just pass -format-style=none by default
but a full -config={}. Without this, with a build dir outside of
the llvm root dir and a .clang-tidy config further up that contains

  CheckOptions:
- key:  modernize-use-default-member-init.UseAssignment
  value:1

these tests would fail:

   Clang Tools :: 
clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-modernize-use-default-member-init.cpp
   Clang Tools :: 
clang-tidy/checkers/modernize-use-default-member-init-bitfield.cpp
   Clang Tools :: clang-tidy/checkers/modernize-use-default-member-init.cpp

After this change, they pass fine, despite the unrelated
.clang-tidy file further up.

Added: 


Modified: 
clang-tools-extra/test/clang-tidy/check_clang_tidy.py

Removed: 




diff  --git a/clang-tools-extra/test/clang-tidy/check_clang_tidy.py 
b/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
index 093c2e059c63..0031d9b04ad1 100755
--- a/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
+++ b/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
@@ -61,12 +61,12 @@ def run_test_once(args, extra_args):
 clang_extra_args = clang_tidy_extra_args[i + 1:]
 clang_tidy_extra_args = clang_tidy_extra_args[:i]
 
-  # If the test does not specify a formatting style, force "none"; otherwise
+  # If the test does not specify a config style, force an empty one; otherwise
   # autodetection logic can discover a ".clang-tidy" file that is not related 
to
   # the test.
   if not any(
-  [arg.startswith('-format-style=') for arg in clang_tidy_extra_args]):
-clang_tidy_extra_args.append('-format-style=none')
+  [arg.startswith('-config=') for arg in clang_tidy_extra_args]):
+clang_tidy_extra_args.append('-config={}')
 
   if extension in ['.m', '.mm']:
 clang_extra_args = ['-fobjc-abi-version=2', '-fobjc-arc', '-fblocks'] + \



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


[PATCH] D90415: [OpenMP] Use __OPENMP_NVPTX__ instead of _OPENMP in complex wrapper headers.

2020-10-29 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D90415#2363056 , @fodinabor wrote:

> Thanks, will land it later.
>
> For the bug see: https://bugs.llvm.org/show_bug.cgi?id=48014
> Do I have to create a new phabricator review, too?
> I'm currently building the release/11.x branch with the patch cherry-picked 
> (which worked flawlessly).

CC tstel...@redhat.com in the bug and ask for it to be merged. Attach the patch 
file to the bug. At least that is (one way) how it works I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90415

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


[PATCH] D90440: [OpenMP][NFC] Clang format ParseOpenMP

2020-10-29 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield accepted this revision.
JonChesterfield added a comment.
This revision is now accepted and ready to land.

Strongly in favour. Whitespace differencess vs clang format impose a cost to 
patches, reviews and downstream forks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90440

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


[PATCH] D90275: [clang][IR] Add support for leaf attribute

2020-10-29 Thread Gulfem Savrun Yeniceri via Phabricator via cfe-commits
gulfem updated this revision to Diff 301789.
gulfem added a comment.

Fix the typo in the test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/attr-leaf.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/attr-leaf.c
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Bitcode/attributes.ll

Index: llvm/test/Bitcode/attributes.ll
===
--- llvm/test/Bitcode/attributes.ll
+++ llvm/test/Bitcode/attributes.ll
@@ -410,6 +410,12 @@
   ret void
 }
 
+; CHECK; define void @f70() #43
+define void @f70() nocallback
+{
+  ret void
+}
+
 ; CHECK: attributes #0 = { noreturn }
 ; CHECK: attributes #1 = { nounwind }
 ; CHECK: attributes #2 = { readnone }
@@ -453,4 +459,5 @@
 ; CHECK: attributes #40 = { null_pointer_is_valid }
 ; CHECK: attributes #41 = { mustprogress }
 ; CHECK: attributes #42 = { nossp }
+; CHECK: attributes #43 = { nocallback }
 ; CHECK: attributes #[[NOBUILTIN]] = { nobuiltin }
Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
===
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp
@@ -906,6 +906,7 @@
   case Attribute::NoRecurse:
   case Attribute::InlineHint:
   case Attribute::MinSize:
+  case Attribute::NoCallback:
   case Attribute::NoDuplicate:
   case Attribute::NoFree:
   case Attribute::NoImplicitFloat:
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1572,6 +1572,7 @@
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
+  case Attribute::NoCallback:
   case Attribute::NoCfCheck:
   case Attribute::NoUnwind:
   case Attribute::NoInline:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -371,6 +371,8 @@
 return "noalias";
   if (hasAttribute(Attribute::NoBuiltin))
 return "nobuiltin";
+  if (hasAttribute(Attribute::NoCallback))
+return "nocallback";
   if (hasAttribute(Attribute::NoCapture))
 return "nocapture";
   if (hasAttribute(Attribute::NoDuplicate))
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -643,6 +643,8 @@
 return bitc::ATTR_KIND_NO_ALIAS;
   case Attribute::NoBuiltin:
 return bitc::ATTR_KIND_NO_BUILTIN;
+  case Attribute::NoCallback:
+return bitc::ATTR_KIND_NO_CALLBACK;
   case Attribute::NoCapture:
 return bitc::ATTR_KIND_NO_CAPTURE;
   case Attribute::NoDuplicate:
Index: llvm/lib/Bitcode/Reader/BitcodeReader.cpp
===
--- llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -1433,6 +1433,8 @@
 return Attribute::NoAlias;
   case bitc::ATTR_KIND_NO_BUILTIN:
 return Attribute::NoBuiltin;
+  case bitc::ATTR_KIND_NO_CALLBACK:
+return Attribute::NoCallback;
   case bitc::ATTR_KIND_NO_CAPTURE:
 return Attribute::NoCapture;
   case bitc::ATTR_KIND_NO_DUPLICATE:
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -198,6 +198,7 @@
   kw_noalias,
   kw_noundef,
   kw_nobuiltin,
+  kw_nocallback,
   kw_nocapture,
   kw_noduplicate,
   kw_nofree,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1314,6 +1314,9 @@
   break;
 case lltok::kw_naked: B.addAttribute(Attribute::Naked); break;
 case lltok::kw_nobuiltin: B.addAttribute(Attribute::NoBuiltin); break;
+case lltok::kw_nocallback:
+  B.addAttribute(Attribute::NoCallback);
+  break;
 case lltok::kw_noduplicate: B.addAttribute(Attribute::NoDuplicate); break;
 case lltok::kw_nofree: B.addAttribute(Attribute::NoFree); break;
 case lltok::kw_noimplicitfloat:
Index: llvm/lib/AsmParser/LLLexer.cpp
===
--- 

[PATCH] D90440: [OpenMP][NFC] Clang format ParseOpenMP

2020-10-29 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert created this revision.
jdoerfert added reviewers: JonChesterfield, ABataev.
Herald added subscribers: guansong, bollu, yaxunl.
Herald added a project: clang.
jdoerfert requested review of this revision.
Herald added a subscriber: sstefan1.

ParseOpenMP.cpp was pretty much clang-formatted except a few minor
locations. Let's make it a clang formatted file.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90440

Files:
  clang/lib/Parse/ParseOpenMP.cpp

Index: clang/lib/Parse/ParseOpenMP.cpp
===
--- clang/lib/Parse/ParseOpenMP.cpp
+++ clang/lib/Parse/ParseOpenMP.cpp
@@ -853,14 +853,14 @@
 }
 } // namespace
 
-void Parser::parseOMPTraitPropertyKind(
-OMPTraitProperty , llvm::omp::TraitSet Set,
-llvm::omp::TraitSelector Selector, llvm::StringMap ) {
+void Parser::parseOMPTraitPropertyKind(OMPTraitProperty ,
+   llvm::omp::TraitSet Set,
+   llvm::omp::TraitSelector Selector,
+   llvm::StringMap ) {
   TIProperty.Kind = TraitProperty::invalid;
 
   SourceLocation NameLoc = Tok.getLocation();
-  StringRef Name =
-  getNameFromIdOrString(*this, Tok, CONTEXT_TRAIT_LVL);
+  StringRef Name = getNameFromIdOrString(*this, Tok, CONTEXT_TRAIT_LVL);
   if (Name.empty()) {
 Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_options)
 << CONTEXT_TRAIT_LVL << listOpenMPContextTraitProperties(Set, Selector);
@@ -1017,14 +1017,13 @@
   << CONTEXT_TRAIT_LVL;
 }
 
-void Parser::parseOMPTraitSelectorKind(
-OMPTraitSelector , llvm::omp::TraitSet Set,
-llvm::StringMap ) {
+void Parser::parseOMPTraitSelectorKind(OMPTraitSelector ,
+   llvm::omp::TraitSet Set,
+   llvm::StringMap ) {
   TISelector.Kind = TraitSelector::invalid;
 
   SourceLocation NameLoc = Tok.getLocation();
-  StringRef Name = getNameFromIdOrString(*this, Tok, CONTEXT_SELECTOR_LVL
-);
+  StringRef Name = getNameFromIdOrString(*this, Tok, CONTEXT_SELECTOR_LVL);
   if (Name.empty()) {
 Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_options)
 << CONTEXT_SELECTOR_LVL << listOpenMPContextTraitSelectors(Set);
@@ -1210,8 +1209,7 @@
   TISet.Kind = TraitSet::invalid;
 
   SourceLocation NameLoc = Tok.getLocation();
-  StringRef Name = getNameFromIdOrString(*this, Tok, CONTEXT_SELECTOR_SET_LVL
-   );
+  StringRef Name = getNameFromIdOrString(*this, Tok, CONTEXT_SELECTOR_SET_LVL);
   if (Name.empty()) {
 Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_options)
 << CONTEXT_SELECTOR_SET_LVL << listOpenMPContextTraitSets();
@@ -1269,8 +1267,7 @@
 ///
 ///  '=' '{'  [, ]* '}'
 void Parser::parseOMPContextSelectorSet(
-OMPTraitSet ,
-llvm::StringMap ) {
+OMPTraitSet , llvm::StringMap ) {
   auto OuterBC = BraceCount;
 
   // If anything went wrong we issue an error or warning and then skip the rest
@@ -1346,7 +1343,7 @@
 /// Parse OpenMP context selectors:
 ///
 ///  [, ]*
-bool Parser::parseOMPContextSelectors(SourceLocation Loc, OMPTraitInfo& TI) {
+bool Parser::parseOMPContextSelectors(SourceLocation Loc, OMPTraitInfo ) {
   llvm::StringMap SeenSets;
   do {
 OMPTraitSet TISet;
@@ -1523,16 +1520,16 @@
 ///device_type-clause:
 /// 'device_type' '(' 'host' | 'nohost' | 'any' )'
 namespace {
-  struct SimpleClauseData {
-unsigned Type;
-SourceLocation Loc;
-SourceLocation LOpen;
-SourceLocation TypeLoc;
-SourceLocation RLoc;
-SimpleClauseData(unsigned Type, SourceLocation Loc, SourceLocation LOpen,
- SourceLocation TypeLoc, SourceLocation RLoc)
-: Type(Type), Loc(Loc), LOpen(LOpen), TypeLoc(TypeLoc), RLoc(RLoc) {}
-  };
+struct SimpleClauseData {
+  unsigned Type;
+  SourceLocation Loc;
+  SourceLocation LOpen;
+  SourceLocation TypeLoc;
+  SourceLocation RLoc;
+  SimpleClauseData(unsigned Type, SourceLocation Loc, SourceLocation LOpen,
+   SourceLocation TypeLoc, SourceLocation RLoc)
+  : Type(Type), Loc(Loc), LOpen(LOpen), TypeLoc(TypeLoc), RLoc(RLoc) {}
+};
 } // anonymous namespace
 
 static Optional
@@ -1596,7 +1593,7 @@
 Diag(DevTypeData.getValue().Loc,
  diag::warn_omp_more_one_device_type_clause);
   }
-  switch(static_cast(DevTypeData.getValue().Type)) {
+  switch (static_cast(DevTypeData.getValue().Type)) {
   case OMPC_DEVICE_TYPE_any:
 DT = OMPDeclareTargetDeclAttr::DT_Any;
 break;
@@ -1961,7 +1958,7 @@
 CachedTokens Toks;
 Toks.push_back(Tok);
 ConsumeToken();
-while(Tok.isNot(tok::annot_pragma_openmp_end)) {
+while (Tok.isNot(tok::annot_pragma_openmp_end)) {
   Toks.push_back(Tok);
   ConsumeAnyToken();
 }
@@ -2009,7 +2006,7 @@
   return DeclGroupPtrTy();
 
  

[PATCH] D84604: Thread safety analysis: Consider global variables in scope

2020-10-29 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert added a comment.

Pushed a fix in rGbbed8cfe80cd27d3a47d877c7608d9be4e487d97 
. For now 
we just consider all static members as inaccessible, so we'll treat them as we 
did before this change.

I have proposed making the check stronger for non-static members in D87194 
, perhaps it makes sense to extend this to 
static members as well so that it fires on `DoStuff()` again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84604

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


[PATCH] D90275: [clang][IR] Add support for leaf attribute

2020-10-29 Thread Gulfem Savrun Yeniceri via Phabricator via cfe-commits
gulfem updated this revision to Diff 301787.
gulfem added a comment.

Add IR and bitcode tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/attr-leaf.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/attr-leaf.c
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Bitcode/attributes.ll

Index: llvm/test/Bitcode/attributes.ll
===
--- llvm/test/Bitcode/attributes.ll
+++ llvm/test/Bitcode/attributes.ll
@@ -410,6 +410,12 @@
   ret void
 }
 
+; CHECK; define void @f70() #43
+define void @f70() nocallback
+{
+  ret void
+}
+
 ; CHECK: attributes #0 = { noreturn }
 ; CHECK: attributes #1 = { nounwind }
 ; CHECK: attributes #2 = { readnone }
@@ -453,4 +459,5 @@
 ; CHECK: attributes #40 = { null_pointer_is_valid }
 ; CHECK: attributes #41 = { mustprogress }
 ; CHECK: attributes #42 = { nossp }
+; CHECK: attributes #43 = { nocallback }
 ; CHECK: attributes #[[NOBUILTIN]] = { nobuiltin }
Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
===
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp
@@ -906,6 +906,7 @@
   case Attribute::NoRecurse:
   case Attribute::InlineHint:
   case Attribute::MinSize:
+  case Attribute::NoCallback:
   case Attribute::NoDuplicate:
   case Attribute::NoFree:
   case Attribute::NoImplicitFloat:
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1572,6 +1572,7 @@
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
+  case Attribute::NoCallback:
   case Attribute::NoCfCheck:
   case Attribute::NoUnwind:
   case Attribute::NoInline:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -371,6 +371,8 @@
 return "noalias";
   if (hasAttribute(Attribute::NoBuiltin))
 return "nobuiltin";
+  if (hasAttribute(Attribute::NoCallback))
+return "nocallback";
   if (hasAttribute(Attribute::NoCapture))
 return "nocapture";
   if (hasAttribute(Attribute::NoDuplicate))
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -643,6 +643,8 @@
 return bitc::ATTR_KIND_NO_ALIAS;
   case Attribute::NoBuiltin:
 return bitc::ATTR_KIND_NO_BUILTIN;
+  case Attribute::NoCallback:
+return bitc::ATTR_KIND_NO_CALLBACK;
   case Attribute::NoCapture:
 return bitc::ATTR_KIND_NO_CAPTURE;
   case Attribute::NoDuplicate:
Index: llvm/lib/Bitcode/Reader/BitcodeReader.cpp
===
--- llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -1433,6 +1433,8 @@
 return Attribute::NoAlias;
   case bitc::ATTR_KIND_NO_BUILTIN:
 return Attribute::NoBuiltin;
+  case bitc::ATTR_KIND_NO_CALLBACK:
+return Attribute::NoCallback;
   case bitc::ATTR_KIND_NO_CAPTURE:
 return Attribute::NoCapture;
   case bitc::ATTR_KIND_NO_DUPLICATE:
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -198,6 +198,7 @@
   kw_noalias,
   kw_noundef,
   kw_nobuiltin,
+  kw_nocallback,
   kw_nocapture,
   kw_noduplicate,
   kw_nofree,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1314,6 +1314,9 @@
   break;
 case lltok::kw_naked: B.addAttribute(Attribute::Naked); break;
 case lltok::kw_nobuiltin: B.addAttribute(Attribute::NoBuiltin); break;
+case lltok::kw_nocallback:
+  B.addAttribute(Attribute::NoCallback);
+  break;
 case lltok::kw_noduplicate: B.addAttribute(Attribute::NoDuplicate); break;
 case lltok::kw_nofree: B.addAttribute(Attribute::NoFree); break;
 case lltok::kw_noimplicitfloat:
Index: llvm/lib/AsmParser/LLLexer.cpp
===
--- 

[clang] bbed8cf - Thread safety analysis: Consider static class members as inaccessible

2020-10-29 Thread Aaron Puchert via cfe-commits

Author: Aaron Puchert
Date: 2020-10-30T00:35:14+01:00
New Revision: bbed8cfe80cd27d3a47d877c7608d9be4e487d97

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

LOG: Thread safety analysis: Consider static class members as inaccessible

This fixes the issue pointed out in D84604#2363134. For now we exclude
static members completely, we'll take them into account later.

Added: 


Modified: 
clang/lib/Analysis/ThreadSafety.cpp
clang/test/SemaCXX/warn-thread-safety-negative.cpp

Removed: 




diff  --git a/clang/lib/Analysis/ThreadSafety.cpp 
b/clang/lib/Analysis/ThreadSafety.cpp
index 65d410a65ba4..21583e92c72d 100644
--- a/clang/lib/Analysis/ThreadSafety.cpp
+++ b/clang/lib/Analysis/ThreadSafety.cpp
@@ -1269,10 +1269,16 @@ bool ThreadSafetyAnalyzer::inCurrentScope(const 
CapabilityExpr ) {
   const threadSafety::til::SExpr *SExp = CapE.sexpr();
   assert(SExp && "Null expressions should be ignored");
 
-  // Global variables are always in scope.
   if (const auto *LP = dyn_cast(SExp)) {
 const ValueDecl *VD = LP->clangDecl();
-return VD->isDefinedOutsideFunctionOrMethod();
+// Variables defined in a function are always inaccessible.
+if (!VD->isDefinedOutsideFunctionOrMethod())
+  return false;
+// For now we consider static class members to be inaccessible.
+if (isa(VD->getDeclContext()))
+  return false;
+// Global variables are always in scope.
+return true;
   }
 
   // Members are in scope from methods of the same class.

diff  --git a/clang/test/SemaCXX/warn-thread-safety-negative.cpp 
b/clang/test/SemaCXX/warn-thread-safety-negative.cpp
index d7db5f402d11..9eabd67e4fc7 100644
--- a/clang/test/SemaCXX/warn-thread-safety-negative.cpp
+++ b/clang/test/SemaCXX/warn-thread-safety-negative.cpp
@@ -118,6 +118,33 @@ void testNamespaceGlobals() 
EXCLUSIVE_LOCKS_REQUIRED(!globalMutex) {
   ns::fq(); // expected-warning {{calling function 'fq' requires negative 
capability '!globalMutex'}}
 }
 
+class StaticMembers {
+public:
+  void pub() EXCLUSIVE_LOCKS_REQUIRED(!publicMutex);
+  void prot() EXCLUSIVE_LOCKS_REQUIRED(!protectedMutex);
+  void priv() EXCLUSIVE_LOCKS_REQUIRED(!privateMutex);
+  void test() {
+pub();
+prot();
+priv();
+  }
+
+  static Mutex publicMutex;
+
+protected:
+  static Mutex protectedMutex;
+
+private:
+  static Mutex privateMutex;
+};
+
+void testStaticMembers() {
+  StaticMembers x;
+  x.pub();
+  x.prot();
+  x.priv();
+}
+
 }  // end namespace ScopeTest
 
 namespace DoubleAttribute {



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


[PATCH] D90422: AArch64: Switch to x20 as the shadow base register for outlined HWASan checks.

2020-10-29 Thread Evgenii Stepanov via Phabricator via cfe-commits
eugenis accepted this revision.
eugenis added a comment.

LGTM
I was confused about the ABI statement in the description at the first glance - 
could you reword it to make it clear that HWASan ABI is not affected?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90422

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


[PATCH] D90424: AArch64: Use SBFX instead of UBFX to extract address granule in outlined HWASan checks.

2020-10-29 Thread Evgenii Stepanov via Phabricator via cfe-commits
eugenis accepted this revision.
eugenis added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90424

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


[PATCH] D90437: [NFC] Clean up PassBuilder

2020-10-29 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks created this revision.
aeubanks added reviewers: ychen, asbirlea.
Herald added subscribers: llvm-commits, cfe-commits, steven_wu, hiraditya.
Herald added projects: clang, LLVM.
aeubanks requested review of this revision.

Make DebugLogging a member variable so that users of PassBuilder don't
need to pass it around so much.

Move call to TargetMachine::registerPassBuilderCallbacks() within
PassBuilder so users don't need to remember to call it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90437

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Passes/PassRegistry.def
  llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
  llvm/tools/opt/NewPMDriver.cpp
  llvm/unittests/IR/PassBuilderCallbacksTest.cpp

Index: llvm/unittests/IR/PassBuilderCallbacksTest.cpp
===
--- llvm/unittests/IR/PassBuilderCallbacksTest.cpp
+++ llvm/unittests/IR/PassBuilderCallbacksTest.cpp
@@ -439,8 +439,8 @@
   "exit:\n"
   "  ret void\n"
   "}\n")),
-CallbacksHandle(),
-PB(nullptr, PipelineTuningOptions(), None, ),
+CallbacksHandle(), PB(false, nullptr, PipelineTuningOptions(), None,
+  ),
 PM(true), LAM(true), FAM(true), CGAM(true), AM(true) {
 
 EXPECT_TRUE( ==
Index: llvm/tools/opt/NewPMDriver.cpp
===
--- llvm/tools/opt/NewPMDriver.cpp
+++ llvm/tools/opt/NewPMDriver.cpp
@@ -140,68 +140,55 @@
 
 /// If one of the EPPipeline command line options was given, register callbacks
 /// for parsing and inserting the given pipeline
-static void registerEPCallbacks(PassBuilder , bool DebugLogging) {
+static void registerEPCallbacks(PassBuilder ) {
   if (tryParsePipelineText(PB, PeepholeEPPipeline))
 PB.registerPeepholeEPCallback(
-[, DebugLogging](FunctionPassManager ,
-PassBuilder::OptimizationLevel Level) {
+[](FunctionPassManager , PassBuilder::OptimizationLevel Level) {
   ExitOnError Err("Unable to parse PeepholeEP pipeline: ");
-  Err(PB.parsePassPipeline(PM, PeepholeEPPipeline, DebugLogging));
+  Err(PB.parsePassPipeline(PM, PeepholeEPPipeline));
 });
   if (tryParsePipelineText(PB,
 LateLoopOptimizationsEPPipeline))
 PB.registerLateLoopOptimizationsEPCallback(
-[, DebugLogging](LoopPassManager ,
-PassBuilder::OptimizationLevel Level) {
+[](LoopPassManager , PassBuilder::OptimizationLevel Level) {
   ExitOnError Err("Unable to parse LateLoopOptimizationsEP pipeline: ");
-  Err(PB.parsePassPipeline(PM, LateLoopOptimizationsEPPipeline,
-   DebugLogging));
+  Err(PB.parsePassPipeline(PM, LateLoopOptimizationsEPPipeline));
 });
   if (tryParsePipelineText(PB, LoopOptimizerEndEPPipeline))
 PB.registerLoopOptimizerEndEPCallback(
-[, DebugLogging](LoopPassManager ,
-PassBuilder::OptimizationLevel Level) {
+[](LoopPassManager , PassBuilder::OptimizationLevel Level) {
   ExitOnError Err("Unable to parse LoopOptimizerEndEP pipeline: ");
-  Err(PB.parsePassPipeline(PM, LoopOptimizerEndEPPipeline,
-   DebugLogging));
+  Err(PB.parsePassPipeline(PM, LoopOptimizerEndEPPipeline));
 });
   if (tryParsePipelineText(PB,
 ScalarOptimizerLateEPPipeline))
 PB.registerScalarOptimizerLateEPCallback(
-[, DebugLogging](FunctionPassManager ,
-PassBuilder::OptimizationLevel Level) {
+[](FunctionPassManager , PassBuilder::OptimizationLevel Level) {
   ExitOnError Err("Unable to parse ScalarOptimizerLateEP pipeline: ");
-  Err(PB.parsePassPipeline(PM, ScalarOptimizerLateEPPipeline,
-   DebugLogging));
+  Err(PB.parsePassPipeline(PM, ScalarOptimizerLateEPPipeline));
 });
   if (tryParsePipelineText(PB, CGSCCOptimizerLateEPPipeline))
 PB.registerCGSCCOptimizerLateEPCallback(
-[, DebugLogging](CGSCCPassManager ,
-PassBuilder::OptimizationLevel Level) {
+[](CGSCCPassManager , PassBuilder::OptimizationLevel Level) {
   ExitOnError Err("Unable to parse CGSCCOptimizerLateEP pipeline: ");
-  Err(PB.parsePassPipeline(PM, CGSCCOptimizerLateEPPipeline,
-   DebugLogging));
+  Err(PB.parsePassPipeline(PM, CGSCCOptimizerLateEPPipeline));
 });
   if (tryParsePipelineText(PB, VectorizerStartEPPipeline))
 PB.registerVectorizerStartEPCallback(
-[, DebugLogging](FunctionPassManager ,
-  

[PATCH] D89761: Split out llvm/Support/FileSystem/UniqueID.h and clang/Basic/FileEntry.h, NFC

2020-10-29 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

I just saw this in passing. Thanks a lot, I had noticed that Filesystem.h is 
super expensive.




Comment at: llvm/include/llvm/Support/FileSystem/UniqueID.h:36
+  bool operator<(const UniqueID ) const {
+return std::tie(Device, File) < std::tie(Other.Device, Other.File);
+  }

FYI std::tie is pretty expensive to compile, unfortunately. You also might 
technically need to include some STL header for it here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89761

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


[PATCH] D90424: AArch64: Use SBFX instead of UBFX to extract address granule in outlined HWASan checks.

2020-10-29 Thread Mitch Phillips via Phabricator via cfe-commits
hctim accepted this revision.
hctim 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/D90424/new/

https://reviews.llvm.org/D90424

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


[PATCH] D90436: [HIP] Use argv[0] as the default choice for the Executable name.

2020-10-29 Thread Artem Belevich via Phabricator via cfe-commits
tra created this revision.
tra added reviewers: sfantao, yaxunl, sdmitriev.
Herald added a subscriber: bixia.
Herald added a project: clang.
tra requested review of this revision.

The path produced by `getMainExecutable()` may not be the right one when the 
files are installed in
a symlinked tree and when the real location of `llvm-objdump` is in a different 
directory.

Given that clang-offload-bundler is invoked by clang, the driver already does 
the job figuring out 
the right path (e.g. it pays attention to `-no-canonical-prefixes`). 
Offload bundler should use it, instead of trying to figure out the path on its 
own.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90436

Files:
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -1025,7 +1025,9 @@
 
   // Save the current executable directory as it will be useful to find other
   // tools.
-  BundlerExecutable = sys::fs::getMainExecutable(argv[0], );
+  BundlerExecutable = argv[0];
+  if (!llvm::sys::fs::exists(BundlerExecutable))
+BundlerExecutable = sys::fs::getMainExecutable(argv[0], 
);
 
   if (llvm::Error Err = Unbundle ? UnbundleFiles() : BundleFiles()) {
 reportError(std::move(Err));


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -1025,7 +1025,9 @@
 
   // Save the current executable directory as it will be useful to find other
   // tools.
-  BundlerExecutable = sys::fs::getMainExecutable(argv[0], );
+  BundlerExecutable = argv[0];
+  if (!llvm::sys::fs::exists(BundlerExecutable))
+BundlerExecutable = sys::fs::getMainExecutable(argv[0], );
 
   if (llvm::Error Err = Unbundle ? UnbundleFiles() : BundleFiles()) {
 reportError(std::move(Err));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D90422: AArch64: Switch to x20 as the shadow base register for outlined HWASan checks.

2020-10-29 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc added a comment.

For the kernel I measured a small regression in boot time (with a version of 
this change that uses x20 for the v1 checks as well since the kernel doesn't 
use short granules yet) -- from 6.65s to 6.70s or 0.8%. But that's a fraction 
of the size gains which were 4% for kernel and (as mentioned) 3% for userspace.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90422

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


[PATCH] D90415: [OpenMP] Use __OPENMP_NVPTX__ instead of _OPENMP in complex wrapper headers.

2020-10-29 Thread Joachim Meyer 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 rGeaee608448c8: [OpenMP] Use __OPENMP_NVPTX__ instead of 
_OPENMP in complex wrapper headers. (authored by fodinabor).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90415

Files:
  clang/lib/Headers/__clang_cuda_complex_builtins.h
  clang/lib/Headers/openmp_wrappers/complex
  clang/lib/Headers/openmp_wrappers/complex.h


Index: clang/lib/Headers/openmp_wrappers/complex.h
===
--- clang/lib/Headers/openmp_wrappers/complex.h
+++ clang/lib/Headers/openmp_wrappers/complex.h
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.
Index: clang/lib/Headers/openmp_wrappers/complex
===
--- clang/lib/Headers/openmp_wrappers/complex
+++ clang/lib/Headers/openmp_wrappers/complex
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.
Index: clang/lib/Headers/__clang_cuda_complex_builtins.h
===
--- clang/lib/Headers/__clang_cuda_complex_builtins.h
+++ clang/lib/Headers/__clang_cuda_complex_builtins.h
@@ -16,7 +16,7 @@
 // to work with CUDA and OpenMP target offloading [in C and C++ mode].)
 
 #pragma push_macro("__DEVICE__")
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp declare target
 #define __DEVICE__ __attribute__((noinline, nothrow, cold, weak))
 #else
@@ -26,7 +26,7 @@
 // To make the algorithms available for C and C++ in CUDA and OpenMP we select
 // different but equivalent function versions. TODO: For OpenMP we currently
 // select the native builtins as the overload support for templates is lacking.
-#if !defined(_OPENMP)
+#if !defined(__OPENMP_NVPTX__)
 #define _ISNANd std::isnan
 #define _ISNANf std::isnan
 #define _ISINFd std::isinf
@@ -276,7 +276,7 @@
 #undef _fmaxd
 #undef _fmaxf
 
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp end declare target
 #endif
 


Index: clang/lib/Headers/openmp_wrappers/complex.h
===
--- clang/lib/Headers/openmp_wrappers/complex.h
+++ clang/lib/Headers/openmp_wrappers/complex.h
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.
Index: clang/lib/Headers/openmp_wrappers/complex
===
--- clang/lib/Headers/openmp_wrappers/complex
+++ clang/lib/Headers/openmp_wrappers/complex
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.
Index: clang/lib/Headers/__clang_cuda_complex_builtins.h
===
--- clang/lib/Headers/__clang_cuda_complex_builtins.h
+++ clang/lib/Headers/__clang_cuda_complex_builtins.h
@@ -16,7 +16,7 @@
 // to work with CUDA and OpenMP target offloading [in C and C++ mode].)
 
 #pragma push_macro("__DEVICE__")
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp declare target
 #define __DEVICE__ __attribute__((noinline, nothrow, cold, weak))
 #else
@@ -26,7 +26,7 @@
 // To make the algorithms available for C and C++ in CUDA and OpenMP we select
 // different but equivalent function versions. TODO: For OpenMP we currently
 // select the native builtins as the overload support for templates is lacking.
-#if !defined(_OPENMP)
+#if !defined(__OPENMP_NVPTX__)
 #define _ISNANd std::isnan
 #define _ISNANf std::isnan
 #define _ISINFd std::isinf
@@ -276,7 +276,7 @@
 #undef _fmaxd
 #undef _fmaxf
 
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp end declare target
 #endif
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] eaee608 - [OpenMP] Use __OPENMP_NVPTX__ instead of _OPENMP in complex wrapper headers.

2020-10-29 Thread Joachim Meyer via cfe-commits

Author: Joachim Meyer
Date: 2020-10-29T23:24:49+01:00
New Revision: eaee608448c832e8f806faae30ae4100620c4688

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

LOG: [OpenMP] Use __OPENMP_NVPTX__ instead of _OPENMP in complex wrapper 
headers.

This is very similar to 7f1e6fcff942, just fixing a left-over.
With this, it should be possible to use both, -x cuda and -fopenmp in the same 
invocation,
enabling to use both OpenMP, targeting CPU, and CUDA, targeting the GPU.

Reviewed By: jdoerfert

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

Added: 


Modified: 
clang/lib/Headers/__clang_cuda_complex_builtins.h
clang/lib/Headers/openmp_wrappers/complex
clang/lib/Headers/openmp_wrappers/complex.h

Removed: 




diff  --git a/clang/lib/Headers/__clang_cuda_complex_builtins.h 
b/clang/lib/Headers/__clang_cuda_complex_builtins.h
index 9b254f700b9d..2b701fef0ea2 100644
--- a/clang/lib/Headers/__clang_cuda_complex_builtins.h
+++ b/clang/lib/Headers/__clang_cuda_complex_builtins.h
@@ -16,7 +16,7 @@
 // to work with CUDA and OpenMP target offloading [in C and C++ mode].)
 
 #pragma push_macro("__DEVICE__")
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp declare target
 #define __DEVICE__ __attribute__((noinline, nothrow, cold, weak))
 #else
@@ -26,7 +26,7 @@
 // To make the algorithms available for C and C++ in CUDA and OpenMP we select
 // 
diff erent but equivalent function versions. TODO: For OpenMP we currently
 // select the native builtins as the overload support for templates is lacking.
-#if !defined(_OPENMP)
+#if !defined(__OPENMP_NVPTX__)
 #define _ISNANd std::isnan
 #define _ISNANf std::isnan
 #define _ISINFd std::isinf
@@ -276,7 +276,7 @@ __DEVICE__ float _Complex __divsc3(float __a, float __b, 
float __c, float __d) {
 #undef _fmaxd
 #undef _fmaxf
 
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp end declare target
 #endif
 

diff  --git a/clang/lib/Headers/openmp_wrappers/complex 
b/clang/lib/Headers/openmp_wrappers/complex
index 306ffe208053..142e526b81b3 100644
--- a/clang/lib/Headers/openmp_wrappers/complex
+++ b/clang/lib/Headers/openmp_wrappers/complex
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.

diff  --git a/clang/lib/Headers/openmp_wrappers/complex.h 
b/clang/lib/Headers/openmp_wrappers/complex.h
index 829c7a785725..00d278548f82 100644
--- a/clang/lib/Headers/openmp_wrappers/complex.h
+++ b/clang/lib/Headers/openmp_wrappers/complex.h
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.



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


[PATCH] D84604: Thread safety analysis: Consider global variables in scope

2020-10-29 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert added a comment.

In D84604#2363134 , @rupprecht wrote:

> I'm seeing failures which I think are due to this patch -- I don't have a 
> nice godbolt repro yet, but it's something like:

Yes, that's very likely.

> I'm also seeing the same error for `DoThings()`, which doesn't make sense. 
> When I add it, I then get errors that `mu_` is private, and therefore needs 
> to be made public or friended for the thread analysis -- which is not at all 
> a good change (the mutex should be encapsulated in the class). Even though 
> it's "global" in the linkage sense, it's not visible outside of the class.

I'll see if I can fix this quickly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84604

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


[PATCH] D90422: AArch64: Switch to x20 as the shadow base register for outlined HWASan checks.

2020-10-29 Thread Mitch Phillips via Phabricator via cfe-commits
hctim accepted this revision.
hctim added a comment.
This revision is now accepted and ready to land.

LGTM - I'm assuming this doesn't regress performance because there's no latency 
of the additional store due to its locality?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90422

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


[PATCH] D90434: [CodeGen] Correct codegen for self-capturing __block var

2020-10-29 Thread ille via Phabricator via cfe-commits
ille created this revision.
ille added reviewers: rjmccall, jfb.
Herald added a project: clang.
ille requested review of this revision.

This is based on my previous patch, https://reviews.llvm.org/D89903, but is an
attempt at a full fix rather than a minimal one, following rjmccall's
suggestion of initializing directly on the heap and emitting a trivial copy
helper.

This applies to situations where a `__block` variable's initializer references a
block that potentially captures the variable itself.

Clang special-cases these situations because the initializer might call
Block_copy and cause the variable to be moved to the heap while it's
still being initialized.  For example, in this snippet:

  int copyBlockAndReturnInt(void (^)(void));
  
  __block int val = copyBlockAndReturnInt(^{
  printf("%p\n", val);
  });

...if `copyBlockAndReturnInt` calls `Block_copy`, `val` will be moved to the
heap.  When `copyBlockAndReturnInt` returns, the generated code needs to store
the value to the new location.

For scalar values like pointers, this is handled by deferring computation of
the variable's address until after the initializer has been evaluated (and just
before actually storing to that address).

But what about structs?  This case would be hard:

  struct Foo { int a, b; };
  int copyBlockAndReturnInt(void (^)(void));
  
  __block struct Foo foo = {42, copyBlockAndReturnInt(^{
  printf("%p\n", );
  })};

To support relocating this to the heap, Clang would have to recalculate
the location of `foo` before writing to each struct field, in case the
initializer of the current field moved the struct.  Block_copy would
also end up copying a half-initialized struct, although that's no big
deal with C structs.

This C++ case, on the other hand, would be impossible:

  struct Foo {
  void (^block_)(void);
  Foo(void (^block)(void)) {
  printf("I am at %p\n", this);
  block_ = Block_copy(block);
  printf("I am now at %p\n", this);
  }
  };
  
  __block Foo foo(^{
  printf("%p\n", );
  });

To support relocating `Foo` to the heap, Clang would have to magically
move it mid-construction.  Normally, Clang uses the move or copy
constructor when moving C++ classes to the heap, but C++ classes
certainly don't expect a move constructor to be called in the middle of
another constructor.  memcpy might work in some cases, but it violates
C++ classes' expectation that object addresses will remain stable.  Thus
there's no real way to make this work, and ideally it would result in a
compile error (or, alternately, a runtime crash upon calling
`Block_copy`).

So how does Clang currently approach this situation?  Well, there's just a
comment:

  case TEK_Aggregate:
[...]
  // TODO: how can we delay here if D is captured by its initializer?

Clang never calls `drillIntoBlockVariable`, and ends up writing the
variable to the beginning of the byref struct (not the corresponding
field in it), which is never the correct location.  This leaves both the
variable and the byref struct corrupt - even if the block is never
actually copied.

This bug dates back to at least 2012, as I reproduced it on LLVM 3.1.

This patch addresses the issue by allocating the variable directly on
the heap and initializing it there.  This ensures it never needs to
move.

For now, to avoid the need for an ABI update, this is done in a hacky
way.  First, a byref struct is allocated on the stack as usual, but the
object data itself is left uninitialized, and the copy helper is set to
a no-op.  Then `_Block_object_assign` is called to migrate it to the
heap, followed immediately by `_Block_object_dispose` to remove the
unnecessary extra reference.  Only then is the object initialized in its
new location.

The implicit heap allocation introduced here may be unnecessary if the
block is never actually copied, which could be a problem in code that's
highly performance sensitive or wants to be resilient to allocation
failure.  To defend against this, this patch adds a warning,
-Wimplicit-block-var-alloc, to diagnose every time the implicit allocation
is triggered.  Since most codebases do not care, the warning is disabled
by default and is not included in any standard warning groups.

This patch also makes the is-captured-by-init analysis simpler yet more
precise (while moving it into Sema so that it can power the new
warning).  As far as I can tell, the previous implementation was
overcomplicated for no good reason.  In ancient days (2011), the
recursive function isCapturedBy only worked on Exprs, and it recursed on
the Expr's children, which it assumed would also be Exprs.  This
assumption turned out to be false for statement expressions.  The simple
fix would have been to change isCapturedBy to accept and recurse on
arbitrary Stmts instead, since children() is defined for all Stmts, not
just Exprs.  I'm not sure if there was some reason that wasn't possible
at the time, but what happened instead is that a special 

Re: [clang] 552c6c2 - PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.

2020-10-29 Thread Richard Smith via cfe-commits
On Thu, 29 Oct 2020 at 08:07, Nico Weber  wrote:

> Hi Richard,
>
> this fires on
>
> thakis@thakis:~/src/llvm-project$ cat foo.m
> static const int gSignals[] = { 0, 1, 2, 3, 4 };
> static const int kNumSignals = sizeof(gSignals) / sizeof(gSignals[0]);
> static int gPreviousSignalHandlers[kNumSignals];
>
> thakis@thakis:~/src/llvm-project$ out/gn/bin/clang -c foo.m
> foo.m:3:12: warning: variable length array folded to constant array as an
> extension [-Wgnu-folding-constant]
> static int gPreviousSignalHandlers[kNumSignals];
>^
> 1 warning generated.
>
>
> Is that intentional? I don't see the VLA there.
>

gPreviousSignalHandlers is a VLA. Unlike C++, C doesn't permit the use of a
'const int' variable in a constant expression.


> On Fri, Oct 16, 2020 at 5:34 PM Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> Author: Richard Smith
>> Date: 2020-10-16T14:34:35-07:00
>> New Revision: 552c6c2328723a248c2b4d2765f75d49129dff20
>>
>> URL:
>> https://github.com/llvm/llvm-project/commit/552c6c2328723a248c2b4d2765f75d49129dff20
>> DIFF:
>> https://github.com/llvm/llvm-project/commit/552c6c2328723a248c2b4d2765f75d49129dff20.diff
>>
>> LOG: PR44406: Follow behavior of array bound constant folding in more
>> recent versions of GCC.
>>
>> Old GCC used to aggressively fold VLAs to constant-bound arrays at block
>> scope in GNU mode. That's non-conforming, and more modern versions of
>> GCC only do this at file scope. Update Clang to do the same.
>>
>> Also promote the warning for this from off-by-default to on-by-default
>> in all cases; more recent versions of GCC likewise warn on this by
>> default.
>>
>> This is still slightly more permissive than GCC, as pointed out in
>> PR44406, as we still fold VLAs to constant arrays in structs, but that
>> seems justifiable given that we don't support VLA-in-struct (and don't
>> intend to ever support it), but GCC does.
>>
>> Differential Revision: https://reviews.llvm.org/D89523
>>
>> Added:
>>
>>
>> Modified:
>> clang/docs/UsersManual.rst
>> clang/include/clang/Basic/DiagnosticSemaKinds.td
>> clang/lib/Sema/SemaDecl.cpp
>> clang/lib/Sema/SemaType.cpp
>> clang/test/CXX/basic/basic.types/p10.cpp
>> clang/test/CXX/drs/dr3xx.cpp
>> clang/test/CodeGen/vla.c
>> clang/test/Misc/warning-flags.c
>> clang/test/PCH/cxx-constexpr.cpp
>> clang/test/Profile/misexpect-switch-default.c
>> clang/test/Profile/misexpect-switch-nonconst.c
>> clang/test/Profile/misexpect-switch-only-default-case.c
>> clang/test/Profile/misexpect-switch.c
>> clang/test/Sema/builtin-assume.c
>> clang/test/Sema/builtins.c
>> clang/test/Sema/complex-int.c
>> clang/test/Sema/const-eval-64.c
>> clang/test/Sema/const-eval.c
>> clang/test/Sema/darwin-align-cast.c
>> clang/test/Sema/decl-in-prototype.c
>> clang/test/Sema/gnu-flags.c
>> clang/test/Sema/i-c-e.c
>> clang/test/Sema/offsetof-64.c
>> clang/test/Sema/rounding-math.c
>> clang/test/Sema/struct-decl.c
>> clang/test/Sema/typedef-variable-type.c
>> clang/test/Sema/vla.c
>> clang/test/SemaCXX/anonymous-struct.cpp
>> clang/test/SemaCXX/constant-expression.cpp
>> clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
>> clang/test/SemaCXX/i-c-e-cxx.cpp
>> clang/test/SemaObjC/gcc-cast-ext.m
>>
>> Removed:
>>
>>
>>
>>
>> 
>> diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
>> index 473fbb6d8d04..9726a25f7f63 100644
>> --- a/clang/docs/UsersManual.rst
>> +++ b/clang/docs/UsersManual.rst
>> @@ -2502,10 +2502,6 @@ Differences between all ``c*`` and ``gnu*`` modes:
>>  -  The Apple "blocks" extension is recognized by default in ``gnu*``
>> modes
>> on some platforms; it can be enabled in any mode with the ``-fblocks``
>> option.
>> --  Arrays that are VLA's according to the standard, but which can be
>> -   constant folded by the frontend are treated as fixed size arrays.
>> -   This occurs for things like "int X[(1, 2)];", which is technically a
>> -   VLA. ``c*`` modes are strictly compliant and treat these as VLAs.
>>
>>  Differences between ``*89`` and ``*94`` modes:
>>
>> @@ -2594,10 +2590,12 @@ Intentionally unsupported GCC extensions
>> the extension appears to be rarely used. Note that clang *does*
>> support flexible array members (arrays with a zero or unspecified
>> size at the end of a structure).
>> --  clang does not have an equivalent to gcc's "fold"; this means that
>> -   clang doesn't accept some constructs gcc might accept in contexts
>> -   where a constant expression is required, like "x-x" where x is a
>> -   variable.
>> +-  GCC accepts many expression forms that are not valid integer constant
>> +   expressions in bit-field widths, enumerator constants, case labels,
>> +   and in array bounds at global scope. Clang also accepts additional
>> +   expression forms in 

[PATCH] D89158: [NewPM] Run callbacks added via registerPipelineStartEPCallback under -O0

2020-10-29 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

Looking at BackendUtil.cpp in Clang as well as the Rust code, I'm back to 
thinking that we should provide a way to to all callbacks. Then in the case of 
passes added via TargetMachine, we should extend 
`TargetMachine::registerPassBuilderCallbacks` to also take a 
`PassBuilder::OptimizationLevel`. Then targets can skip adding optional 
optimization passes at -O0. Does that make sense? It would allow us to clean up 
Clang and Rust.

In fact I see in `AMDGPUTargetMachine::adjustPassManager` a check for an 
optimization level, so some targets are already doing this, although it looks 
like it's more for codegen and not IR passes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89158

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


[PATCH] D89743: Support Attr in DynTypedNode and ASTMatchers.

2020-10-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D89743#2360258 , @sammccall wrote:

> (while this is useful to you, let's keep discussing, but I'm also happy to 
> stop and land this with your preferred API/semantics - just LMK if changes 
> are needed)

Let's hold off on landing for just a little bit. I don't think changes are 
needed yet, but the discussion may change my opinion and we might as well avoid 
churn. However, if you need to land part of this while we discuss other parts, 
LMK.

> In D89743#2360032 , @aaron.ballman 
> wrote:
>
>> Thank you for giving this feedback, it's helpful! I may have to rethink this 
>> a bit because it never dawned on me that someone would think of attributes 
>> being more like a `DeclRefExpr` than a `NamedDecl`. If I'm following along 
>> properly, this is because the AST node for the attribute could have been 
>> generated from various ways of spelling it? e.g., `gcc::aligned` vs 
>> `_Alignas` vs `align` vs `alignas` all making an `AlignedAttr`.
>
> My mental model is that the Attr **classes** own the names, and the Attr 
> **instances** refer to the classes using the names.
>
> So the class `AlignedAttr` has the name `aligned`, and the instance 
> `[[gnu::aligned(8)]]` refers to it. Just like the `FunctionDecl` `double 
> sqrt(double);` has the name `sqrt`, and the DeclRefExpr in `sqrt(8)` refers 
> to it.
>
> To reinforce this, I can't choose a different name for the instance: 
> `[[gnu::whatever]]` doesn't produce an Attr instance at all. But I can choose 
> a different name for the class (by modifying Attr.td).
> So an Attr instance (what we're matching) feels more like a reference than a 
> primary entity. (Similarly, the **semantics** are associated with the Attr 
> class rather than the instance).
>
> If clang's AST modeled syntax rather than semantics, I imagine there'd be one 
> `Attr` class and each instance could have an arbitrary name and arg list. In 
> that case an Attr would seem to "have" a name in the same sense a decl does.

Oh, how interesting, thank you for expounding!

My mental model is that there is no declaration of an attribute (in the usual 
sense, because users cannot specify their own attributes without changing the 
compiler), and so there's not a referential model like there are with a 
DeclRefExpr that refers back to a specific declaration. Instead, to me, an 
attribute is a bit more like a builtin type --  you may have multiple ways to 
spell the type (`char` vs `signed char` or `unsigned char`, `long int` vs 
`long`, etc), but it's the same type under the hood.

However, that brings up an interesting observation: you can't do 
`hasType(hasName("long"))` and instead have to do `hasType(asString("long"))`. 
I don't recall the background about why there is `asString()` for matching 
string types vs `hasName()` -- you wouldn't happen to remember that context, 
would you? For instance, is the correct pattern to allow 
`attr(asString("aligned"))` to map back to an `AlignedAttr` regardless of how 
the attribute was spelled in source, similar to how `asString("long")` matches 
`long int`?

>> I figured it would make more sense for `attr(hasName("aligned"))` to match 
>> any `AlignedAttr` regardless of how the user wrote it in their source code, 
>> but perhaps others have different ideas here.
>
> That definitely seems like the common case. However I can certainly imagine 
> wanting to e.g. write a migration from `__attribute__((xxx))` to 
> `[[gnu::xxx]]`.

Definitely true! I was imagining we'd want a separate checker for narrowing 
based on attribute syntax.

> (If attr **classes** were AST nodes too, like DeclRefExpr/Decl or 
> TypeLoc/Type then you'd resolve this by using a matcher on one or the other)
>
> As it stands it seems too surprising that `Attr::getAttrName()` returns the 
> particular name used for that instance, but `attr(hasAttrName("..."))` would 
> match any name associated with the same class.
> Maybe `attr(equivalentAttrName("..."))` or so, possibly constrasting to 
> `attr(exactAttrName("..."))`?

Yeah, I am starting to see this more readily, so thank you for continuing the 
discussion!

>> The scope handling is a bit of a question mark. Attributes don't really have 
>> namespaces like other identifiers, but they sort of have them when you 
>> squint at the name just right. For instance, the scope handling currently 
>> allows you to match `::foo` in C mode even though C doesn't have the notion 
>> of namespaces. So I thought it wouldn't be unintuitive for it to also work 
>> for namespace scopes as well.
>
> Yup, I don't have a real opinion here, I just assumed it was different. Seems 
> like it would work fine.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89743

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

[PATCH] D90123: [Sema] Improve notes for value category mismatch in overloading

2020-10-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

Thanks!




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:4280
 "candidate %sub{select_ovl_candidate_kind}0,1,2 not viable: "
-"expects an l-value for "
+"expects an %select{l-value|r-value}5 for "
 "%select{%ordinal4 argument|object argument}3">;

Please change this to `lvalue|rvalue` (preferably in a separate commit, and 
likewise for the half-dozen or so other diagnostics that use this 
unconventional spelling). In both C and C++ contexts, these words are spelled 
without a hyphen.



Comment at: clang/lib/Sema/SemaOverload.cpp:10410-10411
 
+  if (Conv.Bad.Kind == BadConversionSequence::lvalue_ref_to_rvalue ||
+  Conv.Bad.Kind == BadConversionSequence::rvalue_ref_to_lvalue) {
+S.Diag(Fn->getLocation(), diag::note_ovl_candidate_bad_value_category)

It's surprising to me that nothing else in this function is considering 
`Conv.Bad.Kind`. Do you know what's going on there? I see that 
`PerformObjectArgumentInitialization` has a `switch` on it, but it looks like 
that's the *only* place that uses it, and we mostly instead try to recompute 
what went wrong after the fact, which seems fragile. I wonder if more of the 
complexity of this function could be reduced by using the stored bad conversion 
kind. (But let's keep this patch targeted on just fixing the value category 
diagnostics!)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90123

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


[PATCH] D90109: [clang-tidy] Use ANSI escape codes for --use-color on Windows

2020-10-29 Thread David Sanders via Phabricator via cfe-commits
dsanders11 added a comment.

> Oh, how neat. The bug you linked to was closed as a dup of another bug. The 
> other bug was then closed as something that's not in scope with the general 
> product direction, whatever that means.

Yea, typical Microsoft/Windows fun there.

> Yeah, that would be reasonable test coverage.

Sounds good. I've updated the revision to remove the `#if` guard and removed 
`REQUIRES: ansi-escape-sequences` from the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90109

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


[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

2020-10-29 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Alright, LGTM.




Comment at: clang/include/clang/AST/DeclCXX.h:1013
   CXXMethodDecl *getLambdaStaticInvoker() const;
+  CXXMethodDecl *getLambdaStaticInvoker(CallingConv CC) const;
+

erichkeane wrote:
> erichkeane wrote:
> > rjmccall wrote:
> > > Probably worth clarifying in the comment which invoker is returned by the 
> > > no-arguments variant.
> > I just looked and the first is actually only used 1x!  I think I can just 
> > replace that usage and remove the former overload if that is acceptable to 
> > you.
> On second thought... I might leave this alone.  Otherwise the ItaniumMangler 
> basically needs to reproduce the functionality.  I think the improved comment 
> is an appropriate change here.
Fine by me.



Comment at: clang/lib/AST/DeclCXX.cpp:1550
+ return FTy->getCallConv() == CC;
+   });
+

erichkeane wrote:
> rjmccall wrote:
> > This seems both rather more complicated and rather more expensive than a 
> > simple loop which assigns to a local pointer.
> Do you mean the filtering copy-if?  The idea was to make it so that the 
> assert below still applies.  If that isn't necessary, this DOES simplify to a 
> std::find and a return.
I mean that if you really want to assert that, you could do so by checking 
whether the existing function is the same as what you've already found; you 
don't need a vector.  But just not checking that seems fine to me.


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

https://reviews.llvm.org/D89559

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


[PATCH] D84604: Thread safety analysis: Consider global variables in scope

2020-10-29 Thread Jordan Rupprecht via Phabricator via cfe-commits
rupprecht added a comment.

I'm seeing failures which I think are due to this patch -- I don't have a nice 
godbolt repro yet, but it's something like:

  foo.h: 
  class Foo {
   public:
static void DoStuff();  // Grabs mu_
  
  private:
static std::vector blah_ GUARDED_BY(mu_);
static Mutex mu_;
  };
  
  bar.h:
  class Bar {
static void DoThings(); // calls Foo::DoStuff()
  };

Because `DoStuff()` grabs `mu_`, it needs the lock, and this patch gives an 
error like `requires negative capability 'mu_'`. That's fine, and in fact 
better analysis is welcome.

However, I'm also seeing the same error for `DoThings()`, which doesn't make 
sense. When I add it, I then get errors that `mu_` is private, and therefore 
needs to be made public or friended for the thread analysis -- which is not at 
all a good change (the mutex should be encapsulated in the class). Even though 
it's "global" in the linkage sense, it's not visible outside of the class.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84604

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


[PATCH] D90109: [clang-tidy] Use ANSI escape codes for --use-color on Windows

2020-10-29 Thread David Sanders via Phabricator via cfe-commits
dsanders11 updated this revision to Diff 301755.
dsanders11 added a comment.

code review changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90109

Files:
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
  llvm/lib/Support/Windows/Process.inc


Index: llvm/lib/Support/Windows/Process.inc
===
--- llvm/lib/Support/Windows/Process.inc
+++ llvm/lib/Support/Windows/Process.inc
@@ -327,9 +327,10 @@
   if (enable) {
 HANDLE Console = GetStdHandle(STD_OUTPUT_HANDLE);
 DWORD Mode;
-GetConsoleMode(Console, );
-Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
-SetConsoleMode(Console, Mode);
+if (GetConsoleMode(Console, ) != 0) {
+  Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
+  SetConsoleMode(Console, Mode);
+}
   }
 #endif
   UseANSI = enable;
Index: clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
@@ -5,7 +5,6 @@
 // RUN: clang-tidy -config='UseColor: false' -dump-config | FileCheck 
-check-prefix=CHECK-CONFIG-NO-COLOR %s
 // RUN: clang-tidy -help | FileCheck -check-prefix=CHECK-OPT-PRESENT %s
 
-// REQUIRES: ansi-escape-sequences
 // RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 
-use-color=false %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
 // RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 
%s | FileCheck -check-prefix=CHECK-NO-COLOR %s
 // RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 
-use-color %s | FileCheck -check-prefix=CHECK-COLOR %s
Index: clang-tools-extra/clang-tidy/ClangTidy.cpp
===
--- clang-tools-extra/clang-tidy/ClangTidy.cpp
+++ clang-tools-extra/clang-tidy/ClangTidy.cpp
@@ -110,6 +110,9 @@
 DiagOpts->ShowColors = Context.getOptions().UseColor.getValueOr(
 llvm::sys::Process::StandardOutHasColors());
 DiagPrinter->BeginSourceFile(LangOpts);
+if (DiagOpts->ShowColors && !llvm::sys::Process::StandardOutIsDisplayed()) 
{
+  llvm::sys::Process::UseANSIEscapeCodes(true);
+}
   }
 
   SourceManager () { return SourceMgr; }


Index: llvm/lib/Support/Windows/Process.inc
===
--- llvm/lib/Support/Windows/Process.inc
+++ llvm/lib/Support/Windows/Process.inc
@@ -327,9 +327,10 @@
   if (enable) {
 HANDLE Console = GetStdHandle(STD_OUTPUT_HANDLE);
 DWORD Mode;
-GetConsoleMode(Console, );
-Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
-SetConsoleMode(Console, Mode);
+if (GetConsoleMode(Console, ) != 0) {
+  Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
+  SetConsoleMode(Console, Mode);
+}
   }
 #endif
   UseANSI = enable;
Index: clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/use-color.cpp
@@ -5,7 +5,6 @@
 // RUN: clang-tidy -config='UseColor: false' -dump-config | FileCheck -check-prefix=CHECK-CONFIG-NO-COLOR %s
 // RUN: clang-tidy -help | FileCheck -check-prefix=CHECK-OPT-PRESENT %s
 
-// REQUIRES: ansi-escape-sequences
 // RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 -use-color=false %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
 // RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 %s | FileCheck -check-prefix=CHECK-NO-COLOR %s
 // RUN: clang-tidy -checks='-*, modernize-use-override' -extra-arg=-std=c++11 -use-color %s | FileCheck -check-prefix=CHECK-COLOR %s
Index: clang-tools-extra/clang-tidy/ClangTidy.cpp
===
--- clang-tools-extra/clang-tidy/ClangTidy.cpp
+++ clang-tools-extra/clang-tidy/ClangTidy.cpp
@@ -110,6 +110,9 @@
 DiagOpts->ShowColors = Context.getOptions().UseColor.getValueOr(
 llvm::sys::Process::StandardOutHasColors());
 DiagPrinter->BeginSourceFile(LangOpts);
+if (DiagOpts->ShowColors && !llvm::sys::Process::StandardOutIsDisplayed()) {
+  llvm::sys::Process::UseANSIEscapeCodes(true);
+}
   }
 
   SourceManager () { return SourceMgr; }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D90430: [clang][NFC] Remove unused FileCheck prefix

2020-10-29 Thread Keith Smiley via Phabricator via cfe-commits
keith created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
keith requested review of this revision.

This is to enable --allow-unused-duplicates=false. This prefix appears
to be outdated and intentionally unused.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90430

Files:
  clang/test/Driver/debug-options.c


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -115,7 +115,7 @@
 // PS4 defaults to sce; -ggdb0 changes tuning but turns off debug info,
 // then -g turns it back on without affecting tuning.
 // RUN: %clang -### -c -ggdb0 -g -target x86_64-scei-ps4 %s 2>&1 \
-// RUN: | FileCheck -check-prefix=G -check-prefix=G_GDB %s
+// RUN: | FileCheck -check-prefix=G_GDB %s
 //
 // RUN: %clang -### -c -g1 %s 2>&1 \
 // RUN: | FileCheck -check-prefix=GLTO_ONLY %s


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -115,7 +115,7 @@
 // PS4 defaults to sce; -ggdb0 changes tuning but turns off debug info,
 // then -g turns it back on without affecting tuning.
 // RUN: %clang -### -c -ggdb0 -g -target x86_64-scei-ps4 %s 2>&1 \
-// RUN: | FileCheck -check-prefix=G -check-prefix=G_GDB %s
+// RUN: | FileCheck -check-prefix=G_GDB %s
 //
 // RUN: %clang -### -c -g1 %s 2>&1 \
 // RUN: | FileCheck -check-prefix=GLTO_ONLY %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D90415: [OpenMP] Use __OPENMP_NVPTX__ instead of _OPENMP in complex wrapper headers.

2020-10-29 Thread Joachim Meyer via Phabricator via cfe-commits
fodinabor added a comment.

Thanks, will land it later.

For the bug see: https://bugs.llvm.org/show_bug.cgi?id=48014
Do I have to create a new phabricator review, too?
I'm currently building the release/11.x branch with the patch cherry-picked 
(which worked flawlessly).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90415

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


[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

2020-10-29 Thread Erich Keane via Phabricator via cfe-commits
erichkeane updated this revision to Diff 301746.
erichkeane marked an inline comment as done.
erichkeane added a comment.

@rjmccall : Think I got everything, is this what you mean?


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

https://reviews.llvm.org/D89559

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp
  clang/test/SemaCXX/lambda-conversion-op-cc.cpp

Index: clang/test/SemaCXX/lambda-conversion-op-cc.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/lambda-conversion-op-cc.cpp
@@ -0,0 +1,190 @@
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc %s -verify -DBAD_CONVERSION
+// RUN: %clang_cc1 -fsyntax-only -triple i386-windows-pc %s -verify -DBAD_CONVERSION -DWIN32
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc %s -ast-dump | FileCheck %s --check-prefixes=CHECK,LIN64,NODEF
+// RUN: %clang_cc1 -fsyntax-only -triple i386-windows-pc %s -ast-dump -DWIN32 | FileCheck %s --check-prefixes=CHECK,WIN32,NODEF
+
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc -fdefault-calling-conv=vectorcall %s -verify -DBAD_VEC_CONVERS
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc -fdefault-calling-conv=vectorcall %s -ast-dump | FileCheck %s --check-prefixes=CHECK,VECTDEF
+
+void useage() {
+  auto normal = [](int, float, double) {};// #1
+  auto vectorcall = [](int, float, double) __attribute__((vectorcall)){}; // #2
+#ifdef WIN32
+  auto thiscall = [](int, float, double) __attribute__((thiscall)){}; // #3
+#endif// WIN32
+  auto cdecl = [](int, float, double) __attribute__((cdecl)){};
+
+  auto genericlambda = [](auto a) {};  // #4
+  auto genericvectorcalllambda = [](auto a) __attribute__((vectorcall)){}; // #5
+
+  // None of these should be ambiguous.
+  (void)+normal;
+  (void)+vectorcall;
+#ifdef WIN32
+  (void)+thiscall;
+#endif // WIN32
+  (void)+cdecl;
+
+#ifdef BAD_CONVERSION
+  // expected-error-re@+1 {{invalid argument type {{.*}} to unary expression}}
+  (void)+genericlambda;
+  // expected-error-re@+1 {{invalid argument type {{.*}} to unary expression}}
+  (void)+genericvectorcalllambda;
+#endif // BAD_CONVERSION
+
+  // CHECK: VarDecl {{.*}} normal '
+  // CHECK: LambdaExpr
+  // WIN32: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((thiscall)) const'
+  // LIN64: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+  // VECTDEF: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+  // NODEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+  // NODEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+  // VECTDEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+  // VECTDEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+  // CHECK: VarDecl {{.*}} vectorcall '
+  // CHECK: LambdaExpr
+  // CHECK: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((vectorcall)) const'
+  // CHECK: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+  // CHECK: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+  // WIN32: VarDecl {{.*}} thiscall '
+  // WIN32: LambdaExpr
+  // WIN32: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((thiscall)) const'
+  // WIN32: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+  // WIN32: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+
+  // CHECK: VarDecl {{.*}} cdecl '
+  // CHECK: LambdaExpr
+  // CHECK: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+  // NODEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+  // NODEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+  // VECTDEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+  // VECTDEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+  // CHECK: VarDecl {{.*}} genericlambda '
+  // CHECK: LambdaExpr
+  //
+  // CHECK: FunctionTemplateDecl {{.*}} operator()
+  // LIN64: CXXMethodDecl {{.*}} operator() 'auto (auto) const' inline
+  // LIN64: CXXMethodDecl {{.*}} operator() 'void (char) const' inline
+  // LIN64: CXXMethodDecl {{.*}} operator() 'void (int) const' inline
+  // WIN32: CXXMethodDecl {{.*}} operator() 'auto (auto) 

[PATCH] D90424: AArch64: Use SBFX instead of UBFX to extract address granule in outlined HWASan checks.

2020-10-29 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc created this revision.
pcc added reviewers: eugenis, hctim.
Herald added subscribers: cfe-commits, danielkiss, hiraditya, kristof.beyls.
Herald added projects: clang, LLVM.
pcc requested review of this revision.

In a kernel (or in general in environments where bit 55 of the address
is set) the shadow base needs to point to the end of the shadow region,
not the beginning. Bit 55 needs to be sign extended into bits 52-63
of the shadow base offset, otherwise we end up loading from an invalid
address. We can do this by using SBFX instead of UBFX.

Using SBFX should have no effect in the userspace case where bit 55
of the address is clear so we do so unconditionally. I don't think
we need a ABI version bump for this (but one will come anyway when
we switch to x20 for the shadow base register).

Depends on D90422 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90424

Files:
  clang/docs/HardwareAssistedAddressSanitizerDesign.rst
  llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
  llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll


Index: llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
===
--- llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
+++ llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
@@ -38,7 +38,7 @@
 ; CHECK-NEXT: .weak __hwasan_check_x0_2_short_v2
 ; CHECK-NEXT: .hidden __hwasan_check_x0_2_short_v2
 ; CHECK-NEXT: __hwasan_check_x0_2_short_v2:
-; CHECK-NEXT: ubfx x16, x0, #4, #52
+; CHECK-NEXT: sbfx x16, x0, #4, #52
 ; CHECK-NEXT: ldrb w16, [x20, x16]
 ; CHECK-NEXT: cmp x16, x0, lsr #56
 ; CHECK-NEXT: b.ne .Ltmp0
@@ -69,7 +69,7 @@
 ; CHECK-NEXT: .weak __hwasan_check_x1_1
 ; CHECK-NEXT: .hidden __hwasan_check_x1_1
 ; CHECK-NEXT: __hwasan_check_x1_1:
-; CHECK-NEXT: ubfx x16, x1, #4, #52
+; CHECK-NEXT: sbfx x16, x1, #4, #52
 ; CHECK-NEXT: ldrb w16, [x9, x16]
 ; CHECK-NEXT: cmp x16, x1, lsr #56
 ; CHECK-NEXT: b.ne .Ltmp3
Index: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
===
--- llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
+++ llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
@@ -348,7 +348,7 @@
 OutStreamer->emitSymbolAttribute(Sym, MCSA_Hidden);
 OutStreamer->emitLabel(Sym);
 
-OutStreamer->emitInstruction(MCInstBuilder(AArch64::UBFMXri)
+OutStreamer->emitInstruction(MCInstBuilder(AArch64::SBFMXri)
  .addReg(AArch64::X16)
  .addReg(Reg)
  .addImm(4)
Index: clang/docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- clang/docs/HardwareAssistedAddressSanitizerDesign.rst
+++ clang/docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -96,7 +96,7 @@
 
   [...]
   __hwasan_check_x0_2_short_v2:
-ubfxx16, x0, #4, #52// shadow offset
+sbfxx16, x0, #4, #52// shadow offset
 ldrbw16, [x20, x16] // load shadow tag
 cmp x16, x0, lsr #56// extract address 
tag, compare with shadow tag
 b.ne.Ltmp0  // jump to short tag 
handler on mismatch


Index: llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
===
--- llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
+++ llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
@@ -38,7 +38,7 @@
 ; CHECK-NEXT: .weak __hwasan_check_x0_2_short_v2
 ; CHECK-NEXT: .hidden __hwasan_check_x0_2_short_v2
 ; CHECK-NEXT: __hwasan_check_x0_2_short_v2:
-; CHECK-NEXT: ubfx x16, x0, #4, #52
+; CHECK-NEXT: sbfx x16, x0, #4, #52
 ; CHECK-NEXT: ldrb w16, [x20, x16]
 ; CHECK-NEXT: cmp x16, x0, lsr #56
 ; CHECK-NEXT: b.ne .Ltmp0
@@ -69,7 +69,7 @@
 ; CHECK-NEXT: .weak __hwasan_check_x1_1
 ; CHECK-NEXT: .hidden __hwasan_check_x1_1
 ; CHECK-NEXT: __hwasan_check_x1_1:
-; CHECK-NEXT: ubfx x16, x1, #4, #52
+; CHECK-NEXT: sbfx x16, x1, #4, #52
 ; CHECK-NEXT: ldrb w16, [x9, x16]
 ; CHECK-NEXT: cmp x16, x1, lsr #56
 ; CHECK-NEXT: b.ne .Ltmp3
Index: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
===
--- llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
+++ llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
@@ -348,7 +348,7 @@
 OutStreamer->emitSymbolAttribute(Sym, MCSA_Hidden);
 OutStreamer->emitLabel(Sym);
 
-OutStreamer->emitInstruction(MCInstBuilder(AArch64::UBFMXri)
+OutStreamer->emitInstruction(MCInstBuilder(AArch64::SBFMXri)
  .addReg(AArch64::X16)
  .addReg(Reg)
  .addImm(4)
Index: clang/docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- 

[PATCH] D90422: AArch64: Switch to x20 as the shadow base register for outlined HWASan checks.

2020-10-29 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc created this revision.
pcc added reviewers: eugenis, hctim.
Herald added subscribers: Sanitizers, cfe-commits, danielkiss, hiraditya, 
kristof.beyls.
Herald added projects: clang, Sanitizers, LLVM.
pcc requested review of this revision.

>From a code size perspective it turns out to be better to use a
callee-saved register to pass the shadow base. For non-leaf functions
it avoids the need to reload the shadow base into x9 after each
function call, at the cost of an additional stack slot to save the
caller's x20. But with x9 there is also a stack size cost, either
as a result of copying x9 to a callee-saved register across calls or
by spilling it to stack, so for the non-leaf functions the change to
stack usage is largely neutral.

It is also code size (and stack size) neutral for many leaf functions.
Although they now need to save/restore x20 this can typically be
combined via LDP/STP into the x30 save/restore. In the case where
the function needs callee-saved registers or stack spills we end up
needing, on average, 8 more bytes of stack and 1 more instruction
but given the improvements to other functions this seems like the
right tradeoff.

Since this is an ABI change for the outlined check functions they
have been renamed.

Unfortunately we cannot change the register for the v1 (non short
granules) check because the runtime assumes that the shadow base
register is stored in x9, so the v1 check still uses x9.

With this change code size of /system/lib64/*.so in an Android build
with HWASan goes from 200066976 bytes to 194085912 bytes, or a 3%
decrease.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90422

Files:
  clang/docs/HardwareAssistedAddressSanitizerDesign.rst
  compiler-rt/test/hwasan/TestCases/register-dump-read.c
  llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll

Index: llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
===
--- llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
+++ llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
@@ -18,12 +18,13 @@
 
 define i8* @f2(i8* %x0, i8* %x1) {
   ; CHECK: f2:
-  ; CHECK: str x30, [sp, #-16]!
+  ; CHECK: stp x30, x20, [sp, #-16]!
   ; CHECK-NEXT: .cfi_def_cfa_offset 16
+  ; CHECK-NEXT: .cfi_offset w20, -8
   ; CHECK-NEXT: .cfi_offset w30, -16
-  ; CHECK-NEXT: mov x9, x1
-  ; CHECK-NEXT: bl __hwasan_check_x0_2_short
-  ; CHECK-NEXT: ldr x30, [sp], #16
+  ; CHECK-NEXT: mov x20, x1
+  ; CHECK-NEXT: bl __hwasan_check_x0_2_short_v2
+  ; CHECK-NEXT: ldp x30, x20, [sp], #16
   ; CHECK-NEXT: ret
   call void @llvm.hwasan.check.memaccess.shortgranules(i8* %x1, i8* %x0, i32 2)
   ret i8* %x0
@@ -32,13 +33,13 @@
 declare void @llvm.hwasan.check.memaccess(i8*, i8*, i32)
 declare void @llvm.hwasan.check.memaccess.shortgranules(i8*, i8*, i32)
 
-; CHECK:  .section .text.hot,"axG",@progbits,__hwasan_check_x0_2_short,comdat
-; CHECK-NEXT: .type __hwasan_check_x0_2_short,@function
-; CHECK-NEXT: .weak __hwasan_check_x0_2_short
-; CHECK-NEXT: .hidden __hwasan_check_x0_2_short
-; CHECK-NEXT: __hwasan_check_x0_2_short:
+; CHECK:  .section .text.hot,"axG",@progbits,__hwasan_check_x0_2_short_v2,comdat
+; CHECK-NEXT: .type __hwasan_check_x0_2_short_v2,@function
+; CHECK-NEXT: .weak __hwasan_check_x0_2_short_v2
+; CHECK-NEXT: .hidden __hwasan_check_x0_2_short_v2
+; CHECK-NEXT: __hwasan_check_x0_2_short_v2:
 ; CHECK-NEXT: ubfx x16, x0, #4, #52
-; CHECK-NEXT: ldrb w16, [x9, x16]
+; CHECK-NEXT: ldrb w16, [x20, x16]
 ; CHECK-NEXT: cmp x16, x0, lsr #56
 ; CHECK-NEXT: b.ne .Ltmp0
 ; CHECK-NEXT: .Ltmp1:
Index: llvm/lib/Target/AArch64/AArch64InstrInfo.td
===
--- llvm/lib/Target/AArch64/AArch64InstrInfo.td
+++ llvm/lib/Target/AArch64/AArch64InstrInfo.td
@@ -1123,9 +1123,12 @@
   (outs), (ins GPR64noip:$ptr, i32imm:$accessinfo),
   [(int_hwasan_check_memaccess X9, GPR64noip:$ptr, (i32 timm:$accessinfo))]>,
   Sched<[]>;
+}
+
+let Uses = [ X20 ], Defs = [ X16, X17, LR, NZCV ] in {
 def HWASAN_CHECK_MEMACCESS_SHORTGRANULES : Pseudo<
   (outs), (ins GPR64noip:$ptr, i32imm:$accessinfo),
-  [(int_hwasan_check_memaccess_shortgranules X9, GPR64noip:$ptr, (i32 timm:$accessinfo))]>,
+  [(int_hwasan_check_memaccess_shortgranules X20, GPR64noip:$ptr, (i32 timm:$accessinfo))]>,
   Sched<[]>;
 }
 
Index: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
===
--- llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
+++ llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
@@ -302,7 +302,7 @@
 std::string SymName = "__hwasan_check_x" + utostr(Reg - AArch64::X0) + "_" +
   utostr(AccessInfo);
 if (IsShort)
-  SymName += "_short";
+  SymName += "_short_v2";
 Sym = OutContext.getOrCreateSymbol(SymName);
   }
 
@@ -354,13 +354,14 @@

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

2020-10-29 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/include/clang/AST/DeclCXX.h:1013
   CXXMethodDecl *getLambdaStaticInvoker() const;
+  CXXMethodDecl *getLambdaStaticInvoker(CallingConv CC) const;
+

erichkeane wrote:
> rjmccall wrote:
> > Probably worth clarifying in the comment which invoker is returned by the 
> > no-arguments variant.
> I just looked and the first is actually only used 1x!  I think I can just 
> replace that usage and remove the former overload if that is acceptable to 
> you.
On second thought... I might leave this alone.  Otherwise the ItaniumMangler 
basically needs to reproduce the functionality.  I think the improved comment 
is an appropriate change here.


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

https://reviews.llvm.org/D89559

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


[PATCH] D90415: [OpenMP] Use __OPENMP_NVPTX__ instead of _OPENMP in complex wrapper headers.

2020-10-29 Thread Joachim Meyer via Phabricator via cfe-commits
fodinabor updated this revision to Diff 301726.
fodinabor edited the summary of this revision.
fodinabor added a comment.

Add missing macro definitions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90415

Files:
  clang/lib/Headers/__clang_cuda_complex_builtins.h
  clang/lib/Headers/openmp_wrappers/complex
  clang/lib/Headers/openmp_wrappers/complex.h


Index: clang/lib/Headers/openmp_wrappers/complex.h
===
--- clang/lib/Headers/openmp_wrappers/complex.h
+++ clang/lib/Headers/openmp_wrappers/complex.h
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.
Index: clang/lib/Headers/openmp_wrappers/complex
===
--- clang/lib/Headers/openmp_wrappers/complex
+++ clang/lib/Headers/openmp_wrappers/complex
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.
Index: clang/lib/Headers/__clang_cuda_complex_builtins.h
===
--- clang/lib/Headers/__clang_cuda_complex_builtins.h
+++ clang/lib/Headers/__clang_cuda_complex_builtins.h
@@ -16,7 +16,7 @@
 // to work with CUDA and OpenMP target offloading [in C and C++ mode].)
 
 #pragma push_macro("__DEVICE__")
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp declare target
 #define __DEVICE__ __attribute__((noinline, nothrow, cold, weak))
 #else
@@ -26,7 +26,7 @@
 // To make the algorithms available for C and C++ in CUDA and OpenMP we select
 // different but equivalent function versions. TODO: For OpenMP we currently
 // select the native builtins as the overload support for templates is lacking.
-#if !defined(_OPENMP)
+#if !defined(__OPENMP_NVPTX__)
 #define _ISNANd std::isnan
 #define _ISNANf std::isnan
 #define _ISINFd std::isinf
@@ -276,7 +276,7 @@
 #undef _fmaxd
 #undef _fmaxf
 
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp end declare target
 #endif
 


Index: clang/lib/Headers/openmp_wrappers/complex.h
===
--- clang/lib/Headers/openmp_wrappers/complex.h
+++ clang/lib/Headers/openmp_wrappers/complex.h
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.
Index: clang/lib/Headers/openmp_wrappers/complex
===
--- clang/lib/Headers/openmp_wrappers/complex
+++ clang/lib/Headers/openmp_wrappers/complex
@@ -18,7 +18,9 @@
 #include 
 
 #define __CUDA__
+#define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_NVPTX__
 #endif
 
 // Grab the host header too.
Index: clang/lib/Headers/__clang_cuda_complex_builtins.h
===
--- clang/lib/Headers/__clang_cuda_complex_builtins.h
+++ clang/lib/Headers/__clang_cuda_complex_builtins.h
@@ -16,7 +16,7 @@
 // to work with CUDA and OpenMP target offloading [in C and C++ mode].)
 
 #pragma push_macro("__DEVICE__")
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp declare target
 #define __DEVICE__ __attribute__((noinline, nothrow, cold, weak))
 #else
@@ -26,7 +26,7 @@
 // To make the algorithms available for C and C++ in CUDA and OpenMP we select
 // different but equivalent function versions. TODO: For OpenMP we currently
 // select the native builtins as the overload support for templates is lacking.
-#if !defined(_OPENMP)
+#if !defined(__OPENMP_NVPTX__)
 #define _ISNANd std::isnan
 #define _ISNANf std::isnan
 #define _ISINFd std::isinf
@@ -276,7 +276,7 @@
 #undef _fmaxd
 #undef _fmaxf
 
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp end declare target
 #endif
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D90419: [AMDGPU] Add gfx90c target

2020-10-29 Thread Tim Renouf via Phabricator via cfe-commits
tpr updated this revision to Diff 301723.
tpr added a comment.

V2: Fixed copy-o in AMDGPUUsage.rst change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90419

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/AMDGPU.td
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
  llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
  llvm/tools/llvm-readobj/ELFDumper.cpp

Index: llvm/tools/llvm-readobj/ELFDumper.cpp
===
--- llvm/tools/llvm-readobj/ELFDumper.cpp
+++ llvm/tools/llvm-readobj/ELFDumper.cpp
@@ -1779,6 +1779,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX906),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX908),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX909),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX90C),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1010),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1011),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1012),
Index: llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
===
--- llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
+++ llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
@@ -166,6 +166,10 @@
 # RUN: llvm-readobj -s -file-headers %t.o.42 | FileCheck --check-prefixes=ELF-ALL,ELF-GFX1032 %s
 # RUN: obj2yaml %t.o.42 | FileCheck --check-prefixes=YAML-GFX1032 %s
 
+# RUN: yaml2obj --docnum=43 %s -o %t.o.43
+# RUN: llvm-readobj -s -file-headers %t.o.43 | FileCheck --check-prefixes=ELF-ALL,ELF-GFX90C %s
+# RUN: obj2yaml %t.o.43 | FileCheck --check-prefixes=YAML-GFX90C %s
+
 # ELF-ALL: Flags [
 # ELF-R600:  EF_AMDGPU_MACH_R600_R600 (0x1)
 # ELF-R630:  EF_AMDGPU_MACH_R600_R630 (0x2)
@@ -203,6 +207,7 @@
 # ELF-GFX906:EF_AMDGPU_MACH_AMDGCN_GFX906 (0x2F)
 # ELF-GFX908:EF_AMDGPU_MACH_AMDGCN_GFX908 (0x30)
 # ELF-GFX909:EF_AMDGPU_MACH_AMDGCN_GFX909 (0x31)
+# ELF-GFX90C:EF_AMDGPU_MACH_AMDGCN_GFX90C (0x32)
 # ELF-GFX1010:   EF_AMDGPU_MACH_AMDGCN_GFX1010 (0x33)
 # ELF-GFX1011:   EF_AMDGPU_MACH_AMDGCN_GFX1011 (0x34)
 # ELF-GFX1012:   EF_AMDGPU_MACH_AMDGCN_GFX1012 (0x35)
@@ -247,6 +252,7 @@
 # YAML-GFX906:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX906 ]
 # YAML-GFX908:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX908 ]
 # YAML-GFX909:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX909 ]
+# YAML-GFX90C:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX90C ]
 # YAML-GFX1010: Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX1010 ]
 # YAML-GFX1011: Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX1011 ]
 # YAML-GFX1012: Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX1012 ]
@@ -715,3 +721,14 @@
   Machine: EM_AMDGPU
   Flags:   [ EF_AMDGPU_MACH_AMDGCN_GFX1032 ]
 ...
+
+# Doc43
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  OSABI:   ELFOSABI_NONE
+  Type:ET_REL
+  Machine: EM_AMDGPU
+  Flags:   [ EF_AMDGPU_MACH_AMDGCN_GFX90C ]
+...
Index: llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
===
--- llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
+++ llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
@@ -52,6 +52,7 @@
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx906 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX906 %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx908 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX908 %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx909 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX909 %s
+; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx90c < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX90C %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx1010 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX1010 %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx1011 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX1011 %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx1012 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX1012 %s
@@ -103,6 +104,7 @@
 ; GFX908:EF_AMDGPU_MACH_AMDGCN_GFX908 (0x30)
 ; GFX908-NEXT:   EF_AMDGPU_SRAM_ECC   (0x200)
 ; GFX909:

[clang] 661797b - [AMDGPU] Update AMD GPU documentation

2020-10-29 Thread via cfe-commits

Author: Tony
Date: 2020-10-29T20:12:47Z
New Revision: 661797bd763331284f1a058609502c0311f8dd38

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

LOG: [AMDGPU] Update AMD GPU documentation

- AMDGPUUsage.rst: Correct AMD GPU DWARF address space table address
  sizes which are in bits and not bytes.

- clang/.../Options.td: Improve description of AMD GPU options.

- Re-generate ClangComamndLineReference.rst from clang/.../Options.td .

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

Added: 


Modified: 
clang/docs/ClangCommandLineReference.rst
clang/include/clang/Driver/Options.td
llvm/docs/AMDGPUUsage.rst

Removed: 




diff  --git a/clang/docs/ClangCommandLineReference.rst 
b/clang/docs/ClangCommandLineReference.rst
index 6864f6058a3f..0dca391cf0b5 100644
--- a/clang/docs/ClangCommandLineReference.rst
+++ b/clang/docs/ClangCommandLineReference.rst
@@ -1641,6 +1641,10 @@ Sets various macros to claim compatibility with the 
given GCC version (default i
 
 Allow device side init function in HIP
 
+.. option:: -fgpu-defer-diag, -fno-gpu-defer-diag
+
+Defer host/device related diagnostic messages for CUDA/HIP
+
 .. option:: -fgpu-rdc, -fcuda-rdc, -fno-gpu-rdc
 
 Generate relocatable device code, also known as separate compilation mode
@@ -2655,6 +2659,10 @@ Align selected branches (fused, jcc, jmp) within 32-byte 
boundary
 
 .. option:: -mcmodel=, -mcmodel=medany (equivalent to -mcmodel=medium), 
-mcmodel=medlow (equivalent to -mcmodel=small)
 
+.. option:: -mcode-object-v3, -mno-code-object-v3
+
+Legacy option to specify code object ABI V2 (-mnocode-object-v3) or V3 
(-mcode-object-v3) (AMDGPU only)
+
 .. option:: -mconsole
 
 .. program:: clang1
@@ -2831,6 +2839,18 @@ Enable stack probes
 
 Set the stack probe size
 
+.. option:: -mstack-protector-guard-offset=
+
+Use the given offset for addressing the stack-protector guard
+
+.. option:: -mstack-protector-guard-reg=
+
+Use the given reg for addressing the stack-protector guard
+
+.. option:: -mstack-protector-guard=
+
+Use the given guard (global, tls) for addressing the stack-protector guard
+
 .. option:: -mstackrealign, -mno-stackrealign
 
 Force realign the stack at entry to every function
@@ -2859,7 +2879,7 @@ Specify bit size of immediate TLS offsets (AArch64 ELF 
only): 12 (for 4KB) \| 24
 .. option:: -mtune=
 .. program:: clang
 
-Only supported on X86. Otherwise accepted for compatibility with GCC.
+Only supported on X86 and RISC-V. Otherwise accepted for compatibility with 
GCC.
 
 .. option:: -mtvos-version-min=, -mappletvos-version-min=
 
@@ -2873,7 +2893,7 @@ Only supported on X86. Otherwise accepted for 
compatibility with GCC.
 
 .. option:: -mwavefrontsize64, -mno-wavefrontsize64
 
-Wavefront size 64 is used
+Specify wavefront size 64 mode (AMDGPU only)
 
 .. option:: -mwindows
 
@@ -2935,28 +2955,28 @@ Specify the size in bits of an SVE vector register. 
Defaults to the vector lengt
 
 AMDGPU
 --
-.. option:: -mcode-object-v3, -mno-code-object-v3
-
-Legacy option to specify code object v3 (AMDGPU only)
-
 .. option:: -mcumode, -mno-cumode
 
-CU wavefront execution mode is used (AMDGPU only)
+Specify CU (-mcumode) or WGP (-mno-cumode) wavefront execution mode (AMDGPU 
only)
 
 .. option:: -msram-ecc, -mno-sram-ecc
 
-Enable SRAM ECC (AMDGPU only)
+Specify SRAM ECC mode (AMDGPU only)
 
 .. option:: -mxnack, -mno-xnack
 
-Enable XNACK (AMDGPU only)
+Specify XNACK mode (AMDGPU only)
 
 ARM
 ---
-.. option:: -fAAPCSBitfieldLoad
+.. option:: -faapcs-bitfield-load
 
 Follows the AAPCS standard that all volatile bit-field write generates at 
least one load. (ARM only).
 
+.. option:: -faapcs-bitfield-width, -fno-aapcs-bitfield-width
+
+Follow the AAPCS standard requirement stating that volatile bit-field width is 
dictated by the field container type. (ARM only).
+
 .. option:: -ffixed-r9
 
 Reserve the r9 register (ARM only)
@@ -3490,13 +3510,7 @@ Set DWARF fission mode to either 'split' or 'single'
 
 .. option:: -gstrict-dwarf, -gno-strict-dwarf
 
-.. option:: -gz
-
-DWARF debug sections compression type
-
-.. program:: clang1
-.. option:: -gz=
-.. program:: clang
+.. option:: -gz=, -gz (equivalent to -gz=zlib)
 
 DWARF debug sections compression type
 

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 0b9817a0cfd4..09996af6f91f 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2468,28 +2468,25 @@ def mexec_model_EQ : Joined<["-"], "mexec-model=">, 
Group;
 
 def mcode_object_v3_legacy : Flag<["-"], "mcode-object-v3">, Group,
-  HelpText<"Legacy option to specify code object v3 (AMDGPU only)">;
-def mno_code_object_v3_legacy : Flag<["-"], "mno-code-object-v3">, 
Group,
-  HelpText<"Legacy option to 

[PATCH] D90364: [AMDGPU] Update AMD GPU documentation

2020-10-29 Thread Tony Tye 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 rG661797bd7633: [AMDGPU] Update AMD GPU documentation 
(authored by t-tye).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90364

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Driver/Options.td
  llvm/docs/AMDGPUUsage.rst

Index: llvm/docs/AMDGPUUsage.rst
===
--- llvm/docs/AMDGPUUsage.rst
+++ llvm/docs/AMDGPUUsage.rst
@@ -1411,13 +1411,13 @@
  address address
  space   space
=== = ===  = ===
-   ``DW_ASPACE_none``  0x00  8   4Global*default address space*
-   ``DW_ASPACE_AMDGPU_generic``0x01  8   4Generic (Flat)
-   ``DW_ASPACE_AMDGPU_region`` 0x02  4   4Region (GDS)
-   ``DW_ASPACE_AMDGPU_local``  0x03  4   4Local (group/LDS)
+   ``DW_ASPACE_none``  0x00  64  32   Global*default address space*
+   ``DW_ASPACE_AMDGPU_generic``0x01  64  32   Generic (Flat)
+   ``DW_ASPACE_AMDGPU_region`` 0x02  32  32   Region (GDS)
+   ``DW_ASPACE_AMDGPU_local``  0x03  32  32   Local (group/LDS)
*Reserved*  0x04
-   ``DW_ASPACE_AMDGPU_private_lane``   0x05  4   4Private (Scratch) *focused lane*
-   ``DW_ASPACE_AMDGPU_private_wave``   0x06  4   4Private (Scratch) *unswizzled wavefront*
+   ``DW_ASPACE_AMDGPU_private_lane``   0x05  32  32   Private (Scratch) *focused lane*
+   ``DW_ASPACE_AMDGPU_private_wave``   0x06  32  32   Private (Scratch) *unswizzled wavefront*
=== = ===  = ===
 
 See :ref:`amdgpu-address-spaces` for information on the AMDGPU address spaces
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2468,28 +2468,25 @@
  HelpText<"Execution model (WebAssembly only)">;
 
 def mcode_object_v3_legacy : Flag<["-"], "mcode-object-v3">, Group,
-  HelpText<"Legacy option to specify code object v3 (AMDGPU only)">;
-def mno_code_object_v3_legacy : Flag<["-"], "mno-code-object-v3">, Group,
-  HelpText<"Legacy option to specify code object v2 (AMDGPU only)">;
+  HelpText<"Legacy option to specify code object ABI V2 (-mnocode-object-v3) or V3 (-mcode-object-v3) (AMDGPU only)">;
+def mno_code_object_v3_legacy : Flag<["-"], "mno-code-object-v3">, Group;
+
+def mcumode : Flag<["-"], "mcumode">, Group,
+  HelpText<"Specify CU (-mcumode) or WGP (-mno-cumode) wavefront execution mode (AMDGPU only)">;
+def mno_cumode : Flag<["-"], "mno-cumode">, Group;
 
-def mxnack : Flag<["-"], "mxnack">, Group,
-  HelpText<"Enable XNACK (AMDGPU only)">;
-def mno_xnack : Flag<["-"], "mno-xnack">, Group,
-  HelpText<"Disable XNACK (AMDGPU only)">;
 def msram_ecc : Flag<["-"], "msram-ecc">, Group,
-  HelpText<"Enable SRAM ECC (AMDGPU only)">;
-def mno_sram_ecc : Flag<["-"], "mno-sram-ecc">, Group,
-  HelpText<"Disable SRAM ECC (AMDGPU only)">;
+  HelpText<"Specify SRAM ECC mode (AMDGPU only)">;
+def mno_sram_ecc : Flag<["-"], "mno-sram-ecc">, Group;
 
-def mcumode : Flag<["-"], "mcumode">, Group,
-  HelpText<"CU wavefront execution mode is used (AMDGPU only)">;
-def mno_cumode : Flag<["-"], "mno-cumode">, Group,
-  HelpText<"WGP wavefront execution mode is used (AMDGPU only)">;
-
-def mwavefrontsize64 : Flag<["-"], "mwavefrontsize64">,
-  Group, HelpText<"Wavefront size 64 is used">;
-def mno_wavefrontsize64 : Flag<["-"], "mno-wavefrontsize64">,
-  Group, HelpText<"Wavefront size 32 is used">;
+def mwavefrontsize64 : Flag<["-"], "mwavefrontsize64">, Group,
+  HelpText<"Specify wavefront size 64 mode (AMDGPU only)">;
+def mno_wavefrontsize64 : Flag<["-"], "mno-wavefrontsize64">, Group,
+  HelpText<"Specify wavefront size 32 mode (AMDGPU only)">;
+
+def mxnack : Flag<["-"], "mxnack">, Group,
+  HelpText<"Specify XNACK mode (AMDGPU only)">;
+def mno_xnack : Flag<["-"], "mno-xnack">, Group;
 
 def faltivec : Flag<["-"], "faltivec">, Group, Flags<[DriverOption]>;
 def fno_altivec : Flag<["-"], "fno-altivec">, Group, Flags<[DriverOption]>;
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -1641,6 +1641,10 @@
 
 Allow device side init 

[PATCH] D90419: [AMDGPU] Add gfx90c target

2020-10-29 Thread Tim Renouf via Phabricator via cfe-commits
tpr created this revision.
Herald added subscribers: llvm-commits, cfe-commits, dexonsmith, kerbowa, 
rupprecht, hiraditya, t-tye, dstuttard, yaxunl, nhaehnle, jvesely, kzhuravl, 
arsenm, jholewinski.
Herald added a reviewer: jhenderson.
Herald added projects: clang, LLVM.
tpr requested review of this revision.
Herald added subscribers: MaskRay, wdng.

This differentiates certain hardware that was previously included in
gfx909.

Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90419

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/AMDGPU.td
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
  llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
  llvm/tools/llvm-readobj/ELFDumper.cpp

Index: llvm/tools/llvm-readobj/ELFDumper.cpp
===
--- llvm/tools/llvm-readobj/ELFDumper.cpp
+++ llvm/tools/llvm-readobj/ELFDumper.cpp
@@ -1779,6 +1779,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX906),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX908),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX909),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX90C),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1010),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1011),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1012),
Index: llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
===
--- llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
+++ llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
@@ -166,6 +166,10 @@
 # RUN: llvm-readobj -s -file-headers %t.o.42 | FileCheck --check-prefixes=ELF-ALL,ELF-GFX1032 %s
 # RUN: obj2yaml %t.o.42 | FileCheck --check-prefixes=YAML-GFX1032 %s
 
+# RUN: yaml2obj --docnum=43 %s -o %t.o.43
+# RUN: llvm-readobj -s -file-headers %t.o.43 | FileCheck --check-prefixes=ELF-ALL,ELF-GFX90C %s
+# RUN: obj2yaml %t.o.43 | FileCheck --check-prefixes=YAML-GFX90C %s
+
 # ELF-ALL: Flags [
 # ELF-R600:  EF_AMDGPU_MACH_R600_R600 (0x1)
 # ELF-R630:  EF_AMDGPU_MACH_R600_R630 (0x2)
@@ -203,6 +207,7 @@
 # ELF-GFX906:EF_AMDGPU_MACH_AMDGCN_GFX906 (0x2F)
 # ELF-GFX908:EF_AMDGPU_MACH_AMDGCN_GFX908 (0x30)
 # ELF-GFX909:EF_AMDGPU_MACH_AMDGCN_GFX909 (0x31)
+# ELF-GFX90C:EF_AMDGPU_MACH_AMDGCN_GFX90C (0x32)
 # ELF-GFX1010:   EF_AMDGPU_MACH_AMDGCN_GFX1010 (0x33)
 # ELF-GFX1011:   EF_AMDGPU_MACH_AMDGCN_GFX1011 (0x34)
 # ELF-GFX1012:   EF_AMDGPU_MACH_AMDGCN_GFX1012 (0x35)
@@ -247,6 +252,7 @@
 # YAML-GFX906:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX906 ]
 # YAML-GFX908:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX908 ]
 # YAML-GFX909:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX909 ]
+# YAML-GFX90C:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX90C ]
 # YAML-GFX1010: Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX1010 ]
 # YAML-GFX1011: Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX1011 ]
 # YAML-GFX1012: Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX1012 ]
@@ -715,3 +721,14 @@
   Machine: EM_AMDGPU
   Flags:   [ EF_AMDGPU_MACH_AMDGCN_GFX1032 ]
 ...
+
+# Doc43
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  OSABI:   ELFOSABI_NONE
+  Type:ET_REL
+  Machine: EM_AMDGPU
+  Flags:   [ EF_AMDGPU_MACH_AMDGCN_GFX90C ]
+...
Index: llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
===
--- llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
+++ llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
@@ -52,6 +52,7 @@
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx906 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX906 %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx908 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX908 %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx909 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX909 %s
+; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx90c < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX90C %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx1010 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX1010 %s
 ; RUN: llc -filetype=obj -march=amdgcn -mcpu=gfx1011 < %s | llvm-readobj -file-headers - | FileCheck --check-prefixes=ALL,ARCH-GCN,GFX1011 %s
 

[PATCH] D90054: Added remotely ran compiler-rt tests.

2020-10-29 Thread Alex Orlov 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 rG8aaafa06b2af: Added remotely ran compiler-rt tests. 
(authored by aorlov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90054

Files:
  clang/cmake/caches/CrossWinToARMLinux.cmake


Index: clang/cmake/caches/CrossWinToARMLinux.cmake
===
--- clang/cmake/caches/CrossWinToARMLinux.cmake
+++ clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -71,7 +71,9 @@
 set(COMPILER_RT_BUILD_XRAY  OFF CACHE BOOL "")
 set(COMPILER_RT_BUILD_LIBFUZZER OFF CACHE BOOL "")
 set(COMPILER_RT_BUILD_PROFILE   OFF CACHE BOOL "")
+set(COMPILER_RT_BUILD_CRT   OFF CACHE BOOL "")
 set(COMPILER_RT_DEFAULT_TARGET_ONLY ON CACHE BOOL "")
+set(COMPILER_RT_INCLUDE_TESTS   ON CACHE BOOL "")
 
 set(LIBUNWIND_USE_COMPILER_RT   ON CACHE BOOL "")
 set(LIBUNWIND_TARGET_TRIPLE "${CMAKE_C_COMPILER_TARGET}" CACHE 
STRING "")
@@ -109,6 +111,9 @@
   set(DEFAULT_TEST_TARGET_INFO  
"libcxx.test.target_info.LinuxRemoteTI")
 
   # Allow override with the custom values.
+  if(NOT DEFINED COMPILER_RT_EMULATOR)
+set(COMPILER_RT_EMULATOR"\\\"${Python3_EXECUTABLE}\\\" 
\\\"${LLVM_PROJECT_DIR}/llvm/utils/remote-exec.py\\\" --execdir %%T 
--exec-pattern='.*\\.c.*\\.tmp.*' 
--host='${REMOTE_TEST_USER}@${REMOTE_TEST_HOST}'" CACHE STRING "")
+  endif()
   if(NOT DEFINED LIBUNWIND_TARGET_INFO)
 set(LIBUNWIND_TARGET_INFO   "${DEFAULT_TEST_TARGET_INFO}" 
CACHE STRING "")
   endif()


Index: clang/cmake/caches/CrossWinToARMLinux.cmake
===
--- clang/cmake/caches/CrossWinToARMLinux.cmake
+++ clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -71,7 +71,9 @@
 set(COMPILER_RT_BUILD_XRAY  OFF CACHE BOOL "")
 set(COMPILER_RT_BUILD_LIBFUZZER OFF CACHE BOOL "")
 set(COMPILER_RT_BUILD_PROFILE   OFF CACHE BOOL "")
+set(COMPILER_RT_BUILD_CRT   OFF CACHE BOOL "")
 set(COMPILER_RT_DEFAULT_TARGET_ONLY ON CACHE BOOL "")
+set(COMPILER_RT_INCLUDE_TESTS   ON CACHE BOOL "")
 
 set(LIBUNWIND_USE_COMPILER_RT   ON CACHE BOOL "")
 set(LIBUNWIND_TARGET_TRIPLE "${CMAKE_C_COMPILER_TARGET}" CACHE STRING "")
@@ -109,6 +111,9 @@
   set(DEFAULT_TEST_TARGET_INFO  "libcxx.test.target_info.LinuxRemoteTI")
 
   # Allow override with the custom values.
+  if(NOT DEFINED COMPILER_RT_EMULATOR)
+set(COMPILER_RT_EMULATOR"\\\"${Python3_EXECUTABLE}\\\" \\\"${LLVM_PROJECT_DIR}/llvm/utils/remote-exec.py\\\" --execdir %%T --exec-pattern='.*\\.c.*\\.tmp.*' --host='${REMOTE_TEST_USER}@${REMOTE_TEST_HOST}'" CACHE STRING "")
+  endif()
   if(NOT DEFINED LIBUNWIND_TARGET_INFO)
 set(LIBUNWIND_TARGET_INFO   "${DEFAULT_TEST_TARGET_INFO}" CACHE STRING "")
   endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 8aaafa0 - Added remotely ran compiler-rt tests.

2020-10-29 Thread Alex Orlov via cfe-commits

Author: Alex Orlov
Date: 2020-10-30T00:11:16+04:00
New Revision: 8aaafa06b2afce8d0c7ac062708fd91aae01909f

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

LOG: Added remotely ran compiler-rt tests.

Use LLVM/utils/remote-exec.py to run compiler-rt tests remotely on the target.

Reviewed By: vvereschaka

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

Added: 


Modified: 
clang/cmake/caches/CrossWinToARMLinux.cmake

Removed: 




diff  --git a/clang/cmake/caches/CrossWinToARMLinux.cmake 
b/clang/cmake/caches/CrossWinToARMLinux.cmake
index 83d581567020..67d49f4e52ec 100644
--- a/clang/cmake/caches/CrossWinToARMLinux.cmake
+++ b/clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -71,7 +71,9 @@ set(COMPILER_RT_BUILD_SANITIZERSOFF CACHE BOOL "")
 set(COMPILER_RT_BUILD_XRAY  OFF CACHE BOOL "")
 set(COMPILER_RT_BUILD_LIBFUZZER OFF CACHE BOOL "")
 set(COMPILER_RT_BUILD_PROFILE   OFF CACHE BOOL "")
+set(COMPILER_RT_BUILD_CRT   OFF CACHE BOOL "")
 set(COMPILER_RT_DEFAULT_TARGET_ONLY ON CACHE BOOL "")
+set(COMPILER_RT_INCLUDE_TESTS   ON CACHE BOOL "")
 
 set(LIBUNWIND_USE_COMPILER_RT   ON CACHE BOOL "")
 set(LIBUNWIND_TARGET_TRIPLE "${CMAKE_C_COMPILER_TARGET}" CACHE 
STRING "")
@@ -109,6 +111,9 @@ if(DEFINED REMOTE_TEST_HOST)
   set(DEFAULT_TEST_TARGET_INFO  
"libcxx.test.target_info.LinuxRemoteTI")
 
   # Allow override with the custom values.
+  if(NOT DEFINED COMPILER_RT_EMULATOR)
+set(COMPILER_RT_EMULATOR"\\\"${Python3_EXECUTABLE}\\\" 
\\\"${LLVM_PROJECT_DIR}/llvm/utils/remote-exec.py\\\" --execdir %%T 
--exec-pattern='.*\\.c.*\\.tmp.*' 
--host='${REMOTE_TEST_USER}@${REMOTE_TEST_HOST}'" CACHE STRING "")
+  endif()
   if(NOT DEFINED LIBUNWIND_TARGET_INFO)
 set(LIBUNWIND_TARGET_INFO   "${DEFAULT_TEST_TARGET_INFO}" 
CACHE STRING "")
   endif()



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


[clang] 9bb9b73 - Remove HAVE_VCS_VERSION_INC, not needed

2020-10-29 Thread Fangrui Song via cfe-commits

Author: Marcel Hlopko
Date: 2020-10-29T13:09:05-07:00
New Revision: 9bb9b737c5573cf3850230bc4db8dac7be0e1e85

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

LOG: Remove HAVE_VCS_VERSION_INC, not needed

This preprocessor define was meant to be used to conditionally include 
VCSVersion.inc. However, the define was always set, and it was the content of 
the header that was conditionally generated. Therefore HAVE_VCS_VERSION_INC 
should be cleaned up.

Reviewed By: gribozavr2, MaskRay

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

Added: 


Modified: 
clang/lib/Basic/CMakeLists.txt
clang/lib/Basic/Version.cpp
lld/Common/CMakeLists.txt
lld/Common/Version.cpp
lldb/source/CMakeLists.txt
lldb/source/lldb.cpp
llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
llvm/utils/gn/secondary/lld/Common/BUILD.gn

Removed: 




diff  --git a/clang/lib/Basic/CMakeLists.txt b/clang/lib/Basic/CMakeLists.txt
index dfbe74a3f9f1..d259b951f2c2 100644
--- a/clang/lib/Basic/CMakeLists.txt
+++ b/clang/lib/Basic/CMakeLists.txt
@@ -33,9 +33,6 @@ set_source_files_properties("${version_inc}"
   PROPERTIES GENERATED TRUE
  HEADER_FILE_ONLY TRUE)
 
-set_property(SOURCE Version.cpp APPEND PROPERTY
- COMPILE_DEFINITIONS "HAVE_VCS_VERSION_INC")
-
 add_clang_library(clangBasic
   Attributes.cpp
   Builtins.cpp

diff  --git a/clang/lib/Basic/Version.cpp b/clang/lib/Basic/Version.cpp
index 286107cab9d7..af3118b0f6da 100644
--- a/clang/lib/Basic/Version.cpp
+++ b/clang/lib/Basic/Version.cpp
@@ -17,9 +17,7 @@
 #include 
 #include 
 
-#ifdef HAVE_VCS_VERSION_INC
 #include "VCSVersion.inc"
-#endif
 
 namespace clang {
 

diff  --git a/lld/Common/CMakeLists.txt b/lld/Common/CMakeLists.txt
index bfa4f7b8ee58..0437d5afb8eb 100644
--- a/lld/Common/CMakeLists.txt
+++ b/lld/Common/CMakeLists.txt
@@ -26,9 +26,6 @@ set_source_files_properties("${version_inc}"
   PROPERTIES GENERATED TRUE
   HEADER_FILE_ONLY TRUE)
 
-set_property(SOURCE Version.cpp APPEND PROPERTY
-  COMPILE_DEFINITIONS "HAVE_VCS_VERSION_INC")
-
 add_lld_library(lldCommon
   Args.cpp
   DWARF.cpp

diff  --git a/lld/Common/Version.cpp b/lld/Common/Version.cpp
index cd9fcd4f4059..f3768091cd0e 100644
--- a/lld/Common/Version.cpp
+++ b/lld/Common/Version.cpp
@@ -12,9 +12,7 @@
 
 #include "lld/Common/Version.h"
 
-#ifdef HAVE_VCS_VERSION_INC
 #include "VCSVersion.inc"
-#endif
 
 // Returns a version string, e.g.:
 // lld 9.0.0 (https://github.com/llvm/llvm-project.git 9efdd7ac5e914d3c9fa1ef)

diff  --git a/lldb/source/CMakeLists.txt b/lldb/source/CMakeLists.txt
index 6dbdec5ec008..56ea8342be4e 100644
--- a/lldb/source/CMakeLists.txt
+++ b/lldb/source/CMakeLists.txt
@@ -26,9 +26,6 @@ set_source_files_properties("${version_inc}"
   PROPERTIES GENERATED TRUE
  HEADER_FILE_ONLY TRUE)
 
-set_property(SOURCE lldb.cpp APPEND PROPERTY
- COMPILE_DEFINITIONS "HAVE_VCS_VERSION_INC")
-
 list(APPEND lldbBase_SOURCES ${version_inc})
 
 if(LLDB_VERSION_STRING)

diff  --git a/lldb/source/lldb.cpp b/lldb/source/lldb.cpp
index 4d4c636a4f9c..10fc2d7cf556 100644
--- a/lldb/source/lldb.cpp
+++ b/lldb/source/lldb.cpp
@@ -13,9 +13,7 @@ using namespace lldb_private;
 
 #include "clang/Basic/Version.h"
 
-#ifdef HAVE_VCS_VERSION_INC
 #include "VCSVersion.inc"
-#endif
 
 static const char *GetLLDBRevision() {
 #ifdef LLDB_REVISION

diff  --git a/llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn 
b/llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
index 43767f15e1a1..2fe572ada231 100644
--- a/llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
+++ b/llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
@@ -103,5 +103,4 @@ static_library("Basic") {
 "XRayInstr.cpp",
 "XRayLists.cpp",
   ]
-  defines = [ "HAVE_VCS_VERSION_INC" ]  # For Version.cpp
 }

diff  --git a/llvm/utils/gn/secondary/lld/Common/BUILD.gn 
b/llvm/utils/gn/secondary/lld/Common/BUILD.gn
index 125cad30a32e..d02d950e88d2 100644
--- a/llvm/utils/gn/secondary/lld/Common/BUILD.gn
+++ b/llvm/utils/gn/secondary/lld/Common/BUILD.gn
@@ -42,5 +42,4 @@ static_library("Common") {
 "Timer.cpp",
 "Version.cpp",
   ]
-  defines = [ "HAVE_VCS_VERSION_INC" ]  # For Version.cpp
 }



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


[PATCH] D84623: Remove HAVE_VCS_VERSION_INC, not needed

2020-10-29 Thread Fangrui Song 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 rG9bb9b737c557: Remove HAVE_VCS_VERSION_INC, not needed 
(authored by hlopko, committed by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84623

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Version.cpp
  lld/Common/CMakeLists.txt
  lld/Common/Version.cpp
  lldb/source/CMakeLists.txt
  lldb/source/lldb.cpp
  llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
  llvm/utils/gn/secondary/lld/Common/BUILD.gn

Index: llvm/utils/gn/secondary/lld/Common/BUILD.gn
===
--- llvm/utils/gn/secondary/lld/Common/BUILD.gn
+++ llvm/utils/gn/secondary/lld/Common/BUILD.gn
@@ -42,5 +42,4 @@
 "Timer.cpp",
 "Version.cpp",
   ]
-  defines = [ "HAVE_VCS_VERSION_INC" ]  # For Version.cpp
 }
Index: llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
@@ -103,5 +103,4 @@
 "XRayInstr.cpp",
 "XRayLists.cpp",
   ]
-  defines = [ "HAVE_VCS_VERSION_INC" ]  # For Version.cpp
 }
Index: lldb/source/lldb.cpp
===
--- lldb/source/lldb.cpp
+++ lldb/source/lldb.cpp
@@ -13,9 +13,7 @@
 
 #include "clang/Basic/Version.h"
 
-#ifdef HAVE_VCS_VERSION_INC
 #include "VCSVersion.inc"
-#endif
 
 static const char *GetLLDBRevision() {
 #ifdef LLDB_REVISION
Index: lldb/source/CMakeLists.txt
===
--- lldb/source/CMakeLists.txt
+++ lldb/source/CMakeLists.txt
@@ -26,9 +26,6 @@
   PROPERTIES GENERATED TRUE
  HEADER_FILE_ONLY TRUE)
 
-set_property(SOURCE lldb.cpp APPEND PROPERTY
- COMPILE_DEFINITIONS "HAVE_VCS_VERSION_INC")
-
 list(APPEND lldbBase_SOURCES ${version_inc})
 
 if(LLDB_VERSION_STRING)
Index: lld/Common/Version.cpp
===
--- lld/Common/Version.cpp
+++ lld/Common/Version.cpp
@@ -12,9 +12,7 @@
 
 #include "lld/Common/Version.h"
 
-#ifdef HAVE_VCS_VERSION_INC
 #include "VCSVersion.inc"
-#endif
 
 // Returns a version string, e.g.:
 // lld 9.0.0 (https://github.com/llvm/llvm-project.git 9efdd7ac5e914d3c9fa1ef)
Index: lld/Common/CMakeLists.txt
===
--- lld/Common/CMakeLists.txt
+++ lld/Common/CMakeLists.txt
@@ -26,9 +26,6 @@
   PROPERTIES GENERATED TRUE
   HEADER_FILE_ONLY TRUE)
 
-set_property(SOURCE Version.cpp APPEND PROPERTY
-  COMPILE_DEFINITIONS "HAVE_VCS_VERSION_INC")
-
 add_lld_library(lldCommon
   Args.cpp
   DWARF.cpp
Index: clang/lib/Basic/Version.cpp
===
--- clang/lib/Basic/Version.cpp
+++ clang/lib/Basic/Version.cpp
@@ -17,9 +17,7 @@
 #include 
 #include 
 
-#ifdef HAVE_VCS_VERSION_INC
 #include "VCSVersion.inc"
-#endif
 
 namespace clang {
 
Index: clang/lib/Basic/CMakeLists.txt
===
--- clang/lib/Basic/CMakeLists.txt
+++ clang/lib/Basic/CMakeLists.txt
@@ -33,9 +33,6 @@
   PROPERTIES GENERATED TRUE
  HEADER_FILE_ONLY TRUE)
 
-set_property(SOURCE Version.cpp APPEND PROPERTY
- COMPILE_DEFINITIONS "HAVE_VCS_VERSION_INC")
-
 add_clang_library(clangBasic
   Attributes.cpp
   Builtins.cpp
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D84623: Remove HAVE_VCS_VERSION_INC, not needed

2020-10-29 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.
Herald added a subscriber: dexonsmith.

Thanks! Assuming you don't have a commit bit, I'll commit on your behalf.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84623

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


[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

2020-10-29 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/include/clang/AST/DeclCXX.h:1013
   CXXMethodDecl *getLambdaStaticInvoker() const;
+  CXXMethodDecl *getLambdaStaticInvoker(CallingConv CC) const;
+

rjmccall wrote:
> Probably worth clarifying in the comment which invoker is returned by the 
> no-arguments variant.
I just looked and the first is actually only used 1x!  I think I can just 
replace that usage and remove the former overload if that is acceptable to you.



Comment at: clang/lib/AST/DeclCXX.cpp:1550
+ return FTy->getCallConv() == CC;
+   });
+

rjmccall wrote:
> This seems both rather more complicated and rather more expensive than a 
> simple loop which assigns to a local pointer.
Do you mean the filtering copy-if?  The idea was to make it so that the assert 
below still applies.  If that isn't necessary, this DOES simplify to a 
std::find and a return.



Comment at: clang/lib/AST/MicrosoftMangle.cpp:2268
+} else if (const auto *AT = dyn_cast_or_null(
+   ResultType->getContainedAutoType())) {
   Out << '?';

rjmccall wrote:
> So, this is changing the mangling of lambda conversion operators.  Is this 
> what MSVC does?
Yes, this mangles the 'return type' of the conversion operator, which MSVC does 
as well.  We have an incompatible mangling (already) that skipped this because 
the type has some sort of deduction in it (to protect against a type that is 
defined in terms of the same type).





Comment at: clang/lib/Sema/SemaLambda.cpp:1467
+  llvm::SmallVector Conventions =
+  getLambdaConversionFunctionCallConv(S, CallOpProto);
+

rjmccall wrote:
> Can we make this call a callback or something rather than returning an array 
> that almost always has one element?
Sure!  Can do.



Comment at: clang/lib/Sema/SemaLambda.cpp:1278
+  if (CallOpCC == DefaultMember)
+return DefaultFree;
+  return CallOpCC;

rjmccall wrote:
> erichkeane wrote:
> > rsmith wrote:
> > > rsmith wrote:
> > > > erichkeane wrote:
> > > > > rjmccall wrote:
> > > > > > ...I made this comment in my first review, but Phabricator threw it 
> > > > > > away.
> > > > > > 
> > > > > > The attributes let you explicitly request the default method CC, 
> > > > > > right?  I think you need to check for an explicit attribute rather 
> > > > > > than just checking CC identity.  There should be an AttributedType 
> > > > > > in the sugar.
> > > > > They do, but I can't seem to find a way to find them.  The calling 
> > > > > convention is already merged into the functiontype by the time we get 
> > > > > here, the AttributedType isn't accessible.
> > > > > 
> > > > > So it seems we don't distinguish between "modified by attribute", 
> > > > > "modified-default by command line", and "modified-default by 
> > > > > TargetInfo."
> > > > > 
> > > > > That said, I somewhat think this is the right thing to do anyway.  If 
> > > > > you're on a platform where the default call convention is different 
> > > > > between a free-function and member-function, I'd think that this is 
> > > > > what you MEAN...
> > > > The `AttributedType` should be present in the type on the 
> > > > `TypeSourceInfo` for the call operator. It might not be present on the 
> > > > type retrieved by `getType()`, though.
> > > > 
> > > > Concretely, what targets have different calling conventions for member 
> > > > versus non-member functions, and what do those calling conventions do 
> > > > differently? (For example, if the default member calling convention 
> > > > treats `this` differently, it doesn't seem reasonable to apply that to 
> > > > the static invoker...)
> > > Answering my own question: the only case where the default member calling 
> > > convention is different from the default non-member calling convention is 
> > > for MinGW on 32-bit x86, where members use `thiscall` by default (which 
> > > passes the first parameter in `%ecx`).
> > > 
> > > Is it reasonable for `[] [[clang::thiscall]] {}` to result in a static 
> > > invoker using the `thiscall` calling convention? Intuitively I'd say no, 
> > > but there's not really anything specific to member functions in 
> > > `thiscall` -- it just means that we pass the first argument in a 
> > > register. (However, the first argument of the lambda and the first 
> > > argument of its static invoker are different, so it's still somewhat 
> > > unclear whether inheriting `thiscall` is appropriate. But usually for any 
> > > given lambda only one of the two is actually used.)
> > > 
> > > But there's another quirk here: the default non-member calling convention 
> > > can be set on the command line with `-fdefault-calling-conv=` (and a few 
> > > other flags such as `-mrtd`). This doesn't affect member functions by 
> > > default. So what should happen if this is compiled with 
> > > 

[PATCH] D90415: [OpenMP] Use __OPENMP_NVPTX__ instead of _OPENMP in complex wrapper headers.

2020-10-29 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.

You need to define & undefine the macro around the includes of 
`__clang_cuda_complex_builtins.h` in 
`clang/lib/Headers/openmp_wrappers/complex` and 
`clang/lib/Headers/openmp_wrappers/complex.h`. (see also rG7f1e6fcff942 
) That 
should fix the tests. Assuming the tests pass, LGTM.

For release 11, can you file a bug and prepare a patch that applies to the 
relevant branch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90415

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


[PATCH] D90109: [clang-tidy] Use ANSI escape codes for --use-color on Windows

2020-10-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D90109#2360538 , @dsanders11 wrote:

>> What issues did you run into regarding testing, because I feel like the 
>> patch should have test coverage (esp given that color vs ANSI escape codes 
>> are a bit of an oddity to reason about)?
>
> I'm unable to create a debug build, due to issues with LLVM and Visual Studio 
> 16.7 
> .
>  There's Google results on the issue, but I don't see any solution and I'm 
> using `master` and the latest version of Visual Studio. It seems you can (and 
> perhaps should?) run the tests with a Release build, so I've gone ahead and 
> done that.

Oh, how neat. The bug you linked to was closed as a dup of another bug. The 
other bug was then closed as something that's not in scope with the general 
product direction, whatever that means.

> I also wasn't seeing any of the test targets being made by CMake until I 
> included `-DLLVM_INCLUDE_TESTS=On`, I think maybe I set that to off when 
> trying to determine why the debug build was failing and didn't realize that 
> would stay in `CMakeCache.txt` until I set it back on.
>
> Removing `REQUIRES: ansi-escape-sequences` from the 
> `clang-tidy/infrastructure/use-color.cpp` test does run it on Windows and 
> does pass as expected with this change. Is that all you're looking for with 
> test coverage?

Yeah, that would be reasonable test coverage.




Comment at: llvm/lib/Support/Windows/Process.inc:330
 DWORD Mode;
-GetConsoleMode(Console, );
-Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
-SetConsoleMode(Console, Mode);
+if (GetConsoleMode(Console, ) != 0) {
+  Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;

dsanders11 wrote:
> aaron.ballman wrote:
> > dsanders11 wrote:
> > > Fixes a crash when calling UseANSIEscapeCodes if standard out isn't a 
> > > console.
> > If this fails, do we still want to set `UseANSI` to `enable` below? Similar 
> > if setting the mode fails?
> If we don't set `UseANSI` below then this patch won't do what it's intended 
> to do, since piped stdoutwouldn't have ANSI escape codes. This code block is 
> assuming that standard output is a console, so `GetConsoleMode` won't work on 
> redirected stdout.
> 
> You could use `llvm::sys::Process::StandardOutIsDisplayed()` to check, but 
> for Windows that's actually just doing the same thing, doing a 
> `GetConsoleMode` call and seeing if it succeeds or not.
> 
> For this patch to do what it's intended to do, `UseANSIEscapeCodes` needs to 
> turn on ANSI escape codes even if there isn't a console.
Ah, thank you for the explanation -- my complaint is more that 
`UseANSIEscapeCodes` can fail but doesn't alert the caller to the failure. 
However, that's not a new issue, so I think it's fine as-is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90109

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


[PATCH] D90316: [FPEnv] Diagnose pragmas FENV_ROUND,_ACCESS and float_control if target does not support StrictFP

2020-10-29 Thread Melanie Blower via Phabricator via cfe-commits
mibintc marked 2 inline comments as done.
mibintc added inline comments.



Comment at: clang/lib/Parse/ParsePragma.cpp:2967
+PP.Diag(Tok.getLocation(), diag::warn_pragma_fp_ignored)
+<< PragmaName.getIdentifierInfo()->getName();
+return;

aaron.ballman wrote:
> Can you pass in `PragmaName` directly, or does that do unfortunate things 
> with single quotes?
After I changed it to PragmaName, the clang-format didn't find anything to fix


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90316

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


[PATCH] D90316: [FPEnv] Diagnose pragmas FENV_ROUND,_ACCESS and float_control if target does not support StrictFP

2020-10-29 Thread Melanie Blower via Phabricator via cfe-commits
mibintc updated this revision to Diff 301708.
mibintc added a comment.

respond to @aaron.ballman 's review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90316

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParsePragma.cpp
  clang/test/Parser/pragma-fp-warn.c


Index: clang/test/Parser/pragma-fp-warn.c
===
--- /dev/null
+++ clang/test/Parser/pragma-fp-warn.c
@@ -0,0 +1,19 @@
+
+// RUN: %clang_cc1 -triple wasm32 -fsyntax-only -Wno-unknown-pragmas 
-Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -triple thumbv7 -fsyntax-only -Wno-unknown-pragmas 
-Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -triple aarch64 -fsyntax-only -Wno-unknown-pragmas 
-Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -DEXPOK -triple x86_64 -fsyntax-only -Wno-unknown-pragmas 
-Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -DEXPOK -triple systemz -fsyntax-only -Wno-unknown-pragmas 
-Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -DEXPOK -triple powerpc -fsyntax-only -Wno-unknown-pragmas 
-Wignored-pragmas -verify %s
+#ifdef EXPOK
+// expected-no-diagnostics
+#else
+// expected-warning@+4 {{'#pragma float_control' is not supported on this 
target - ignored}}
+// expected-warning@+5 {{'#pragma FENV_ACCESS' is not supported on this target 
- ignored}}
+// expected-warning@+6 {{'#pragma FENV_ROUND' is not supported on this target 
- ignored}}
+#endif
+#pragma float_control(precise, on)
+
+#pragma STDC FENV_ACCESS OFF
+
+#pragma STDC FENV_ROUND FE_DOWNWARD
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -103,6 +103,12 @@
 
   void HandlePragma(Preprocessor , PragmaIntroducer Introducer,
 Token ) override {
+Token PragmaName = Tok;
+if (!PP.getTargetInfo().hasStrictFP() && !PP.getLangOpts().ExpStrictFP) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_fp_ignored)
+  << PragmaName.getIdentifierInfo()->getName();
+  return;
+}
 tok::OnOffSwitch OOS;
 if (PP.LexOnOffSwitch(OOS))
  return;
@@ -2553,6 +2559,12 @@
  Token ) {
   Sema::PragmaMsStackAction Action = Sema::PSK_Set;
   SourceLocation FloatControlLoc = Tok.getLocation();
+  Token PragmaName = Tok;
+  if (!PP.getTargetInfo().hasStrictFP() && !PP.getLangOpts().ExpStrictFP) {
+PP.Diag(Tok.getLocation(), diag::warn_pragma_fp_ignored)
+<< PragmaName.getIdentifierInfo()->getName();
+return;
+  }
   PP.Lex(Tok);
   if (Tok.isNot(tok::l_paren)) {
 PP.Diag(FloatControlLoc, diag::err_expected) << tok::l_paren;
@@ -2952,6 +2964,11 @@
 Token ) {
   Token PragmaName = Tok;
   SmallVector TokenList;
+  if (!PP.getTargetInfo().hasStrictFP() && !PP.getLangOpts().ExpStrictFP) {
+PP.Diag(Tok.getLocation(), diag::warn_pragma_fp_ignored)
+<< PragmaName.getIdentifierInfo()->getName();
+return;
+  }
 
   PP.Lex(Tok);
   if (Tok.isNot(tok::identifier)) {
Index: clang/include/clang/Basic/DiagnosticParseKinds.td
===
--- clang/include/clang/Basic/DiagnosticParseKinds.td
+++ clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1147,6 +1147,9 @@
 def warn_stdc_unknown_rounding_mode : Warning<
   "invalid or unsupported rounding mode in '#pragma STDC FENV_ROUND' - 
ignored">,
   InGroup;
+def warn_pragma_fp_ignored : Warning<
+  "'#pragma %0' is not supported on this target - ignored">,
+  InGroup;
 // - #pragma comment
 def err_pragma_comment_malformed : Error<
   "pragma comment requires parenthesized identifier and optional string">;


Index: clang/test/Parser/pragma-fp-warn.c
===
--- /dev/null
+++ clang/test/Parser/pragma-fp-warn.c
@@ -0,0 +1,19 @@
+
+// RUN: %clang_cc1 -triple wasm32 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -triple thumbv7 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -triple aarch64 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -DEXPOK -triple x86_64 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -DEXPOK -triple systemz -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -DEXPOK -triple powerpc -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
+#ifdef EXPOK
+// expected-no-diagnostics
+#else
+// expected-warning@+4 {{'#pragma float_control' is not supported on this target - ignored}}
+// expected-warning@+5 {{'#pragma FENV_ACCESS' is not supported on this target - ignored}}
+// expected-warning@+6 {{'#pragma FENV_ROUND' is not supported on this target - ignored}}

[PATCH] D82278: Fix traversal over CXXConstructExpr in Syntactic mode

2020-10-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82278

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


[PATCH] D90415: [OpenMP] Use __OPENMP_NVPTX__ instead of _OPENMP in complex wrapper headers.

2020-10-29 Thread Joachim Meyer via Phabricator via cfe-commits
fodinabor created this revision.
Herald added subscribers: cfe-commits, guansong, yaxunl.
Herald added a project: clang.
fodinabor requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

This is very similar to 7f1e6fcff942 
, just 
fixing a left-over.
With this it should be possible to use both, -x cuda and -fopenmp in the same 
invocation,
enabling to use both OpenMP, targeting CPU, and CUDA, targeting the GPU.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90415

Files:
  clang/lib/Headers/__clang_cuda_complex_builtins.h


Index: clang/lib/Headers/__clang_cuda_complex_builtins.h
===
--- clang/lib/Headers/__clang_cuda_complex_builtins.h
+++ clang/lib/Headers/__clang_cuda_complex_builtins.h
@@ -16,7 +16,7 @@
 // to work with CUDA and OpenMP target offloading [in C and C++ mode].)
 
 #pragma push_macro("__DEVICE__")
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp declare target
 #define __DEVICE__ __attribute__((noinline, nothrow, cold, weak))
 #else
@@ -26,7 +26,7 @@
 // To make the algorithms available for C and C++ in CUDA and OpenMP we select
 // different but equivalent function versions. TODO: For OpenMP we currently
 // select the native builtins as the overload support for templates is lacking.
-#if !defined(_OPENMP)
+#if !defined(__OPENMP_NVPTX__)
 #define _ISNANd std::isnan
 #define _ISNANf std::isnan
 #define _ISINFd std::isinf
@@ -276,7 +276,7 @@
 #undef _fmaxd
 #undef _fmaxf
 
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp end declare target
 #endif
 


Index: clang/lib/Headers/__clang_cuda_complex_builtins.h
===
--- clang/lib/Headers/__clang_cuda_complex_builtins.h
+++ clang/lib/Headers/__clang_cuda_complex_builtins.h
@@ -16,7 +16,7 @@
 // to work with CUDA and OpenMP target offloading [in C and C++ mode].)
 
 #pragma push_macro("__DEVICE__")
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp declare target
 #define __DEVICE__ __attribute__((noinline, nothrow, cold, weak))
 #else
@@ -26,7 +26,7 @@
 // To make the algorithms available for C and C++ in CUDA and OpenMP we select
 // different but equivalent function versions. TODO: For OpenMP we currently
 // select the native builtins as the overload support for templates is lacking.
-#if !defined(_OPENMP)
+#if !defined(__OPENMP_NVPTX__)
 #define _ISNANd std::isnan
 #define _ISNANf std::isnan
 #define _ISINFd std::isinf
@@ -276,7 +276,7 @@
 #undef _fmaxd
 #undef _fmaxf
 
-#ifdef _OPENMP
+#ifdef __OPENMP_NVPTX__
 #pragma omp end declare target
 #endif
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

2020-10-29 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/include/clang/AST/DeclCXX.h:1013
   CXXMethodDecl *getLambdaStaticInvoker() const;
+  CXXMethodDecl *getLambdaStaticInvoker(CallingConv CC) const;
+

Probably worth clarifying in the comment which invoker is returned by the 
no-arguments variant.



Comment at: clang/lib/AST/DeclCXX.cpp:1550
+ return FTy->getCallConv() == CC;
+   });
+

This seems both rather more complicated and rather more expensive than a simple 
loop which assigns to a local pointer.



Comment at: clang/lib/AST/DeclCXX.cpp:1568
+return llvm::find_if(Invokers, MDEqual) != Invokers.end();
+  }
+

Can you clarify how this method is semantically different from:

```
  assert(MD->getParent() == this);
  return isLambda() && MD->getName() == getLambdaStaticInvokerName();
```

other than probably inadvertently working with a method from a completely 
different class?



Comment at: clang/lib/AST/MicrosoftMangle.cpp:2268
+} else if (const auto *AT = dyn_cast_or_null(
+   ResultType->getContainedAutoType())) {
   Out << '?';

So, this is changing the mangling of lambda conversion operators.  Is this what 
MSVC does?



Comment at: clang/lib/Sema/SemaLambda.cpp:1467
+  llvm::SmallVector Conventions =
+  getLambdaConversionFunctionCallConv(S, CallOpProto);
+

Can we make this call a callback or something rather than returning an array 
that almost always has one element?



Comment at: clang/lib/Sema/SemaLambda.cpp:1278
+  if (CallOpCC == DefaultMember)
+return DefaultFree;
+  return CallOpCC;

erichkeane wrote:
> rsmith wrote:
> > rsmith wrote:
> > > erichkeane wrote:
> > > > rjmccall wrote:
> > > > > ...I made this comment in my first review, but Phabricator threw it 
> > > > > away.
> > > > > 
> > > > > The attributes let you explicitly request the default method CC, 
> > > > > right?  I think you need to check for an explicit attribute rather 
> > > > > than just checking CC identity.  There should be an AttributedType in 
> > > > > the sugar.
> > > > They do, but I can't seem to find a way to find them.  The calling 
> > > > convention is already merged into the functiontype by the time we get 
> > > > here, the AttributedType isn't accessible.
> > > > 
> > > > So it seems we don't distinguish between "modified by attribute", 
> > > > "modified-default by command line", and "modified-default by 
> > > > TargetInfo."
> > > > 
> > > > That said, I somewhat think this is the right thing to do anyway.  If 
> > > > you're on a platform where the default call convention is different 
> > > > between a free-function and member-function, I'd think that this is 
> > > > what you MEAN...
> > > The `AttributedType` should be present in the type on the 
> > > `TypeSourceInfo` for the call operator. It might not be present on the 
> > > type retrieved by `getType()`, though.
> > > 
> > > Concretely, what targets have different calling conventions for member 
> > > versus non-member functions, and what do those calling conventions do 
> > > differently? (For example, if the default member calling convention 
> > > treats `this` differently, it doesn't seem reasonable to apply that to 
> > > the static invoker...)
> > Answering my own question: the only case where the default member calling 
> > convention is different from the default non-member calling convention is 
> > for MinGW on 32-bit x86, where members use `thiscall` by default (which 
> > passes the first parameter in `%ecx`).
> > 
> > Is it reasonable for `[] [[clang::thiscall]] {}` to result in a static 
> > invoker using the `thiscall` calling convention? Intuitively I'd say no, 
> > but there's not really anything specific to member functions in `thiscall` 
> > -- it just means that we pass the first argument in a register. (However, 
> > the first argument of the lambda and the first argument of its static 
> > invoker are different, so it's still somewhat unclear whether inheriting 
> > `thiscall` is appropriate. But usually for any given lambda only one of the 
> > two is actually used.)
> > 
> > But there's another quirk here: the default non-member calling convention 
> > can be set on the command line with `-fdefault-calling-conv=` (and a few 
> > other flags such as `-mrtd`). This doesn't affect member functions by 
> > default. So what should happen if this is compiled with 
> > `-fdefault-calling-conv=stdcall` (assuming the default calling convention 
> > is otherwise `cdecl`):
> > 
> > ```
> > auto *p0 = [] [[clang::stdcal]] {};
> > auto *p1 = [] {};
> > auto *p2 = [] [[clang::cdecl]] {};
> > ```
> > 
> > `p0` seems easy: the default non-member calling convention and the explicit 
> > calling convention are the same. The invoker should be `stdcall`.
> > 
> > For `p1`, the 

[PATCH] D90329: [PowerPC] Fix va_arg in Objective-C on 32-bit ELF targets

2020-10-29 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4723
+  bool isInt = Ty->isIntegerType() || Ty->hasPointerRepresentation() ||
+   Ty->isAggregateType();
   bool isF64 = Ty->isFloatingType() && getContext().getTypeSize(Ty) == 64;

I suspect this code doesn't handle C++ member pointers correctly.  But maybe we 
can leave that for a followup.

Could we simplify this to `bool isInt = !Ty->isFloatingType();`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90329

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


[PATCH] D90392: [clang-tidy] Omit std::make_unique/make_shared for default initialization.

2020-10-29 Thread Chris Kennelly via Phabricator via cfe-commits
ckennelly added a comment.

In D90392#2362327 , @lebedev.ri wrote:

> In D90392#2362308 , @ckennelly wrote:
>
>> In D90392#2362118 , @njames93 wrote:
>>
>>> IIUC, this is handling the case where `Ptr.reset(new int)` which is 
>>> different to `Ptr.reset(new int())` because the former doesn't initialise 
>>> the int while the latter default(zero) initialises it.
>>> If that's correct I still think we should still warn about this case, but 
>>> don't suggest an auto-fix as that will change behaviour.
>>> Maybe put a note explaining why it can't be auto-fixed.
>>
>> I disagree with printing a warning but not a fix.
>>
>> These uses should migrate to 
>> `std::make_unique_for_overwrite`/`std::make_shared_for_overwrite`.  I am 
>> planning on sending a follow-up patch for that but want to avoid the 
>> existing make-unique/make-shared checks try to migrate default 
>> initialization use cases.
>
> Reminder that there is more than one version of C++ standard, and users are 
> not obligated to be using some particular version, and the checks should not 
> be making that decision for user.

Understood, but replacing `std::unique_ptr(new int)` with 
`std::make_unique()` does change program behavior.  Once the code migrates 
to value initialization, it can be hard to determine later whether that 
initialization ends up being unnecessary when C++20 or an analogue for 
`std::make_unique_for_overwrite` is available.

I'm hesitant to nudge users towards the behavior change when alternatives would 
be available (maintain the status quo, have C++20, preadopt a 
`make_unique_for_overwrite` helper like we do with this clang-tidy for 
pre-C++14 builds).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90392

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


[PATCH] D84362: [NFC] Refactor DiagnosticBuilder and PartialDiagnostic

2020-10-29 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

It sounds like what you want is a diagnostic library that's almost completely 
abstracted over the kinds of entities that can be stored in a diagnostic, 
including the definition of a source location.  I don't think that's 
incompatible with this patch; there's no need to suggest reversion.

Source locations, supplemental source ranges, and fix-its are all still 
meaningful concepts in the driver, it's just that a source location is, say, an 
offset into a particular argument rather than a location in the file.  So the 
challenge for you is to come up with a way to abstract this that doesn't 
significantly make things worse for Clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84362

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


[clang-tools-extra] 7df80a1 - [clangd] Add support for multiple DecisionForest model experiments.

2020-10-29 Thread Utkarsh Saxena via cfe-commits

Author: Utkarsh Saxena
Date: 2020-10-29T19:49:40+01:00
New Revision: 7df80a1204f0dc91fb8bba7635e2354adf08989f

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

LOG: [clangd] Add support for multiple DecisionForest model experiments.

With every incremental change, one needs to check-in new model upstream.
This also significantly increases the size of the git repo with every
new model.
Testing and comparing the old and previous model is also not possible as
we run only a single model at any point.

One solution is to have a "staging" decision forest which can be
injected into clangd without pushing it to upstream. Compare the
performance of the staging model with the live model. After a couple of
enhancements have been done to staging model, we can then replace the
live model upstream with the staging model. This reduces upstream churn
and also allows us to compare models with current baseline model.

This is done by having a callback in CodeCompleteOptions which is called
only when we want to use a decision forest ranking model. This allows us
to inject different completion model internally.

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

Added: 


Modified: 
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/CodeComplete.h
clang-tools-extra/clangd/Quality.cpp
clang-tools-extra/clangd/Quality.h
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CodeComplete.cpp 
b/clang-tools-extra/clangd/CodeComplete.cpp
index 1d2770823190..8396de635135 100644
--- a/clang-tools-extra/clangd/CodeComplete.cpp
+++ b/clang-tools-extra/clangd/CodeComplete.cpp
@@ -1644,19 +1644,10 @@ class CodeCompleteFlow {
   return Scores;
 
 case RM::DecisionForest:
-  Scores.Quality = 0;
-  Scores.Relevance = 0;
-  // Exponentiating DecisionForest prediction makes the score of each tree 
a
-  // multiplciative boost (like NameMatch). This allows us to weigh the
-  // prediciton score and NameMatch appropriately.
-  Scores.ExcludingName = pow(Opts.DecisionForestBase,
- evaluateDecisionForest(Quality, Relevance));
-  // NeedsFixIts is not part of the DecisionForest as generating training
-  // data that needs fixits is not-feasible.
-  if (Relevance.NeedsFixIts)
-Scores.ExcludingName *= 0.5;
-  // NameMatch should be a multiplier on total score to support rescoring.
-  Scores.Total = Relevance.NameMatch * Scores.ExcludingName;
+  DecisionForestScores DFScores = Opts.DecisionForestScorer(
+  Quality, Relevance, Opts.DecisionForestBase);
+  Scores.ExcludingName = DFScores.ExcludingName;
+  Scores.Total = DFScores.Total;
   return Scores;
 }
 llvm_unreachable("Unhandled CodeCompletion ranking model.");

diff  --git a/clang-tools-extra/clangd/CodeComplete.h 
b/clang-tools-extra/clangd/CodeComplete.h
index 82a2656f172e..ce8a2097a6d9 100644
--- a/clang-tools-extra/clangd/CodeComplete.h
+++ b/clang-tools-extra/clangd/CodeComplete.h
@@ -154,14 +154,21 @@ struct CodeCompleteOptions {
 DecisionForest,
   } RankingModel = Heuristics;
 
+  /// Callback used to score a CompletionCandidate if DecisionForest ranking
+  /// model is enabled.
+  /// This allows us to inject experimental models and compare them with
+  /// baseline model using A/B testing.
+  std::function
+  DecisionForestScorer = 
   /// Weight for combining NameMatch and Prediction of DecisionForest.
   /// CompletionScore is NameMatch * pow(Base, Prediction).
   /// The optimal value of Base largely depends on the semantics of the model
   /// and prediction score (e.g. algorithm used during training, number of
   /// trees, etc.). Usually if the range of Prediciton is [-20, 20] then a Base
   /// in [1.2, 1.7] works fine.
-  /// Semantics: E.g. the completion score reduces by 50% if the Prediciton
-  /// score is reduced by 2.6 points for Base = 1.3.
+  /// Semantics: E.g. For Base = 1.3, if the Prediciton score reduces by 2.6
+  /// points then completion score reduces by 50% or 1.3^(-2.6).
   float DecisionForestBase = 1.3f;
 };
 

diff  --git a/clang-tools-extra/clangd/Quality.cpp 
b/clang-tools-extra/clangd/Quality.cpp
index 55b97eef123f..96784c077d05 100644
--- a/clang-tools-extra/clangd/Quality.cpp
+++ b/clang-tools-extra/clangd/Quality.cpp
@@ -487,8 +487,9 @@ float evaluateSymbolAndRelevance(float SymbolQuality, float 
SymbolRelevance) {
   return SymbolQuality * SymbolRelevance;
 }
 
-float evaluateDecisionForest(const SymbolQualitySignals ,
- const SymbolRelevanceSignals ) {
+DecisionForestScores
+evaluateDecisionForest(const SymbolQualitySignals ,
+   const 

[PATCH] D90014: [clangd] Add support for multiple DecisionForest model experiments.

2020-10-29 Thread Utkarsh Saxena 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 rG7df80a1204f0: [clangd] Add support for multiple 
DecisionForest model experiments. (authored by usaxena95).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90014

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/Quality.cpp
  clang-tools-extra/clangd/Quality.h
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -194,6 +194,33 @@
   ElementsAre(Named("clangA"), Named("clangD")));
 }
 
+TEST(DecisionForestRankingModel, DecisionForestScorerCallbackTest) {
+  clangd::CodeCompleteOptions Opts;
+  constexpr float MagicNumber = 1234.5678;
+  Opts.RankingModel = CodeCompleteOptions::DecisionForest;
+  Opts.DecisionForestScorer = [](const SymbolQualitySignals &,
+ const SymbolRelevanceSignals &, float Base) {
+DecisionForestScores Scores;
+Scores.Total = MagicNumber;
+Scores.ExcludingName = MagicNumber;
+return Scores;
+  };
+  llvm::StringRef Code = "int func() { int xyz; xy^ }";
+  auto Results = completions(Code,
+ /*IndexSymbols=*/{}, Opts);
+  ASSERT_EQ(Results.Completions.size(), 1u);
+  EXPECT_EQ(Results.Completions[0].Score.Total, MagicNumber);
+  EXPECT_EQ(Results.Completions[0].Score.ExcludingName, MagicNumber);
+
+  // Do not use DecisionForestScorer for heuristics model.
+  Opts.RankingModel = CodeCompleteOptions::Heuristics;
+  Results = completions(Code,
+/*IndexSymbols=*/{}, Opts);
+  ASSERT_EQ(Results.Completions.size(), 1u);
+  EXPECT_NE(Results.Completions[0].Score.Total, MagicNumber);
+  EXPECT_NE(Results.Completions[0].Score.ExcludingName, MagicNumber);
+}
+
 TEST(CompletionTest, Limit) {
   clangd::CodeCompleteOptions Opts;
   Opts.Limit = 2;
Index: clang-tools-extra/clangd/Quality.h
===
--- clang-tools-extra/clangd/Quality.h
+++ clang-tools-extra/clangd/Quality.h
@@ -165,8 +165,18 @@
 /// Combine symbol quality and relevance into a single score.
 float evaluateSymbolAndRelevance(float SymbolQuality, float SymbolRelevance);
 
-float evaluateDecisionForest(const SymbolQualitySignals ,
- const SymbolRelevanceSignals );
+/// Same semantics as CodeComplete::Score. Quality score and Relevance score
+/// have been removed since DecisionForest cannot assign individual scores to
+/// Quality and Relevance signals.
+struct DecisionForestScores {
+  float Total = 0.f;
+  float ExcludingName = 0.f;
+};
+
+DecisionForestScores
+evaluateDecisionForest(const SymbolQualitySignals ,
+   const SymbolRelevanceSignals , float Base);
+
 /// TopN is a lossy container that preserves only the "best" N elements.
 template > class TopN {
 public:
Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -487,8 +487,9 @@
   return SymbolQuality * SymbolRelevance;
 }
 
-float evaluateDecisionForest(const SymbolQualitySignals ,
- const SymbolRelevanceSignals ) {
+DecisionForestScores
+evaluateDecisionForest(const SymbolQualitySignals ,
+   const SymbolRelevanceSignals , float Base) {
   Example E;
   E.setIsDeprecated(Quality.Deprecated);
   E.setIsReservedName(Quality.ReservedName);
@@ -512,7 +513,19 @@
   E.setHadSymbolType(Relevance.HadSymbolType);
   E.setTypeMatchesPreferred(Relevance.TypeMatchesPreferred);
   E.setFilterLength(Relevance.FilterLength);
-  return Evaluate(E);
+
+  DecisionForestScores Scores;
+  // Exponentiating DecisionForest prediction makes the score of each tree a
+  // multiplciative boost (like NameMatch). This allows us to weigh the
+  // prediciton score and NameMatch appropriately.
+  Scores.ExcludingName = pow(Base, Evaluate(E));
+  // NeedsFixIts is not part of the DecisionForest as generating training
+  // data that needs fixits is not-feasible.
+  if (Relevance.NeedsFixIts)
+Scores.ExcludingName *= 0.5;
+  // NameMatch should be a multiplier on total score to support rescoring.
+  Scores.Total = Relevance.NameMatch * Scores.ExcludingName;
+  return Scores;
 }
 
 // Produces an integer that sorts in the same order as F.
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -154,14 

[clang] 5d1eae7 - Add support of the next Ubuntu (Ubuntu 21.04 - Hirsute Hippo)

2020-10-29 Thread Sylvestre Ledru via cfe-commits

Author: Sylvestre Ledru
Date: 2020-10-29T19:11:32+01:00
New Revision: 5d1eae7d23e3477d6044cf9d60a90ce9719f17e6

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

LOG: Add support of the next Ubuntu (Ubuntu 21.04 - Hirsute Hippo)

Added: 


Modified: 
clang/include/clang/Driver/Distro.h
clang/lib/Driver/Distro.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Distro.h 
b/clang/include/clang/Driver/Distro.h
index 2b5ec9ab8eea..0e98d00764c1 100644
--- a/clang/include/clang/Driver/Distro.h
+++ b/clang/include/clang/Driver/Distro.h
@@ -70,6 +70,7 @@ class Distro {
 UbuntuEoan,
 UbuntuFocal,
 UbuntuGroovy,
+UbuntuHirsute,
 UnknownDistro
   };
 
@@ -121,7 +122,7 @@ class Distro {
   }
 
   bool IsUbuntu() const {
-return DistroVal >= UbuntuHardy && DistroVal <= UbuntuGroovy;
+return DistroVal >= UbuntuHardy && DistroVal <= UbuntuHirsute;
   }
 
   bool IsAlpineLinux() const { return DistroVal == AlpineLinux; }

diff  --git a/clang/lib/Driver/Distro.cpp b/clang/lib/Driver/Distro.cpp
index 02a71cbd5a9c..ee4fe841e7ee 100644
--- a/clang/lib/Driver/Distro.cpp
+++ b/clang/lib/Driver/Distro.cpp
@@ -87,6 +87,7 @@ static Distro::DistroType 
DetectLsbRelease(llvm::vfs::FileSystem ) {
 .Case("eoan", Distro::UbuntuEoan)
 .Case("focal", Distro::UbuntuFocal)
 .Case("groovy", Distro::UbuntuGroovy)
+.Case("hirsute", Distro::UbuntuHirsute)
 .Default(Distro::UnknownDistro);
   return Version;
 }



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


[PATCH] D90357: [WebAssembly] Implement SIMD signselect instructions

2020-10-29 Thread Thomas Lively 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 rGbe6f50798e79: [WebAssembly] Implement SIMD signselect 
instructions (authored by tlively).
Herald added a subscriber: wingo.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90357

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
  llvm/test/MC/WebAssembly/simd-encodings.s

Index: llvm/test/MC/WebAssembly/simd-encodings.s
===
--- llvm/test/MC/WebAssembly/simd-encodings.s
+++ llvm/test/MC/WebAssembly/simd-encodings.s
@@ -694,4 +694,16 @@
 # CHECK: i64x2.extmul_high_i32x4_u # encoding: [0xfd,0xd7,0x01]
 i64x2.extmul_high_i32x4_u
 
+# CHECK: i8x16.signselect # encoding: [0xfd,0x7d]
+i8x16.signselect
+
+# CHECK: i16x8.signselect # encoding: [0xfd,0x7e]
+i16x8.signselect
+
+# CHECK: i32x4.signselect # encoding: [0xfd,0x7f]
+i32x4.signselect
+
+# CHECK: i64x2.signselect # encoding: [0xfd,0x94,0x01]
+i64x2.signselect
+
 end_function
Index: llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
+++ llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
@@ -127,6 +127,18 @@
   ret <16 x i8> %a
 }
 
+; CHECK-LABEL: signselect_v16i8:
+; SIMD128-NEXT: .functype signselect_v16i8 (v128, v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: i8x16.signselect $push[[R:[0-9]+]]=, $0, $1, $2{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <16 x i8> @llvm.wasm.signselect.v16i8(<16 x i8>, <16 x i8>, <16 x i8>)
+define <16 x i8> @signselect_v16i8(<16 x i8> %v1, <16 x i8> %v2, <16 x i8> %c) {
+  %a = call <16 x i8> @llvm.wasm.signselect.v16i8(
+ <16 x i8> %v1, <16 x i8> %v2, <16 x i8> %c
+  )
+  ret <16 x i8> %a
+}
+
 ; CHECK-LABEL: narrow_signed_v16i8:
 ; SIMD128-NEXT: .functype narrow_signed_v16i8 (v128, v128) -> (v128){{$}}
 ; SIMD128-NEXT: i8x16.narrow_i16x8_s $push[[R:[0-9]+]]=, $0, $1{{$}}
@@ -339,6 +351,18 @@
   ret <8 x i16> %a
 }
 
+; CHECK-LABEL: signselect_v8i16:
+; SIMD128-NEXT: .functype signselect_v8i16 (v128, v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: i16x8.signselect $push[[R:[0-9]+]]=, $0, $1, $2{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <8 x i16> @llvm.wasm.signselect.v8i16(<8 x i16>, <8 x i16>, <8 x i16>)
+define <8 x i16> @signselect_v8i16(<8 x i16> %v1, <8 x i16> %v2, <8 x i16> %c) {
+  %a = call <8 x i16> @llvm.wasm.signselect.v8i16(
+<8 x i16> %v1, <8 x i16> %v2, <8 x i16> %c
+  )
+  ret <8 x i16> %a
+}
+
 ; CHECK-LABEL: narrow_signed_v8i16:
 ; SIMD128-NEXT: .functype narrow_signed_v8i16 (v128, v128) -> (v128){{$}}
 ; SIMD128-NEXT: i16x8.narrow_i32x4_s $push[[R:[0-9]+]]=, $0, $1{{$}}
@@ -467,6 +491,18 @@
   ret <4 x i32> %a
 }
 
+; CHECK-LABEL: signselect_v4i32:
+; SIMD128-NEXT: .functype signselect_v4i32 (v128, v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: i32x4.signselect $push[[R:[0-9]+]]=, $0, $1, $2{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <4 x i32> @llvm.wasm.signselect.v4i32(<4 x i32>, <4 x i32>, <4 x i32>)
+define <4 x i32> @signselect_v4i32(<4 x i32> %v1, <4 x i32> %v2, <4 x i32> %c) {
+  %a = call <4 x i32> @llvm.wasm.signselect.v4i32(
+<4 x i32> %v1, <4 x i32> %v2, <4 x i32> %c
+  )
+  ret <4 x i32> %a
+}
+
 ; CHECK-LABEL: trunc_sat_s_v4i32:
 ; NO-SIMD128-NOT: f32x4
 ; SIMD128-NEXT: .functype trunc_sat_s_v4i32 (v128) -> (v128){{$}}
@@ -572,6 +608,18 @@
   ret <2 x i64> %a
 }
 
+; CHECK-LABEL: signselect_v2i64:
+; SIMD128-NEXT: .functype signselect_v2i64 (v128, v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: i64x2.signselect $push[[R:[0-9]+]]=, $0, $1, $2{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <2 x i64> @llvm.wasm.signselect.v2i64(<2 x i64>, <2 x i64>, <2 x i64>)
+define <2 x i64> @signselect_v2i64(<2 x i64> %v1, <2 x i64> %v2, <2 x i64> %c) {
+  %a = call <2 x i64> @llvm.wasm.signselect.v2i64(
+<2 x i64> %v1, <2 x i64> %v2, <2 x i64> %c
+  )
+  ret <2 x i64> %a
+}
+
 ; ==
 ; 4 x f32
 ; ==
Index: llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
===
--- llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
+++ llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
@@ -747,6 +747,23 @@
   )>;
 } // foreach vec_t
 
+// Sign select
+multiclass SIMDSignSelect simdop> {
+  defm SIGNSELECT_#vec_t :
+SIMD_I<(outs V128:$dst), (ins V128:$v1, V128:$v2, V128:$c), (outs), 

[clang] be6f507 - [WebAssembly] Implement SIMD signselect instructions

2020-10-29 Thread Thomas Lively via cfe-commits

Author: Thomas Lively
Date: 2020-10-29T11:06:20-07:00
New Revision: be6f50798e79336cdfd8fe464f37d41ac135640d

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

LOG: [WebAssembly] Implement SIMD signselect instructions

As proposed in https://github.com/WebAssembly/simd/pull/124, using the opcodes
adopted by V8 in
https://chromium-review.googlesource.com/c/v8/v8/+/2486235/2/src/wasm/wasm-opcodes.h.
Uses new builtin functions and a new target intrinsic exclusively to ensure that
the new instructions are only emitted when a user explicitly opts in to using
them since they are still in the prototyping and evaluation phase.

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsWebAssembly.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/builtins-wasm.c
llvm/include/llvm/IR/IntrinsicsWebAssembly.td
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
llvm/test/MC/WebAssembly/simd-encodings.s

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsWebAssembly.def 
b/clang/include/clang/Basic/BuiltinsWebAssembly.def
index e86346d71c59..c1e594e147b3 100644
--- a/clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ b/clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -134,6 +134,12 @@ TARGET_BUILTIN(__builtin_wasm_extmul_low_i32x4_u_i64x2, 
"V2ULLiV4UiV4Ui", "nc",
 TARGET_BUILTIN(__builtin_wasm_extmul_high_i32x4_u_i64x2, "V2ULLiV4UiV4Ui", 
"nc", "simd128")
 
 TARGET_BUILTIN(__builtin_wasm_bitselect, "V4iV4iV4iV4i", "nc", "simd128")
+
+TARGET_BUILTIN(__builtin_wasm_signselect_i8x16, "V16ScV16ScV16ScV16Sc", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_signselect_i16x8, "V8sV8sV8sV8s", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_signselect_i32x4, "V4iV4iV4iV4i", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_signselect_i64x2, "V2LLiV2LLiV2LLiV2LLi", "nc", 
"simd128")
+
 TARGET_BUILTIN(__builtin_wasm_shuffle_v8x16, 
"V16ScV16ScV16ScIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi", "nc", "simd128")
 
 TARGET_BUILTIN(__builtin_wasm_any_true_i8x16, "iV16Sc", "nc", "simd128")

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index f933113fa883..7341a440b873 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -16675,6 +16675,17 @@ Value 
*CodeGenFunction::EmitWebAssemblyBuiltinExpr(unsigned BuiltinID,
 CGM.getIntrinsic(Intrinsic::wasm_bitselect, ConvertType(E->getType()));
 return Builder.CreateCall(Callee, {V1, V2, C});
   }
+  case WebAssembly::BI__builtin_wasm_signselect_i8x16:
+  case WebAssembly::BI__builtin_wasm_signselect_i16x8:
+  case WebAssembly::BI__builtin_wasm_signselect_i32x4:
+  case WebAssembly::BI__builtin_wasm_signselect_i64x2: {
+Value *V1 = EmitScalarExpr(E->getArg(0));
+Value *V2 = EmitScalarExpr(E->getArg(1));
+Value *C = EmitScalarExpr(E->getArg(2));
+Function *Callee =
+CGM.getIntrinsic(Intrinsic::wasm_signselect, 
ConvertType(E->getType()));
+return Builder.CreateCall(Callee, {V1, V2, C});
+  }
   case WebAssembly::BI__builtin_wasm_dot_s_i32x4_i16x8: {
 Value *LHS = EmitScalarExpr(E->getArg(0));
 Value *RHS = EmitScalarExpr(E->getArg(1));

diff  --git a/clang/test/CodeGen/builtins-wasm.c 
b/clang/test/CodeGen/builtins-wasm.c
index ee635317ff7a..e5c7211ad5be 100644
--- a/clang/test/CodeGen/builtins-wasm.c
+++ b/clang/test/CodeGen/builtins-wasm.c
@@ -622,6 +622,34 @@ i32x4 bitselect(i32x4 x, i32x4 y, i32x4 c) {
   // WEBASSEMBLY-NEXT: ret
 }
 
+i8x16 signselect_i8x16(i8x16 x, i8x16 y, i8x16 c) {
+  return __builtin_wasm_signselect_i8x16(x, y, c);
+  // WEBASSEMBLY: call <16 x i8> @llvm.wasm.signselect.v16i8(
+  // WEBASSEMBLY-SAME: <16 x i8> %x, <16 x i8> %y, <16 x i8> %c)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+i16x8 signselect_i16x8(i16x8 x, i16x8 y, i16x8 c) {
+  return __builtin_wasm_signselect_i16x8(x, y, c);
+  // WEBASSEMBLY: call <8 x i16> @llvm.wasm.signselect.v8i16(
+  // WEBASSEMBLY-SAME: <8 x i16> %x, <8 x i16> %y, <8 x i16> %c)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+i32x4 signselect_i32x4(i32x4 x, i32x4 y, i32x4 c) {
+  return __builtin_wasm_signselect_i32x4(x, y, c);
+  // WEBASSEMBLY: call <4 x i32> @llvm.wasm.signselect.v4i32(
+  // WEBASSEMBLY-SAME: <4 x i32> %x, <4 x i32> %y, <4 x i32> %c)
+  // WEBASSEMBLY-NEXT: ret
+}
+
+i64x2 signselect_i64x2(i64x2 x, i64x2 y, i64x2 c) {
+  return __builtin_wasm_signselect_i64x2(x, y, c);
+  // WEBASSEMBLY: call <2 x i64> @llvm.wasm.signselect.v2i64(
+  // WEBASSEMBLY-SAME: <2 x i64> %x, <2 x i64> %y, <2 x i64> %c)
+  // WEBASSEMBLY-NEXT: ret
+}
+
 i8x16 popcnt(i8x16 x) {
   return __builtin_wasm_popcnt_i8x16(x);
   // WEBASSEMBLY: call <16 x i8> @llvm.wasm.popcnt(<16 x i8> %x)


[PATCH] D89670: [clangd] Store the containing symbol for refs

2020-10-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/index/Ref.h:91
   RefKind Kind = RefKind::Unknown;
+  SymbolID Container;
 };

i am afraid we are going to have an indeterminate value here if for whatever 
reason `Container` detection fails. (e.g. for macros, or if ASTNode.Parent set 
to nullptr by libindex).

Sent out https://reviews.llvm.org/D90397 to address the issue.



Comment at: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp:779
+  AssertContainer("ref7b", "f5");// parameter type of function
+}
+

can we also have an assertion checking containers for top level symbols are the 
same ?

and extend the test to have multiple declarations inside:
- a namespace
- inside a record (like S1)
and ensure the container is same for those (and different than top-level 
symbols themselves). It is okay for those symbols.

Note that it is OK for namespaces to be not in the index, i just want to make 
sure the containers for the top-level symbols inside a namespace are the same.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89670

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


[PATCH] D90397: [clangd] Value initialize SymbolIDs

2020-10-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 301678.
kadircet marked an inline comment as done.
kadircet added a comment.

- change invalid -> null.
- add an implicit bool conversion operator.
- update apis returning optionals.

Note that all the functional changes are in SymbolID.h, rest is api updates.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90397

Files:
  clang-tools-extra/clangd/AST.cpp
  clang-tools-extra/clangd/AST.h
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CollectMacros.cpp
  clang-tools-extra/clangd/HeaderSourceSwitch.cpp
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/IncludeFixer.cpp
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/index/SymbolID.h
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -2077,7 +2077,7 @@
   TestTU TU = TestTU::withCode(T.code());
   auto AST = TU.build();
   Symbol IndexSym;
-  IndexSym.ID = *getSymbolID((AST, "X"));
+  IndexSym.ID = getSymbolID((AST, "X"));
   IndexSym.Documentation = "comment from index";
   SymbolSlab::Builder Symbols;
   Symbols.insert(IndexSym);
Index: clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
===
--- clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
+++ clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
@@ -96,7 +96,7 @@
   auto SID = getSymbolID(Macro->Name, Macro->Info, SM);
 
   EXPECT_THAT(ExpectedRefs,
-  UnorderedElementsAreArray(ActualMacroRefs.MacroRefs[*SID]))
+  UnorderedElementsAreArray(ActualMacroRefs.MacroRefs[SID]))
   << "Annotation=" << I << ", MacroName=" << Macro->Name
   << ", Test = " << Test;
 }
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -63,7 +63,7 @@
   // tradeoff. We expect the number of symbol references in the current file
   // is smaller than the limit.
   Req.Limit = 100;
-  Req.IDs.insert(*getSymbolID());
+  Req.IDs.insert(getSymbolID());
   llvm::Optional OtherFile;
   Index.refs(Req, [&](const Ref ) {
 if (OtherFile)
@@ -244,7 +244,7 @@
 return;
   for (const auto *Target : Ref.Targets) {
 auto ID = getSymbolID(Target);
-if (!ID || TargetIDs.find(*ID) == TargetIDs.end())
+if (!ID || TargetIDs.find(ID) == TargetIDs.end())
   return;
   }
   Results.push_back(Ref.NameLoc);
@@ -304,7 +304,7 @@
size_t MaxLimitFiles) {
   trace::Span Tracer("FindOccurrencesOutsideFile");
   RefsRequest RQuest;
-  RQuest.IDs.insert(*getSymbolID());
+  RQuest.IDs.insert(getSymbolID());
 
   // Absolute file path => rename occurrences in that file.
   llvm::StringMap> AffectedFiles;
Index: clang-tools-extra/clangd/index/SymbolID.h
===
--- clang-tools-extra/clangd/index/SymbolID.h
+++ clang-tools-extra/clangd/index/SymbolID.h
@@ -15,6 +15,7 @@
 #include "llvm/Support/Error.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
+#include 
 #include 
 
 namespace clang {
@@ -53,8 +54,11 @@
   std::string str() const;
   static llvm::Expected fromStr(llvm::StringRef);
 
+  bool isNull() const { return HashValue != std::array{}; }
+  operator bool() const { return isNull(); }
+
 private:
-  std::array HashValue;
+  std::array HashValue{};
 };
 
 llvm::hash_code hash_value(const SymbolID );
Index: clang-tools-extra/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -324,7 +324,7 @@
   // refs, because the indexing code only populates relations for specific
   // occurrences. For example, RelationBaseOf is only populated for the
   // occurrence inside the base-specifier.
-  processRelations(*ND, *ID, Relations);
+  processRelations(*ND, ID, Relations);
 
   bool CollectRef = static_cast(Opts.RefFilter & toRefKind(Roles));
   bool IsOnlyRef =
@@ -356,15 +356,15 @@
   if (!OriginalDecl)
 return true;
 
-  const Symbol *BasicSymbol = Symbols.find(*ID);
+  const Symbol *BasicSymbol = Symbols.find(ID);
   if (isPreferredDeclaration(*OriginalDecl, Roles))
 // If OriginalDecl is preferred, 

[PATCH] D90367: [darwin] add support for __isPlatformVersionAtLeast check for if (@available)

2020-10-29 Thread Nico Weber via Phabricator via cfe-commits
thakis accepted this revision.
thakis added a comment.
This revision is now accepted and ready to land.

Thanks!




Comment at: clang/lib/CodeGen/CGObjC.cpp:3874
 
   if (!CGM.IsOSVersionAtLeastFn) {
 llvm::FunctionType *FTy =

Isn't the rest of the function basically dead code? Do non-darwin targets 
support this feature? As far as I can tell, they don't?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90367

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


[PATCH] D88233: [clang][aarch64] Address various fixed-length SVE vector operations

2020-10-29 Thread Francesco Petrogalli via Phabricator via cfe-commits
fpetrogalli accepted this revision.
fpetrogalli added a comment.
This revision is now accepted and ready to land.

LGTM, thank you!


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

https://reviews.llvm.org/D88233

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


[PATCH] D90121: clang-format: Add a consumer to diagnostics engine

2020-10-29 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Is it possible to add an automated test for this in clang/test/Format/... using 
chmod -w in a RUN line?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90121

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


[PATCH] D90316: [FPEnv] Diagnose pragmas FENV_ROUND,_ACCESS and float_control if target does not support StrictFP

2020-10-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParsePragma.cpp:107
+if (!PP.getTargetInfo().hasStrictFP() && !PP.getLangOpts().ExpStrictFP) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_fp_ignored)
+  << "FENV_ACCESS";

Can you fix the lint issues (run the patch through clang-format)? Same for 
below.



Comment at: clang/lib/Parse/ParsePragma.cpp:2967
+PP.Diag(Tok.getLocation(), diag::warn_pragma_fp_ignored)
+<< PragmaName.getIdentifierInfo()->getName();
+return;

Can you pass in `PragmaName` directly, or does that do unfortunate things with 
single quotes?



Comment at: clang/test/Parser/pragma-fp-warn.c:11-13
+// expected-warning@+8 {{'#pragma FENV_ROUND' is not supported on this target 
- ignored}}
+// expected-warning@+5 {{'#pragma FENV_ACCESS' is not supported on this target 
- ignored}}
+// expected-warning@+2 {{'#pragma float_control' is not supported on this 
target - ignored}}

I'd appreciate reversing the order of the comments so that they're in the same 
order as the pragmas below.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90316

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


[PATCH] D90362: scan-build supprot relative 'file' in cdb.

2020-10-29 Thread Yu Shan via Phabricator via cfe-commits
aabbaabb added a comment.

Gabor or Petr, 
Can any one of you help me commit this change? Not sure if I could commit 
myself.

In D90362#2361400 , @xazax.hun wrote:

> I know that the current situation is a mess, but there is an alternative 
> version of scan-build-py on Github, which is also distributed on pypi. Could 
> you check if that version is also susceptible to this problem and open a pull 
> request for the author in case it is?
>
> The repository is here: https://github.com/rizsotto/scan-build
>
> This would be the best way to ensure the bug is fixed for all the users.

Do you mean pull this change into that repo after this got submitted in trunk? 
Will do!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90362

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


[PATCH] D80623: WIP: Add an API to simplify setting TraversalKind in clang-tidy matchers

2020-10-29 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added a comment.

Reviving this so it can be used to port `clang-tidy` checks to 
`IgnoreUnlessSpelledInSource`.




Comment at: clang/include/clang/ASTMatchers/ASTMatchFinder.h:118
+/// behavior of clang-tidy.
+virtual llvm::Optional
+getCheckTraversalKind() const;

sammccall wrote:
> I don't really get why this would be optional.
> A check's implementation isn't really going to be robust to "whatever the 
> default is", it's going to be tested against one or the other.
> So None isn't really a sensible return value - can't the base class simply 
> return the actual default?
ASTMatchFinder doesn't know the ASTContext, so it can't access the default. 
That's why I made it an optional.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80623

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


[PATCH] D89799: [clang][driver] Rename DriverOption as NoXarchOption (NFC)

2020-10-29 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Driver/ToolChain.cpp:1203
+unsigned DiagID =
+Diags.getCustomDiagID(DiagnosticsEngine::Error,
+  "invalid Xarch argument: '%0', not all driver "

If this is not of much uses, hope we can remove it in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89799

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


[PATCH] D80623: WIP: Add an API to simplify setting TraversalKind in clang-tidy matchers

2020-10-29 Thread Stephen Kelly via Phabricator via cfe-commits
steveire updated this revision to Diff 301667.
steveire added a comment.

Update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80623

Files:
  clang/include/clang/ASTMatchers/ASTMatchFinder.h
  clang/lib/ASTMatchers/ASTMatchFinder.cpp


Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -877,6 +877,7 @@
 Callback(Callback) {}
 
 void visitMatch(const BoundNodes& BoundNodesView) override {
+  TraversalKindScope RAII(*Context, Callback->getCheckTraversalKind());
   Callback->run(MatchFinder::MatchResult(BoundNodesView, Context));
 }
 
@@ -1142,7 +1143,11 @@
 
 void MatchFinder::addMatcher(const DeclarationMatcher ,
  MatchCallback *Action) {
-  Matchers.DeclOrStmt.emplace_back(NodeMatch, Action);
+  if (auto TK = Action->getCheckTraversalKind()) {
+Matchers.DeclOrStmt.emplace_back(traverse(*TK, NodeMatch), Action);
+  } else {
+Matchers.DeclOrStmt.emplace_back(NodeMatch, Action);
+  }
   Matchers.AllCallbacks.insert(Action);
 }
 
@@ -1154,7 +1159,11 @@
 
 void MatchFinder::addMatcher(const StatementMatcher ,
  MatchCallback *Action) {
-  Matchers.DeclOrStmt.emplace_back(NodeMatch, Action);
+  if (auto TK = Action->getCheckTraversalKind()) {
+Matchers.DeclOrStmt.emplace_back(traverse(*TK, NodeMatch), Action);
+  } else {
+Matchers.DeclOrStmt.emplace_back(NodeMatch, Action);
+  }
   Matchers.AllCallbacks.insert(Action);
 }
 
@@ -1243,5 +1252,10 @@
 
 StringRef MatchFinder::MatchCallback::getID() const { return ""; }
 
+llvm::Optional
+MatchFinder::MatchCallback::getCheckTraversalKind() const {
+  return llvm::None;
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: clang/include/clang/ASTMatchers/ASTMatchFinder.h
===
--- clang/include/clang/ASTMatchers/ASTMatchFinder.h
+++ clang/include/clang/ASTMatchers/ASTMatchFinder.h
@@ -110,6 +110,13 @@
 /// This id is used, for example, for the profiling output.
 /// It defaults to "".
 virtual StringRef getID() const;
+
+/// TraversalKind to use while matching and processing
+/// the result nodes. This API is temporary to facilitate
+/// third parties porting existing code to the default
+/// behavior of clang-tidy.
+virtual llvm::Optional
+getCheckTraversalKind() const;
   };
 
   /// Called when parsing is finished. Intended for testing only.


Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -877,6 +877,7 @@
 Callback(Callback) {}
 
 void visitMatch(const BoundNodes& BoundNodesView) override {
+  TraversalKindScope RAII(*Context, Callback->getCheckTraversalKind());
   Callback->run(MatchFinder::MatchResult(BoundNodesView, Context));
 }
 
@@ -1142,7 +1143,11 @@
 
 void MatchFinder::addMatcher(const DeclarationMatcher ,
  MatchCallback *Action) {
-  Matchers.DeclOrStmt.emplace_back(NodeMatch, Action);
+  if (auto TK = Action->getCheckTraversalKind()) {
+Matchers.DeclOrStmt.emplace_back(traverse(*TK, NodeMatch), Action);
+  } else {
+Matchers.DeclOrStmt.emplace_back(NodeMatch, Action);
+  }
   Matchers.AllCallbacks.insert(Action);
 }
 
@@ -1154,7 +1159,11 @@
 
 void MatchFinder::addMatcher(const StatementMatcher ,
  MatchCallback *Action) {
-  Matchers.DeclOrStmt.emplace_back(NodeMatch, Action);
+  if (auto TK = Action->getCheckTraversalKind()) {
+Matchers.DeclOrStmt.emplace_back(traverse(*TK, NodeMatch), Action);
+  } else {
+Matchers.DeclOrStmt.emplace_back(NodeMatch, Action);
+  }
   Matchers.AllCallbacks.insert(Action);
 }
 
@@ -1243,5 +1252,10 @@
 
 StringRef MatchFinder::MatchCallback::getID() const { return ""; }
 
+llvm::Optional
+MatchFinder::MatchCallback::getCheckTraversalKind() const {
+  return llvm::None;
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: clang/include/clang/ASTMatchers/ASTMatchFinder.h
===
--- clang/include/clang/ASTMatchers/ASTMatchFinder.h
+++ clang/include/clang/ASTMatchers/ASTMatchFinder.h
@@ -110,6 +110,13 @@
 /// This id is used, for example, for the profiling output.
 /// It defaults to "".
 virtual StringRef getID() const;
+
+/// TraversalKind to use while matching and processing
+/// the result nodes. This API is temporary to facilitate
+/// third parties porting existing code to the default
+/// behavior of clang-tidy.
+virtual llvm::Optional
+getCheckTraversalKind() const;
   };
 
   /// Called when 

[PATCH] D90366: [ThinLTO] Fix empty .llvmcmd sections

2020-10-29 Thread Mircea Trofin 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 rG13aee94bc710: [ThinLTO] Fix empty .llvmcmd sections 
(authored by mtrofin).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90366

Files:
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/thinlto_embed_bitcode.ll


Index: clang/test/CodeGen/thinlto_embed_bitcode.ll
===
--- clang/test/CodeGen/thinlto_embed_bitcode.ll
+++ clang/test/CodeGen/thinlto_embed_bitcode.ll
@@ -17,12 +17,20 @@
 ; round-trip through compilation and ensure the objects are the same.
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t.o -x ir %t1.bc -c 
-fthinlto-index=%t.o.thinlto.bc -mllvm -lto-embed-bitcode=post-merge-pre-opt
 ; RUN: llvm-readelf -S %t.o | FileCheck %s 
--check-prefixes=CHECK-ELF,CHECK-ELF-CMD
+; RUN: llvm-objcopy --dump-section=.llvmcmd=%t-embedded.cmd %t.o /dev/null
+; RUN: grep x86_64-unknown-linux-gnu %t-embedded.cmd | count 1
 ; RUN: llvm-objcopy --dump-section=.llvmbc=%t-embedded.bc %t.o /dev/null
 ; RUN: llvm-dis %t-embedded.bc -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-NOOPT
 ; We should only need the index and the post-thinlto merged module to generate 
 ; the exact same .o as we originally did.
 ; RUN: rm %t1.bc %t2.bc
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t-redo.o -x ir 
%t-embedded.bc -c -fthinlto-index=%t.o.thinlto.bc -mllvm 
-lto-embed-bitcode=post-merge-pre-opt -mllvm -thinlto-assume-merged
+;
+; The resulting .o is almost the same, but the .llvmcmd section would be
+; different because of the extra -thinlto-assume-merged.
+; A simple, meaningful comparison is to just compare the stripped objects.
+; RUN: llvm-strip --strip-all %t-redo.o 
+; RUN: llvm-strip --strip-all %t.o 
 ; RUN: diff %t-redo.o %t.o
 
 ; CHECK-ELF:  .text   PROGBITS  [[#%x,OFF:]] [[#%x,SIZE:]] 
00 AX 0
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1095,23 +1095,21 @@
   // FIXME: For backend options that are not yet recorded as function
   // attributes in the IR, keep track of them so we can embed them in a
   // separate data section and use them when building the bitcode.
-  if (Opts.getEmbedBitcode() == CodeGenOptions::Embed_All) {
-for (const auto  : Args) {
-  // Do not encode output and input.
-  if (A->getOption().getID() == options::OPT_o ||
-  A->getOption().getID() == options::OPT_INPUT ||
-  A->getOption().getID() == options::OPT_x ||
-  A->getOption().getID() == options::OPT_fembed_bitcode ||
-  A->getOption().matches(options::OPT_W_Group))
-continue;
-  ArgStringList ASL;
-  A->render(Args, ASL);
-  for (const auto  : ASL) {
-StringRef ArgStr(arg);
-Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
-// using \00 to separate each commandline options.
-Opts.CmdArgs.push_back('\0');
-  }
+  for (const auto  : Args) {
+// Do not encode output and input.
+if (A->getOption().getID() == options::OPT_o ||
+A->getOption().getID() == options::OPT_INPUT ||
+A->getOption().getID() == options::OPT_x ||
+A->getOption().getID() == options::OPT_fembed_bitcode ||
+A->getOption().matches(options::OPT_W_Group))
+  continue;
+ArgStringList ASL;
+A->render(Args, ASL);
+for (const auto  : ASL) {
+  StringRef ArgStr(arg);
+  Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
+  // using \00 to separate each commandline options.
+  Opts.CmdArgs.push_back('\0');
 }
   }
 


Index: clang/test/CodeGen/thinlto_embed_bitcode.ll
===
--- clang/test/CodeGen/thinlto_embed_bitcode.ll
+++ clang/test/CodeGen/thinlto_embed_bitcode.ll
@@ -17,12 +17,20 @@
 ; round-trip through compilation and ensure the objects are the same.
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t.o -x ir %t1.bc -c -fthinlto-index=%t.o.thinlto.bc -mllvm -lto-embed-bitcode=post-merge-pre-opt
 ; RUN: llvm-readelf -S %t.o | FileCheck %s --check-prefixes=CHECK-ELF,CHECK-ELF-CMD
+; RUN: llvm-objcopy --dump-section=.llvmcmd=%t-embedded.cmd %t.o /dev/null
+; RUN: grep x86_64-unknown-linux-gnu %t-embedded.cmd | count 1
 ; RUN: llvm-objcopy --dump-section=.llvmbc=%t-embedded.bc %t.o /dev/null
 ; RUN: llvm-dis %t-embedded.bc -o - | FileCheck %s --check-prefixes=CHECK,CHECK-NOOPT
 ; We should only need the index and the post-thinlto merged module to generate 
 ; the exact same .o as we originally did.
 ; RUN: rm %t1.bc %t2.bc
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o 

[clang] 13aee94 - [ThinLTO] Fix empty .llvmcmd sections

2020-10-29 Thread Mircea Trofin via cfe-commits

Author: Mircea Trofin
Date: 2020-10-29T09:57:42-07:00
New Revision: 13aee94bc710bfa6277c1f07146c714ee65bf2de

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

LOG: [ThinLTO] Fix empty .llvmcmd sections

When passing -lto-embed-bitcode=post-merge-pre-opt, we were getting
empty .llvmcmd sections. It turns out that is because the
CodeGenOptions::CmdArgs field was only populated when clang saw
-fembed-bitcode={all|marker}.

This patch always populates the CodeGenOptions::CmdArgs. The overhead
of carrying through in memory in all cases is likely negligible in
the grand schema of things, and it keeps the using code simple.

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

Added: 


Modified: 
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/CodeGen/thinlto_embed_bitcode.ll

Removed: 




diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 5175063adb02..22579161b345 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -1095,23 +1095,21 @@ static bool ParseCodeGenArgs(CodeGenOptions , 
ArgList , InputKind IK,
   // FIXME: For backend options that are not yet recorded as function
   // attributes in the IR, keep track of them so we can embed them in a
   // separate data section and use them when building the bitcode.
-  if (Opts.getEmbedBitcode() == CodeGenOptions::Embed_All) {
-for (const auto  : Args) {
-  // Do not encode output and input.
-  if (A->getOption().getID() == options::OPT_o ||
-  A->getOption().getID() == options::OPT_INPUT ||
-  A->getOption().getID() == options::OPT_x ||
-  A->getOption().getID() == options::OPT_fembed_bitcode ||
-  A->getOption().matches(options::OPT_W_Group))
-continue;
-  ArgStringList ASL;
-  A->render(Args, ASL);
-  for (const auto  : ASL) {
-StringRef ArgStr(arg);
-Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
-// using \00 to separate each commandline options.
-Opts.CmdArgs.push_back('\0');
-  }
+  for (const auto  : Args) {
+// Do not encode output and input.
+if (A->getOption().getID() == options::OPT_o ||
+A->getOption().getID() == options::OPT_INPUT ||
+A->getOption().getID() == options::OPT_x ||
+A->getOption().getID() == options::OPT_fembed_bitcode ||
+A->getOption().matches(options::OPT_W_Group))
+  continue;
+ArgStringList ASL;
+A->render(Args, ASL);
+for (const auto  : ASL) {
+  StringRef ArgStr(arg);
+  Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
+  // using \00 to separate each commandline options.
+  Opts.CmdArgs.push_back('\0');
 }
   }
 

diff  --git a/clang/test/CodeGen/thinlto_embed_bitcode.ll 
b/clang/test/CodeGen/thinlto_embed_bitcode.ll
index 5f7b9f632af3..6c7e36e7226b 100644
--- a/clang/test/CodeGen/thinlto_embed_bitcode.ll
+++ b/clang/test/CodeGen/thinlto_embed_bitcode.ll
@@ -17,12 +17,20 @@
 ; round-trip through compilation and ensure the objects are the same.
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t.o -x ir %t1.bc -c 
-fthinlto-index=%t.o.thinlto.bc -mllvm -lto-embed-bitcode=post-merge-pre-opt
 ; RUN: llvm-readelf -S %t.o | FileCheck %s 
--check-prefixes=CHECK-ELF,CHECK-ELF-CMD
+; RUN: llvm-objcopy --dump-section=.llvmcmd=%t-embedded.cmd %t.o /dev/null
+; RUN: grep x86_64-unknown-linux-gnu %t-embedded.cmd | count 1
 ; RUN: llvm-objcopy --dump-section=.llvmbc=%t-embedded.bc %t.o /dev/null
 ; RUN: llvm-dis %t-embedded.bc -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-NOOPT
 ; We should only need the index and the post-thinlto merged module to generate 
 ; the exact same .o as we originally did.
 ; RUN: rm %t1.bc %t2.bc
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t-redo.o -x ir 
%t-embedded.bc -c -fthinlto-index=%t.o.thinlto.bc -mllvm 
-lto-embed-bitcode=post-merge-pre-opt -mllvm -thinlto-assume-merged
+;
+; The resulting .o is almost the same, but the .llvmcmd section would be
+; 
diff erent because of the extra -thinlto-assume-merged.
+; A simple, meaningful comparison is to just compare the stripped objects.
+; RUN: llvm-strip --strip-all %t-redo.o 
+; RUN: llvm-strip --strip-all %t.o 
 ; RUN: 
diff  %t-redo.o %t.o
 
 ; CHECK-ELF:  .text   PROGBITS  [[#%x,OFF:]] [[#%x,SIZE:]] 
00 AX 0



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


[PATCH] D90362: scan-build supprot relative 'file' in cdb.

2020-10-29 Thread Yu Shan via Phabricator via cfe-commits
aabbaabb added a comment.

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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90362

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


[PATCH] D90121: clang-format: Add a consumer to diagnostics engine

2020-10-29 Thread Kirill Dmitrenko via Phabricator via cfe-commits
dmikis added a comment.

@thakis We've stumbled upon this problem when tried to format in-place a 
read-only file. `clang-format` tries to report this problem via 
`DiagnosticEngine`, and that fails on assert 
.
 `clang-format` crashes. We use perforce and source files being read only is a 
common occurrence for us.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90121

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


[PATCH] D89959: UBSAN: emit distinctive traps in trapping mode

2020-10-29 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added inline comments.



Comment at: clang/lib/CodeGen/CGExpr.cpp:3458
+llvm::CallInst *TrapCall =
+Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::ubsantrap),
+   llvm::ConstantInt::get(CGM.Int32Ty, 
CheckHandlerID));

vsk wrote:
> This seems to apply the current DebugLoc from Builder to the shared trap call 
> when optimizing. That's potentially misleading (say you have two trapping 
> additions -- if the second one traps, the crashlog will make it look like the 
> first one trapped).
> 
> I think the fix is just: `if (optimizing) TrapCall->dropLocation();`. This 
> can be fixed before/after/in this patch, whatever you prefer.
Or better: instead of dropping the debug loc of the trap call immediately, 
apply a merged debug loc before emitting the condbr (see 
Instruction::applyMergedLocation). That way, if there aren't multiple trapping 
operations, the original debug loc is preserved.


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

https://reviews.llvm.org/D89959

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


[PATCH] D89571: [clangd] Add textDocument/ast extension method to dump the AST

2020-10-29 Thread Adam Czachorowski via Phabricator via cfe-commits
adamcz accepted this revision.
adamcz added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/ClangdServer.cpp:799
+  return CB(Offset.takeError());
+if (auto O = positionToOffset(Inputs->Inputs.Contents, R.end))
+  End = *O;

Also here please ;)



Comment at: clang-tools-extra/clangd/ClangdServer.h:323
+  /// Describe the AST subtree for a piece of code.
+  void getAST(PathRef File, Range, Callback>);
+

sammccall wrote:
> adamcz wrote:
> > Any reason not to name arguments here?
> I generally prefer not to name them in the declaration when it doesn't 
> communicate anything beyond the type.
> 
> Done here as most of the other functions name them.
> 
> (I'm curious, do you think there are useful names here, or is the 
> irregularity between named/unnamed bothersome?)
Unnamed argument makes me think that it's ignored by this function. It's 
in-line with Google style guide, maybe doesn't necessary apply here.



Comment at: clang-tools-extra/clangd/DumpAST.cpp:209
+  std::string getDetail(const Decl *D) {
+auto *ND = dyn_cast(D);
+if (!ND || llvm::isa_and_nonnull(ND->getAsFunction()) 
||

lint says this can be const



Comment at: clang-tools-extra/clangd/unittests/DumpASTTests.cpp:12
+#include "TestTU.h"
+#include "llvm/Support/ScopedPrinter.h"
+#include "gmock/gmock.h"

include order lint warning here



Comment at: clang-tools-extra/clangd/unittests/DumpASTTests.cpp:104
+  };
+  for (const auto  : Cases) {
+ParsedAST AST = TestTU::withCode(Case.first).build();

sammccall wrote:
> adamcz wrote:
> > Can you add a test case for class with overloaded operator(s)? They tend to 
> > cause issues here and there.
> Added one with use of an overloaded operator (LMK if you wanted to dump the 
> declaration instead)
Thanks, that's exactly what I wanted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89571

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


[PATCH] D89959: UBSAN: emit distinctive traps in trapping mode

2020-10-29 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added inline comments.



Comment at: clang/lib/CodeGen/CGExpr.cpp:3447
   // If we're optimizing, collapse all calls to trap down to just one per
   // function to save on code size.
+  if (TrapBBs.size() <= CheckHandlerID)

'per check, per function'?



Comment at: clang/lib/CodeGen/CGExpr.cpp:3458
+llvm::CallInst *TrapCall =
+Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::ubsantrap),
+   llvm::ConstantInt::get(CGM.Int32Ty, 
CheckHandlerID));

This seems to apply the current DebugLoc from Builder to the shared trap call 
when optimizing. That's potentially misleading (say you have two trapping 
additions -- if the second one traps, the crashlog will make it look like the 
first one trapped).

I think the fix is just: `if (optimizing) TrapCall->dropLocation();`. This can 
be fixed before/after/in this patch, whatever you prefer.



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:6702
 
+def ubsan_trap_xform : SDNodeXFormgetTargetConstant(N->getZExtValue() | ('U' << 8), SDLoc(N), 
MVT::i32);

assert(N->getZExtValue() < 256)? Or alternatively, maybe it'd be simpler to 
define `@llvm.ubsantrap(i8 immarg)`?


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

https://reviews.llvm.org/D89959

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


[clang] dee7704 - [AMDGPU] Add __builtin_amdgcn_grid_size

2020-10-29 Thread Jon Chesterfield via cfe-commits

Author: Jon Chesterfield
Date: 2020-10-29T16:25:13Z
New Revision: dee7704829bd421ad3cce4b2132d28f4459b7319

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

LOG: [AMDGPU] Add __builtin_amdgcn_grid_size

[AMDGPU] Add __builtin_amdgcn_grid_size

Similar to D76772, loads the data from the dispatch pointer. Marked invariant.

Patch also updates the openmp devicertl to use this builtin.

Reviewed By: yaxunl

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsAMDGPU.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGenOpenCL/builtins-amdgcn.cl
openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsAMDGPU.def 
b/clang/include/clang/Basic/BuiltinsAMDGPU.def
index 042a86368559..f5901e6f8f3b 100644
--- a/clang/include/clang/Basic/BuiltinsAMDGPU.def
+++ b/clang/include/clang/Basic/BuiltinsAMDGPU.def
@@ -37,6 +37,10 @@ BUILTIN(__builtin_amdgcn_workgroup_size_x, "Us", "nc")
 BUILTIN(__builtin_amdgcn_workgroup_size_y, "Us", "nc")
 BUILTIN(__builtin_amdgcn_workgroup_size_z, "Us", "nc")
 
+BUILTIN(__builtin_amdgcn_grid_size_x, "Ui", "nc")
+BUILTIN(__builtin_amdgcn_grid_size_y, "Ui", "nc")
+BUILTIN(__builtin_amdgcn_grid_size_z, "Ui", "nc")
+
 BUILTIN(__builtin_amdgcn_mbcnt_hi, "UiUiUi", "nc")
 BUILTIN(__builtin_amdgcn_mbcnt_lo, "UiUiUi", "nc")
 

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 6f7505b7b5c2..f933113fa883 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -14750,6 +14750,22 @@ Value *EmitAMDGPUWorkGroupSize(CodeGenFunction , 
unsigned Index) {
   llvm::MDNode::get(CGF.getLLVMContext(), None));
   return LD;
 }
+
+// \p Index is 0, 1, and 2 for x, y, and z dimension, respectively.
+Value *EmitAMDGPUGridSize(CodeGenFunction , unsigned Index) {
+  const unsigned XOffset = 12;
+  auto *DP = EmitAMDGPUDispatchPtr(CGF);
+  // Indexing the HSA kernel_dispatch_packet struct.
+  auto *Offset = llvm::ConstantInt::get(CGF.Int32Ty, XOffset + Index * 4);
+  auto *GEP = CGF.Builder.CreateGEP(DP, Offset);
+  auto *DstTy =
+  CGF.Int32Ty->getPointerTo(GEP->getType()->getPointerAddressSpace());
+  auto *Cast = CGF.Builder.CreateBitCast(GEP, DstTy);
+  auto *LD = CGF.Builder.CreateLoad(Address(Cast, CharUnits::fromQuantity(4)));
+  LD->setMetadata(llvm::LLVMContext::MD_invariant_load,
+  llvm::MDNode::get(CGF.getLLVMContext(), None));
+  return LD;
+}
 } // namespace
 
 // For processing memory ordering and memory scope arguments of various
@@ -15010,6 +15026,14 @@ Value *CodeGenFunction::EmitAMDGPUBuiltinExpr(unsigned 
BuiltinID,
   case AMDGPU::BI__builtin_amdgcn_workgroup_size_z:
 return EmitAMDGPUWorkGroupSize(*this, 2);
 
+  // amdgcn grid size
+  case AMDGPU::BI__builtin_amdgcn_grid_size_x:
+return EmitAMDGPUGridSize(*this, 0);
+  case AMDGPU::BI__builtin_amdgcn_grid_size_y:
+return EmitAMDGPUGridSize(*this, 1);
+  case AMDGPU::BI__builtin_amdgcn_grid_size_z:
+return EmitAMDGPUGridSize(*this, 2);
+
   // r600 intrinsics
   case AMDGPU::BI__builtin_r600_recipsqrt_ieee:
   case AMDGPU::BI__builtin_r600_recipsqrt_ieeef:

diff  --git a/clang/test/CodeGenOpenCL/builtins-amdgcn.cl 
b/clang/test/CodeGenOpenCL/builtins-amdgcn.cl
index 56c83df6b6b4..20edaf2aae3f 100644
--- a/clang/test/CodeGenOpenCL/builtins-amdgcn.cl
+++ b/clang/test/CodeGenOpenCL/builtins-amdgcn.cl
@@ -559,6 +559,24 @@ void test_get_workgroup_size(int d, global int *out)
}
 }
 
+// CHECK-LABEL: @test_get_grid_size(
+// CHECK: call align 4 dereferenceable(64) i8 addrspace(4)* 
@llvm.amdgcn.dispatch.ptr()
+// CHECK: getelementptr i8, i8 addrspace(4)* %{{.*}}, i64 12
+// CHECK: load i32, i32 addrspace(4)* %{{.*}}, align 4, !invariant.load
+// CHECK: getelementptr i8, i8 addrspace(4)* %{{.*}}, i64 16
+// CHECK: load i32, i32 addrspace(4)* %{{.*}}, align 4, !invariant.load
+// CHECK: getelementptr i8, i8 addrspace(4)* %{{.*}}, i64 20
+// CHECK: load i32, i32 addrspace(4)* %{{.*}}, align 4, !invariant.load
+void test_get_grid_size(int d, global int *out)
+{
+   switch (d) {
+   case 0: *out = __builtin_amdgcn_grid_size_x(); break;
+   case 1: *out = __builtin_amdgcn_grid_size_y(); break;
+   case 2: *out = __builtin_amdgcn_grid_size_z(); break;
+   default: *out = 0;
+   }
+}
+
 // CHECK-LABEL: @test_fmed3_f32
 // CHECK: call float @llvm.amdgcn.fmed3.f32(
 void test_fmed3_f32(global float* out, float a, float b, float c)

diff  --git a/openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip 
b/openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
index 8c53d99b9fb6..9fbdc67b56ab 100644
--- a/openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
+++ 

[PATCH] D90251: [AMDGPU] Add __builtin_amdgcn_grid_size

2020-10-29 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 rGdee7704829bd: [AMDGPU] Add __builtin_amdgcn_grid_size 
(authored by JonChesterfield).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90251

Files:
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGenOpenCL/builtins-amdgcn.cl
  openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip

Index: openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
@@ -119,12 +119,6 @@
 }
 
 namespace {
-DEVICE uint32_t grid_size_x() {
-  size_t grid_size_x_offset = 96; // In bits, from AQL kernel dispatch format
-  return *(uint32_t *)((char *)__builtin_amdgcn_dispatch_ptr() +
-   grid_size_x_offset / 8);
-}
-
 DEVICE uint32_t get_grid_dim(uint32_t n, uint16_t d) {
   uint32_t q = n / d;
   return q + (n > q * d);
@@ -137,11 +131,11 @@
 } // namespace
 
 DEVICE int GetNumberOfBlocksInKernel() {
-  return get_grid_dim(grid_size_x(), __builtin_amdgcn_workgroup_size_x());
+  return get_grid_dim(__builtin_amdgcn_grid_size_x(), __builtin_amdgcn_workgroup_size_x());
 }
 
 DEVICE int GetNumberOfThreadsInBlock() {
-  return get_workgroup_dim(__builtin_amdgcn_workgroup_id_x(), grid_size_x(),
+  return get_workgroup_dim(__builtin_amdgcn_workgroup_id_x(), __builtin_amdgcn_grid_size_x(),
__builtin_amdgcn_workgroup_size_x());
 }
 
Index: clang/test/CodeGenOpenCL/builtins-amdgcn.cl
===
--- clang/test/CodeGenOpenCL/builtins-amdgcn.cl
+++ clang/test/CodeGenOpenCL/builtins-amdgcn.cl
@@ -559,6 +559,24 @@
 	}
 }
 
+// CHECK-LABEL: @test_get_grid_size(
+// CHECK: call align 4 dereferenceable(64) i8 addrspace(4)* @llvm.amdgcn.dispatch.ptr()
+// CHECK: getelementptr i8, i8 addrspace(4)* %{{.*}}, i64 12
+// CHECK: load i32, i32 addrspace(4)* %{{.*}}, align 4, !invariant.load
+// CHECK: getelementptr i8, i8 addrspace(4)* %{{.*}}, i64 16
+// CHECK: load i32, i32 addrspace(4)* %{{.*}}, align 4, !invariant.load
+// CHECK: getelementptr i8, i8 addrspace(4)* %{{.*}}, i64 20
+// CHECK: load i32, i32 addrspace(4)* %{{.*}}, align 4, !invariant.load
+void test_get_grid_size(int d, global int *out)
+{
+	switch (d) {
+	case 0: *out = __builtin_amdgcn_grid_size_x(); break;
+	case 1: *out = __builtin_amdgcn_grid_size_y(); break;
+	case 2: *out = __builtin_amdgcn_grid_size_z(); break;
+	default: *out = 0;
+	}
+}
+
 // CHECK-LABEL: @test_fmed3_f32
 // CHECK: call float @llvm.amdgcn.fmed3.f32(
 void test_fmed3_f32(global float* out, float a, float b, float c)
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -14750,6 +14750,22 @@
   llvm::MDNode::get(CGF.getLLVMContext(), None));
   return LD;
 }
+
+// \p Index is 0, 1, and 2 for x, y, and z dimension, respectively.
+Value *EmitAMDGPUGridSize(CodeGenFunction , unsigned Index) {
+  const unsigned XOffset = 12;
+  auto *DP = EmitAMDGPUDispatchPtr(CGF);
+  // Indexing the HSA kernel_dispatch_packet struct.
+  auto *Offset = llvm::ConstantInt::get(CGF.Int32Ty, XOffset + Index * 4);
+  auto *GEP = CGF.Builder.CreateGEP(DP, Offset);
+  auto *DstTy =
+  CGF.Int32Ty->getPointerTo(GEP->getType()->getPointerAddressSpace());
+  auto *Cast = CGF.Builder.CreateBitCast(GEP, DstTy);
+  auto *LD = CGF.Builder.CreateLoad(Address(Cast, CharUnits::fromQuantity(4)));
+  LD->setMetadata(llvm::LLVMContext::MD_invariant_load,
+  llvm::MDNode::get(CGF.getLLVMContext(), None));
+  return LD;
+}
 } // namespace
 
 // For processing memory ordering and memory scope arguments of various
@@ -15010,6 +15026,14 @@
   case AMDGPU::BI__builtin_amdgcn_workgroup_size_z:
 return EmitAMDGPUWorkGroupSize(*this, 2);
 
+  // amdgcn grid size
+  case AMDGPU::BI__builtin_amdgcn_grid_size_x:
+return EmitAMDGPUGridSize(*this, 0);
+  case AMDGPU::BI__builtin_amdgcn_grid_size_y:
+return EmitAMDGPUGridSize(*this, 1);
+  case AMDGPU::BI__builtin_amdgcn_grid_size_z:
+return EmitAMDGPUGridSize(*this, 2);
+
   // r600 intrinsics
   case AMDGPU::BI__builtin_r600_recipsqrt_ieee:
   case AMDGPU::BI__builtin_r600_recipsqrt_ieeef:
Index: clang/include/clang/Basic/BuiltinsAMDGPU.def
===
--- clang/include/clang/Basic/BuiltinsAMDGPU.def
+++ clang/include/clang/Basic/BuiltinsAMDGPU.def
@@ -37,6 +37,10 @@
 BUILTIN(__builtin_amdgcn_workgroup_size_y, "Us", "nc")
 BUILTIN(__builtin_amdgcn_workgroup_size_z, "Us", "nc")
 
+BUILTIN(__builtin_amdgcn_grid_size_x, "Ui", 

[PATCH] D90366: [ThinLTO] Fix empty .llvmcmd sections

2020-10-29 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson accepted this revision.
tejohnson 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/D90366/new/

https://reviews.llvm.org/D90366

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


[PATCH] D90392: [clang-tidy] Omit std::make_unique/make_shared for default initialization.

2020-10-29 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D90392#2362308 , @ckennelly wrote:

> In D90392#2362118 , @njames93 wrote:
>
>> IIUC, this is handling the case where `Ptr.reset(new int)` which is 
>> different to `Ptr.reset(new int())` because the former doesn't initialise 
>> the int while the latter default(zero) initialises it.
>> If that's correct I still think we should still warn about this case, but 
>> don't suggest an auto-fix as that will change behaviour.
>> Maybe put a note explaining why it can't be auto-fixed.
>
> I disagree with printing a warning but not a fix.
>
> These uses should migrate to 
> `std::make_unique_for_overwrite`/`std::make_shared_for_overwrite`.  I am 
> planning on sending a follow-up patch for that but want to avoid the existing 
> make-unique/make-shared checks try to migrate default initialization use 
> cases.

Reminder that there is more than one version of C++ standard, and users are not 
obligated to be using some particular version, and the checks should not be 
making that decision for user.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90392

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


[PATCH] D90366: [ThinLTO] Fix empty .llvmcmd sections

2020-10-29 Thread Mircea Trofin via Phabricator via cfe-commits
mtrofin updated this revision to Diff 301650.
mtrofin marked an inline comment as done.
mtrofin added a comment.

updated description


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90366

Files:
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/thinlto_embed_bitcode.ll


Index: clang/test/CodeGen/thinlto_embed_bitcode.ll
===
--- clang/test/CodeGen/thinlto_embed_bitcode.ll
+++ clang/test/CodeGen/thinlto_embed_bitcode.ll
@@ -17,12 +17,20 @@
 ; round-trip through compilation and ensure the objects are the same.
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t.o -x ir %t1.bc -c 
-fthinlto-index=%t.o.thinlto.bc -mllvm -lto-embed-bitcode=post-merge-pre-opt
 ; RUN: llvm-readelf -S %t.o | FileCheck %s 
--check-prefixes=CHECK-ELF,CHECK-ELF-CMD
+; RUN: llvm-objcopy --dump-section=.llvmcmd=%t-embedded.cmd %t.o /dev/null
+; RUN: grep x86_64-unknown-linux-gnu %t-embedded.cmd | count 1
 ; RUN: llvm-objcopy --dump-section=.llvmbc=%t-embedded.bc %t.o /dev/null
 ; RUN: llvm-dis %t-embedded.bc -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-NOOPT
 ; We should only need the index and the post-thinlto merged module to generate 
 ; the exact same .o as we originally did.
 ; RUN: rm %t1.bc %t2.bc
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t-redo.o -x ir 
%t-embedded.bc -c -fthinlto-index=%t.o.thinlto.bc -mllvm 
-lto-embed-bitcode=post-merge-pre-opt -mllvm -thinlto-assume-merged
+;
+; The resulting .o is almost the same, but the .llvmcmd section would be
+; different because of the extra -thinlto-assume-merged.
+; A simple, meaningful comparison is to just compare the stripped objects.
+; RUN: llvm-strip --strip-all %t-redo.o 
+; RUN: llvm-strip --strip-all %t.o 
 ; RUN: diff %t-redo.o %t.o
 
 ; CHECK-ELF:  .text   PROGBITS  [[#%x,OFF:]] [[#%x,SIZE:]] 
00 AX 0
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1095,23 +1095,21 @@
   // FIXME: For backend options that are not yet recorded as function
   // attributes in the IR, keep track of them so we can embed them in a
   // separate data section and use them when building the bitcode.
-  if (Opts.getEmbedBitcode() == CodeGenOptions::Embed_All) {
-for (const auto  : Args) {
-  // Do not encode output and input.
-  if (A->getOption().getID() == options::OPT_o ||
-  A->getOption().getID() == options::OPT_INPUT ||
-  A->getOption().getID() == options::OPT_x ||
-  A->getOption().getID() == options::OPT_fembed_bitcode ||
-  A->getOption().matches(options::OPT_W_Group))
-continue;
-  ArgStringList ASL;
-  A->render(Args, ASL);
-  for (const auto  : ASL) {
-StringRef ArgStr(arg);
-Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
-// using \00 to separate each commandline options.
-Opts.CmdArgs.push_back('\0');
-  }
+  for (const auto  : Args) {
+// Do not encode output and input.
+if (A->getOption().getID() == options::OPT_o ||
+A->getOption().getID() == options::OPT_INPUT ||
+A->getOption().getID() == options::OPT_x ||
+A->getOption().getID() == options::OPT_fembed_bitcode ||
+A->getOption().matches(options::OPT_W_Group))
+  continue;
+ArgStringList ASL;
+A->render(Args, ASL);
+for (const auto  : ASL) {
+  StringRef ArgStr(arg);
+  Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
+  // using \00 to separate each commandline options.
+  Opts.CmdArgs.push_back('\0');
 }
   }
 


Index: clang/test/CodeGen/thinlto_embed_bitcode.ll
===
--- clang/test/CodeGen/thinlto_embed_bitcode.ll
+++ clang/test/CodeGen/thinlto_embed_bitcode.ll
@@ -17,12 +17,20 @@
 ; round-trip through compilation and ensure the objects are the same.
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t.o -x ir %t1.bc -c -fthinlto-index=%t.o.thinlto.bc -mllvm -lto-embed-bitcode=post-merge-pre-opt
 ; RUN: llvm-readelf -S %t.o | FileCheck %s --check-prefixes=CHECK-ELF,CHECK-ELF-CMD
+; RUN: llvm-objcopy --dump-section=.llvmcmd=%t-embedded.cmd %t.o /dev/null
+; RUN: grep x86_64-unknown-linux-gnu %t-embedded.cmd | count 1
 ; RUN: llvm-objcopy --dump-section=.llvmbc=%t-embedded.bc %t.o /dev/null
 ; RUN: llvm-dis %t-embedded.bc -o - | FileCheck %s --check-prefixes=CHECK,CHECK-NOOPT
 ; We should only need the index and the post-thinlto merged module to generate 
 ; the exact same .o as we originally did.
 ; RUN: rm %t1.bc %t2.bc
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t-redo.o -x ir %t-embedded.bc -c -fthinlto-index=%t.o.thinlto.bc -mllvm 

[PATCH] D90392: [clang-tidy] Omit std::make_unique/make_shared for default initialization.

2020-10-29 Thread Chris Kennelly via Phabricator via cfe-commits
ckennelly added a comment.

In D90392#2362118 , @njames93 wrote:

> IIUC, this is handling the case where `Ptr.reset(new int)` which is different 
> to `Ptr.reset(new int())` because the former doesn't initialise the int while 
> the latter default(zero) initialises it.
> If that's correct I still think we should still warn about this case, but 
> don't suggest an auto-fix as that will change behaviour.
> Maybe put a note explaining why it can't be auto-fixed.

I disagree with printing a warning but not a fix.

These uses should migrate to 
`std::make_unique_for_overwrite`/`std::make_shared_for_overwrite`.  I am 
planning on sending a follow-up patch for that but want to avoid the existing 
make-unique/make-shared checks try to migrate default initialization use cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90392

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


[PATCH] D90392: [clang-tidy] Omit std::make_unique/make_shared for default initialization.

2020-10-29 Thread Chris Kennelly via Phabricator via cfe-commits
ckennelly updated this revision to Diff 301649.
ckennelly marked 3 inline comments as done.
ckennelly added a comment.

Apply review feedback from njames93


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90392

Files:
  clang-tools-extra/clang-tidy/modernize/MakeSmartPtrCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize-make-shared.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
@@ -96,34 +96,28 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P1 = std::make_unique();
 
-  // Without parenthesis.
+  // Without parenthesis, default initialization.
   std::unique_ptr P2 = std::unique_ptr(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: std::unique_ptr P2 = std::make_unique();
 
   P2.reset(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: P2 = std::make_unique();
 
   P2 = std::unique_ptr(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: P2 = std::make_unique();
 
   // With auto.
   auto P3 = std::unique_ptr(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use std::make_unique instead
   // CHECK-FIXES: auto P3 = std::make_unique();
 
-  std::unique_ptr P4 = std::unique_ptr((new int));
+  std::unique_ptr P4 = std::unique_ptr((new int()));
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: std::unique_ptr P4 = std::make_unique();
-  P4.reset((new int));
+  P4.reset((new int()));
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P4 = std::make_unique();
-  std::unique_ptr P5 = std::unique_ptrnew int;
+  std::unique_ptr P5 = std::unique_ptrnew int();
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: std::unique_ptr P5 = std::make_unique();
-  P5.reset(new int);
+  P5.reset(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P5 = std::make_unique();
 
@@ -137,6 +131,8 @@
 Q = unique_ptr(new int());
 // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: use std::make_unique instead
 // CHECK-FIXES: Q = std::make_unique();
+
+Q = unique_ptr(new int);
   }
 
   std::unique_ptr R(new int());
@@ -446,12 +442,12 @@
   // CHECK-FIXES: FFs = std::make_unique(Num2);
 
   std::unique_ptr FI;
-  FI.reset(new int[5]()); // default initialization.
+  FI.reset(new int[5]()); // value initialization.
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning:
   // CHECK-FIXES: FI = std::make_unique(5);
 
   // The check doesn't give warnings and fixes for cases where the original new
-  // expression doesn't do any initialization.
+  // expression does default initialization.
   FI.reset(new int[5]);
   FI.reset(new int[Num]);
   FI.reset(new int[Num2]);
@@ -459,13 +455,13 @@
 
 void aliases() {
   typedef std::unique_ptr IntPtr;
-  IntPtr Typedef = IntPtr(new int);
+  IntPtr Typedef = IntPtr(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: use std::make_unique instead
   // CHECK-FIXES: IntPtr Typedef = std::make_unique();
 
   // We use 'bool' instead of '_Bool'.
   typedef std::unique_ptr BoolPtr;
-  BoolPtr BoolType = BoolPtr(new bool);
+  BoolPtr BoolType = BoolPtr(new bool());
   // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: use std::make_unique instead
   // CHECK-FIXES: BoolPtr BoolType = std::make_unique();
 
@@ -476,12 +472,12 @@
 // CHECK-FIXES: BasePtr StructType = std::make_unique();
 
 #define PTR unique_ptr
-  std::unique_ptr Macro = std::PTR(new int);
+  std::unique_ptr Macro = std::PTR(new int());
 // CHECK-MESSAGES: :[[@LINE-1]]:32: warning: use std::make_unique instead
 // CHECK-FIXES: std::unique_ptr Macro = std::make_unique();
 #undef PTR
 
-  std::unique_ptr Using = unique_ptr_(new int);
+  std::unique_ptr Using = unique_ptr_(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:32: warning: use std::make_unique instead
   // CHECK-FIXES: std::unique_ptr Using = std::make_unique();
 }
@@ -505,7 +501,7 @@
   Nest.reset(new std::unique_ptr(new int));
   // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use std::make_unique instead
   // CHECK-FIXES: Nest = std::make_unique>(new int);
-  Nest->reset(new int);
+  Nest->reset(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:9: 

[PATCH] D90392: [clang-tidy] Omit std::make_unique/make_shared for default initialization.

2020-10-29 Thread Chris Kennelly via Phabricator via cfe-commits
ckennelly updated this revision to Diff 301648.
ckennelly added a comment.

Apply feedback from ymandel


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90392

Files:
  clang-tools-extra/clang-tidy/modernize/MakeSmartPtrCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize-make-shared.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-make-unique.cpp
@@ -96,34 +96,28 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P1 = std::make_unique();
 
-  // Without parenthesis.
+  // Without parenthesis, default initialization.
   std::unique_ptr P2 = std::unique_ptr(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: std::unique_ptr P2 = std::make_unique();
 
   P2.reset(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: P2 = std::make_unique();
 
   P2 = std::unique_ptr(new int);
-  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use std::make_unique instead [modernize-make-unique]
-  // CHECK-FIXES: P2 = std::make_unique();
 
   // With auto.
   auto P3 = std::unique_ptr(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use std::make_unique instead
   // CHECK-FIXES: auto P3 = std::make_unique();
 
-  std::unique_ptr P4 = std::unique_ptr((new int));
+  std::unique_ptr P4 = std::unique_ptr((new int()));
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: std::unique_ptr P4 = std::make_unique();
-  P4.reset((new int));
+  P4.reset((new int()));
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P4 = std::make_unique();
-  std::unique_ptr P5 = std::unique_ptrnew int;
+  std::unique_ptr P5 = std::unique_ptrnew int();
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: std::unique_ptr P5 = std::make_unique();
-  P5.reset(new int);
+  P5.reset(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: P5 = std::make_unique();
 
@@ -137,6 +131,8 @@
 Q = unique_ptr(new int());
 // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: use std::make_unique instead
 // CHECK-FIXES: Q = std::make_unique();
+
+Q = unique_ptr(new int);
   }
 
   std::unique_ptr R(new int());
@@ -446,12 +442,12 @@
   // CHECK-FIXES: FFs = std::make_unique(Num2);
 
   std::unique_ptr FI;
-  FI.reset(new int[5]()); // default initialization.
+  FI.reset(new int[5]()); // value initialization.
   // CHECK-MESSAGES: :[[@LINE-1]]:6: warning:
   // CHECK-FIXES: FI = std::make_unique(5);
 
   // The check doesn't give warnings and fixes for cases where the original new
-  // expression doesn't do any initialization.
+  // expression does default initialization.
   FI.reset(new int[5]);
   FI.reset(new int[Num]);
   FI.reset(new int[Num2]);
@@ -459,13 +455,13 @@
 
 void aliases() {
   typedef std::unique_ptr IntPtr;
-  IntPtr Typedef = IntPtr(new int);
+  IntPtr Typedef = IntPtr(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: use std::make_unique instead
   // CHECK-FIXES: IntPtr Typedef = std::make_unique();
 
   // We use 'bool' instead of '_Bool'.
   typedef std::unique_ptr BoolPtr;
-  BoolPtr BoolType = BoolPtr(new bool);
+  BoolPtr BoolType = BoolPtr(new bool());
   // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: use std::make_unique instead
   // CHECK-FIXES: BoolPtr BoolType = std::make_unique();
 
@@ -476,12 +472,12 @@
 // CHECK-FIXES: BasePtr StructType = std::make_unique();
 
 #define PTR unique_ptr
-  std::unique_ptr Macro = std::PTR(new int);
+  std::unique_ptr Macro = std::PTR(new int());
 // CHECK-MESSAGES: :[[@LINE-1]]:32: warning: use std::make_unique instead
 // CHECK-FIXES: std::unique_ptr Macro = std::make_unique();
 #undef PTR
 
-  std::unique_ptr Using = unique_ptr_(new int);
+  std::unique_ptr Using = unique_ptr_(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:32: warning: use std::make_unique instead
   // CHECK-FIXES: std::unique_ptr Using = std::make_unique();
 }
@@ -505,7 +501,7 @@
   Nest.reset(new std::unique_ptr(new int));
   // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use std::make_unique instead
   // CHECK-FIXES: Nest = std::make_unique>(new int);
-  Nest->reset(new int);
+  Nest->reset(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: use std::make_unique instead
   // 

[PATCH] D89959: UBSAN: emit distinctive traps in trapping mode

2020-10-29 Thread Jan Korous via Phabricator via cfe-commits
jkorous added a comment.

Friendly ping


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

https://reviews.llvm.org/D89959

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


  1   2   >