date:20220125

[PATCH] D116387: [CodeCompletion][clangd] Clean __uglified parameter names in completion & hover

2022-01-25 Thread Sam McCall via Phabricator via cfe-commits

sammccall updated this revision to Diff 403149.
sammccall marked an inline comment as done.
sammccall added a comment.

Fix hover revert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116387

Files:
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
  clang/include/clang/AST/PrettyPrinter.h
  clang/include/clang/Basic/IdentifierTable.h
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/TemplateName.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/test/CodeCompletion/deuglify.cpp
  clang/unittests/AST/DeclPrinterTest.cpp
  clang/unittests/AST/StmtPrinterTest.cpp
  clang/unittests/AST/TypePrinterTest.cpp

Index: clang/unittests/AST/TypePrinterTest.cpp
===
--- clang/unittests/AST/TypePrinterTest.cpp
+++ clang/unittests/AST/TypePrinterTest.cpp
@@ -62,4 +62,21 @@
   ASSERT_TRUE(PrintedTypeMatches(
   Code, {}, Matcher, "const N::Type &",
   [](PrintingPolicy ) { Policy.FullyQualifiedName = true; }));
-}
\ No newline at end of file
+}
+
+TEST(TypePrinter, ParamsUglified) {
+  llvm::StringLiteral Code = R"cpp(
+template  class __f>
+const __f<_Tp&> *A = nullptr;
+  )cpp";
+  auto Clean = [](PrintingPolicy ) {
+Policy.CleanUglifiedParameters = true;
+  };
+
+  ASSERT_TRUE(PrintedTypeMatches(Code, {},
+ varDecl(hasType(qualType().bind("id"))),
+ "const __f<_Tp &> *", nullptr));
+  ASSERT_TRUE(PrintedTypeMatches(Code, {},
+ varDecl(hasType(qualType().bind("id"))),
+ "const f *", Clean));
+}
Index: clang/unittests/AST/StmtPrinterTest.cpp
===
--- clang/unittests/AST/StmtPrinterTest.cpp
+++ clang/unittests/AST/StmtPrinterTest.cpp
@@ -263,3 +263,22 @@
 
   [](PrintingPolicy ) { PP.TerseOutput = true; }));
 }
+
+TEST(StmtPrinter, ParamsUglified) {
+  llvm::StringLiteral Code = R"cpp(
+template  class _C>
+auto foo(int __j) {
+  return typename _C<_T>::_F(_I, __j);
+}
+  )cpp";
+  auto Clean = [](PrintingPolicy ) {
+Policy.CleanUglifiedParameters = true;
+  };
+
+  ASSERT_TRUE(PrintedStmtCXXMatches(StdVer::CXX14, Code,
+returnStmt().bind("id"),
+"return typename _C<_T>::_F(_I, __j);\n"));
+  ASSERT_TRUE(
+  PrintedStmtCXXMatches(StdVer::CXX14, Code, returnStmt().bind("id"),
+"return typename C::_F(I, j);\n", Clean));
+}
Index: clang/unittests/AST/DeclPrinterTest.cpp
===
--- clang/unittests/AST/DeclPrinterTest.cpp
+++ clang/unittests/AST/DeclPrinterTest.cpp
@@ -1336,6 +1336,41 @@
   ASSERT_TRUE(PrintedDeclCXX11Matches(Code, "NT2", "int NT2 = 5"));
 }
 
+TEST(DeclPrinter, TestFunctionParamUglified) {
+  llvm::StringLiteral Code = R"cpp(
+class __c;
+void _A(__c *__param);
+  )cpp";
+  auto Clean = [](PrintingPolicy ) {
+Policy.CleanUglifiedParameters = true;
+  };
+
+  ASSERT_TRUE(PrintedDeclCXX17Matches(Code, namedDecl(hasName("_A")).bind("id"),
+  "void _A(__c *__param)"));
+  ASSERT_TRUE(PrintedDeclCXX17Matches(Code, namedDecl(hasName("_A")).bind("id"),
+  "void _A(__c *param)", Clean));
+}
+
+TEST(DeclPrinter, TestTemplateParamUglified) {
+  llvm::StringLiteral Code = R"cpp(
+template  class _Container>
+struct _A{};
+  )cpp";
+  auto Clean = [](PrintingPolicy ) {
+Policy.CleanUglifiedParameters = true;
+  };
+
+  ASSERT_TRUE(PrintedDeclCXX17Matches(
+  Code, classTemplateDecl(hasName("_A")).bind("id"),
+  "template  class _Container> "
+  "struct _A {}"));
+  ASSERT_TRUE(PrintedDeclCXX17Matches(
+  Code, classTemplateDecl(hasName("_A")).bind("id"),
+  "template  class Container> "
+  "struct _A {}",
+  Clean));
+}
+
 TEST(DeclPrinter, TestStaticAssert1) {
   ASSERT_TRUE(PrintedDeclCXX17Matches("static_assert(true);",
   staticAssertDecl().bind("id"),
Index: clang/test/CodeCompletion/deuglify.cpp
===
--- /dev/null
+++ clang/test/CodeCompletion/deuglify.cpp
@@ -0,0 +1,25 @@
+// Fake standard library with uglified names.
+// Parameters (including template params) get ugliness stripped.
+namespace std {
+
+template 
+class __vector_base {};
+
+template 
+class vector : private __vector_base<_Tp> {
+public:
+  _Tp (unsigned __index) const;
+  int __stays_ugly();
+};
+
+} // namespace std
+
+int x = std::vector{}.at(42);
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:17:14 %s -o - | FileCheck -check-prefix=CHECK-CC1 %s
+// CHECK-CC1:

[PATCH] D116387: [CodeCompletion][clangd] Clean __uglified parameter names in completion & hover

2022-01-25 Thread Sam McCall via Phabricator via cfe-commits

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



Comment at: clang-tools-extra/clangd/Hover.cpp:65
   Base.SuppressTemplateArgsInCXXConstructors = true;
+  Base.CleanUglifiedParameters = true;
   return Base;

hokein wrote:
> IIUC, the code looks like we change the hover behavior as well, but I think 
> our plan is to not change hover. 
Oops, I messed up the revert. Fixed now!



Comment at: clang/lib/AST/DeclPrinter.cpp:889
+  printDeclType(T, (isa(D) && Policy.CleanUglifiedParameters &&
+D->getIdentifier())
+   ? D->getIdentifier()->deuglifiedName()

hokein wrote:
> nit: `D->getIdentifier()` seems redundant -- `D->getName()` has an 
> `isIdentifier()` assertion, we should expect that we can always get 
> identifier from D here. 
Sadly not: if D has no name (e.g. the param in `void foo(int)`) then 
`isIdentifier()` is true but `getIdentifier()` is nullptr :-(

This is a big trap in the API, but not one I can easily fix here.



Comment at: clang/lib/Basic/IdentifierTable.cpp:312
 
+StringRef IdentifierInfo::deuglifiedName() const {
+  StringRef Name = getName();

hokein wrote:
> Not objecting the current approach -- an alternative is to incline this into 
> `getName` by adding a parameter `Deuglify` to control the behavior.
> 
> Not sure it is much better, but it seem to save some boilerplate code like 
> `Policy.CleanUglifiedParameters ? II->deuglifiedName() : II->getName()`. 
Yeah, I was concerned about putting this in the way of a critical/central 
function.

If we were to do this maybe we should choose a spelling like 
`getDeuglifiedName(bool Deuglify=true)`.


I'm not sure this is so much better, as it only helps some fraction of the 
callsites (not the ones that need to fall back to printing the whole 
DeclarationName instead, and not the one that want to use 
Policy.CleanUglifyParameters to short-circuit some other check instead)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116387

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

[PATCH] D118169: [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

2022-01-25 Thread serge via Phabricator via cfe-commits

serge-sans-paille accepted this revision.
serge-sans-paille added a comment.

No performance regression on my side either (but only minor gains).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118169

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

[clang] f563bd7 - [NFC] Group PowerPC clang codegen tests into directory

2022-01-25 Thread Qiu Chaofan via cfe-commits


Author: Qiu Chaofan
Date: 2022-01-26T15:19:22+08:00
New Revision: f563bd74cb9a4f0d2d3eb49d35536b648361ec53

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

LOG: [NFC] Group PowerPC clang codegen tests into directory

Added: 
clang/test/CodeGen/PowerPC/2009-02-13-zerosize-union-field-ppc.c
clang/test/CodeGen/PowerPC/aix-alignment.c
clang/test/CodeGen/PowerPC/aix-altivec-vaargs.c
clang/test/CodeGen/PowerPC/aix-altivec.c
clang/test/CodeGen/PowerPC/aix-constructor-attribute.c
clang/test/CodeGen/PowerPC/aix-destructor-attribute.c
clang/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.cpp
clang/test/CodeGen/PowerPC/aix-init-priority-attribute.cpp
clang/test/CodeGen/PowerPC/aix-return.c
clang/test/CodeGen/PowerPC/aix-struct-arg.c
clang/test/CodeGen/PowerPC/aix-tls-model.cpp
clang/test/CodeGen/PowerPC/aix-vaargs.c
clang/test/CodeGen/PowerPC/aix-vector-attr-aligned.c
clang/test/CodeGen/PowerPC/aix-visibility-inlines-hidden.cpp
clang/test/CodeGen/PowerPC/aix32-complex-varargs.c
clang/test/CodeGen/PowerPC/aix_alloca_align.c
clang/test/CodeGen/PowerPC/altivec-ct.c
clang/test/CodeGen/PowerPC/altivec-dss.c
clang/test/CodeGen/PowerPC/altivec.c
clang/test/CodeGen/PowerPC/attr-target-ppc.c
clang/test/CodeGen/PowerPC/bool_test.c
clang/test/CodeGen/PowerPC/builtins-ppc-32bit-vec-ll.c
clang/test/CodeGen/PowerPC/builtins-ppc-altivec.c
clang/test/CodeGen/PowerPC/builtins-ppc-build-pair-mma.c
clang/test/CodeGen/PowerPC/builtins-ppc-cache.c
clang/test/CodeGen/PowerPC/builtins-ppc-crypto-disabled.c
clang/test/CodeGen/PowerPC/builtins-ppc-crypto.c
clang/test/CodeGen/PowerPC/builtins-ppc-error.c
clang/test/CodeGen/PowerPC/builtins-ppc-fastmath.c
clang/test/CodeGen/PowerPC/builtins-ppc-fma.c
clang/test/CodeGen/PowerPC/builtins-ppc-fpconstrained.c
clang/test/CodeGen/PowerPC/builtins-ppc-htm.c
clang/test/CodeGen/PowerPC/builtins-ppc-int128.c
clang/test/CodeGen/PowerPC/builtins-ppc-ld-st-rmb.c
clang/test/CodeGen/PowerPC/builtins-ppc-p10.c
clang/test/CodeGen/PowerPC/builtins-ppc-p10vector-error.c
clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
clang/test/CodeGen/PowerPC/builtins-ppc-p7-disabled.c
clang/test/CodeGen/PowerPC/builtins-ppc-p7.c
clang/test/CodeGen/PowerPC/builtins-ppc-p8vector.c
clang/test/CodeGen/PowerPC/builtins-ppc-p9-f128.c
clang/test/CodeGen/PowerPC/builtins-ppc-p9vector.c
clang/test/CodeGen/PowerPC/builtins-ppc-pair-mma.c
clang/test/CodeGen/PowerPC/builtins-ppc-quadword-noi128.c
clang/test/CodeGen/PowerPC/builtins-ppc-quadword.c
clang/test/CodeGen/PowerPC/builtins-ppc-vec-ins-error.c
clang/test/CodeGen/PowerPC/builtins-ppc-vsx.c
clang/test/CodeGen/PowerPC/builtins-ppc-xl-xst.c

clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-cas-error.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-cas.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-cipher.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-cmplx.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-conversionfunc.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-darn.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-error.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-expect.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-fetch-error.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-fetch.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-fp.c

clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed-64bit-only.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-move-tofrom-regs.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-popcnt.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-prefetch.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr8.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-error.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-warning.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-rotate.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-stfiw.c
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-swdiv.c

[PATCH] D118169: [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

2022-01-25 Thread serge via Phabricator via cfe-commits

serge-sans-paille added a comment.

The change looks fine to me. I've started a set of benchmark to make sure it 
provides the expected speedup.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118169

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

[clang-tools-extra] f0726ae - Refactor: Extract Class MessagePrefix (NFC)

2022-01-25 Thread via cfe-commits


Author: Richard
Date: 2022-01-25T23:19:33-07:00
New Revision: f0726ae0f9fa3fc5fadec7fdc940cc2f88759001

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

LOG: Refactor: Extract Class MessagePrefix (NFC)

The work is the same, the only difference is the prefix
of the strings we look for in the reference files.

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 1a234029b60bd..d764f20ef2ecc 100755
--- a/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
+++ b/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
@@ -51,6 +51,21 @@ def try_run(args, raise_error=True):
   return process_output
 
 
+# This class represents the appearance of a message prefix in a file.
+class MessagePrefix:
+  def __init__(self, label):
+self.has_message = False
+self.prefixes = []
+self.label = label
+
+  def check(self, file_check_suffix, input_text):
+self.prefix = self.label + file_check_suffix
+self.has_message = self.prefix in input_text
+if self.has_message:
+  self.prefixes.append(self.prefix)
+return self.has_message
+
+
 class CheckRunner:
   def __init__(self, args, extra_args):
 self.resource_dir = args.resource_dir
@@ -63,12 +78,12 @@ def __init__(self, args, extra_args):
 self.std = args.std
 self.check_suffix = args.check_suffix
 self.input_text = ''
-self.check_fixes_prefixes = []
-self.check_messages_prefixes = []
-self.check_notes_prefixes = []
 self.has_check_fixes = False
 self.has_check_messages = False
 self.has_check_notes = False
+self.fixes = MessagePrefix('CHECK-FIXES')
+self.messages = MessagePrefix('CHECK-MESSAGES')
+self.notes = MessagePrefix('CHECK-NOTES')
 
 file_name_with_extension = self.assume_file_name or self.input_file_name
 _, extension = os.path.splitext(file_name_with_extension)
@@ -109,38 +124,29 @@ def read_input(self):
   self.input_text = input_file.read()
 
   def get_prefixes(self):
-for check in self.check_suffix:
-  if check and not re.match('^[A-Z0-9\\-]+$', check):
+for suffix in self.check_suffix:
+  if suffix and not re.match('^[A-Z0-9\\-]+$', suffix):
 sys.exit('Only A..Z, 0..9 and "-" are allowed in check suffixes list,'
- + ' but "%s" was given' % check)
+ + ' but "%s" was given' % suffix)
 
-  file_check_suffix = ('-' + check) if check else ''
-  check_fixes_prefix = 'CHECK-FIXES' + file_check_suffix
-  check_messages_prefix = 'CHECK-MESSAGES' + file_check_suffix
-  check_notes_prefix = 'CHECK-NOTES' + file_check_suffix
+  file_check_suffix = ('-' + suffix) if suffix else ''
 
-  has_check_fix = check_fixes_prefix in self.input_text
-  has_check_message = check_messages_prefix in self.input_text
-  has_check_note = check_notes_prefix in self.input_text
+  has_check_fix = self.fixes.check(file_check_suffix, self.input_text)
+  self.has_check_fixes = self.has_check_fixes or has_check_fix
+
+  has_check_message = self.messages.check(file_check_suffix, 
self.input_text)
+  self.has_check_messages = self.has_check_messages or has_check_message
+
+  has_check_note = self.notes.check(file_check_suffix, self.input_text)
+  self.has_check_notes = self.has_check_notes or has_check_note
 
   if has_check_note and has_check_message:
 sys.exit('Please use either %s or %s but not both' %
-  (check_notes_prefix, check_messages_prefix))
+  (self.notes.prefix, self.messages.prefix))
 
   if not has_check_fix and not has_check_message and not has_check_note:
 sys.exit('%s, %s or %s not found in the input' %
-  (check_fixes_prefix, check_messages_prefix, check_notes_prefix))
-
-  self.has_check_fixes = self.has_check_fixes or has_check_fix
-  self.has_check_messages = self.has_check_messages or has_check_message
-  self.has_check_notes = self.has_check_notes or has_check_note
-
-  if has_check_fix:
-self.check_fixes_prefixes.append(check_fixes_prefix)
-  if has_check_message:
-self.check_messages_prefixes.append(check_messages_prefix)
-  if has_check_note:
-self.check_notes_prefixes.append(check_notes_prefix)
+  (self.fixes.prefix, self.messages.prefix, self.notes.prefix))
 
 assert self.has_check_fixes or self.has_check_messages or 
self.has_check_notes
 
@@ -173,7 +179,7 @@ def run_clang_tidy(self):
   def check_fixes(self):
 if self.has_check_fixes:
   try_run(['FileCheck', '-input-file=' + self.temp_file_name, 
self.input_file_name,
-  '-check-prefixes=' +

[PATCH] D118095: [AVR][clang] Reject non assembly source files for the avr1 family

2022-01-25 Thread Ben Shi via Phabricator via cfe-commits

benshi001 updated this revision to Diff 403135.

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

https://reviews.llvm.org/D118095

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/AVR.cpp
  clang/lib/Driver/ToolChains/AVR.h
  clang/test/Driver/avr-mmcu.S
  clang/test/Driver/avr-mmcu.c

Index: clang/test/Driver/avr-mmcu.c
===
--- clang/test/Driver/avr-mmcu.c
+++ clang/test/Driver/avr-mmcu.c
@@ -1,12 +1,15 @@
 // A test for the propagation of the -mmcu option to -cc1 and -cc1as
 
-// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 -save-temps %s 2>&1 | FileCheck -check-prefix=CHECK0 %s
-// CHECK0: clang{{.*}} "-cc1" {{.*}} "-target-cpu" "attiny11"
-// CHECK0: clang{{.*}} "-cc1as" {{.*}} "-target-cpu" "attiny11"
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 %s -c 2>&1 | FileCheck -check-prefix=CHECKA %s
+// CHECKA: error: device 'attiny11' only supports assembly programming
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 -x assembler-with-cpp %s -c 2>&1 | FileCheck -check-prefix=CHECKB %s
+// CHECKB-NOT: error: device 'attiny11' only supports assembly programming
 
 // RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=at90s2313 -save-temps %s 2>&1 | FileCheck -check-prefix=CHECK1 %s
 // CHECK1: clang{{.*}} "-cc1" {{.*}} "-target-cpu" "at90s2313"
 // CHECK1: clang{{.*}} "-cc1as" {{.*}} "-target-cpu" "at90s2313"
+// CHECK1-NOT: error: device 'at90s2313' only supports assembly programming
 
 // RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=at90s8515 -save-temps %s 2>&1 | FileCheck -check-prefix=CHECK2 %s
 // CHECK2: clang{{.*}} "-cc1" {{.*}} "-target-cpu" "at90s8515"
Index: clang/test/Driver/avr-mmcu.S
===
--- /dev/null
+++ clang/test/Driver/avr-mmcu.S
@@ -0,0 +1,13 @@
+// A test for the supported language mode by different avr families.
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 %s -c 2>&1 | FileCheck -check-prefix=CHECKA %s
+// CHECKA-NOT: error: device 'attiny11' only supports assembly programming
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 -x c++ %s -c 2>&1 | FileCheck -check-prefix=CHECKB %s
+// CHECKB: error: device 'attiny11' only supports assembly programming
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=at90s8515 %s -c 2>&1 | FileCheck -check-prefix=CHECKC %s
+// CHECKC-NOT: error: device 'at90s8515' only supports assembly programming
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=at90s8515 %s -x c++ -c 2>&1 | FileCheck -check-prefix=CHECKD %s
+// CHECKD-NOT: error: device 'at90s8515' only supports assembly programming
Index: clang/lib/Driver/ToolChains/AVR.h
===
--- clang/lib/Driver/ToolChains/AVR.h
+++ clang/lib/Driver/ToolChains/AVR.h
@@ -19,6 +19,8 @@
 namespace toolchains {
 
 class LLVM_LIBRARY_VISIBILITY AVRToolChain : public Generic_ELF {
+  std::string AVRMcu;
+
 public:
   AVRToolChain(const Driver , const llvm::Triple ,
const llvm::opt::ArgList );
Index: clang/lib/Driver/ToolChains/AVR.cpp
===
--- clang/lib/Driver/ToolChains/AVR.cpp
+++ clang/lib/Driver/ToolChains/AVR.cpp
@@ -12,6 +12,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/InputInfo.h"
 #include "clang/Driver/Options.h"
+#include "clang/Driver/Types.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -19,6 +20,7 @@
 #include "llvm/MC/SubtargetFeature.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
 
 using namespace clang::driver;
 using namespace clang::driver::toolchains;
@@ -311,24 +313,27 @@
 : Generic_ELF(D, Triple, Args), LinkStdlib(false) {
   GCCInstallation.init(Triple, Args);
 
+  // Save the CPU name for further checks.
+  AVRMcu = getCPUName(D, Args, Triple);
+
   // Only add default libraries if the user hasn't explicitly opted out.
   if (!Args.hasArg(options::OPT_nostdlib) &&
   !Args.hasArg(options::OPT_nodefaultlibs) &&
+  !Args.hasArg(options::OPT_S /* does not apply when not linking */) &&
   !Args.hasArg(options::OPT_c /* does not apply when not linking */)) {
-std::string CPU = getCPUName(D, Args, Triple);
 
-if (CPU.empty()) {
+if (AVRMcu.empty()) {
   // We cannot link any standard libraries without an MCU specified.
   D.Diag(diag::warn_drv_avr_mcu_not_specified);
 } else {
-  Optional FamilyName = GetMCUFamilyName(CPU);
+  Optional FamilyName = GetMCUFamilyName(AVRMcu);
   Optional AVRLibcRoot = findAVRLibcInstallation();
 
   if (!FamilyName.hasValue()) {
 // We do not have an entry for this CPU in

[PATCH] D115610: [C++20] [Modules] Don't create multiple global module fragment

2022-01-25 Thread Chuanqi Xu via Phabricator via cfe-commits

ChuanqiXu added a comment.

In D115610#3269265 , @urnathan wrote:

> Seems good to me, @iains you've been looking at this?

According to the discussion in 
https://github.com/llvm/llvm-project/issues/51682, it looks like Iains plans to 
implement something like P1184R2 (I found that is your paper!) in clang. So I 
added him before.

(Might you make the status as green?)




Comment at: clang/include/clang/Sema/Sema.h:2217
+  /// The gloabl module fragment of the current tranlation unit.
+  clang::Module *GlobalModuleFragmentCache = nullptr;
 

tbaeder wrote:
> Typos in "gloabl" and "tranlation" in the comment. Any reason to call this a 
> "cache"? This was confusing to me at first.
This is consistent with the current style in Sema. You could find many example 
by searching `Cache;` in Sema.h. I think the semantic is "Cache something to 
avoid search/create again".


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

https://reviews.llvm.org/D115610

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

[PATCH] D115610: [C++20] [Modules] Don't create multiple global module fragment

2022-01-25 Thread Chuanqi Xu via Phabricator via cfe-commits

ChuanqiXu updated this revision to Diff 403130.
ChuanqiXu added a comment.

Address comments


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

https://reviews.llvm.org/D115610

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaModule.cpp
  clang/test/CXX/module/module.unit/p7/Inputs/h8.h
  clang/test/CXX/module/module.unit/p7/Inputs/m8.cppm
  clang/test/CXX/module/module.unit/p7/t8.cpp


Index: clang/test/CXX/module/module.unit/p7/t8.cpp
===
--- /dev/null
+++ clang/test/CXX/module/module.unit/p7/t8.cpp
@@ -0,0 +1,7 @@
+// RUN: rm -fr %t
+// RUN: mkdir %t
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %S/Inputs/m8.cppm 
-I%S/Inputs -o %t/m8.pcm
+// RUN: %clang_cc1 -std=c++20 -I%S/Inputs/ -fprebuilt-module-path=%t %s 
-verify -fsyntax-only
+// expected-no-diagnostics
+export module t8;
+import m8;
Index: clang/test/CXX/module/module.unit/p7/Inputs/m8.cppm
===
--- /dev/null
+++ clang/test/CXX/module/module.unit/p7/Inputs/m8.cppm
@@ -0,0 +1,7 @@
+module;
+#include "h8.h"
+export module m8;
+
+extern "C++" {
+void bar();
+}
Index: clang/test/CXX/module/module.unit/p7/Inputs/h8.h
===
--- /dev/null
+++ clang/test/CXX/module/module.unit/p7/Inputs/h8.h
@@ -0,0 +1,4 @@
+#ifndef H8
+#define H8
+void foo();
+#endif
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -720,19 +720,24 @@
 
 Module *Sema::PushGlobalModuleFragment(SourceLocation BeginLoc,
bool IsImplicit) {
-  ModuleMap  = PP.getHeaderSearchInfo().getModuleMap();
-  Module *GlobalModule =
-  Map.createGlobalModuleFragmentForModuleUnit(BeginLoc, 
getCurrentModule());
-  assert(GlobalModule && "module creation should not fail");
+  // We shouldn't create new global module fragment if there is already
+  // one.
+  if (!GlobalModuleFragmentCache) {
+ModuleMap  = PP.getHeaderSearchInfo().getModuleMap();
+GlobalModuleFragmentCache = Map.createGlobalModuleFragmentForModuleUnit(
+BeginLoc, getCurrentModule());
+  }
+
+  assert(GlobalModuleFragmentCache && "module creation should not fail");
 
   // Enter the scope of the global module.
-  ModuleScopes.push_back({BeginLoc, GlobalModule,
+  ModuleScopes.push_back({BeginLoc, GlobalModuleFragmentCache,
   /*ModuleInterface=*/false,
   /*ImplicitGlobalModuleFragment=*/IsImplicit,
-  /*VisibleModuleSet*/{}});
-  VisibleModules.setVisible(GlobalModule, BeginLoc);
+  /*VisibleModuleSet*/ {}});
+  VisibleModules.setVisible(GlobalModuleFragmentCache, BeginLoc);
 
-  return GlobalModule;
+  return GlobalModuleFragmentCache;
 }
 
 void Sema::PopGlobalModuleFragment() {
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -2218,6 +2218,8 @@
   };
   /// The modules we're currently parsing.
   llvm::SmallVector ModuleScopes;
+  /// The global module fragment of the current translation unit.
+  clang::Module *GlobalModuleFragmentCache = nullptr;
 
   /// Namespace definitions that we will export when they finish.
   llvm::SmallPtrSet DeferredExportedNamespaces;


Index: clang/test/CXX/module/module.unit/p7/t8.cpp
===
--- /dev/null
+++ clang/test/CXX/module/module.unit/p7/t8.cpp
@@ -0,0 +1,7 @@
+// RUN: rm -fr %t
+// RUN: mkdir %t
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %S/Inputs/m8.cppm -I%S/Inputs -o %t/m8.pcm
+// RUN: %clang_cc1 -std=c++20 -I%S/Inputs/ -fprebuilt-module-path=%t %s -verify -fsyntax-only
+// expected-no-diagnostics
+export module t8;
+import m8;
Index: clang/test/CXX/module/module.unit/p7/Inputs/m8.cppm
===
--- /dev/null
+++ clang/test/CXX/module/module.unit/p7/Inputs/m8.cppm
@@ -0,0 +1,7 @@
+module;
+#include "h8.h"
+export module m8;
+
+extern "C++" {
+void bar();
+}
Index: clang/test/CXX/module/module.unit/p7/Inputs/h8.h
===
--- /dev/null
+++ clang/test/CXX/module/module.unit/p7/Inputs/h8.h
@@ -0,0 +1,4 @@
+#ifndef H8
+#define H8
+void foo();
+#endif
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -720,19 +720,24 @@
 
 Module *Sema::PushGlobalModuleFragment(SourceLocation BeginLoc,
bool IsImplicit) {
-  ModuleMap  = PP.getHeaderSearchInfo().getModuleMap();
-  Module *GlobalModule =
-

[PATCH] D117972: [PowerPC] Fix SSE translation on FreeBSD

2022-01-25 Thread Qiu Chaofan via Phabricator via cfe-commits

qiucf accepted this revision as: qiucf.
qiucf 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/D117972/new/

https://reviews.llvm.org/D117972

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

[PATCH] D118199: [AArch64] ACLE feature macro for Armv8.8-A MOPS

2022-01-25 Thread Son Tuan Vu via Phabricator via cfe-commits

tyb0807 added a comment.

Yes, https://reviews.llvm.org/D116160 is deprecated and will be abandoned.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118199

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

[PATCH] D115867: [C++20] [Coroutines] Warning for always_inline coroutine

2022-01-25 Thread Chuanqi Xu via Phabricator via cfe-commits

ChuanqiXu marked 2 inline comments as done.
ChuanqiXu added a comment.

In D115867#3270137 , @Quuxplusone 
wrote:

> LGTM now, modulo my suggested edits (and the necessary corresponding edits in 
> the test case).
> I don't think I'm really qualified to accept, but as nobody else is looking, 
> and my name is the one with the red next to it, I'll at least change mine to 
> green. I //recommend// getting someone else to look at this before landing it.

Thanks for helping to reword! This idea is inspired by @rjmccall so I guess 
this one should be good to him. Given the current situation, it might not be 
easy to find someone else to look at it. I would wait for 1~2 days before 
landing.




Comment at: clang/include/clang/Basic/AttrDocs.td:6140-6142
+Note that a coroutine function wouldn't get inlined in O0 if it is marked with 
"always_inline".
+In other optimization levels, only the first part of the coroutine - "ramp 
function"`_
+can be guaranteed to be inlined.

Quuxplusone wrote:
> Why is the `-O0` behavior different for coroutines, versus regular functions? 
> My understanding from this documentation is that `-O0 + always_inline` 
> //will// attempt inlining for regular functions, but will //not// attempt 
> inlining (not even of the ramp) for coroutines. That feels asymmetric and 
> weird.
> So my default assumption is that maybe this documentation is wrong?
> ...ah, I see you mention below that this is a known deficiency. So I think 
> this documentation is OK after you take my suggested edit. (I don't know if 
> it would be appropriate to mention the bug number in this documentation as 
> well, so I'll err on the side of not mentioning it.)
I have made a longer explanation at: 
https://github.com/llvm/llvm-project/issues/53413 (and I cite this in following 
comment). I feel it is not good to write something so long in this document. 


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

https://reviews.llvm.org/D115867

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

[PATCH] D115867: [C++20] [Coroutines] Warning for always_inline coroutine

2022-01-25 Thread Chuanqi Xu via Phabricator via cfe-commits

ChuanqiXu updated this revision to Diff 403121.
ChuanqiXu added a comment.

Address comments


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

https://reviews.llvm.org/D115867

Files:
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaCoroutine.cpp
  clang/test/SemaCXX/coroutines.cpp


Index: clang/test/SemaCXX/coroutines.cpp
===
--- clang/test/SemaCXX/coroutines.cpp
+++ clang/test/SemaCXX/coroutines.cpp
@@ -1460,3 +1460,13 @@
   co_await missing_await_suspend{}; // expected-error {{no member named 
'await_suspend' in 'missing_await_suspend'}}
   co_await missing_await_resume{}; // expected-error {{no member named 
'await_resume' in 'missing_await_resume'}}
 }
+
+__attribute__((__always_inline__))
+void warn_always_inline() { // expected-warning {{this coroutine may be split 
into pieces; not every piece is guaranteed to be inlined}}
+  co_await suspend_always{};
+}
+
+[[gnu::always_inline]]
+void warn_gnu_always_inline() { // expected-warning {{this coroutine may be 
split into pieces; not every piece is guaranteed to be inlined}}
+  co_await suspend_always{};
+}
Index: clang/lib/Sema/SemaCoroutine.cpp
===
--- clang/lib/Sema/SemaCoroutine.cpp
+++ clang/lib/Sema/SemaCoroutine.cpp
@@ -1081,6 +1081,14 @@
 return;
   }
 
+  // The always_inline attribute doesn't reliably apply to a coroutine,
+  // because the coroutine will be split into pieces and some pieces
+  // might be called indirectly, as in a virtual call. Even the ramp
+  // function cannot be inlined at -O0, due to pipeline ordering
+  // problems (see https://llvm.org/PR53413). Tell the user about it.
+  if (FD->hasAttr())
+Diag(FD->getLocation(), diag::warn_always_inline_coroutine);
+
   // [stmt.return.coroutine]p1:
   //   A coroutine shall not enclose a return statement ([stmt.return]).
   if (Fn->FirstReturnLoc.isValid()) {
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -0,6 +0,10 @@
 def note_coroutine_function_declare_noexcept : Note<
   "must be declared with 'noexcept'"
 >;
+def warn_always_inline_coroutine : Warning<
+  "this coroutine may be split into pieces; not every piece is guaranteed to 
be inlined"
+  >,
+  InGroup;
 } // end of coroutines issue category
 
 let CategoryName = "Documentation Issue" in {
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -58,7 +58,9 @@
   DiagGroup<"deprecated-experimental-coroutine">;
 def DeprecatedCoroutine :
   DiagGroup<"deprecated-coroutine", [DeprecatedExperimentalCoroutine]>;
-def Coroutine : DiagGroup<"coroutine", [CoroutineMissingUnhandledException, 
DeprecatedCoroutine]>;
+def AlwaysInlineCoroutine :
+  DiagGroup<"always-inline-coroutine">;
+def Coroutine : DiagGroup<"coroutine", [CoroutineMissingUnhandledException, 
DeprecatedCoroutine, AlwaysInlineCoroutine]>;
 def ObjCBoolConstantConversion : DiagGroup<"objc-bool-constant-conversion">;
 def ConstantConversion : DiagGroup<"constant-conversion",
[BitFieldConstantConversion,
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -6202,6 +6202,10 @@
 
 Does not guarantee that inline substitution actually occurs.
 
+A coroutine function will not be inlined at -O0, even if it is marked with 
this attribute.
+At higher optimization levels, only the first part of the coroutine - the 
"ramp function"`_
+is guaranteed to be inlined.
+
 See also `the Microsoft Docs on Inline Functions`_, `the GCC Common Function
 Attribute docs`_, and `the GCC Inline docs`_.
 


Index: clang/test/SemaCXX/coroutines.cpp
===
--- clang/test/SemaCXX/coroutines.cpp
+++ clang/test/SemaCXX/coroutines.cpp
@@ -1460,3 +1460,13 @@
   co_await missing_await_suspend{}; // expected-error {{no member named 'await_suspend' in 'missing_await_suspend'}}
   co_await missing_await_resume{}; // expected-error {{no member named 'await_resume' in 'missing_await_resume'}}
 }
+
+__attribute__((__always_inline__))
+void warn_always_inline() { // expected-warning {{this coroutine may be split into pieces; not every piece is guaranteed to be inlined}}
+  co_await suspend_always{};
+}
+
+[[gnu::always_inline]]
+void warn_gnu_always_inline() { // expected-warning {{this coroutine may be split

[PATCH] D118211: Add missing namespace to PPCLinux.cpp

2022-01-25 Thread Mike Hommey via Phabricator via cfe-commits

glandium created this revision.
Herald added subscribers: shchenz, kbarton, nemanjai.
glandium requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes a build failure with MSVC introduced in
https://reviews.llvm.org/D112906


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118211

Files:
  clang/lib/Driver/ToolChains/PPCLinux.cpp


Index: clang/lib/Driver/ToolChains/PPCLinux.cpp
===
--- clang/lib/Driver/ToolChains/PPCLinux.cpp
+++ clang/lib/Driver/ToolChains/PPCLinux.cpp
@@ -13,6 +13,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 
+using namespace clang::driver;
 using namespace clang::driver::toolchains;
 using namespace llvm::opt;
 using namespace llvm::sys;


Index: clang/lib/Driver/ToolChains/PPCLinux.cpp
===
--- clang/lib/Driver/ToolChains/PPCLinux.cpp
+++ clang/lib/Driver/ToolChains/PPCLinux.cpp
@@ -13,6 +13,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 
+using namespace clang::driver;
 using namespace clang::driver::toolchains;
 using namespace llvm::opt;
 using namespace llvm::sys;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56303: [clang-tidy] Recognize labelled statements when simplifying boolean exprs

2022-01-25 Thread Richard via Phabricator via cfe-commits

LegalizeAdulthood added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/SimplifyBooleanExprCheck.cpp:72-73
 
-const Expr *getBoolLiteral(const MatchFinder::MatchResult ,
-   StringRef Id) {
+static const Expr *getBoolLiteral(const MatchFinder::MatchResult ,
+  StringRef Id) {
   if (const Expr *Literal = Result.Nodes.getNodeAs(Id))

LegalizeAdulthood wrote:
> FYI
> 
> These tabs here (and elsewhere) are phantoms somehow
> introduced into the diff by Phabricator.  My local diff file
> that I uploaded has zero tabs in it anywhere.
> 
When I look more carefully, I see it's one column to the left of the
first column in the file so it's trying to somehow say that this line
had increased indent in the diff?

I thought it was a TAB indicator and another reviewer thought so as well.

But it isn't a TAB at all `:)`


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

https://reviews.llvm.org/D56303

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

[PATCH] D56303: [clang-tidy] Recognize labelled statements when simplifying boolean exprs

2022-01-25 Thread Richard via Phabricator via cfe-commits

LegalizeAdulthood added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/SimplifyBooleanExprCheck.cpp:72-73
 
-const Expr *getBoolLiteral(const MatchFinder::MatchResult ,
-   StringRef Id) {
+static const Expr *getBoolLiteral(const MatchFinder::MatchResult ,
+  StringRef Id) {
   if (const Expr *Literal = Result.Nodes.getNodeAs(Id))

FYI

These tabs here (and elsewhere) are phantoms somehow
introduced into the diff by Phabricator.  My local diff file
that I uploaded has zero tabs in it anywhere.



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

https://reviews.llvm.org/D56303

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

[PATCH] D117939: [clang-tidy] Add more documentation about check development

2022-01-25 Thread Richard via Phabricator via cfe-commits

LegalizeAdulthood updated this revision to Diff 403118.
LegalizeAdulthood added a comment.

Update from review comments


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

https://reviews.llvm.org/D117939

Files:
  clang-tools-extra/docs/clang-tidy/Contributing.rst

Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -22,6 +22,8 @@
 check, it will create the check, update the CMake file and create a test;
   * ``rename_check.py`` does what the script name suggests, renames an existing
 check;
+  * :program:`pp-trace` logs method calls on `PPCallbacks` for a source file
+and is invaluable in understanding the preprocessor mechanism;
   * :program:`clang-query` is invaluable for interactive prototyping of AST
 matchers and exploration of the Clang AST;
   * `clang-check`_ with the ``-ast-dump`` (and optionally ``-ast-dump-filter``)
@@ -70,6 +72,14 @@
 .. _Using Clang Tools: https://clang.llvm.org/docs/ClangTools.html
 .. _How To Setup Clang Tooling For LLVM: https://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 
+When you `configure the CMake build `_,
+make sure that you enable the ``clang`` and ``clang-tools-extra`` projects to
+build :program:`clang-tidy`.
+Because your new check will have associated documentation, you will also want to install
+`Sphinx `_ and enable it in the CMake configuration.
+To save build time of the core Clang libraries you may want to only enable the ``X86``
+target in the CMake configuration.
+
 
 The Directory Structure
 ---
@@ -215,11 +225,206 @@
 and `clang-tidy/google/ExplicitConstructorCheck.cpp
 `_).
 
+If you need to interact with macros or preprocessor directives, you will want to
+override the method ``registerPPCallbacks``.  The ``add_new_check.py`` script
+does not generate an override for this method in the starting point for your
+new check.
+
+If your check applies only under a specific set of language options, be sure
+to override the method ``isLanguageVersionSupported`` to reflect that.
+
+Check development tips
+--
+
+Writing your first check can be a daunting task, particularly if you are unfamiliar
+with the LLVM and Clang code bases.  Here are some suggestions for orienting yourself
+in the codebase and working on your check incrementally.
+
+Guide to useful documentation
+^
+
+Many of the support classes created for LLVM are used by Clang, such as `StringRef
+`_
+and `SmallVector `_.
+These and other commonly used classes are described in the `Important and useful LLVM APIs
+`_ and
+`Picking the Right Data Structure for the Task
+`_
+sections of the `LLVM Programmer's Manual
+`_.  You don't need to memorize all the
+details of these classes; the generated `doxygen documentation `_
+has everything if you need it.  In the header `LLVM/ADT/STLExtras.h
+`_ you'll find useful versions of the STL
+algorithms that operate on LLVM containers, such as `llvm::all_of
+`_.
+
+Clang is implemented on top of LLVM and introduces its own set of classes that you
+will interact with while writing your check.  When a check issues diagnostics and
+fix-its, these are associated with locations in the source code.  Source code locations,
+source files, ranges of source locations and the `SourceManager
+`_ class provide
+the mechanisms for describing such locations.  These and
+other topics are described in the `"Clang" CFE Internals Manual
+`_.  Whereas the doxygen generated
+documentation serves as a reference to the internals of Clang, this document serves
+as a guide to other developers.  Topics in that manual of interest to a check developer
+are:
+
+- `The Clang "Basic" Library
+  `_ for
+  information about diagnostics, fix-it hints and source locations.
+- `The Lexer and Preprocessor Library
+  `_
+  for information about tokens,

[PATCH] D117681: [RISCV] Add the policy operand for some masked RVV ternary IR intrinsics.

2022-01-25 Thread Zakk Chen via Phabricator via cfe-commits

khchen updated this revision to Diff 403117.
khchen added a comment.

rebase and address Craig's comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117681

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslidedown.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslideup.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vslidedown.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vslideup.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwmacc.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/test/CodeGen/RISCV/rvv/vfmacc.ll
  llvm/test/CodeGen/RISCV/rvv/vfmadd.ll
  llvm/test/CodeGen/RISCV/rvv/vfmsac.ll
  llvm/test/CodeGen/RISCV/rvv/vfmsub.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmacc.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmadd.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmsac.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmsub.ll
  llvm/test/CodeGen/RISCV/rvv/vfwmacc.ll
  llvm/test/CodeGen/RISCV/rvv/vfwmsac.ll
  llvm/test/CodeGen/RISCV/rvv/vfwnmacc.ll
  llvm/test/CodeGen/RISCV/rvv/vfwnmsac.ll
  llvm/test/CodeGen/RISCV/rvv/vmacc-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmacc-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vmadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vnmsac-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vnmsac-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vnmsub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vnmsub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vslidedown-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vslidedown-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vslideup-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vslideup-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vwmacc-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vwmacc-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vwmaccsu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vwmaccsu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vwmaccu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vwmaccu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vwmaccus-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vwmaccus-rv64.ll

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

[PATCH] D118095: [AVR][clang] Reject non assembly source files for the avr1 family

2022-01-25 Thread Ben Shi via Phabricator via cfe-commits

benshi001 updated this revision to Diff 403116.

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

https://reviews.llvm.org/D118095

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/AVR.cpp
  clang/lib/Driver/ToolChains/AVR.h
  clang/test/Driver/avr-mmcu.S
  clang/test/Driver/avr-mmcu.c

Index: clang/test/Driver/avr-mmcu.c
===
--- clang/test/Driver/avr-mmcu.c
+++ clang/test/Driver/avr-mmcu.c
@@ -1,12 +1,15 @@
 // A test for the propagation of the -mmcu option to -cc1 and -cc1as
 
-// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 -save-temps %s 2>&1 | FileCheck -check-prefix=CHECK0 %s
-// CHECK0: clang{{.*}} "-cc1" {{.*}} "-target-cpu" "attiny11"
-// CHECK0: clang{{.*}} "-cc1as" {{.*}} "-target-cpu" "attiny11"
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 %s -c 2>&1 | FileCheck -check-prefix=CHECKA %s
+// CHECKA: error: device 'attiny11' only supports assembly programming
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 -x assembler-with-cpp %s -c 2>&1 | FileCheck -check-prefix=CHECKB %s
+// CHECKB-NOT: error: device 'attiny11' only supports assembly programming
 
 // RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=at90s2313 -save-temps %s 2>&1 | FileCheck -check-prefix=CHECK1 %s
 // CHECK1: clang{{.*}} "-cc1" {{.*}} "-target-cpu" "at90s2313"
 // CHECK1: clang{{.*}} "-cc1as" {{.*}} "-target-cpu" "at90s2313"
+// CHECK1-NOT: error: device 'at90s2313' only supports assembly programming
 
 // RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=at90s8515 -save-temps %s 2>&1 | FileCheck -check-prefix=CHECK2 %s
 // CHECK2: clang{{.*}} "-cc1" {{.*}} "-target-cpu" "at90s8515"
Index: clang/test/Driver/avr-mmcu.S
===
--- /dev/null
+++ clang/test/Driver/avr-mmcu.S
@@ -0,0 +1,13 @@
+// A test for the supported language mode by different avr families.
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 %s -c 2>&1 | FileCheck -check-prefix=CHECKA %s
+// CHECKA-NOT: error: device 'attiny11' only supports assembly programming
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=attiny11 -x c++ %s -c 2>&1 | FileCheck -check-prefix=CHECKB %s
+// CHECKB: error: device 'attiny11' only supports assembly programming
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=at90s8515 %s -c 2>&1 | FileCheck -check-prefix=CHECKC %s
+// CHECKC-NOT: error: device 'at90s8515' only supports assembly programming
+
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=at90s8515 %s -x c++ -c 2>&1 | FileCheck -check-prefix=CHECKD %s
+// CHECKD-NOT: error: device 'at90s8515' only supports assembly programming
Index: clang/lib/Driver/ToolChains/AVR.h
===
--- clang/lib/Driver/ToolChains/AVR.h
+++ clang/lib/Driver/ToolChains/AVR.h
@@ -19,6 +19,8 @@
 namespace toolchains {
 
 class LLVM_LIBRARY_VISIBILITY AVRToolChain : public Generic_ELF {
+  std::string AVRMcu;
+
 public:
   AVRToolChain(const Driver , const llvm::Triple ,
const llvm::opt::ArgList );
Index: clang/lib/Driver/ToolChains/AVR.cpp
===
--- clang/lib/Driver/ToolChains/AVR.cpp
+++ clang/lib/Driver/ToolChains/AVR.cpp
@@ -12,6 +12,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/InputInfo.h"
 #include "clang/Driver/Options.h"
+#include "clang/Driver/Types.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -19,6 +20,7 @@
 #include "llvm/MC/SubtargetFeature.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
 
 using namespace clang::driver;
 using namespace clang::driver::toolchains;
@@ -311,24 +313,27 @@
 : Generic_ELF(D, Triple, Args), LinkStdlib(false) {
   GCCInstallation.init(Triple, Args);
 
+  // Save the CPU name for further checks.
+  AVRMcu = getCPUName(D, Args, Triple);
+
   // Only add default libraries if the user hasn't explicitly opted out.
   if (!Args.hasArg(options::OPT_nostdlib) &&
   !Args.hasArg(options::OPT_nodefaultlibs) &&
+  !Args.hasArg(options::OPT_S /* does not apply when not linking */) &&
   !Args.hasArg(options::OPT_c /* does not apply when not linking */)) {
-std::string CPU = getCPUName(D, Args, Triple);
 
-if (CPU.empty()) {
+if (AVRMcu.empty()) {
   // We cannot link any standard libraries without an MCU specified.
   D.Diag(diag::warn_drv_avr_mcu_not_specified);
 } else {
-  Optional FamilyName = GetMCUFamilyName(CPU);
+  Optional FamilyName = GetMCUFamilyName(AVRMcu);
   Optional AVRLibcRoot = findAVRLibcInstallation();
 
   if (!FamilyName.hasValue()) {
 // We do not have an entry for this CPU in

[PATCH] D118110: [CMake] [Clang] Add CMake build option to specify long double format on PowerPC

2022-01-25 Thread Qiu Chaofan via Phabricator via cfe-commits

qiucf added a comment.

> It is probably not worth the effort since there won't be that many test cases 
> that test the front end's IR generation for long double, but there should be 
> a way to set up lit to know the default through its configuration files.

Yes, lit doesn't know about it. But lit can't do things in IR test like 
`#ifdef` in C nor change default semantics of clang, so it seems not able to 
help in such cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118110

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

[PATCH] D118110: [CMake] [Clang] Add CMake build option to specify long double format on PowerPC

2022-01-25 Thread Qiu Chaofan via Phabricator via cfe-commits

qiucf updated this revision to Diff 403114.
qiucf marked 3 inline comments as done.
qiucf edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118110

Files:
  clang/CMakeLists.txt
  clang/include/clang/Config/config.h.cmake
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Analysis/builtin_signbit.cpp
  clang/test/Driver/ppc-abi.c

Index: clang/test/Driver/ppc-abi.c
===
--- clang/test/Driver/ppc-abi.c
+++ clang/test/Driver/ppc-abi.c
@@ -63,9 +63,6 @@
 // CHECK-ELFv1-IEEE: "-mabi=ieeelongdouble"
 // CHECK-ELFv1-IEEE: "-target-abi" "elfv1"
 
-// Check -mabi=ibmlongdouble is the default.
-// RUN: %clang -target powerpc64le-linux-gnu %s -### 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-ELFv2-IBM128 %s
 // RUN: %clang -target powerpc64le-linux-gnu %s -mabi=ibmlongdouble -### 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-ELFv2-IBM128 %s
 
Index: clang/test/Analysis/builtin_signbit.cpp
===
--- clang/test/Analysis/builtin_signbit.cpp
+++ clang/test/Analysis/builtin_signbit.cpp
@@ -1,6 +1,9 @@
-// RUN: %clang -target powerpc-linux-gnu -emit-llvm -S -O0 %s -o - | FileCheck %s --check-prefix=CHECK-BE --check-prefix=CHECK
-// RUN: %clang -target powerpc64-linux-gnu   -emit-llvm -S -O0 %s -o - | FileCheck %s --check-prefix=CHECK-BE --check-prefix=CHECK
-// RUN: %clang -target powerpc64le-linux-gnu -emit-llvm -S -O0 %s -o - | FileCheck %s --check-prefix=CHECK-LE --check-prefix=CHECK
+// RUN: %clang -target powerpc-linux-gnu -emit-llvm -S -mabi=ibmlongdouble \
+// RUN:   -O0 %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang -target powerpc64-linux-gnu -emit-llvm -S -mabi=ibmlongdouble \
+// RUN:   -O0 %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang -target powerpc64le-linux-gnu -emit-llvm -S -mabi=ibmlongdouble \
+// RUN:   -O0 %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-LE
 
 bool b;
 double d = -1.0;
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2061,7 +2061,7 @@
 }
   }
 
-  bool IEEELongDouble = false;
+  bool IEEELongDouble = getToolChain().defaultToIEEELongDouble();
   for (const Arg *A : Args.filtered(options::OPT_mabi_EQ)) {
 StringRef V = A->getValue();
 if (V == "ieeelongdouble")
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -109,6 +109,10 @@
   return ENABLE_X86_RELAX_RELOCATIONS;
 }
 
+bool ToolChain::defaultToIEEELongDouble() const {
+  return PPC_LINUX_DEFAULT_IEEELONGDOUBLE && getTriple().isOSLinux();
+}
+
 SanitizerArgs
 ToolChain::getSanitizerArgs(const llvm::opt::ArgList ) const {
   SanitizerArgs SanArgs(*this, JobArgs, !SanitizerArgsChecked);
Index: clang/include/clang/Driver/ToolChain.h
===
--- clang/include/clang/Driver/ToolChain.h
+++ clang/include/clang/Driver/ToolChain.h
@@ -409,6 +409,9 @@
   /// Check whether to enable x86 relax relocations by default.
   virtual bool useRelaxRelocations() const;
 
+  /// Check whether use IEEE binary128 as long double format by default.
+  bool defaultToIEEELongDouble() const;
+
   /// GetDefaultStackProtectorLevel - Get the default stack protector level for
   /// this tool chain.
   virtual LangOptions::StackProtectorMode
Index: clang/include/clang/Config/config.h.cmake
===
--- clang/include/clang/Config/config.h.cmake
+++ clang/include/clang/Config/config.h.cmake
@@ -78,6 +78,9 @@
 /* enable x86 relax relocations by default */
 #cmakedefine01 ENABLE_X86_RELAX_RELOCATIONS
 
+/* Enable IEEE binary128 as default long double format on PowerPC Linux. */
+#cmakedefine01 PPC_LINUX_DEFAULT_IEEELONGDOUBLE
+
 /* Enable each functionality of modules */
 #cmakedefine01 CLANG_ENABLE_ARCMT
 #cmakedefine01 CLANG_ENABLE_OBJC_REWRITER
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -237,6 +237,9 @@
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL
 "enable x86 relax relocations by default")
 
+set(PPC_LINUX_DEFAULT_IEEELONGDOUBLE OFF CACHE BOOL
+"Enable IEEE binary128 as default long double format on PowerPC Linux.")
+
 set(CLANG_SPAWN_CC1 OFF CACHE BOOL
 "Whether clang should use a new process for the CC1 invocation")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D118120: [C++20] [Modules] Only check decls under namespace scope in CheckRedeclarationExported

2022-01-25 Thread Chuanqi Xu 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 rG5c1f7b296ac0: [C++20] [Modules] Only check decls under 
namespace scope in… (authored by ChuanqiXu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118120

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CXX/module/module.interface/p6.cpp


Index: clang/test/CXX/module/module.interface/p6.cpp
===
--- clang/test/CXX/module/module.interface/p6.cpp
+++ clang/test/CXX/module/module.interface/p6.cpp
@@ -91,3 +91,24 @@
 T TemplVar; // expected-note {{previous declaration is here}}
 export template 
 T TemplVar; // expected-error {{cannot export redeclaration 'TemplVar' here 
since the previous declaration is not exported}}
+
+// Test the compiler wouldn't complain about the redeclaration of friend in 
exported class.
+namespace Friend {
+template 
+class bar;
+class gua;
+template 
+void hello();
+void hi();
+export class foo;
+bool operator<(const foo , const foo );
+export class foo {
+  template 
+  friend class bar;
+  friend class gua;
+  template 
+  friend void hello();
+  friend void hi();
+  friend bool operator<(const foo , const foo );
+};
+} // namespace Friend
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -1635,6 +1635,19 @@
 // A redeclaration of an entity X is implicitly exported if X was introduced by
 // an exported declaration; otherwise it shall not be exported.
 bool Sema::CheckRedeclarationExported(NamedDecl *New, NamedDecl *Old) {
+  // [module.interface]p1:
+  // An export-declaration shall inhabit a namespace scope.
+  //
+  // So it is meaningless to talk about redeclaration which is not at namespace
+  // scope.
+  if (!New->getLexicalDeclContext()
+   ->getNonTransparentContext()
+   ->isFileContext() ||
+  !Old->getLexicalDeclContext()
+   ->getNonTransparentContext()
+   ->isFileContext())
+return false;
+
   bool IsNewExported = New->isInExportDeclContext();
   bool IsOldExported = Old->isInExportDeclContext();
 


Index: clang/test/CXX/module/module.interface/p6.cpp
===
--- clang/test/CXX/module/module.interface/p6.cpp
+++ clang/test/CXX/module/module.interface/p6.cpp
@@ -91,3 +91,24 @@
 T TemplVar; // expected-note {{previous declaration is here}}
 export template 
 T TemplVar; // expected-error {{cannot export redeclaration 'TemplVar' here since the previous declaration is not exported}}
+
+// Test the compiler wouldn't complain about the redeclaration of friend in exported class.
+namespace Friend {
+template 
+class bar;
+class gua;
+template 
+void hello();
+void hi();
+export class foo;
+bool operator<(const foo , const foo );
+export class foo {
+  template 
+  friend class bar;
+  friend class gua;
+  template 
+  friend void hello();
+  friend void hi();
+  friend bool operator<(const foo , const foo );
+};
+} // namespace Friend
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -1635,6 +1635,19 @@
 // A redeclaration of an entity X is implicitly exported if X was introduced by
 // an exported declaration; otherwise it shall not be exported.
 bool Sema::CheckRedeclarationExported(NamedDecl *New, NamedDecl *Old) {
+  // [module.interface]p1:
+  // An export-declaration shall inhabit a namespace scope.
+  //
+  // So it is meaningless to talk about redeclaration which is not at namespace
+  // scope.
+  if (!New->getLexicalDeclContext()
+   ->getNonTransparentContext()
+   ->isFileContext() ||
+  !Old->getLexicalDeclContext()
+   ->getNonTransparentContext()
+   ->isFileContext())
+return false;
+
   bool IsNewExported = New->isInExportDeclContext();
   bool IsOldExported = Old->isInExportDeclContext();
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 5c1f7b2 - [C++20] [Modules] Only check decls under namespace scope in CheckRedeclarationExported

2022-01-25 Thread Chuanqi Xu via cfe-commits


Author: Chuanqi Xu
Date: 2022-01-26T10:54:52+08:00
New Revision: 5c1f7b296ac0dddeca02891976e6ab5cfc006719

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

LOG: [C++20] [Modules] Only check decls under namespace scope in 
CheckRedeclarationExported

Since only the decls inhabit in a namespace scope could be exported, it
is not meaningful to check it in CheckRedeclarationExported, which
implements [module.interface]/p6.

Reviewed By: urnathan

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

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/test/CXX/module/module.interface/p6.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 673631a12eee0..7c5f6b318e973 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -1635,6 +1635,19 @@ bool Sema::CheckRedeclarationModuleOwnership(NamedDecl 
*New, NamedDecl *Old) {
 // A redeclaration of an entity X is implicitly exported if X was introduced by
 // an exported declaration; otherwise it shall not be exported.
 bool Sema::CheckRedeclarationExported(NamedDecl *New, NamedDecl *Old) {
+  // [module.interface]p1:
+  // An export-declaration shall inhabit a namespace scope.
+  //
+  // So it is meaningless to talk about redeclaration which is not at namespace
+  // scope.
+  if (!New->getLexicalDeclContext()
+   ->getNonTransparentContext()
+   ->isFileContext() ||
+  !Old->getLexicalDeclContext()
+   ->getNonTransparentContext()
+   ->isFileContext())
+return false;
+
   bool IsNewExported = New->isInExportDeclContext();
   bool IsOldExported = Old->isInExportDeclContext();
 

diff  --git a/clang/test/CXX/module/module.interface/p6.cpp 
b/clang/test/CXX/module/module.interface/p6.cpp
index a696851ccbff4..070aa62f5800a 100644
--- a/clang/test/CXX/module/module.interface/p6.cpp
+++ b/clang/test/CXX/module/module.interface/p6.cpp
@@ -91,3 +91,24 @@ template 
 T TemplVar; // expected-note {{previous declaration is here}}
 export template 
 T TemplVar; // expected-error {{cannot export redeclaration 'TemplVar' here 
since the previous declaration is not exported}}
+
+// Test the compiler wouldn't complain about the redeclaration of friend in 
exported class.
+namespace Friend {
+template 
+class bar;
+class gua;
+template 
+void hello();
+void hi();
+export class foo;
+bool operator<(const foo , const foo );
+export class foo {
+  template 
+  friend class bar;
+  friend class gua;
+  template 
+  friend void hello();
+  friend void hi();
+  friend bool operator<(const foo , const foo );
+};
+} // namespace Friend



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

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

2022-01-25 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

> In addition to the ABI compatibility concern, IMO, GCC's behavior here is 
> better and more user friendly:
>
> - C++ classes have methods
> - calling a method on a field takes the address of a field

I mean, this argument is hardly limited to non-POD types.  I suppose you could 
argue that with trivially-copyable types, you could at least copy the object 
somewhere else before calling the method.  But then the condition ought to be 
"has a trivial, non-deleted copy/move constructor" rather than "POD for the 
purposes of the ABI."

Well, anyway, as always, GCC is entitled to set the ABI for the platforms on 
which it is the system compiler.  I assume the POD definition actually comes 
from C++03 and not C++98, in which IIRC member pointers were non-trivial.  
Darwin will opt out, yes, and I think we should assume that PS4 will as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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

[PATCH] D117972: [PowerPC] Fix SSE translation on FreeBSD

2022-01-25 Thread Piotr Kubaj via Phabricator via cfe-commits

pkubaj updated this revision to Diff 403103.
pkubaj added a comment.

Address review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117972

Files:
  clang/lib/Headers/ppc_wrappers/mm_malloc.h


Index: clang/lib/Headers/ppc_wrappers/mm_malloc.h
===
--- clang/lib/Headers/ppc_wrappers/mm_malloc.h
+++ clang/lib/Headers/ppc_wrappers/mm_malloc.h
@@ -19,7 +19,7 @@
 #ifndef __cplusplus
 extern int posix_memalign (void **, size_t, size_t);
 #else
-extern "C" int posix_memalign (void **, size_t, size_t) throw ();
+extern "C" int posix_memalign (void **, size_t, size_t);
 #endif
 
 static __inline void *


Index: clang/lib/Headers/ppc_wrappers/mm_malloc.h
===
--- clang/lib/Headers/ppc_wrappers/mm_malloc.h
+++ clang/lib/Headers/ppc_wrappers/mm_malloc.h
@@ -19,7 +19,7 @@
 #ifndef __cplusplus
 extern int posix_memalign (void **, size_t, size_t);
 #else
-extern "C" int posix_memalign (void **, size_t, size_t) throw ();
+extern "C" int posix_memalign (void **, size_t, size_t);
 #endif
 
 static __inline void *
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118199: [AArch64] ACLE feature macro for Armv8.8-A MOPS

2022-01-25 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers added a comment.

> This patch supersedes the one from https://reviews.llvm.org/D116160.

Can that one be abandoned then?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118199

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

[PATCH] D117972: [PowerPC] Fix SSE translation on FreeBSD

2022-01-25 Thread Qiu Chaofan via Phabricator via cfe-commits

qiucf added a comment.

Thanks for the fix!




Comment at: clang/lib/Headers/ppc_wrappers/mm_malloc.h:22
 #else
+#if defined(__linux__)
 extern "C" int posix_memalign (void **, size_t, size_t) throw ();

Actually I just realised we don't need this guard, Clang already has a hack for 
this: previous declaration in system header has `throw ()` but later doesn't is 
okay.

See x86's header 
https://github.com/llvm/llvm-project/blob/510710d0374908e3e2bd37f9a32065da423a7e4c/clang/lib/Headers/mm_malloc.h#L21-L25
 .

I tested on Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117972

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

[PATCH] D117295: [clang][sema] Allow unnamed decls in C++20 module export{} blocks

2022-01-25 Thread Chuanqi Xu via Phabricator via cfe-commits

ChuanqiXu added a comment.

Oh, it looks like we couldn't go on since the part of PR1766R1 is not adopted: 
https://github.com/cplusplus/draft/issues/5237


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

https://reviews.llvm.org/D117295

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

[PATCH] D112493: [OpenMP][NFCI] Record the location string as part of the ident_t

2022-01-25 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert abandoned this revision.
jdoerfert added a comment.

Committed partially as 944aa0421cb7da3aa764b2a108ea25ef8bceb979 
, rest is 
NFC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112493

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

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

2022-01-25 Thread Zakk Chen 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 rG9273378b8576: [RISCV] Add the passthru operand for RVV 
nomask load intrinsics. (authored by khchen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117647

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vloxei.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vluxei.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vleff.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxei.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlse.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxei.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp
  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.h
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/test/CodeGen/RISCV/rvv/rv32-vsetvli-intrinsics.ll
  llvm/test/CodeGen/RISCV/rvv/rv64-vsetvli-intrinsics.ll
  llvm/test/CodeGen/RISCV/rvv/rvv-out-arguments.ll
  llvm/test/CodeGen/RISCV/rvv/unmasked-tu.ll
  llvm/test/CodeGen/RISCV/rvv/vle-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vle-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vleff-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vleff-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vloxei-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vloxei-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vlse-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vlse-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vluxei-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vluxei-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.ll
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.mir
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert.ll
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert.mir

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

[PATCH] D118205: [ASan] Added a unit test for D118184.

2022-01-25 Thread Kirill Stoimenov 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 rG69da422bdaa6: [ASan] Added a unit test for D118184. 
(authored by kstoimenov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118205

Files:
  clang/test/Driver/sanitizer-ld.c


Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -24,6 +24,24 @@
 //
 // CHECK-ASAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.asan-x86_64
 
+// RUN: %clang -fsanitize=address %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-EXECUTABLE-LINUX %s
+//
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan-x86_64
+
+// RUN: %clang -fsanitize=address -shared %s -### -o %t.o 2>&1  \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-SHARED-LINUX %s
+//
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan-x86_64
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address 
-shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \


Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -24,6 +24,24 @@
 //
 // CHECK-ASAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.asan-x86_64
 
+// RUN: %clang -fsanitize=address %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-EXECUTABLE-LINUX %s
+//
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan-x86_64
+
+// RUN: %clang -fsanitize=address -shared %s -### -o %t.o 2>&1  \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-SHARED-LINUX %s
+//
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan-x86_64
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address -shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 69da422 - [ASan] Added a unit test for D118184.

2022-01-25 Thread Kirill Stoimenov via cfe-commits


Author: Kirill Stoimenov
Date: 2022-01-26T01:20:02Z
New Revision: 69da422bdaa684fbd14c95b06f40ac57910642d9

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

LOG: [ASan] Added a unit test for D118184.

To make sure the the libraries are there for executable and not there for DSOs.

Reviewed By: kda

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

Added: 


Modified: 
clang/test/Driver/sanitizer-ld.c

Removed: 




diff  --git a/clang/test/Driver/sanitizer-ld.c 
b/clang/test/Driver/sanitizer-ld.c
index ea8c49f2384ad..d96cddb31d687 100644
--- a/clang/test/Driver/sanitizer-ld.c
+++ b/clang/test/Driver/sanitizer-ld.c
@@ -24,6 +24,24 @@
 //
 // CHECK-ASAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.asan-x86_64
 
+// RUN: %clang -fsanitize=address %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-EXECUTABLE-LINUX %s
+//
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan-x86_64
+
+// RUN: %clang -fsanitize=address -shared %s -### -o %t.o 2>&1  \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-SHARED-LINUX %s
+//
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan-x86_64
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address 
-shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \



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

[PATCH] D118205: [ASan] Added a unit test for D118184.

2022-01-25 Thread Kevin Athey via Phabricator via cfe-commits

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

thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118205

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

[PATCH] D118205: [ASan] Added a unit test for D118184.

2022-01-25 Thread Kirill Stoimenov via Phabricator via cfe-commits

kstoimenov updated this revision to Diff 403083.
kstoimenov added a comment.

Fixed order.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118205

Files:
  clang/test/Driver/sanitizer-ld.c


Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -24,6 +24,24 @@
 //
 // CHECK-ASAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.asan-x86_64
 
+// RUN: %clang -fsanitize=address %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-EXECUTABLE-LINUX %s
+//
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan-x86_64
+
+// RUN: %clang -fsanitize=address -shared %s -### -o %t.o 2>&1  \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-SHARED-LINUX %s
+//
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan-x86_64
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address 
-shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \


Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -24,6 +24,24 @@
 //
 // CHECK-ASAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.asan-x86_64
 
+// RUN: %clang -fsanitize=address %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-EXECUTABLE-LINUX %s
+//
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan-x86_64
+
+// RUN: %clang -fsanitize=address -shared %s -### -o %t.o 2>&1  \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-SHARED-LINUX %s
+//
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan-x86_64
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address -shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118205: [ASan] Added a unit test for D118184.

2022-01-25 Thread Kirill Stoimenov via Phabricator via cfe-commits

kstoimenov created this revision.
kstoimenov added a reviewer: kda.
kstoimenov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

To make sure the the libraries are there for executable and not there for DSOs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118205

Files:
  clang/test/Driver/sanitizer-ld.c


Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -24,6 +24,24 @@
 //
 // CHECK-ASAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.asan-x86_64
 
+// RUN: %clang -fsanitize=address %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-EXECUTABLE-LINUX %s
+//
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan-x86_64
+
+// RUN: %clang -fsanitize=address -shared %s -### -o %t.o 2>&1  \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-SHARED-LINUX %s
+//
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan-x86_64
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan_static-x86_64
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address 
-shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \


Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -24,6 +24,24 @@
 //
 // CHECK-ASAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.asan-x86_64
 
+// RUN: %clang -fsanitize=address %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-EXECUTABLE-LINUX %s
+//
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan_static-x86_64
+// CHECK-ASAN-EXECUTABLE-LINUX: libclang_rt.asan-x86_64
+
+// RUN: %clang -fsanitize=address -shared %s -### -o %t.o 2>&1  \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-SHARED-LINUX %s
+//
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan-x86_64
+// CHECK-ASAN-SHARED-LINUX-NOT: libclang_rt.asan_static-x86_64
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address -shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

2022-01-25 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:428
+const Driver , StringRef TargetTriple, const ArgList ,
+llvm::Triple *UnnormalizedTriple = nullptr, StringRef DarwinArchName = "") 
{
   // FIXME: Already done in Compilation *Driver::BuildCompilation

phosek wrote:
> I find the name `UnnormalizedTriple` a bit confusing as it may imply that 
> there's some "un-normalization" process involved. I'd prefer using a 
> `TargetTriple` to refer to "triple given by the user (via the `--target=` 
> option)" and `NormalizedTriple` as "normalized triple".
`llvm::Triple Target(llvm::Triple::normalize(TargetTriple));` refers to the 
normalized triple is references in many places. Having a `TargetTriple` may 
cause confusion.

I also want to avoid renaming `Target` (referenced in too many places) to 
minimize the diff. 



Comment at: clang/lib/Driver/Driver.cpp:1203-1206
+  if (Normalized.isOSFuchsia())
+TargetTriple = Normalized.str();
+  else
+TargetTriple = Unnormalized.str();

phosek wrote:
> I really think this logic belongs to `clang::driver::toolchains::Fuchsia`. 
> Moving it there is going to require some changes to how toolchains are 
> instantiated, and should thus be done as a separate change, but doing so 
> could also help us cleanup other special case logic like that exists in 
> `Driver` like 
> https://github.com/llvm/llvm-project/blob/8ba9c794feb30cd969b9776c39873def10c51bff/clang/lib/Driver/Driver.cpp#L576.
I agree. The change seems involved so I do not do it here...

Moving `toolchains::MinGW::fixTripleArch(D, Target, Args);` to the 
toolchain-specific file will indeed be nice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D118084: [CUDA, NVPTX] Pass byval aggregates directly

2022-01-25 Thread Artem Belevich via Phabricator via cfe-commits

tra added a comment.

In D118084#3271073 , @jdoerfert wrote:

> @lebedev.ri wanted to teach SROA how to deal with dynamic indices before, 
> IIRC. It seems to be generally useful.

Interesting. I'd like to hear more.

> This patch can wait till then?

Yes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118084

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

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

2022-01-25 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added a comment.

No worries! Thanks for the reply.

I use Debian and want it to work well and support the 
`-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on` direction.
Currently, `-DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-linux-gnu` (Debian style 
multiarch triple, so no `-unknown` or `-pc`) does not work for libc++ and some 
runtime libraries.
This led to the revert of D107799  which I 
think really unfortunate because runtime builds encourage 
`LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`, which de facto deviate from the regular 
builds and llvm-project has to support two hierarchies.

---

Here is `-DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-unknown-linux-gnu`:

  cmake -GNinja -Hllvm -B/tmp/out/custom1 -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_CROSSCOMPILING=on -DCMAKE_INSTALL_PREFIX=/tmp/opt/aarch64 
-DLLVM_TARGETS_TO_BUILD=AArch64 
-DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-unknown-linux-gnu 
-DLLVM_TARGET_ARCH=AArch64 -DLLVM_ENABLE_PROJECTS='clang;lld' 
-DLLVM_ENABLE_RUNTIMES='compiler-rt;l
  ibcxx;libcxxabi;libunwind'
  ninja -C /tmp/out/custom1 lld cxx cxxabi unwind builtins
  
  /tmp/out/custom1/bin/clang++ -c -stdlib=libc++ a.cc; 
/tmp/out/custom1/bin/clang++ -fuse-ld=lld --dyld-prefix=/usr/aarch64-linux-gnu 
--unwindlib=libunwind --rtlib=compiler-rt -nostdlib++ -pthread -static-libgcc 
a.o 
-Wl,--push-state,-Bstatic,-lc++,-lc++abi,--pop-state,-rpath=/usr/aarch64-linux-gnu/lib
 -ldl -o a  # works
  ./a  # runs if you have binfmt_misc and qemu-aarch64-static

If I change the CMake line to use 
`-DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-linux-gnu`, libc++ compiles do not work:

  % /tmp/out/custom1/bin/clang++ -fuse-ld=lld 
--dyld-prefix=/usr/aarch64-linux-gnu -Wl,-rpath=/usr/aarch64-linux-gnu/lib a.cc 
-o a
  % ./a  # works
  
  % /tmp/out/custom1/bin/clang++ -c -stdlib=libc++ a.cc
  In file included from a.cc:1:
  In file included from /tmp/out/custom1/bin/../include/c++/v1/stdio.h:101:
  /tmp/out/custom1/bin/../include/c++/v1/__config:13:10: fatal error: 
'__config_site' file not found
  #include <__config_site>
   ^~~
  1 error generated.

`/tmp/out/custom1/include/aarch64-linux-gnu/c++/v1/` is not in the search path.

With this change, the command will succeed. Here are the search paths for 
includes and libraries:

  % /tmp/out/custom1/bin/clang++ -fuse-ld=lld -stdlib=libc++ -v a.cc |& sed -E 
's/ "?-[iIL]/\n&/g'
  clang version 14.0.0
  Target: aarch64-unknown-linux-gnu
  Thread model: posix
  InstalledDir: /tmp/out/custom1/bin
  Found candidate GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/11
  Selected GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/11
  Candidate multilib: .;@m64
  Selected multilib: .;@m64
   "/tmp/out/custom1/bin/clang-14" -cc1 -triple aarch64-unknown-linux-gnu 
-emit-obj -mrelax-all --mrelax-relocations -disable-free 
-clear-ast-before-backend -disable-llvm-verifier -discard-value-names 
-main-file-name a.cc -mrelocation-model static -mframe-pointer=non-leaf 
-fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases 
-funwind-tables=2 -target-cpu generic -target-feature +neon -target-feature 
+v8a -target-abi aapcs -fallow-half-arguments-and-returns -mllvm 
-treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -v 
-fcoverage-compilation-dir=/tmp/c -resource-dir 
/tmp/out/custom1/lib/clang/14.0.0
   -internal-isystem /tmp/out/custom1/bin/../include/aarch64-linux-gnu/c++/v1
   -internal-isystem /tmp/out/custom1/bin/../include/c++/v1
   -internal-isystem /tmp/out/custom1/lib/clang/14.0.0/include
   -internal-isystem /usr/local/include
   -internal-isystem 
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/include
   -internal-externc-isystem /include
   -internal-externc-isystem /usr/include -fdeprecated-macro 
-fdebug-compilation-dir=/tmp/c -ferror-limit 19 -fno-signed-char 
-fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -target-feature 
+outline-atomics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/a-ffa089.o -x 
c++ a.cc
  clang -cc1 version 14.0.0 based upon LLVM 14.0.0git default target 
aarch64-linux-gnu
  ignoring nonexistent directory "/include"
  #include "..." search starts here:
  #include <...> search starts here:
   /tmp/out/custom1/bin/../include/aarch64-linux-gnu/c++/v1
   /tmp/out/custom1/bin/../include/c++/v1
   /tmp/out/custom1/lib/clang/14.0.0/include
   /usr/local/include
   /usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/include
   /usr/include
  End of search list.
   "/tmp/out/custom1/bin/ld.lld" -EL --eh-frame-hdr -m aarch64linux 
-dynamic-linker /lib/ld-linux-aarch64.so.1 -o a.out 
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/lib/crt1.o
 
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/lib/crti.o
 /usr/lib/gcc-cross/aarch64-linux-gnu/11/crtbegin.o
   -L/tmp/out/custom1/bin/../lib/aarch64-linux-gnu
   -L/usr/lib/gcc-cross/aarch64-linux-gnu/11

[PATCH] D118084: [CUDA, NVPTX] Pass byval aggregates directly

2022-01-25 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added a subscriber: lebedev.ri.
jdoerfert added a comment.

@lebedev.ri wanted to teach SROA how to deal with dynamic indices before, IIRC. 
It seems to be generally useful. This patch can wait till then?




Comment at: clang/lib/CodeGen/TargetInfo.cpp:7193
  EIT->getNumBits() > 64))
   return getNaturalAlignIndirect(Ty, /* byval */ true);
   }

tra wrote:
> jdoerfert wrote:
> > When is this ever hit and should we not disable byval here too while we are 
> > at it?
> Basically it's saying "pass as byval pointer if it's an int that's larger 
> than what we can lower".
> Yes, I think passing such integer directly would make sense.
> 
> We may hit this if clang wants to pass `__i128` (do larger int types exist in 
> clang?). 
> I think (some of) this may be a leftover from the days when we didn't support 
> i128 in CUDA/NVPTX. I think we do now.
We have larger types, I somewhat doubt using them will work properly everywhere 
though.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118084

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

[PATCH] D118084: [CUDA, NVPTX] Pass byval aggregates directly

2022-01-25 Thread Artem Belevich via Phabricator via cfe-commits

tra planned changes to this revision.
tra added a comment.

Getting rid of byval helps getting rid of locals in quite a few places, but 
runs into a new problem. 

Looks like this change does have unexpected side-effects.
When we need to dynamically index into a struct passed directly, there's no 
easy way to do it as `extractvalue` only supports constant indices. 
With `byval` aggregates LLVM uses GEP which does allow using dynamic indexing. 
Alloca would only show up after `nvptx-lower-args` pass and that by that time 
IR would often be simple enough to eliminate that alloca. 
Now, clang generates  a local copy early on and, indexes into it dynamically 
with GEP... and then LLVM fails to eliminate the local copy because SROA fails 
to deal with dynamic indices and that in turn prevents IR optimizations that 
were possible without alloca.
https://github.com/llvm/llvm-project/issues/51734

That's rather unfortunate. This regression is serious enough to be a 
showstopper for my use case.

Comment at: clang/lib/CodeGen/TargetInfo.cpp:7193
  EIT->getNumBits() > 64))
   return getNaturalAlignIndirect(Ty, /* byval */ true);
   }

jdoerfert wrote:
> When is this ever hit and should we not disable byval here too while we are 
> at it?
Basically it's saying "pass as byval pointer if it's an int that's larger than 
what we can lower".
Yes, I think passing such integer directly would make sense.

We may hit this if clang wants to pass `__i128` (do larger int types exist in 
clang?). 
I think (some of) this may be a leftover from the days when we didn't support 
i128 in CUDA/NVPTX. I think we do now.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118084

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

[PATCH] D117262: [NFC] Store Address's alignment into PointerIntPairs

2022-01-25 Thread Arthur Eubanks via Phabricator via cfe-commits

aeubanks updated this revision to Diff 403070.
aeubanks added a comment.

only use PointerIntPair when alignof(Value*) >= 8


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117262

Files:
  clang/lib/CodeGen/Address.h

Index: clang/lib/CodeGen/Address.h
===
--- clang/lib/CodeGen/Address.h
+++ clang/lib/CodeGen/Address.h
@@ -14,30 +14,79 @@
 #ifndef LLVM_CLANG_LIB_CODEGEN_ADDRESS_H
 #define LLVM_CLANG_LIB_CODEGEN_ADDRESS_H
 
-#include "llvm/IR/Constants.h"
 #include "clang/AST/CharUnits.h"
+#include "llvm/ADT/PointerIntPair.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/Support/MathExtras.h"
 
 namespace clang {
 namespace CodeGen {
 
-/// An aligned address.
-class Address {
+namespace {
+// We try to save some space by using 6 bits over two PointerIntPairs to store
+// the alignment. However, some arches don't support 3 bits in a PointerIntPair
+// so we fallback to storing the alignment separately.
+template = 8> class AddressImpl {};
+
+template  class AddressImpl {
   llvm::Value *Pointer;
   llvm::Type *ElementType;
   CharUnits Alignment;
 
+public:
+  AddressImpl(llvm::Value *Pointer, llvm::Type *ElementType,
+  CharUnits Alignment)
+  : Pointer(Pointer), ElementType(ElementType), Alignment(Alignment) {}
+  llvm::Value *getPointer() const { return Pointer; }
+  llvm::Type *getElementType() const { return ElementType; }
+  CharUnits getAlignment() const { return Alignment; }
+};
+
+template  class AddressImpl {
+  // Int portion stores upper 3 bits of the log of the alignment.
+  llvm::PointerIntPair Pointer;
+  // Int portion stores lower 3 bits of the log of the alignment.
+  llvm::PointerIntPair ElementType;
+
+public:
+  AddressImpl(llvm::Value *Pointer, llvm::Type *ElementType,
+  CharUnits Alignment)
+  : Pointer(Pointer), ElementType(ElementType) {
+if (Alignment.isZero())
+  return;
+// Currently the max supported alignment is much less than 1 << 63 and is
+// guaranteed to be a power of 2, so we can store the log of the alignment
+// into 6 bits.
+assert(Alignment.isPowerOfTwo() && "Alignment cannot be zero");
+auto AlignLog = llvm::Log2_64(Alignment.getQuantity());
+assert(AlignLog < (1 << 6) && "cannot fit alignment into 6 bits");
+this->Pointer.setInt(AlignLog >> 3);
+this->ElementType.setInt(AlignLog & 7);
+  }
+  llvm::Value *getPointer() const { return Pointer.getPointer(); }
+  llvm::Type *getElementType() const { return ElementType.getPointer(); }
+  CharUnits getAlignment() const {
+unsigned AlignLog = (Pointer.getInt() << 3) | ElementType.getInt();
+return CharUnits::fromQuantity(1 << AlignLog);
+  }
+};
+} // namespace
+
+/// An aligned address.
+class Address {
+  AddressImpl A;
+
 protected:
-  Address(std::nullptr_t) : Pointer(nullptr), ElementType(nullptr) {}
+  Address(std::nullptr_t) : A(nullptr, nullptr, CharUnits::Zero()) {}
 
 public:
-  Address(llvm::Value *pointer, llvm::Type *elementType, CharUnits alignment)
-  : Pointer(pointer), ElementType(elementType), Alignment(alignment) {
-assert(pointer != nullptr && "Pointer cannot be null");
-assert(elementType != nullptr && "Element type cannot be null");
-assert(llvm::cast(pointer->getType())
-   ->isOpaqueOrPointeeTypeMatches(elementType) &&
+  Address(llvm::Value *Pointer, llvm::Type *ElementType, CharUnits Alignment)
+  : A(Pointer, ElementType, Alignment) {
+assert(Pointer != nullptr && "Pointer cannot be null");
+assert(ElementType != nullptr && "Element type cannot be null");
+assert(llvm::cast(Pointer->getType())
+   ->isOpaqueOrPointeeTypeMatches(ElementType) &&
"Incorrect pointer element type");
-assert(!alignment.isZero() && "Alignment cannot be zero");
   }
 
   // Deprecated: Use constructor with explicit element type instead.
@@ -46,11 +95,11 @@
 Alignment) {}
 
   static Address invalid() { return Address(nullptr); }
-  bool isValid() const { return Pointer != nullptr; }
+  bool isValid() const { return A.getPointer() != nullptr; }
 
   llvm::Value *getPointer() const {
 assert(isValid());
-return Pointer;
+return A.getPointer();
   }
 
   /// Return the type of the pointer value.
@@ -61,7 +110,7 @@
   /// Return the type of the values stored in this address.
   llvm::Type *getElementType() const {
 assert(isValid());
-return ElementType;
+return A.getElementType();
   }
 
   /// Return the address space that this address resides in.
@@ -77,19 +126,19 @@
   /// Return the alignment of this pointer.
   CharUnits getAlignment() const {
 assert(isValid());
-return Alignment;
+return A.getAlignment();
   }
 
   /// Return address with different pointer, but same element type and
   /// alignment.
   Address withPointer(llvm::Value *NewPointer) const {
-

[PATCH] D118184: [ASan] Not linking asan_static library for DSO.

2022-01-25 Thread Kirill Stoimenov 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 rGcf730d8ce134: [ASan] Not linking asan_static library for 
DSO. (authored by kstoimenov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118184

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp


Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -826,16 +826,16 @@
   if (SanArgs.needsStatsRt() && SanArgs.linkRuntimes())
 StaticRuntimes.push_back("stats_client");
 
-  // Always link the static runtime regardless of DSO or executable.
-  if (SanArgs.needsAsanRt())
-HelperStaticRuntimes.push_back("asan_static");
-
   // Collect static runtimes.
   if (Args.hasArg(options::OPT_shared)) {
 // Don't link static runtimes into DSOs.
 return;
   }
 
+  // Always link the static runtime for executable.
+  if (SanArgs.needsAsanRt())
+HelperStaticRuntimes.push_back("asan_static");
+
   // Each static runtime that has a DSO counterpart above is excluded below,
   // but runtimes that exist only as static are not affected by needsSharedRt.
 


Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -826,16 +826,16 @@
   if (SanArgs.needsStatsRt() && SanArgs.linkRuntimes())
 StaticRuntimes.push_back("stats_client");
 
-  // Always link the static runtime regardless of DSO or executable.
-  if (SanArgs.needsAsanRt())
-HelperStaticRuntimes.push_back("asan_static");
-
   // Collect static runtimes.
   if (Args.hasArg(options::OPT_shared)) {
 // Don't link static runtimes into DSOs.
 return;
   }
 
+  // Always link the static runtime for executable.
+  if (SanArgs.needsAsanRt())
+HelperStaticRuntimes.push_back("asan_static");
+
   // Each static runtime that has a DSO counterpart above is excluded below,
   // but runtimes that exist only as static are not affected by needsSharedRt.
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] cf730d8 - [ASan] Not linking asan_static library for DSO.

2022-01-25 Thread Kirill Stoimenov via cfe-commits


Author: Kirill Stoimenov
Date: 2022-01-26T00:13:26Z
New Revision: cf730d8ce1341ba593144df2e2bc8411238e04c3

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

LOG: [ASan] Not linking asan_static library for DSO.

Without this change DSOs fail to link because of missing 
asan_report_(load|store)n functions.

Reviewed By: kda

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 3897f67d1fe64..5711998f90434 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -826,16 +826,16 @@ collectSanitizerRuntimes(const ToolChain , const 
ArgList ,
   if (SanArgs.needsStatsRt() && SanArgs.linkRuntimes())
 StaticRuntimes.push_back("stats_client");
 
-  // Always link the static runtime regardless of DSO or executable.
-  if (SanArgs.needsAsanRt())
-HelperStaticRuntimes.push_back("asan_static");
-
   // Collect static runtimes.
   if (Args.hasArg(options::OPT_shared)) {
 // Don't link static runtimes into DSOs.
 return;
   }
 
+  // Always link the static runtime for executable.
+  if (SanArgs.needsAsanRt())
+HelperStaticRuntimes.push_back("asan_static");
+
   // Each static runtime that has a DSO counterpart above is excluded below,
   // but runtimes that exist only as static are not affected by needsSharedRt.
 



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

[clang] fe30370 - Reland "[AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)"

2022-01-25 Thread Dávid Bolvanský via cfe-commits


Author: Dávid Bolvanský
Date: 2022-01-26T01:11:06+01:00
New Revision: fe30370b007e7efa1bd1f39a3189b27ae4e5fcbe

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

LOG: Reland "[AlwaysInliner] Enable call site inlining to make flatten 
attribute working again (#53360)"

Added: 


Modified: 
clang/test/CodeGen/flatten.c
clang/test/CodeGenCXX/flatten.cpp
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
llvm/test/Transforms/Inline/always-inline.ll

Removed: 




diff  --git a/clang/test/CodeGen/flatten.c b/clang/test/CodeGen/flatten.c
index 287d4f2a46b65..4e762223de486 100644
--- a/clang/test/CodeGen/flatten.c
+++ b/clang/test/CodeGen/flatten.c
@@ -1,9 +1,3 @@
-// UNSUPPORTED: experimental-new-pass-manager
-// Currently, 
diff erent code seems to be intentionally generated under the new
-// PM since we alwaysinline functions and not callsites under new PM.
-// Under new PM, f() will not be inlined from g() since f is not marked as
-// alwaysinline.
-
 // RUN: %clang_cc1 -triple=x86_64-linux-gnu %s -emit-llvm -o - | FileCheck %s
 
 void f(void) {}

diff  --git a/clang/test/CodeGenCXX/flatten.cpp 
b/clang/test/CodeGenCXX/flatten.cpp
index 7a6484591aaa0..e988d6d726dd7 100644
--- a/clang/test/CodeGenCXX/flatten.cpp
+++ b/clang/test/CodeGenCXX/flatten.cpp
@@ -1,7 +1,3 @@
-// UNSUPPORTED: experimental-new-pass-manager
-// See the comment for CodeGen/flatten.c on why this is unsupported with the 
new
-// PM.
-
 // RUN: %clang_cc1 -triple=x86_64-linux-gnu -std=c++11 %s -emit-llvm -o - | 
FileCheck %s
 
 void f(void) {}

diff  --git a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp 
b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
index 7acc9b266ad82..a6d9ce1033f3c 100644
--- a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
+++ b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
@@ -54,13 +54,13 @@ PreservedAnalyses AlwaysInlinerPass::run(Module ,
 if (F.isPresplitCoroutine())
   continue;
 
-if (!F.isDeclaration() && F.hasFnAttribute(Attribute::AlwaysInline) &&
-isInlineViable(F).isSuccess()) {
+if (!F.isDeclaration() && isInlineViable(F).isSuccess()) {
   Calls.clear();
 
   for (User *U : F.users())
 if (auto *CB = dyn_cast(U))
-  if (CB->getCalledFunction() == )
+  if (CB->getCalledFunction() ==  &&
+  CB->hasFnAttr(Attribute::AlwaysInline))
 Calls.insert(CB);
 
   for (CallBase *CB : Calls) {
@@ -92,10 +92,12 @@ PreservedAnalyses AlwaysInlinerPass::run(Module ,
 Changed = true;
   }
 
-  // Remember to try and delete this function afterward. This both avoids
-  // re-walking the rest of the module and avoids dealing with any iterator
-  // invalidation issues while deleting functions.
-  InlinedFunctions.push_back();
+  if (F.hasFnAttribute(Attribute::AlwaysInline)) {
+// Remember to try and delete this function afterward. This both avoids
+// re-walking the rest of the module and avoids dealing with any
+// iterator invalidation issues while deleting functions.
+InlinedFunctions.push_back();
+  }
 }
   }
 

diff  --git a/llvm/test/Transforms/Inline/always-inline.ll 
b/llvm/test/Transforms/Inline/always-inline.ll
index 0fcf956199c46..f947bdbd87347 100644
--- a/llvm/test/Transforms/Inline/always-inline.ll
+++ b/llvm/test/Transforms/Inline/always-inline.ll
@@ -1,14 +1,11 @@
-; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | 
FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | 
FileCheck %s --check-prefix=CHECK
 ;
 ; Ensure the threshold has no impact on these decisions.
-; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
-; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK
+; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK
 ;
 ; The new pass manager doesn't re-use any threshold based infrastructure for
-; the always inliner, but test that we get the correct result. The new PM
-; always inliner also doesn't support inlining call-site alwaysinline
-; annotations. It isn't clear that this is a reasonable use case for
-; 'alwaysinline'.
+; the always inliner, but test that we get the correct result.
 ; RUN: opt < %s -inline-threshold=0 -passes=always-inline -S | FileCheck %s 
--check-prefix=CHECK
 ; RUN: opt < %s -inline-threshold=2000 -passes=always-inline -S | 
FileCheck %s --check-prefix=CHECK

[PATCH] D118184: [ASan] Not linking asan_static library for DSO.

2022-01-25 Thread Kevin Athey via Phabricator via cfe-commits

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

unit test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118184

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

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

2022-01-25 Thread Sam McCall via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGce94432702bf: [clangd] Add designator inlay hints for 
initializer lists. (authored by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116786

Files:
  clang-tools-extra/clangd/Config.h
  clang-tools-extra/clangd/ConfigCompile.cpp
  clang-tools-extra/clangd/ConfigFragment.h
  clang-tools-extra/clangd/ConfigYAML.cpp
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -13,21 +13,22 @@
 #include "TestWorkspace.h"
 #include "XRefs.h"
 #include "support/Context.h"
+#include "llvm/Support/ScopedPrinter.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
 namespace clang {
 namespace clangd {
 
-std::ostream <<(std::ostream , const InlayHint ) {
-  return Stream << Hint.label;
+llvm::raw_ostream <<(llvm::raw_ostream ,
+  const InlayHint ) {
+  return Stream << Hint.label << "@" << Hint.range;
 }
 
 namespace {
 
 using ::testing::ElementsAre;
 using ::testing::IsEmpty;
-using ::testing::UnorderedElementsAre;
 
 std::vector hintsOfKind(ParsedAST , InlayHintKind Kind) {
   std::vector Result;
@@ -45,17 +46,24 @@
   std::string RangeName;
   HintSide Side = Left;
 
-  friend std::ostream <<(std::ostream ,
-  const ExpectedHint ) {
-return Stream << Hint.RangeName << ": " << Hint.Label;
+  friend llvm::raw_ostream <<(llvm::raw_ostream ,
+   const ExpectedHint ) {
+return Stream << Hint.Label << "@$" << Hint.RangeName;
   }
 };
 
-MATCHER_P2(HintMatcher, Expected, Code, "") {
-  return arg.label == Expected.Label &&
- arg.range == Code.range(Expected.RangeName) &&
- arg.position ==
- ((Expected.Side == Left) ? arg.range.start : arg.range.end);
+MATCHER_P2(HintMatcher, Expected, Code, llvm::to_string(Expected)) {
+  if (arg.label != Expected.Label) {
+*result_listener << "label is " << arg.label;
+return false;
+  }
+  if (arg.range != Code.range(Expected.RangeName)) {
+*result_listener << "range is " << arg.label << " but $"
+ << Expected.RangeName << " is "
+ << llvm::to_string(Code.range(Expected.RangeName));
+return false;
+  }
+  return true;
 }
 
 MATCHER_P(labelIs, Label, "") { return arg.label == Label; }
@@ -64,6 +72,7 @@
   Config C;
   C.InlayHints.Parameters = false;
   C.InlayHints.DeducedTypes = false;
+  C.InlayHints.Designators = false;
   return C;
 }
 
@@ -100,6 +109,15 @@
   assertHints(InlayHintKind::TypeHint, AnnotatedSource, Expected...);
 }
 
+template 
+void assertDesignatorHints(llvm::StringRef AnnotatedSource,
+   ExpectedHints... Expected) {
+  Config Cfg;
+  Cfg.InlayHints.Designators = true;
+  WithContextValue WithCfg(Config::Key, std::move(Cfg));
+  assertHints(InlayHintKind::DesignatorHint, AnnotatedSource, Expected...);
+}
+
 TEST(ParameterHints, Smoke) {
   assertParameterHints(R"cpp(
 void foo(int param);
@@ -658,6 +676,71 @@
   ExpectedHint{": int", "var"});
 }
 
+TEST(DesignatorHints, Basic) {
+  assertDesignatorHints(R"cpp(
+struct S { int x, y, z; };
+S s {$x[[1]], $y[[2+2]]};
+
+int x[] = {$0[[0]], $1[[1]]};
+  )cpp",
+ExpectedHint{".x=", "x"}, ExpectedHint{".y=", "y"},
+ExpectedHint{"[0]=", "0"}, ExpectedHint{"[1]=", "1"});
+}
+
+TEST(DesignatorHints, Nested) {
+  assertDesignatorHints(R"cpp(
+struct Inner { int x, y; };
+struct Outer { Inner a, b; };
+Outer o{ $a[[{ $x[[1]], $y[[2]] }]], $bx[[3]] };
+  )cpp",
+ExpectedHint{".a=", "a"}, ExpectedHint{".x=", "x"},
+ExpectedHint{".y=", "y"}, ExpectedHint{".b.x=", "bx"});
+}
+
+TEST(DesignatorHints, AnonymousRecord) {
+  assertDesignatorHints(R"cpp(
+struct S {
+  union {
+struct {
+  struct {
+int y;
+  };
+} x;
+  };
+};
+S s{$xy[[42]]};
+  )cpp",
+ExpectedHint{".x.y=", "xy"});
+}
+
+TEST(DesignatorHints, Suppression) {
+  assertDesignatorHints(R"cpp(
+struct Point { int a, b, c, d, e, f, g, h; };
+Point p{/*a=*/1, .c=2, /* .d = */3, $e[[4]]};
+  )cpp",
+ExpectedHint{".e=", "e"});
+}
+
+TEST(DesignatorHints, StdArray) {
+  // Designators for std::array should be [0] rather than .__elements[0].
+  // While technically correct, the designator is useless and horrible to read.
+  assertDesignatorHints(R"cpp(
+

[clang-tools-extra] ce94432 - [clangd] Add designator inlay hints for initializer lists.

2022-01-25 Thread Sam McCall via cfe-commits


Author: Sam McCall
Date: 2022-01-26T00:35:29+01:00
New Revision: ce94432702bf42a0b95a2693aa47177f37dd0bb3

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

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

These make the init lists appear as if designated initialization was used.

Example:
  ExpectedHint{"param: ", "arg"}
becomes
  ExpectedHint{.Label="param: ", .RangeName="arg"}

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

Added: 


Modified: 
clang-tools-extra/clangd/Config.h
clang-tools-extra/clangd/ConfigCompile.cpp
clang-tools-extra/clangd/ConfigFragment.h
clang-tools-extra/clangd/ConfigYAML.cpp
clang-tools-extra/clangd/InlayHints.cpp
clang-tools-extra/clangd/Protocol.cpp
clang-tools-extra/clangd/Protocol.h
clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Config.h 
b/clang-tools-extra/clangd/Config.h
index 952626db31e4..f84b5ef1ffb5 100644
--- a/clang-tools-extra/clangd/Config.h
+++ b/clang-tools-extra/clangd/Config.h
@@ -130,6 +130,7 @@ struct Config {
 // Whether specific categories of hints are enabled.
 bool Parameters = true;
 bool DeducedTypes = true;
+bool Designators = false;
   } InlayHints;
 };
 

diff  --git a/clang-tools-extra/clangd/ConfigCompile.cpp 
b/clang-tools-extra/clangd/ConfigCompile.cpp
index a606b98a2dba..268f214639b9 100644
--- a/clang-tools-extra/clangd/ConfigCompile.cpp
+++ b/clang-tools-extra/clangd/ConfigCompile.cpp
@@ -541,6 +541,10 @@ struct FragmentCompiler {
   Out.Apply.push_back([Value(**F.DeducedTypes)](const Params &, Config ) 
{
 C.InlayHints.DeducedTypes = Value;
   });
+if (F.Designators)
+  Out.Apply.push_back([Value(**F.Designators)](const Params &, Config ) {
+C.InlayHints.Designators = Value;
+  });
   }
 
   constexpr static llvm::SourceMgr::DiagKind Error = llvm::SourceMgr::DK_Error;

diff  --git a/clang-tools-extra/clangd/ConfigFragment.h 
b/clang-tools-extra/clangd/ConfigFragment.h
index d165b6305aa5..0be906036c87 100644
--- a/clang-tools-extra/clangd/ConfigFragment.h
+++ b/clang-tools-extra/clangd/ConfigFragment.h
@@ -293,6 +293,8 @@ struct Fragment {
 llvm::Optional> ParameterNames;
 /// Show deduced types for `auto`.
 llvm::Optional> DeducedTypes;
+/// Show designators in aggregate initialization.
+llvm::Optional> Designators;
   };
   InlayHintsBlock InlayHints;
 };

diff  --git a/clang-tools-extra/clangd/ConfigYAML.cpp 
b/clang-tools-extra/clangd/ConfigYAML.cpp
index 04c0c633a3bb..0c758b6d296d 100644
--- a/clang-tools-extra/clangd/ConfigYAML.cpp
+++ b/clang-tools-extra/clangd/ConfigYAML.cpp
@@ -229,6 +229,10 @@ class Parser {
   if (auto Value = boolValue(N, "DeducedTypes"))
 F.DeducedTypes = *Value;
 });
+Dict.handle("Designators", [&](Node ) {
+  if (auto Value = boolValue(N, "Designators"))
+F.Designators = *Value;
+});
 Dict.parse(N);
   }
 

diff  --git a/clang-tools-extra/clangd/InlayHints.cpp 
b/clang-tools-extra/clangd/InlayHints.cpp
index e534faa80c4b..671f9a151d40 100644
--- a/clang-tools-extra/clangd/InlayHints.cpp
+++ b/clang-tools-extra/clangd/InlayHints.cpp
@@ -13,6 +13,7 @@
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Basic/SourceManager.h"
+#include "llvm/ADT/ScopeExit.h"
 
 namespace clang {
 namespace clangd {
@@ -21,6 +22,167 @@ namespace {
 // For now, inlay hints are always anchored at the left or right of their 
range.
 enum class HintSide { Left, Right };
 
+// Helper class to iterate over the designator names of an aggregate type.
+//
+// For an array type, yields [0], [1], [2]...
+// For aggregate classes, yields null for each base, then .field1, .field2, ...
+class AggregateDesignatorNames {
+public:
+  AggregateDesignatorNames(QualType T) {
+if (!T.isNull()) {
+  T = T.getCanonicalType();
+  if (T->isArrayType()) {
+IsArray = true;
+Valid = true;
+return;
+  }
+  if (const RecordDecl *RD = T->getAsRecordDecl()) {
+Valid = true;
+FieldsIt = RD->field_begin();
+FieldsEnd = RD->field_end();
+if (const auto *CRD = llvm::dyn_cast(RD)) {
+  BasesIt = CRD->bases_begin();
+  BasesEnd = CRD->bases_end();
+  Valid = CRD->isAggregate();
+}
+OneField = Valid && BasesIt == BasesEnd && FieldsIt != FieldsEnd &&
+   std::next(FieldsIt) == FieldsEnd;
+  }
+}
+  }
+  // Returns false if the type was not an aggregate.
+  operator bool() { return Valid; }
+  // Advance to the next element in the aggregate.
+  void next() {
+if (IsArray)
+  ++Index;
+else if (BasesIt != BasesEnd)
+

[PATCH] D118084: [CUDA, NVPTX] Pass byval aggregates directly

2022-01-25 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added a comment.

The RFC discussion concluded this should be fine wrt. the interoperability use 
cases we want to support.
Code change looks good but I have one question.




Comment at: clang/lib/CodeGen/TargetInfo.cpp:7183
 }
-return getNaturalAlignIndirect(Ty, /* byval */ true);
+// We want to pass whole aggregate value as one argument.
+auto AI = ABIArgInfo::getDirect();

Nit: Maybe a note that this effectively disables passing values via `byval`.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:7193
  EIT->getNumBits() > 64))
   return getNaturalAlignIndirect(Ty, /* byval */ true);
   }

When is this ever hit and should we not disable byval here too while we are at 
it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118084

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

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

2022-01-25 Thread Petr Hosek via Phabricator via cfe-commits

phosek added a subscriber: hvdijk.
phosek added a comment.

In D110663#3270509 , @MaskRay wrote:

> Ping @phosek

I apologize about the belated response, but I wanted to test this change first
given the potentially large blast radius.

To clarify, when I talk Fuchsia toolchain, I don't just mean toolchain
targeting Fuchsia, but a Clang toolchain distribution our team manages that's
also used by a number of other teams such Dart, Flutter, Pigweed to build code
for variety of platforms including Linux.

In my testing, I found that these users aren't currently using a single uniform
target triple spelling, I've seen both `${arch}-linux-gnu` and
`${arch}-unknown-linux-gnu` used pretty liberally. So if we were to land this
change today, it would break many of these users. We could clean up and unify
all of these uses, but it's going to take some effort because it spans lots of
projects. I'm also worried that there might be other Clang users in a similar
situation who are not included on this change.

That's why I think there should be an RFC sent to cfe-dev, to both reach an
agreement on whether this is a direction everyone agrees with, but also to
raise the awareness. There's also a question whether this should be rolled out
in a more gradual fashion (for example by starting with a warning first).

Furthermore, I'm also not sure about the motivation behind this change. The
change summary mentions D109837 , but @hvdijk
said that this is not a blocker. Is there another reason for doing this?

Comment at: clang/lib/Driver/Driver.cpp:428
+const Driver , StringRef TargetTriple, const ArgList ,
+llvm::Triple *UnnormalizedTriple = nullptr, StringRef DarwinArchName = "")
{
// FIXME: Already done in Compilation *Driver::BuildCompilation

I find the name `UnnormalizedTriple` a bit confusing as it may imply that
there's some "un-normalization" process involved. I'd prefer using a
`TargetTriple` to refer to "triple given by the user (via the `--target=`
option)" and `NormalizedTriple` as "normalized triple".

Comment at: clang/lib/Driver/Driver.cpp:1203-1206
+ if (Normalized.isOSFuchsia())
+TargetTriple = Normalized.str();
+ else
+TargetTriple = Unnormalized.str();

I really think this logic belongs to `clang::driver::toolchains::Fuchsia`.
Moving it there is going to require some changes to how toolchains are
instantiated, and should thus be done as a separate change, but doing so could
also help us cleanup other special case logic like that exists in `Driver` like
https://github.com/llvm/llvm-project/blob/8ba9c794feb30cd969b9776c39873def10c51bff/clang/lib/Driver/Driver.cpp#L576.

Repository:
rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D116875: [clang-tidy] Add performance-inefficient-array-traversal check

2022-01-25 Thread Nathan James via Phabricator via cfe-commits

njames93 updated this revision to Diff 403050.
njames93 added a comment.

Simplify check logic to only detect loop inits with 0 and incriment with 1.
Functionality can be introduced with later patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116875

Files:
  clang-tools-extra/clang-tidy/performance/CMakeLists.txt
  clang-tools-extra/clang-tidy/performance/InefficientArrayTraversalCheck.cpp
  clang-tools-extra/clang-tidy/performance/InefficientArrayTraversalCheck.h
  clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-array-traversal.rst
  
clang-tools-extra/test/clang-tidy/checkers/performance-inefficient-array-traversal.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance-inefficient-array-traversal.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance-inefficient-array-traversal.cpp
@@ -0,0 +1,113 @@
+// RUN: %check_clang_tidy %s performance-inefficient-array-traversal %t
+
+constexpr unsigned Rows = 10U;
+constexpr unsigned Cols = 16U;
+
+int Arr[Rows][Cols];
+int *PtrArr[Cols];
+int **Ptr;
+int FlatArray[Rows * Cols];
+
+void foo();
+
+void warned() {
+  for (unsigned I = 0; I < Cols; ++I) {
+for (unsigned J = 0; J < Rows; ++J) {
+  Arr[J][I]++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Nonsequential array traversal can harm performance
+  // CHECK-MESSAGES: :[[@LINE-3]]:5: note: Row index 'J' incremented in this loop
+  // CHECK-MESSAGES: :[[@LINE-5]]:3: note: Column index 'I' incremented in this loop
+}
+  }
+  for (unsigned I = 0; I < Cols; ++I)
+for (unsigned J = 0; J < Rows; ++J)
+  Arr[J][I]++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Nonsequential array traversal can harm performance
+
+  // Ensure it works on array access that use pointers
+  for (unsigned I = 0; I < Cols; ++I)
+for (unsigned J = 0; J < Rows; ++J)
+  PtrArr[J][I]++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Nonsequential array traversal can harm performance
+
+  for (unsigned I = 0; I < Cols; ++I)
+for (unsigned J = 0; J < Rows; ++J)
+  Ptr[J][I]++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Nonsequential array traversal can harm performance
+
+  // Detect += 1 as the loop incriment
+  for (unsigned I = 0; I < Cols; I += 1)
+for (unsigned J = 0; J < Rows; J += 1)
+  Arr[J][I]++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Nonsequential array traversal can harm performance
+
+  // Detect X = X + 1 as the loop incriment
+  for (unsigned I = 0; I < Cols; I = I + 1)
+for (unsigned J = 0; J < Rows; J = J + 1)
+  Arr[J][I]++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Nonsequential array traversal can harm performance
+
+  // Still warn on this as calls inside the inner loop shouldn't complicate a fix.
+  for (unsigned I = 0; I < Cols; ++I) {
+for (unsigned J = 0; J < Rows; ++J) {
+  foo();
+  Arr[J][I]++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Nonsequential array traversal can harm performance
+  foo();
+}
+  }
+  for (unsigned I = 0; I < Cols; ++I) {
+for (unsigned J = 0; J < Rows; ++J) {
+  FlatArray[J * Cols + I]++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: Nonsequential array traversal can harm performance
+  // CHECK-MESSAGES: :[[@LINE-3]]:5: note: Row index 'J' incremented in this loop
+  // CHECK-MESSAGES: :[[@LINE-5]]:3: note: Column index 'I' incremented in this loop
+}
+  }
+}
+
+void ignored() {
+  // Correct traversal.
+  for (unsigned I = 0; I < Rows; ++I) {
+for (unsigned J = 0; J < Cols; ++J) {
+  Arr[I][J]++;
+}
+  }
+  for (unsigned I = 0; I < Rows; ++I) {
+for (unsigned J = 0; J < Cols; ++J) {
+  PtrArr[I][J]++;
+}
+  }
+  for (unsigned I = 0; I < Rows; ++I) {
+for (unsigned J = 0; J < Cols; ++J) {
+  FlatArray[I * Cols + J]++;
+}
+  }
+  // Don'w warn on these cases as extra code inside the outer loop could complicate a fix.
+  for (unsigned I = 0; I < Cols; ++I) {
+foo();
+for (unsigned J = 0; J < Rows; ++J) {
+  Arr[J][I]++;
+}
+  }
+  for (unsigned I = 0; I < Cols; ++I) {
+for (unsigned J = 0; J < Rows; ++J) {
+  Arr[J][I]++;
+}
+foo();
+  }
+
+  // Nested loop increments incorrect variable, don't warn on the traversal.
+  for (unsigned I = 0; I < Cols; ++I)
+for (unsigned J = 0; J < Rows; ++I)
+  Arr[J][I]++;
+
+  // These 2 loops are questionable and definitely a memory safety bug,
+  // but this is not the point of this check.
+  for (unsigned I = 0; I < Cols; ++I)
+for (unsigned J = 0; J < Rows; ++I)
+  FlatArray[I * Cols + J]++;
+  for (unsigned I = 0; I < Rows; ++I)
+for (unsigned J = 0; J < Cols;

[PATCH] D118199: [AArch64] ACLE feature macro for Armv8.8-A MOPS

2022-01-25 Thread Son Tuan Vu via Phabricator via cfe-commits

tyb0807 created this revision.
Herald added a subscriber: kristof.beyls.
tyb0807 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This introduces the new __ARM_FEATURE_MOPS ACLE feature test macro,
which signals the availability of the new Armv8.8-A/Armv9.3-A
instructions for standardising memcpy, memset and memmove operations.

This patch supersedes the one from https://reviews.llvm.org/D116160.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118199

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/test/CodeGen/aarch64-mops.c
  clang/test/Preprocessor/aarch64-target-features.c

Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -516,3 +516,15 @@
 // RUN: %clang -target aarch64-none-linux-gnu -march=armv8.1-a -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-LSE %s
 // RUN: %clang -target arm64-none-linux-gnu -march=armv8.1-a -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-LSE %s
 // CHECK-LSE: __ARM_FEATURE_ATOMICS 1
+
+// == Check Armv8.8-A/Armv9.3-A memcpy and memset acceleration instructions (MOPS)
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8.7-a -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-NOMOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8.7-a+mops -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8.8-a -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8.8-a+mops -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv9.2-a -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-NOMOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv9.2-a+mops -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv9.3-a -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv9.3-a+mops -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
+// CHECK-MOPS: __ARM_FEATURE_MOPS 1
+// CHECK-NOMOPS-NOT: __ARM_FEATURE_MOPS 1
Index: clang/test/CodeGen/aarch64-mops.c
===
--- clang/test/CodeGen/aarch64-mops.c
+++ clang/test/CodeGen/aarch64-mops.c
@@ -1,152 +1,277 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
 
-// RUN: %clang_cc1 -triple aarch64-arm-unknown-eabi -target-feature +mops -S -emit-llvm -o - %s  | FileCheck %s
+// RUN: %clang_cc1 -triple aarch64-arm-unknown-eabi -target-feature +mops -S -emit-llvm -o - %s  | FileCheck --check-prefix=CHECK-MOPS %s
+// RUN: %clang_cc1 -triple aarch64-arm-unknown-eabi   -S -emit-llvm -o - %s  | FileCheck --check-prefix=CHECK-NOMOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8.7-a+mops -S -emit-llvm %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8.7-a  -S -emit-llvm %s -o - | FileCheck --check-prefix=CHECK-NOMOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8.8-a+mops -S -emit-llvm %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8.8-a  -S -emit-llvm %s -o - | FileCheck --check-prefix=CHECK-MOPS %s
 
-#define __ARM_FEATURE_MOPS 1
 #include 
 #include 
 
-// CHECK-LABEL: @bzero_0(
-// CHECK-NEXT:  entry:
-// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
-// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
-// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
-// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 0)
-// CHECK-NEXT:ret i8* [[TMP1]]
+// CHECK-MOPS-LABEL: @bzero_0(
+// CHECK-MOPS:   entry:
+// CHECK-MOPS-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-MOPS-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-MOPS-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-MOPS-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 0)
+// CHECK-MOPS-NEXT:ret i8* [[TMP1]]
+//
+// CHECK-NOMOPS-LABEL: @bzero_0(
+// CHECK-NOMOPS:   entry:
+// CHECK-NOMOPS-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NOMOPS-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NOMOPS-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NOMOPS-NEXT:[[CALL:%.*]] = call i32 bitcast (i32 (...)* @__arm_mops_memset_tag to i32 (i8*, i32, i32)*)(i8* noundef [[TMP0]], i32 noundef 0, i32 noundef 0)
+// CHECK-NOMOPS-NEXT:[[CONV:%.*]] = sext i32 [[CALL]] to i64
+//

[PATCH] D118198: [OpenMP] Remove call to 'clang-offload-wrapper' binary

2022-01-25 Thread Joseph Huber via Phabricator via cfe-commits

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, JonChesterfield, ronlieb, saiislam.
Herald added subscribers: guansong, yaxunl, mgorny.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

This patch removes the system call to the `clang-offload-wrapper` tool
by replicating its functionality in a new file. This improves
performance and makes the future wrapping functionality easier to
change.

Depends on D118197 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118198

Files:
  clang/tools/clang-linker-wrapper/CMakeLists.txt
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
  clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
  clang/tools/clang-linker-wrapper/OffloadWrapper.h

Index: clang/tools/clang-linker-wrapper/OffloadWrapper.h
===
--- /dev/null
+++ clang/tools/clang-linker-wrapper/OffloadWrapper.h
@@ -0,0 +1,20 @@
+//===- OffloadWrapper.h -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_CLANG_LINKER_WRAPPER_OFFLOAD_WRAPPER_H
+#define LLVM_CLANG_TOOLS_CLANG_LINKER_WRAPPER_OFFLOAD_WRAPPER_H
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/IR/Module.h"
+
+/// Wrap the input device images into the module \p M as global symbols and
+/// registers the images with the OpenMP Offloading runtime libomptarget.
+llvm::Error wrapBinaries(llvm::Module ,
+ llvm::ArrayRef> Images);
+
+#endif
Index: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
===
--- /dev/null
+++ clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
@@ -0,0 +1,267 @@
+//===- OffloadWrapper.cpp ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "OffloadWrapper.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/Triple.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/GlobalVariable.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/LLVMContext.h"
+#include "llvm/IR/Module.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
+
+using namespace llvm;
+
+namespace {
+
+IntegerType *getSizeTTy(Module ) {
+  LLVMContext  = M.getContext();
+  switch (M.getDataLayout().getPointerTypeSize(Type::getInt8PtrTy(C))) {
+  case 4u:
+return Type::getInt32Ty(C);
+  case 8u:
+return Type::getInt64Ty(C);
+  }
+  llvm_unreachable("unsupported pointer type size");
+}
+
+// struct __tgt_offload_entry {
+//   void *addr;
+//   char *name;
+//   size_t size;
+//   int32_t flags;
+//   int32_t reserved;
+// };
+StructType *getEntryTy(Module ) {
+  LLVMContext  = M.getContext();
+  StructType *EntryTy = StructType::getTypeByName(C, "__tgt_offload_entry");
+  if (!EntryTy)
+EntryTy = StructType::create("__tgt_offload_entry", Type::getInt8PtrTy(C),
+ Type::getInt8PtrTy(C), getSizeTTy(M),
+ Type::getInt32Ty(C), Type::getInt32Ty(C));
+  return EntryTy;
+}
+
+PointerType *getEntryPtrTy(Module ) {
+  return PointerType::getUnqual(getEntryTy(M));
+}
+
+// struct __tgt_device_image {
+//   void *ImageStart;
+//   void *ImageEnd;
+//   __tgt_offload_entry *EntriesBegin;
+//   __tgt_offload_entry *EntriesEnd;
+// };
+StructType *getDeviceImageTy(Module ) {
+  LLVMContext  = M.getContext();
+  StructType *ImageTy = StructType::getTypeByName(C, "__tgt_device_image");
+  if (!ImageTy)
+ImageTy = StructType::create("__tgt_device_image", Type::getInt8PtrTy(C),
+ Type::getInt8PtrTy(C), getEntryPtrTy(M),
+ getEntryPtrTy(M));
+  return ImageTy;
+}
+
+PointerType *getDeviceImagePtrTy(Module ) {
+  return PointerType::getUnqual(getDeviceImageTy(M));
+}
+
+// struct __tgt_bin_desc {
+//   int32_t NumDeviceImages;
+//   __tgt_device_image *DeviceImages;
+//   __tgt_offload_entry *HostEntriesBegin;
+//   __tgt_offload_entry *HostEntriesEnd;
+// };
+StructType *getBinDescTy(Module ) {
+  LLVMContext  = M.getContext();
+  StructType *DescTy = StructType::getTypeByName(C, "__tgt_bin_desc");
+  if (!DescTy)
+DescTy = StructType::create("__tgt_bin_desc", Type::getInt32Ty(C),
+getDeviceImagePtrTy(M), getEntryPtrTy(M),
+getEntryPtrTy(M));
+  return

[PATCH] D118197: [OpenMP] Replace sysmtem call to `llc` with target machine

2022-01-25 Thread Joseph Huber via Phabricator via cfe-commits

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, JonChesterfield, ronlieb, saiislam.
Herald added subscribers: mikhail.ramalho, guansong, yaxunl, mgorny.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

This patch replaces the system call to the `llc` binary with a library
call to the target machine interface. This should be faster than
relying on an external system call to compile the final wrapper binary.

Depends on D118155 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118197

Files:
  clang/tools/clang-linker-wrapper/CMakeLists.txt
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp

Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -23,6 +23,7 @@
 #include "llvm/IR/Module.h"
 #include "llvm/IRReader/IRReader.h"
 #include "llvm/LTO/LTO.h"
+#include "llvm/MC/TargetRegistry.h"
 #include "llvm/Object/Archive.h"
 #include "llvm/Object/ArchiveWriter.h"
 #include "llvm/Object/Binary.h"
@@ -42,6 +43,7 @@
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/WithColor.h"
 #include "llvm/Support/raw_ostream.h"
+#include "llvm/Target/TargetMachine.h"
 
 using namespace llvm;
 using namespace llvm::object;
@@ -969,6 +971,49 @@
   return Error::success();
 }
 
+// Compile the module to an object file using the appropriate target machine for
+// the host triple.
+Expected compileModule(Module ) {
+  if (M.getTargetTriple().empty())
+M.setTargetTriple(HostTriple);
+
+  std::string Msg;
+  const Target *T = TargetRegistry::lookupTarget(M.getTargetTriple(), Msg);
+  if (!T)
+return createStringError(inconvertibleErrorCode(), Msg);
+
+  auto Options =
+  codegen::InitTargetOptionsFromCodeGenFlags(Triple(M.getTargetTriple()));
+  StringRef CPU = "";
+  StringRef Features = "";
+  std::unique_ptr TM(T->createTargetMachine(
+  HostTriple, CPU, Features, Options, Reloc::PIC_, M.getCodeModel()));
+
+  if (M.getDataLayout().isDefault())
+M.setDataLayout(TM->createDataLayout());
+
+  SmallString<128> ObjectFile;
+  int FD = -1;
+  if (Error Err = createOutputFile(sys::path::filename(ExecutableName) +
+   "offload-wrapper",
+   "o", ObjectFile))
+return std::move(Err);
+  if (std::error_code EC = sys::fs::openFileForWrite(ObjectFile, FD))
+return errorCodeToError(EC);
+
+  auto OS = std::make_unique(FD, true);
+
+  legacy::PassManager CodeGenPasses;
+  TargetLibraryInfoImpl TLII(Triple(M.getTargetTriple()));
+  CodeGenPasses.add(new TargetLibraryInfoWrapperPass(TLII));
+  if (TM->addPassesToEmitFile(CodeGenPasses, *OS, nullptr, CGFT_ObjectFile))
+return createStringError(inconvertibleErrorCode(),
+ "Failed to execute host backend");
+  CodeGenPasses.run(M);
+
+  return static_cast(ObjectFile);
+}
+
 /// Creates an object file containing the device image stored in the filename \p
 /// ImageFile that can be linked with the host.
 Expected wrapDeviceImage(StringRef ImageFile) {
@@ -1000,33 +1045,11 @@
 return createStringError(inconvertibleErrorCode(),
  "'clang-offload-wrapper' failed");
 
-  ErrorOr CompilerPath =
-  sys::findProgramByName("llc", sys::path::parent_path(LinkerExecutable));
-  if (!WrapperPath)
-WrapperPath = sys::findProgramByName("llc");
-  if (!WrapperPath)
-return createStringError(WrapperPath.getError(),
- "Unable to find 'llc' in path");
-
-  // Create a new file to write the wrapped bitcode file to.
-  SmallString<128> ObjectFile;
-  if (Error Err = createOutputFile(sys::path::filename(ExecutableName) +
-   "-offload-wrapper",
-   "o", ObjectFile))
-return std::move(Err);
-
-  SmallVector CompilerArgs;
-  CompilerArgs.push_back(*CompilerPath);
-  CompilerArgs.push_back("--filetype=obj");
-  CompilerArgs.push_back("--relocation-model=pic");
-  CompilerArgs.push_back("-o");
-  CompilerArgs.push_back(ObjectFile);
-  CompilerArgs.push_back(BitcodeFile);
-
-  if (sys::ExecuteAndWait(*CompilerPath, CompilerArgs))
-return createStringError(inconvertibleErrorCode(), "'llc' failed");
+  LLVMContext Context;
+  SMDiagnostic Err;
+  std::unique_ptr M = parseIRFile(BitcodeFile, Err, Context);
 
-  return static_cast(ObjectFile);
+  return compileModule(*M);
 }
 
 Optional findFile(StringRef Dir, const Twine ) {
Index: clang/tools/clang-linker-wrapper/CMakeLists.txt
===
--- clang/tools/clang-linker-wrapper/CMakeLists.txt
+++ clang/tools/clang-linker-wrapper/CMakeLists.txt
@@ -4,6 +4,8 @@
   Core
   BinaryFormat
   MC
+

[PATCH] D118196: [syntax][pseudo] Implement LR parsing table.

2022-01-25 Thread Haojian Wu via Phabricator via cfe-commits

hokein created this revision.
hokein added a reviewer: sammccall.
Herald added a subscriber: mgorny.
hokein requested review of this revision.
Herald added a project: clang.

This patch introduces a dense implementation of the LR parsing table, which is
used by LR parsers. We implement a SLR(1) parsing table from an LR(0) automaton.

Statistics of the LR parsing table on the C++ spec grammar:

  number of states: 1449
  number of actions: 83069
  number of index entries: 72612
  size of the table (bytes): 1380908


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118196

Files:
  clang/include/clang/Tooling/Syntax/Pseudo/Grammar.h
  clang/include/clang/Tooling/Syntax/Pseudo/LRAutomaton.h
  clang/include/clang/Tooling/Syntax/Pseudo/LRTable.h
  clang/lib/Tooling/Syntax/Pseudo/CMakeLists.txt
  clang/lib/Tooling/Syntax/Pseudo/Grammar.cpp
  clang/lib/Tooling/Syntax/Pseudo/LRBuilder.cpp
  clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp
  clang/unittests/Tooling/Syntax/Pseudo/CMakeLists.txt
  clang/unittests/Tooling/Syntax/Pseudo/GrammarTests.cpp
  clang/unittests/Tooling/Syntax/Pseudo/LRBuilderTests.cpp

Index: clang/unittests/Tooling/Syntax/Pseudo/LRBuilderTests.cpp
===
--- /dev/null
+++ clang/unittests/Tooling/Syntax/Pseudo/LRBuilderTests.cpp
@@ -0,0 +1,112 @@
+//===--- LRBuilderTests.cpp --*- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Tooling/Syntax/Pseudo/LRAutomaton.h"
+#include "clang/Tooling/Syntax/Pseudo/LRTable.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+namespace clang {
+namespace syntax {
+namespace pseudo {
+namespace {
+
+TEST(TableTest, BuildLRTable) {
+  struct TestCase {
+llvm::StringRef BNF;
+llvm::StringRef ExpectedStates;
+llvm::StringRef ExpectedTable;
+  };
+
+  TestCase Cases[] = {
+  {
+  R"bnf(
+_ := expr
+expr := IDENTIFIER
+  )bnf",
+  R"(States:
+State 0
+_ :=  â¢ expr
+expr :=  â¢ IDENTIFIER
+State 1
+expr := IDENTIFIER â¢ 
+State 2
+_ := expr â¢ 
+)",
+  R"(LRTable:
+State 0
+'IDENTIFIER': shift, and go to state 1
+'expr': go to state 2
+State 1
+'EOF': reduce by rule 1 'expr := IDENTIFIER'
+State 2
+'EOF': accept
+)",
+  },
+  {
+  // A grammar with a S/R conflict in SLR table: (id-id)-id, or
+  // id-(id-id).
+  R"bnf(
+_ := expr
+expr := expr - expr  # S/R conflict at state 4 on '-' token
+expr := IDENTIFIER
+  )bnf",
+  R"(States:
+State 0
+_ :=  â¢ expr
+expr :=  â¢ IDENTIFIER
+expr :=  â¢ expr - expr
+State 1
+expr := IDENTIFIER â¢ 
+State 2
+_ := expr â¢ 
+expr := expr â¢ - expr
+State 3
+expr :=  â¢ IDENTIFIER
+expr :=  â¢ expr - expr
+expr := expr - â¢ expr
+State 4
+expr := expr â¢ - expr
+expr := expr - expr â¢ 
+)",
+  R"(LRTable:
+State 0
+'IDENTIFIER': shift, and go to state 1
+'expr': go to state 2
+State 1
+'EOF': reduce by rule 1 'expr := IDENTIFIER'
+'-': reduce by rule 1 'expr := IDENTIFIER'
+State 2
+'EOF': accept
+'-': shift, and go to state 3
+State 3
+'IDENTIFIER': shift, and go to state 1
+'expr': go to state 4
+State 4
+'EOF': reduce by rule 2 'expr := expr - expr'
+'-': shift, and go to state 3
+'-': reduce by rule 2 'expr := expr - expr'
+)",
+  },
+  };
+  for (const auto  : Cases) {
+std::vector Diags;
+auto G = Grammar::parseBNF(C.BNF, Diags);
+ASSERT_THAT(Diags, testing::IsEmpty());
+auto Automaton = LRAutomaton::build(*G);
+auto Table = LRTable::build(*G);
+EXPECT_EQ(Automaton.dumpForTests(*G), C.ExpectedStates);
+EXPECT_EQ(Table.dumpForTests(*G), C.ExpectedTable);
+  }
+}
+
+} // namespace
+} // namespace pseudo
+} // namespace syntax
+} // namespace clang
Index: clang/unittests/Tooling/Syntax/Pseudo/GrammarTests.cpp
===
--- clang/unittests/Tooling/Syntax/Pseudo/GrammarTests.cpp
+++ clang/unittests/Tooling/Syntax/Pseudo/GrammarTests.cpp
@@ -1,4 +1,4 @@
-//===--- GrammarTests.cpp - grammar tests  *- C++-*-===//
+//===--- GrammarTests.cpp - grammar tests  ---*- C++-*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -19,6 +19,7 @@
 using testing::AllOf;
 using testing::ElementsAre;
 using testing::IsEmpty;
+using testing::Pair;
 using testing::UnorderedElementsAre;
 
 MATCHER_P(TargetID, SID, "") { return arg.target() == SID; }
@@ -34,7 +35,7 @@
 G =

[clang] 493509a - [NFC] DeclCXX: Fix -Wreorder-ctor

2022-01-25 Thread Jordan Rupprecht via cfe-commits


Author: Jordan Rupprecht
Date: 2022-01-25T14:29:35-08:00
New Revision: 493509a40ad1653feb779861badd3ee59fc4a79c

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

LOG: [NFC] DeclCXX: Fix -Wreorder-ctor

>From 8ba9c794feb30cd969b9776c39873def10c51bff

Added: 


Modified: 
clang/lib/AST/DeclCXX.cpp

Removed: 




diff  --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index a15498c89d6a1..0cf6e60b2a6c3 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -79,10 +79,9 @@ CXXRecordDecl::DefinitionData::DefinitionData(CXXRecordDecl 
*D)
   HasBasesWithFields(false), HasBasesWithNonStaticDataMembers(false),
   HasPrivateFields(false), HasProtectedFields(false),
   HasPublicFields(false), HasMutableFields(false), 
HasVariantMembers(false),
-  HasOnlyCMembers(true), HasInClassInitializer(false),
+  HasOnlyCMembers(true), HasInitMethod(false), 
HasInClassInitializer(false),
   HasUninitializedReferenceMember(false), HasUninitializedFields(false),
-  HasInheritedConstructor(false),
-  HasInheritedDefaultConstructor(false),
+  HasInheritedConstructor(false), HasInheritedDefaultConstructor(false),
   HasInheritedAssignment(false),
   NeedOverloadResolutionForCopyConstructor(false),
   NeedOverloadResolutionForMoveConstructor(false),
@@ -111,7 +110,7 @@ CXXRecordDecl::DefinitionData::DefinitionData(CXXRecordDecl 
*D)
   HasDeclaredCopyAssignmentWithConstParam(false),
   IsAnyDestructorNoReturn(false), IsLambda(false),
   IsParsingBaseSpecifiers(false), ComputedVisibleConversions(false),
-  HasODRHash(false), Definition(D), HasInitMethod(false) {}
+  HasODRHash(false), Definition(D) {}
 
 CXXBaseSpecifier *CXXRecordDecl::DefinitionData::getBasesSlowCase() const {
   return Bases.get(Definition->getASTContext().getExternalSource());



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

[PATCH] D117830: [HeaderSearch] Track framework name in LookupFile

2022-01-25 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added a comment.

I don't have any suggestions here except for running the patch through 
`clang-format`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117830

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

[clang] 8ba9c79 - Add support for sycl_special_class attribute.

2022-01-25 Thread Zahira Ammarguellat via cfe-commits


Author: Zahira Ammarguellat
Date: 2022-01-25T14:17:09-08:00
New Revision: 8ba9c794feb30cd969b9776c39873def10c51bff

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

LOG: Add support for sycl_special_class attribute.

Special classes such as accessor, sampler, and stream need additional
implementation when they are passed from host to device.

This patch is adding a new attribute “sycl_special_class” used to mark
SYCL classes/struct that need the additional compiler handling.

Added: 
clang/test/SemaSYCL/special-class-attribute-on-non-sycl.cpp
clang/test/SemaSYCL/special-class-attribute.cpp

Modified: 
clang/include/clang/AST/CXXRecordDeclDefinitionBits.def
clang/include/clang/AST/DeclCXX.h
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/AST/DeclCXX.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/Misc/pragma-attribute-supported-attributes-list.test

Removed: 




diff  --git a/clang/include/clang/AST/CXXRecordDeclDefinitionBits.def 
b/clang/include/clang/AST/CXXRecordDeclDefinitionBits.def
index 9b270682f8cf0..cdf0804680ad0 100644
--- a/clang/include/clang/AST/CXXRecordDeclDefinitionBits.def
+++ b/clang/include/clang/AST/CXXRecordDeclDefinitionBits.def
@@ -112,6 +112,9 @@ FIELD(HasVariantMembers, 1, NO_MERGE)
 /// True if there no non-field members declared by the user.
 FIELD(HasOnlyCMembers, 1, NO_MERGE)
 
+/// True if there is an '__init' method defined by the user.
+FIELD(HasInitMethod, 1, NO_MERGE)
+
 /// True if any field has an in-class initializer, including those
 /// within anonymous unions or structs.
 FIELD(HasInClassInitializer, 1, NO_MERGE)

diff  --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index b54e6b0ac2171..2833df0505dac 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1139,6 +1139,9 @@ class CXXRecordDecl : public RecordDecl {
   /// \note This does NOT include a check for union-ness.
   bool isEmpty() const { return data().Empty; }
 
+  void setInitMethod(bool Val) { data().HasInitMethod = Val; }
+  bool hasInitMethod() const { return data().HasInitMethod; }
+
   bool hasPrivateFields() const {
 return data().HasPrivateFields;
   }

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index b071ebb4d576b..be56373cc3ca4 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -1191,6 +1191,13 @@ def SYCLKernel : InheritableAttr {
   let Documentation = [SYCLKernelDocs];
 }
 
+def SYCLSpecialClass: InheritableAttr {
+  let Spellings = [Clang<"sycl_special_class">];
+  let Subjects = SubjectList<[CXXRecord]>;
+  let LangOpts = [SYCL];
+  let Documentation = [SYCLSpecialClassDocs];
+}
+
 def C11NoReturn : InheritableAttr {
   let Spellings = [Keyword<"_Noreturn">];
   let Subjects = SubjectList<[Function], ErrorDiag>;

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index a24218a9c82b6..18fac924b1140 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -409,6 +409,71 @@ The SYCL kernel in the previous code sample meets these 
expectations.
   }];
 }
 
+def SYCLSpecialClassDocs : Documentation {
+  let Category = DocCatStmt;
+  let Content = [{
+SYCL defines some special classes (accessor, sampler, and stream) which require
+specific handling during the generation of the SPIR entry point.
+The ``__attribute__((sycl_special_class))`` attribute is used in SYCL
+headers to indicate that a class or a struct needs a specific handling when
+it is passed from host to device.
+Special classes will have a mandatory ``__init`` method and an optional
+``__finalize`` method (the ``__finalize`` method is used only with the
+``stream`` type). Kernel parameters types are extract from the ``__init`` 
method
+parameters. The kernel function arguments list is derived from the
+arguments of the ``__init`` method. The arguments of the ``__init`` method are
+copied into the kernel function argument list and the ``__init`` and
+``__finalize`` methods are called at the beginning and the end of the kernel,
+respectively.
+The ``__init`` and ``__finalize`` methods must be defined inside the
+special class.
+Please note that this is an attribute that is used as an internal
+implementation detail and not intended to be used by external users.
+
+The syntax of the attribute is as follows:
+
+.. code-block:: c++
+
+   class __attribute__((sycl_special_class)) accessor {};
+   class [[clang::sycl_special_class]] accessor {};
+
+This is a code example that illustrates the use of the attribute:
+
+.. code-block:: c++
+

[clang] 90f185c - Revert "[AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)"

2022-01-25 Thread Dávid Bolvanský via cfe-commits


Author: Dávid Bolvanský
Date: 2022-01-25T23:13:46+01:00
New Revision: 90f185c964d05e9f3081bb4acc734b3932db221a

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

LOG: Revert "[AlwaysInliner] Enable call site inlining to make flatten 
attribute working again (#53360)"

This reverts commit ceec4383681c42bfd3d06a6913ce7554bea160b0. Clang tests fail.

Added: 


Modified: 
clang/test/CodeGen/flatten.c
clang/test/CodeGenCXX/flatten.cpp
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
llvm/test/Transforms/Inline/always-inline.ll

Removed: 




diff  --git a/clang/test/CodeGen/flatten.c b/clang/test/CodeGen/flatten.c
index 4e762223de486..287d4f2a46b65 100644
--- a/clang/test/CodeGen/flatten.c
+++ b/clang/test/CodeGen/flatten.c
@@ -1,3 +1,9 @@
+// UNSUPPORTED: experimental-new-pass-manager
+// Currently, 
diff erent code seems to be intentionally generated under the new
+// PM since we alwaysinline functions and not callsites under new PM.
+// Under new PM, f() will not be inlined from g() since f is not marked as
+// alwaysinline.
+
 // RUN: %clang_cc1 -triple=x86_64-linux-gnu %s -emit-llvm -o - | FileCheck %s
 
 void f(void) {}

diff  --git a/clang/test/CodeGenCXX/flatten.cpp 
b/clang/test/CodeGenCXX/flatten.cpp
index e988d6d726dd7..7a6484591aaa0 100644
--- a/clang/test/CodeGenCXX/flatten.cpp
+++ b/clang/test/CodeGenCXX/flatten.cpp
@@ -1,3 +1,7 @@
+// UNSUPPORTED: experimental-new-pass-manager
+// See the comment for CodeGen/flatten.c on why this is unsupported with the 
new
+// PM.
+
 // RUN: %clang_cc1 -triple=x86_64-linux-gnu -std=c++11 %s -emit-llvm -o - | 
FileCheck %s
 
 void f(void) {}

diff  --git a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp 
b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
index 8f20f59b5e4d7..7acc9b266ad82 100644
--- a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
+++ b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
@@ -54,13 +54,13 @@ PreservedAnalyses AlwaysInlinerPass::run(Module ,
 if (F.isPresplitCoroutine())
   continue;
 
-if (!F.isDeclaration() && isInlineViable(F).isSuccess()) {
+if (!F.isDeclaration() && F.hasFnAttribute(Attribute::AlwaysInline) &&
+isInlineViable(F).isSuccess()) {
   Calls.clear();
 
   for (User *U : F.users())
 if (auto *CB = dyn_cast(U))
-  if (CB->getCalledFunction() ==  &&
-  CB->hasFnAttr(Attribute::AlwaysInline))
+  if (CB->getCalledFunction() == )
 Calls.insert(CB);
 
   for (CallBase *CB : Calls) {

diff  --git a/llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll 
b/llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
index 5d62747180233..d805d7549231d 100644
--- a/llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
+++ b/llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
@@ -3,7 +3,9 @@
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.12.0"
 
-; CHECK-NOT: define {{.*}} @f(i8* %buffer, i32* %array)
+; CHECK: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
+; CHECK-NEXT: entry:
+; CHECK-NEXT:  unreachable
 
 define internal {i8*, i32} @f(i8* %buffer, i32* %array) {
 entry:

diff  --git a/llvm/test/Transforms/Inline/always-inline.ll 
b/llvm/test/Transforms/Inline/always-inline.ll
index 8eb3d020f6634..0fcf956199c46 100644
--- a/llvm/test/Transforms/Inline/always-inline.ll
+++ b/llvm/test/Transforms/Inline/always-inline.ll
@@ -1,11 +1,14 @@
-; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | 
FileCheck %s --check-prefix=CHECK
+; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | 
FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
 ;
 ; Ensure the threshold has no impact on these decisions.
-; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK
-; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK
+; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
 ;
 ; The new pass manager doesn't re-use any threshold based infrastructure for
-; the always inliner, but test that we get the correct result.
+; the always inliner, but test that we get the correct result. The new PM
+; always inliner also doesn't support inlining call-site alwaysinline
+; annotations. It isn't clear that this is a reasonable use case for
+; 'alwaysinline'.
 ; RUN: opt < %s -inline-threshold=0 -passes=always-inline -S | FileCheck %s

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

In D117965#3270744 , @thakis wrote:

> Could this have caused http://45.33.8.238/linux/66347/step_7.txt ?

Yeah, possible as inliner removes internal  unused functions (small change 
before commit, missed check-clang).

I will revert and fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117965

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

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Nico Weber via Phabricator via cfe-commits

thakis added a comment.

Could this have caused http://45.33.8.238/linux/66347/step_7.txt ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117965

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

[PATCH] D117939: [clang-tidy] Add more documentation about check development

2022-01-25 Thread Richard via Phabricator via cfe-commits

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

Comment at: clang-tools-extra/docs/clang-tidy/Contributing.rst:362
+Private custom matchers are a good example of auxiliary support code for your 
check
+that is best tested with a unit test.  It will be easier to test your matchers 
or
+other support classes by writing a unit test than by writing a ``FileCheck`` 
integration

If I change the wording from "is best tested with a unit test" to "can be 
tested with a unit test",
would that alleviate the concern?  I want to encourage appropriate testing and 
unit testing
complex helper code is better than integration testing helper code.

I find it easier to have confidence in private matchers if they are unit tested 
and I've recently
had a few situations where I had to write relatively complex helper functions 
to analyze raw
text that I felt would have been better tested with a unit test than an 
integration test.

Comment at: clang-tools-extra/docs/clang-tidy/Contributing.rst:389-390
+- Test your check under both Windows and Linux environments.
+- Watch out for high false positive rates; ideally there should be none, but a
+  small number may be tolerable.  High false positive rates prevent adoption.
+- Consider configurable options for your check to deal with false positives.

ymandel wrote:
> Is it worth giving a rule-of-thumb? Personally I'd go with < 10%, all things 
> being equal.  A check for a serious bug may reasonably have a higher false 
> positive rate, and trivial checks might not justify *any* false positives. 
> But, if neither of these apply, I'd recommend 10% as the default.
I'm OK with rule-of-thumb 10% advice.

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

https://reviews.llvm.org/D117939

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

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Dávid Bolvanský 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 rGceec4383681c: [AlwaysInliner] Enable call site inlining to 
make flatten attribute working… (authored by xbolva00).

Changed prior to commit:
  https://reviews.llvm.org/D117965?vs=402997=403028#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117965

Files:
  clang/test/CodeGen/flatten.c
  clang/test/CodeGenCXX/flatten.cpp
  llvm/lib/Transforms/IPO/AlwaysInliner.cpp
  llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
  llvm/test/Transforms/Inline/always-inline.ll

Index: llvm/test/Transforms/Inline/always-inline.ll
===
--- llvm/test/Transforms/Inline/always-inline.ll
+++ llvm/test/Transforms/Inline/always-inline.ll
@@ -1,14 +1,11 @@
-; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
 ;
 ; Ensure the threshold has no impact on these decisions.
-; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
-; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
+; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
 ;
 ; The new pass manager doesn't re-use any threshold based infrastructure for
-; the always inliner, but test that we get the correct result. The new PM
-; always inliner also doesn't support inlining call-site alwaysinline
-; annotations. It isn't clear that this is a reasonable use case for
-; 'alwaysinline'.
+; the always inliner, but test that we get the correct result.
 ; RUN: opt < %s -inline-threshold=0 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
 ; RUN: opt < %s -inline-threshold=2000 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
 ; RUN: opt < %s -inline-threshold=-2000 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
@@ -26,12 +23,6 @@
ret i32 %r
 }
 
-; The always inliner can't DCE arbitrary internal functions. PR2945
-define internal i32 @pr2945() nounwind {
-; CHECK-LABEL: @pr2945(
-  ret i32 0
-}
-
 define internal void @inner2(i32 %N) alwaysinline {
 ; CHECK-NOT: @inner2(
   %P = alloca i32, i32 %N
@@ -146,10 +137,9 @@
   ret i32 1
 }
 define i32 @outer7() {
-; CHECK-CALL-LABEL: @outer7(
-; CHECK-CALL-NOT: call
-; CHECK-CALL: ret
-
+; CHECK-LABEL: @outer7(
+; CHECK-NOT: call
+; CHECK: ret
%r = call i32 @inner7() alwaysinline
ret i32 %r
 }
Index: llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
===
--- llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
+++ llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
@@ -3,9 +3,7 @@
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.12.0"
 
-; CHECK: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
-; CHECK-NEXT: entry:
-; CHECK-NEXT:  unreachable
+; CHECK-NOT: define {{.*}} @f(i8* %buffer, i32* %array)
 
 define internal {i8*, i32} @f(i8* %buffer, i32* %array) {
 entry:
Index: llvm/lib/Transforms/IPO/AlwaysInliner.cpp
===
--- llvm/lib/Transforms/IPO/AlwaysInliner.cpp
+++ llvm/lib/Transforms/IPO/AlwaysInliner.cpp
@@ -54,13 +54,13 @@
 if (F.isPresplitCoroutine())
   continue;
 
-if (!F.isDeclaration() && F.hasFnAttribute(Attribute::AlwaysInline) &&
-isInlineViable(F).isSuccess()) {
+if (!F.isDeclaration() && isInlineViable(F).isSuccess()) {
   Calls.clear();
 
   for (User *U : F.users())
 if (auto *CB = dyn_cast(U))
-  if (CB->getCalledFunction() == )
+  if (CB->getCalledFunction() ==  &&
+  CB->hasFnAttr(Attribute::AlwaysInline))
 Calls.insert(CB);
 
   for (CallBase *CB : Calls) {
Index: clang/test/CodeGenCXX/flatten.cpp
===
--- clang/test/CodeGenCXX/flatten.cpp
+++ clang/test/CodeGenCXX/flatten.cpp
@@ -1,7 +1,3 @@
-// UNSUPPORTED: experimental-new-pass-manager
-// See the comment for CodeGen/flatten.c on why this is unsupported with the new
-// PM.
-
 // RUN: %clang_cc1 -triple=x86_64-linux-gnu -std=c++11 %s -emit-llvm -o - | FileCheck %s
 
 void f(void) {}
Index: clang/test/CodeGen/flatten.c
===
--- clang/test/CodeGen/flatten.c

[clang] ceec438 - [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Dávid Bolvanský via cfe-commits


Author: Dávid Bolvanský
Date: 2022-01-25T22:55:30+01:00
New Revision: ceec4383681c42bfd3d06a6913ce7554bea160b0

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

LOG: [AlwaysInliner] Enable call site inlining to make flatten attribute 
working again (#53360)

Problem: Migration to new PM broke flatten attribute.

This is one use case why LLVM should support inlining call-site with 
alwaysinline.  The flatten attribute is nowdays broken, so we should either 
land patch like this one or remove everything related to  flatten attribute 
from Clang.

Second use case is something like "per call site inlining intrinsics" to 
control inlining even more; mentioned in
https://lists.llvm.org/pipermail/cfe-dev/2018-September/059232.html

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

Reviewed By: aeubanks

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

Added: 


Modified: 
clang/test/CodeGen/flatten.c
clang/test/CodeGenCXX/flatten.cpp
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
llvm/test/Transforms/Inline/always-inline.ll

Removed: 




diff  --git a/clang/test/CodeGen/flatten.c b/clang/test/CodeGen/flatten.c
index 287d4f2a46b65..4e762223de486 100644
--- a/clang/test/CodeGen/flatten.c
+++ b/clang/test/CodeGen/flatten.c
@@ -1,9 +1,3 @@
-// UNSUPPORTED: experimental-new-pass-manager
-// Currently, 
diff erent code seems to be intentionally generated under the new
-// PM since we alwaysinline functions and not callsites under new PM.
-// Under new PM, f() will not be inlined from g() since f is not marked as
-// alwaysinline.
-
 // RUN: %clang_cc1 -triple=x86_64-linux-gnu %s -emit-llvm -o - | FileCheck %s
 
 void f(void) {}

diff  --git a/clang/test/CodeGenCXX/flatten.cpp 
b/clang/test/CodeGenCXX/flatten.cpp
index 7a6484591aaa0..e988d6d726dd7 100644
--- a/clang/test/CodeGenCXX/flatten.cpp
+++ b/clang/test/CodeGenCXX/flatten.cpp
@@ -1,7 +1,3 @@
-// UNSUPPORTED: experimental-new-pass-manager
-// See the comment for CodeGen/flatten.c on why this is unsupported with the 
new
-// PM.
-
 // RUN: %clang_cc1 -triple=x86_64-linux-gnu -std=c++11 %s -emit-llvm -o - | 
FileCheck %s
 
 void f(void) {}

diff  --git a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp 
b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
index 7acc9b266ad82..8f20f59b5e4d7 100644
--- a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
+++ b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
@@ -54,13 +54,13 @@ PreservedAnalyses AlwaysInlinerPass::run(Module ,
 if (F.isPresplitCoroutine())
   continue;
 
-if (!F.isDeclaration() && F.hasFnAttribute(Attribute::AlwaysInline) &&
-isInlineViable(F).isSuccess()) {
+if (!F.isDeclaration() && isInlineViable(F).isSuccess()) {
   Calls.clear();
 
   for (User *U : F.users())
 if (auto *CB = dyn_cast(U))
-  if (CB->getCalledFunction() == )
+  if (CB->getCalledFunction() ==  &&
+  CB->hasFnAttr(Attribute::AlwaysInline))
 Calls.insert(CB);
 
   for (CallBase *CB : Calls) {

diff  --git a/llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll 
b/llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
index d805d7549231d..5d62747180233 100644
--- a/llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
+++ b/llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
@@ -3,9 +3,7 @@
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.12.0"
 
-; CHECK: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
-; CHECK-NEXT: entry:
-; CHECK-NEXT:  unreachable
+; CHECK-NOT: define {{.*}} @f(i8* %buffer, i32* %array)
 
 define internal {i8*, i32} @f(i8* %buffer, i32* %array) {
 entry:

diff  --git a/llvm/test/Transforms/Inline/always-inline.ll 
b/llvm/test/Transforms/Inline/always-inline.ll
index 0fcf956199c46..8eb3d020f6634 100644
--- a/llvm/test/Transforms/Inline/always-inline.ll
+++ b/llvm/test/Transforms/Inline/always-inline.ll
@@ -1,14 +1,11 @@
-; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | 
FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | 
FileCheck %s --check-prefix=CHECK
 ;
 ; Ensure the threshold has no impact on these decisions.
-; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
-; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S 
| FileCheck %s --check-prefix=CHECK
+; RUN: opt < %s -inline-threshold=-2000

[PATCH] D117939: [clang-tidy] Add more documentation about check development

2022-01-25 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

ymandel added a comment.

Overall, this looks fantastic! You may want to consider (in a separate patch) 
mentioning godbolt.org, which is a great UI for interacting with clang-query 
and the AST. Example configuration: https://godbolt.org/z/v88W8ET19

In D117939#3266234 , 
@LegalizeAdulthood wrote:

> In D117939#3266228 , @njames93 
> wrote:
>
>> @aaron.ballman I think this has exposed some limitations with the 
>> add-new-check script. Maybe there is merit for the script to be updated to 
>> support preprocessor callbacks and options, WDYT?
>
> It could certainly use an option to specify that your check is Transformer
> based.

Agreed. Happy to do this if there's interest. I already have a (google) 
internal version of this script that does exactly that. In fact, we set it as 
the default, and require users to explicitly opt out. It is our preference for 
all new clang tidy checks.




Comment at: clang-tools-extra/docs/clang-tidy/Contributing.rst:233-234
+
+If your check applies only under a specific set of language options, you will
+want to override the method ``isLanguageVersionSupported`` to reflect that.
+

nit: "be sure"? (just to vary the language a bit)



Comment at: clang-tools-extra/docs/clang-tidy/Contributing.rst:389-390
+- Test your check under both Windows and Linux environments.
+- Watch out for high false positive rates; ideally there should be none, but a
+  small number may be tolerable.  High false positive rates prevent adoption.
+- Consider configurable options for your check to deal with false positives.

Is it worth giving a rule-of-thumb? Personally I'd go with < 10%, all things 
being equal.  A check for a serious bug may reasonably have a higher false 
positive rate, and trivial checks might not justify *any* false positives. But, 
if neither of these apply, I'd recommend 10% as the default.



Comment at: clang-tools-extra/docs/clang-tidy/Contributing.rst:301-317
+The Transformer library allows you to write a check that transforms source 
code by
+expressing the transformation as a ``RewriteRule``.  The Transformer library 
provides
+functions for composing edits to source code to create rewrite rules.  Unless 
you need
+to perform low-level source location manipulation, you may want to consider 
writing your
+check with the Transformer library.  The `Clang Transformer Tutorial
+`_ describes the 
Transformer
+library in detail.

aaron.ballman wrote:
> LegalizeAdulthood wrote:
> > aaron.ballman wrote:
> > > LegalizeAdulthood wrote:
> > > > aaron.ballman wrote:
> > > > > I think this documentation is really good, but at the same time, I 
> > > > > don't think we have any clang-tidy checks that make use of the 
> > > > > transformer library currently. I don't see a reason we shouldn't 
> > > > > document this more prominently, but I'd like to hear from @ymandel 
> > > > > and/or @alexfh whether they think the library is ready for officially 
> > > > > supported use within clang-tidy and whether we need any sort of 
> > > > > broader community discussion. (I don't see any issues here, just 
> > > > > crossing t's and dotting i's in terms of process.)
> > > > There are at least two checks that use the Transformer library 
> > > > currently.
> > > The only mentions of `TransformerClangTidyCheck.h` that I can find are in 
> > > `ClangTransformerTutorial.rst` and `clang-formatted-files.txt`, so if 
> > > there are other checks using this functionality, they're not following 
> > > what's documented here.
> > `CleanupCtadCheck`, `StringFindStrContainsCheck`, and 
> > `StringviewNullptrCheck` all derive from `TransformerClangTidyCheck`.
> > 
> > The first two are in the `abseil` module and the last is in the `bugprone` 
> > module.
> Oh, interesting, thanks for pointing that out! It turns out that that `clang` 
> and `clang-tools-extra` are different sibling directories and searching 
> `clang` for things you expect to find in `clang-tools-extra` is not very 
> helpful. :-D
> 
> My concerns are no longer a concern here.
My 2cents: definitely comfortable encouraging adoption. In fact, we require it 
on internal checks unless the user has a strong reason to opt out.



Comment at: clang-tools-extra/docs/clang-tidy/Contributing.rst:360-361
+
+Private custom matchers are a good example of auxiliary support code for your 
check
+that is best tested with a unit test.  It will be easier to test your matchers 
or
+other support classes by writing a unit test than by writing a ``FileCheck`` 
integration

aaron.ballman wrote:
> LegalizeAdulthood wrote:
> > aaron.ballman wrote:
> > > LegalizeAdulthood wrote:
> > > > aaron.ballman wrote:
> > > > > Do we have any private matchers that are unit tested? My 
> > > > > understanding was

[PATCH] D118184: [ASan] Not lininking asan_static library for DSO.

2022-01-25 Thread Kirill Stoimenov via Phabricator via cfe-commits

kstoimenov created this revision.
kstoimenov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Whithout this change DSOs fail to link because of missing 
asan_report_(load|store)n functions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118184

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp


Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -826,16 +826,16 @@
   if (SanArgs.needsStatsRt() && SanArgs.linkRuntimes())
 StaticRuntimes.push_back("stats_client");
 
-  // Always link the static runtime regardless of DSO or executable.
-  if (SanArgs.needsAsanRt())
-HelperStaticRuntimes.push_back("asan_static");
-
   // Collect static runtimes.
   if (Args.hasArg(options::OPT_shared)) {
 // Don't link static runtimes into DSOs.
 return;
   }
 
+  // Always link the static runtime for executable.
+  if (SanArgs.needsAsanRt())
+HelperStaticRuntimes.push_back("asan_static");
+
   // Each static runtime that has a DSO counterpart above is excluded below,
   // but runtimes that exist only as static are not affected by needsSharedRt.
 


Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -826,16 +826,16 @@
   if (SanArgs.needsStatsRt() && SanArgs.linkRuntimes())
 StaticRuntimes.push_back("stats_client");
 
-  // Always link the static runtime regardless of DSO or executable.
-  if (SanArgs.needsAsanRt())
-HelperStaticRuntimes.push_back("asan_static");
-
   // Collect static runtimes.
   if (Args.hasArg(options::OPT_shared)) {
 // Don't link static runtimes into DSOs.
 return;
   }
 
+  // Always link the static runtime for executable.
+  if (SanArgs.needsAsanRt())
+HelperStaticRuntimes.push_back("asan_static");
+
   // Each static runtime that has a DSO counterpart above is excluded below,
   // but runtimes that exist only as static are not affected by needsSharedRt.
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118150: [clang] Fix serialized diagnostics edge-cases

2022-01-25 Thread Michael Spencer via Phabricator via cfe-commits

Bigcheese accepted this revision.
Bigcheese 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/D118150/new/

https://reviews.llvm.org/D118150

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

[PATCH] D118169: [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

2022-01-25 Thread Erich Keane via Phabricator via cfe-commits

erichkeane accepted this revision.
erichkeane added a comment.

This looks fine to change, and seems like a slight compile timeimprovement.

It seems that the only thing we use this for is .find, .erase, and operator[], 
all of which don't depend on iterator order, so this should not cause any 
problems with determinism.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118169

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

[PATCH] D118169: [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

2022-01-25 Thread Arthur Eubanks via Phabricator via cfe-commits

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

https://llvm-compile-time-tracker.com/compare.php?from=c39d22d1968cf07e54b5816ba76dccef8acaace1=1958f5a5fb5be3fb5b6bad5079a2f3485db0b0e9=instructions
mostly neutral but a tiny bit of green

seems fine to me


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118169

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

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

2022-01-25 Thread Tom Stellard via Phabricator via cfe-commits

tstellar added a comment.

Can you add a release note to go along with this change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

2022-01-25 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a subscriber: probinson.
dblaikie added a comment.

@probinson for Sony ABI input


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Arthur Eubanks via Phabricator via cfe-commits

aeubanks accepted this revision.
aeubanks added inline comments.
This revision is now accepted and ready to land.



Comment at: llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll:6
 
-; CHECK: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
-; CHECK-NEXT: entry:
-; CHECK-NEXT:  unreachable
+; CHECK-NOT: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
 

`CHECK-NOT: define {{.*}} @f` is probably a bit more robust


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

https://reviews.llvm.org/D117965

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

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

2022-01-25 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added a comment.

Ping @phosek


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D117238: [C2x] Add BITINT_MAXWIDTH support

2022-01-25 Thread Erich Keane via Phabricator via cfe-commits

erichkeane accepted this revision.
erichkeane added a comment.

Accept again, thanks!  Note the purpose of the assert is to make sure that a 
backend doesn't make a bad decision, and the test for 'max size' is only 
validating 1 backend (AND has now been changed to >128 I think).


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

https://reviews.llvm.org/D117238

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

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

2022-01-25 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added a comment.

In addition to the ABI compatibility concern, IMO, GCC's behavior here is 
better and more user friendly:

- C++ classes have methods
- calling a method on a field takes the address of a field
- if the field is in a packed struct, it may be misaligned
- misaligned loads and stores cause UB
- the UB is not trivial or hypothetical: it manifests as a crash, or load/store 
tearing or non-atomicity

GCC prevents users from getting into this situation by ignoring the packed 
attribute in the presence of non-C++98-POD fields and warning the user about 
it. Clang should do the same. Currently, Clang's stance seems to be, if the 
user asks permission to shoot themselves in the foot, they can go right ahead. 
That's less than ideal.

Between the usability concern and the ABI concern, it seems worth changing 
behavior here, even if it means leaving behind a flag or a new attribute such 
as `__attribute__((packed_nonpod))` to get the old behavior. I don't see a PS4 
reviewer here, but every time I've asked them if we can tweak some ABI detail, 
they ask to be opted out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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

[PATCH] D112915: [clang][modules] Track included files per submodule

2022-01-25 Thread Volodymyr Sapsai via Phabricator via cfe-commits

vsapsai added a comment.

Can you please rebase this change after D114095 
 lands? Overall looks good but I want to take 
one final look and triggering the pre-merge checks will be useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112915

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

[PATCH] D117238: [C2x] Add BITINT_MAXWIDTH support

2022-01-25 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman updated this revision to Diff 403008.
aaron.ballman added a comment.

Updated based on review feedback. I added an additional assert to test that the 
value picked by the target meets the requirements from the C standard. (We 
already had a test case for it in lit, but no reason not to assert for even 
earlier notification of an issue.)


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

https://reviews.llvm.org/D117238

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Headers/limits.h
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/ext-int-cc.c
  clang/test/CodeGen/ext-int.c
  clang/test/CodeGenCXX/ext-int.cpp
  clang/test/Headers/limits.cpp
  clang/test/Preprocessor/init-aarch64.c
  clang/test/Preprocessor/init.c
  clang/test/Sema/builtins-overflow.c
  clang/test/SemaCXX/ext-int.cpp

Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -28,9 +28,9 @@
   constexpr _BitInt(6) n = 33; // expected-warning{{implicit conversion from 'int' to 'const _BitInt(6)' changes value from 33 to -31}}
   constexpr _BitInt(7) o = 33;
 
-  // Check LLVM imposed max size.
-  _BitInt(8388609) p;   // expected-error {{signed _BitInt of bit sizes greater than 8388608 not supported}}
-  unsigned _BitInt(0xFF) q; // expected-error {{unsigned _BitInt of bit sizes greater than 8388608 not supported}}
+  // Check imposed max size.
+  _BitInt(129) p;   // expected-error {{signed _BitInt of bit sizes greater than 128 not supported}}
+  unsigned _BitInt(0xFF) q; // expected-error {{unsigned _BitInt of bit sizes greater than 128 not supported}}
 
 // Ensure template params are instantiated correctly.
   // expected-error@5{{signed _BitInt must have a bit size of at least 2}}
@@ -186,14 +186,8 @@
   static_assert(sizeof(x43_s) == 8, "");
   static_assert(sizeof(x4_s) == 1, "");
 
-  static_assert(sizeof(_BitInt(3340)) == 424, ""); // 424 * 8 == 3392.
-  static_assert(sizeof(_BitInt(1049)) == 136, ""); // 136  *  8 == 1088.
-
   static_assert(alignof(decltype(x43_s)) == 8, "");
   static_assert(alignof(decltype(x4_s)) == 1, "");
-
-  static_assert(alignof(_BitInt(3340)) == 8, "");
-  static_assert(alignof(_BitInt(1049)) == 8, "");
 }
 
 constexpr int func() { return 42;}
Index: clang/test/Sema/builtins-overflow.c
===
--- clang/test/Sema/builtins-overflow.c
+++ clang/test/Sema/builtins-overflow.c
@@ -26,6 +26,7 @@
 _BitInt(128) result;
 _Bool status = __builtin_mul_overflow(x, y, ); // expect ok
   }
+#if __BITINT_MAXWIDTH__ > 128
   {
 unsigned _BitInt(129) x = 1;
 unsigned _BitInt(129) y = 1;
@@ -38,4 +39,5 @@
 _BitInt(129) result;
 _Bool status = __builtin_mul_overflow(x, y, ); // expected-error {{__builtin_mul_overflow does not support 'signed _BitInt' operands of more than 128 bits}}
   }
+#endif
 }
Index: clang/test/Preprocessor/init.c
===
--- clang/test/Preprocessor/init.c
+++ clang/test/Preprocessor/init.c
@@ -1520,6 +1520,7 @@
 // WEBASSEMBLY-NEXT:#define __ATOMIC_RELEASE 3
 // WEBASSEMBLY-NEXT:#define __ATOMIC_SEQ_CST 5
 // WEBASSEMBLY-NEXT:#define __BIGGEST_ALIGNMENT__ 16
+// WEBASSEMBLY-NEXT:#define __BITINT_MAXWIDTH__ 128
 // WEBASSEMBLY-NEXT:#define __BOOL_WIDTH__ 8
 // WEBASSEMBLY-NEXT:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
 // WEBASSEMBLY-NEXT:#define __CHAR16_TYPE__ unsigned short
Index: clang/test/Preprocessor/init-aarch64.c
===
--- clang/test/Preprocessor/init-aarch64.c
+++ clang/test/Preprocessor/init-aarch64.c
@@ -40,6 +40,7 @@
 // AARCH64-NEXT: #define __ATOMIC_SEQ_CST 5
 // AARCH64:  #define __BIGGEST_ALIGNMENT__ 16
 // AARCH64_BE-NEXT: #define __BIG_ENDIAN__ 1
+// AARCH64-NEXT: #define __BITINT_MAXWIDTH__ 128
 // AARCH64-NEXT: #define __BOOL_WIDTH__ 8
 // AARCH64_BE-NEXT: #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__
 // AARCH64_LE-NEXT: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
Index: clang/test/Headers/limits.cpp
===
--- clang/test/Headers/limits.cpp
+++ clang/test/Headers/limits.cpp
@@ -74,8 +74,11 @@
 _Static_assert(ULLONG_WIDTH / CHAR_BIT == sizeof(unsigned long long));
 _Static_assert(LLONG_WIDTH == ULLONG_WIDTH);
 _Static_assert(LLONG_WIDTH / CHAR_BIT == sizeof(signed long long));
+
+_Static_assert(BITINT_MAXWIDTH >= ULLONG_WIDTH);
 #else
 /* None of these are defined. */
 int BOOL_WIDTH, CHAR_WIDTH, SCHAR_WIDTH, UCHAR_WIDTH, USHRT_WIDTH, SHRT_WIDTH,
-UINT_WIDTH, INT_WIDTH, ULONG_WIDTH, LONG_WIDTH, ULLONG_WIDTH, LLONG_WIDTH;
+UINT_WIDTH, INT_WIDTH, ULONG_WIDTH, LONG_WIDTH, ULLONG_WIDTH, LLONG_WIDTH,
+BITINT_MAXWIDTH;
 #endif

[PATCH] D118178: [clang][dataflow] Allow clients to disable built-in transfer functions.

2022-01-25 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

ymandel created this revision.
ymandel added a reviewer: sgatev.
Herald added subscribers: tschuett, steakhal.
ymandel requested review of this revision.
Herald added a project: clang.

These built-in functions build the (sophisticated) model of the code's
memory. This model isn't used by all analyses, so we provide for disabling it to
avoid incurring the costs associated with its construction.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118178

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
  clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -42,6 +42,8 @@
 template 
 class AnalysisCallback : public ast_matchers::MatchFinder::MatchCallback {
 public:
+  AnalysisCallback(AnalysisT (*MakeAnalysis)(ASTContext &))
+  : MakeAnalysis(MakeAnalysis) {}
   void run(const ast_matchers::MatchFinder::MatchResult ) override {
 assert(BlockStates.empty());
 
@@ -54,12 +56,13 @@
 auto CFCtx = llvm::cantFail(
 ControlFlowContext::build(nullptr, Body, Result.Context));
 
-AnalysisT Analysis(*Result.Context);
+AnalysisT Analysis = MakeAnalysis(*Result.Context);
 DataflowAnalysisContext DACtx;
 Environment Env(DACtx);
 BlockStates = runDataflowAnalysis(CFCtx, Analysis, Env);
   }
 
+  AnalysisT (*MakeAnalysis)(ASTContext &);
   std::vector<
   llvm::Optional>>
   BlockStates;
@@ -67,11 +70,11 @@
 
 template 
 std::vector>>
-runAnalysis(llvm::StringRef Code) {
+runAnalysis(llvm::StringRef Code, AnalysisT (*MakeAnalysis)(ASTContext &)) {
   std::unique_ptr AST =
   tooling::buildASTFromCodeWithArgs(Code, {"-std=c++11"});
 
-  AnalysisCallback Callback;
+  AnalysisCallback Callback(MakeAnalysis);
   ast_matchers::MatchFinder Finder;
   Finder.addMatcher(
   ast_matchers::functionDecl(ast_matchers::hasName("target")).bind("func"),
@@ -82,9 +85,8 @@
 }
 
 TEST(DataflowAnalysisTest, NoopAnalysis) {
-  auto BlockStates = runAnalysis(R"(
-void target() {}
-  )");
+  auto BlockStates = runAnalysis(
+  "void target() {}", [](ASTContext ) { return NoopAnalysis(C, false); });
   EXPECT_EQ(BlockStates.size(), 2u);
   EXPECT_TRUE(BlockStates[0].hasValue());
   EXPECT_TRUE(BlockStates[1].hasValue());
@@ -109,8 +111,9 @@
 : public DataflowAnalysis {
 public:
   explicit NonConvergingAnalysis(ASTContext )
-  : DataflowAnalysis(Context) {
-  }
+  : DataflowAnalysis(
+Context,
+/*ApplyBuiltinTransfer=*/false) {}
 
   static NonConvergingLattice initialElement() { return {0}; }
 
@@ -120,11 +123,13 @@
 };
 
 TEST(DataflowAnalysisTest, NonConvergingAnalysis) {
-  auto BlockStates = runAnalysis(R"(
+  auto BlockStates = runAnalysis(
+  R"(
 void target() {
   while(true) {}
 }
-  )");
+  )",
+  [](ASTContext ) { return NonConvergingAnalysis(C); });
   EXPECT_EQ(BlockStates.size(), 4u);
   EXPECT_TRUE(BlockStates[0].hasValue());
   EXPECT_TRUE(BlockStates[1].hasValue());
Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -40,11 +40,14 @@
 protected:
   template 
   void runDataflow(llvm::StringRef Code, Matcher Match,
-   LangStandard::Kind Std = LangStandard::lang_cxx17) {
+   LangStandard::Kind Std = LangStandard::lang_cxx17,
+   bool ApplyBuiltinTransfer = true) {
 ASSERT_THAT_ERROR(
 test::checkDataflow(
 Code, "target",
-[](ASTContext , Environment &) { return NoopAnalysis(C); },
+[ApplyBuiltinTransfer](ASTContext , Environment &) {
+  return NoopAnalysis(C, ApplyBuiltinTransfer);
+},
 [](
 llvm::ArrayRef<
 std::pair>>
@@ -73,6 +76,31 @@
   return Result;
 }
 
+TEST_F(TransferTest, IntVarDeclNotTrackedWhenTransferDisabled) {
+  std::string Code = R"(
+void target() {
+  int Foo;
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext ) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment  = Results[0].second.Env;
+
+const

[PATCH] D45438: [CodeView] Enable debugging of captured variables within C++ lambdas

2022-01-25 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added inline comments.



Comment at: lib/CodeGen/CGDebugInfo.cpp:812-814
+  // CodeView types with C++ mangling need a type identifier.
+  if (CGM.getCodeGenOpts().EmitCodeView)
+return true;

dblaikie wrote:
> rnk wrote:
> > dblaikie wrote:
> > > bwyma wrote:
> > > > dblaikie wrote:
> > > > > rnk wrote:
> > > > > > rnk wrote:
> > > > > > > dblaikie wrote:
> > > > > > > > Just came across this code today - it's /probably/ a problem 
> > > > > > > > for LTO. LLVM IR linking depends on the identifier to determine 
> > > > > > > > if two structs are the same for linkage purposes - so if an 
> > > > > > > > identifier is added for a non-linkage (local/not externally 
> > > > > > > > visible) type, LLVM will consider them to be the same even 
> > > > > > > > though they're unrelated:
> > > > > > > > ```
> > > > > > > > namespace { struct t1 { int i; int j; }; }
> > > > > > > > t1 v1;
> > > > > > > > void *v3 = 
> > > > > > > > ```
> > > > > > > > ```
> > > > > > > > namespace { struct t1 { int i; }; }
> > > > > > > > t1 v1;
> > > > > > > > void *v2 = 
> > > > > > > > ```
> > > > > > > > ```
> > > > > > > > $ clang++-tot -emit-llvm -S a.cpp b.cpp -g -gcodeview  && 
> > > > > > > > ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && 
> > > > > > > > ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep 
> > > > > > > > "\"t1\""
> > > > > > > > !8 = distinct !DICompositeType(tag: DW_TAG_structure_type, 
> > > > > > > > name: "t1", scope: !9, file: !3, line: 1, size: 64, flags: 
> > > > > > > > DIFlagTypePassByValue, elements: !10, identifier: 
> > > > > > > > "_ZTSN12_GLOBAL__N_12t1E")
> > > > > > > > $ clang++-tot -emit-llvm -S a.cpp b.cpp -g && 
> > > > > > > > ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && 
> > > > > > > > ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep 
> > > > > > > > "\"t1\""
> > > > > > > > !8 = distinct !DICompositeType(tag: DW_TAG_structure_type, 
> > > > > > > > name: "t1", scope: !9, file: !3, line: 1, size: 64, flags: 
> > > > > > > > DIFlagTypePassByValue, elements: !10)
> > > > > > > > !21 = distinct !DICompositeType(tag: DW_TAG_structure_type, 
> > > > > > > > name: "t1", scope: !9, file: !17, line: 1, size: 32, flags: 
> > > > > > > > DIFlagTypePassByValue, elements: !22)
> > > > > > > > ```
> > > > > > > > 
> > > > > > > > So in linking, now both `a.cpp` and `b.cpp` refer to a single 
> > > > > > > > `t1` type (in this case, it looks like the first one - the 64 
> > > > > > > > bit wide one).
> > > > > > > > 
> > > > > > > > If CodeView actually can't represent these two distinct types 
> > > > > > > > with the same name in the same object file, so be it? But this 
> > > > > > > > looks like it's likely to cause problems for consumers/users.
> > > > > > > If you use the MSVC ABI, we will assign unique identifiers to 
> > > > > > > these two structs:
> > > > > > > ```
> > > > > > > !9 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > > > "t1", scope: !10, file: !7, line: 1, size: 64, flags: 
> > > > > > > DIFlagTypePassByValue, elements: !11, identifier: 
> > > > > > > ".?AUt1@?A0xF964240C@@")
> > > > > > > ```
> > > > > > > 
> > > > > > > The `A0xF964240C` is set up here, and it is based on the source 
> > > > > > > file path (the hash will only be unique when source file paths 
> > > > > > > are unique across the build):
> > > > > > > https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/MicrosoftMangle.cpp#L464
> > > > > > > ```
> > > > > > >   // It's important to make the mangled names unique because, 
> > > > > > > when CodeView
> > > > > > >   // debug info is in use, the debugger uses mangled type names 
> > > > > > > to distinguish
> > > > > > >   // between otherwise identically named types in anonymous 
> > > > > > > namespaces.
> > > > > > > ```
> > > > > > > 
> > > > > > > Maybe this should use a "is MSVC ABI" check instead, since that 
> > > > > > > is what controls whether the identifier will be unique, and the 
> > > > > > > unique-ness is what matters for LTO and PDBs.
> > > > > > After thinking about it some more, see the comment I added here: 
> > > > > > rG59320fc9d78237a5f9fdd6a5030d6554bb6976ce
> > > > > > 
> > > > > > ```
> > > > > > // If the type is not externally visible, it should be unique to 
> > > > > > the current TU,
> > > > > > // and should not need an identifier to participate in type 
> > > > > > deduplication.
> > > > > > // However, when emitting CodeView, the format internally uses these
> > > > > > // unique type name identifers for references between debug info. 
> > > > > > For example,
> > > > > > // the method of a class in an anonymous namespace uses the 
> > > > > > identifer to refer
> > > > > > // to its parent class. The Microsoft C++ ABI attempts to provide 
> > > > > > unique names
> > > > > > // for such types, so when emitting CodeView, always use 
> > > > > > identifiers for C++
> > > > > > // types. This may

[PATCH] D114095: [clang][lex] Include tracking: simplify and move to preprocessor

2022-01-25 Thread Volodymyr Sapsai via Phabricator via cfe-commits

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

Looks good to me. Thanks for working on it!

Though I haven't built it locally and it can be useful for pre-merge checks to 
finish.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114095

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

[PATCH] D45438: [CodeView] Enable debugging of captured variables within C++ lambdas

2022-01-25 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added inline comments.



Comment at: lib/CodeGen/CGDebugInfo.cpp:812-814
+  // CodeView types with C++ mangling need a type identifier.
+  if (CGM.getCodeGenOpts().EmitCodeView)
+return true;

rnk wrote:
> dblaikie wrote:
> > bwyma wrote:
> > > dblaikie wrote:
> > > > rnk wrote:
> > > > > rnk wrote:
> > > > > > dblaikie wrote:
> > > > > > > Just came across this code today - it's /probably/ a problem for 
> > > > > > > LTO. LLVM IR linking depends on the identifier to determine if 
> > > > > > > two structs are the same for linkage purposes - so if an 
> > > > > > > identifier is added for a non-linkage (local/not externally 
> > > > > > > visible) type, LLVM will consider them to be the same even though 
> > > > > > > they're unrelated:
> > > > > > > ```
> > > > > > > namespace { struct t1 { int i; int j; }; }
> > > > > > > t1 v1;
> > > > > > > void *v3 = 
> > > > > > > ```
> > > > > > > ```
> > > > > > > namespace { struct t1 { int i; }; }
> > > > > > > t1 v1;
> > > > > > > void *v2 = 
> > > > > > > ```
> > > > > > > ```
> > > > > > > $ clang++-tot -emit-llvm -S a.cpp b.cpp -g -gcodeview  && 
> > > > > > > ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && 
> > > > > > > ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep 
> > > > > > > "\"t1\""
> > > > > > > !8 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > > > "t1", scope: !9, file: !3, line: 1, size: 64, flags: 
> > > > > > > DIFlagTypePassByValue, elements: !10, identifier: 
> > > > > > > "_ZTSN12_GLOBAL__N_12t1E")
> > > > > > > $ clang++-tot -emit-llvm -S a.cpp b.cpp -g && 
> > > > > > > ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && 
> > > > > > > ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep 
> > > > > > > "\"t1\""
> > > > > > > !8 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > > > "t1", scope: !9, file: !3, line: 1, size: 64, flags: 
> > > > > > > DIFlagTypePassByValue, elements: !10)
> > > > > > > !21 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > > > "t1", scope: !9, file: !17, line: 1, size: 32, flags: 
> > > > > > > DIFlagTypePassByValue, elements: !22)
> > > > > > > ```
> > > > > > > 
> > > > > > > So in linking, now both `a.cpp` and `b.cpp` refer to a single 
> > > > > > > `t1` type (in this case, it looks like the first one - the 64 bit 
> > > > > > > wide one).
> > > > > > > 
> > > > > > > If CodeView actually can't represent these two distinct types 
> > > > > > > with the same name in the same object file, so be it? But this 
> > > > > > > looks like it's likely to cause problems for consumers/users.
> > > > > > If you use the MSVC ABI, we will assign unique identifiers to these 
> > > > > > two structs:
> > > > > > ```
> > > > > > !9 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > > "t1", scope: !10, file: !7, line: 1, size: 64, flags: 
> > > > > > DIFlagTypePassByValue, elements: !11, identifier: 
> > > > > > ".?AUt1@?A0xF964240C@@")
> > > > > > ```
> > > > > > 
> > > > > > The `A0xF964240C` is set up here, and it is based on the source 
> > > > > > file path (the hash will only be unique when source file paths are 
> > > > > > unique across the build):
> > > > > > https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/MicrosoftMangle.cpp#L464
> > > > > > ```
> > > > > >   // It's important to make the mangled names unique because, when 
> > > > > > CodeView
> > > > > >   // debug info is in use, the debugger uses mangled type names to 
> > > > > > distinguish
> > > > > >   // between otherwise identically named types in anonymous 
> > > > > > namespaces.
> > > > > > ```
> > > > > > 
> > > > > > Maybe this should use a "is MSVC ABI" check instead, since that is 
> > > > > > what controls whether the identifier will be unique, and the 
> > > > > > unique-ness is what matters for LTO and PDBs.
> > > > > After thinking about it some more, see the comment I added here: 
> > > > > rG59320fc9d78237a5f9fdd6a5030d6554bb6976ce
> > > > > 
> > > > > ```
> > > > > // If the type is not externally visible, it should be unique to the 
> > > > > current TU,
> > > > > // and should not need an identifier to participate in type 
> > > > > deduplication.
> > > > > // However, when emitting CodeView, the format internally uses these
> > > > > // unique type name identifers for references between debug info. For 
> > > > > example,
> > > > > // the method of a class in an anonymous namespace uses the identifer 
> > > > > to refer
> > > > > // to its parent class. The Microsoft C++ ABI attempts to provide 
> > > > > unique names
> > > > > // for such types, so when emitting CodeView, always use identifiers 
> > > > > for C++
> > > > > // types. This may create problems when attempting to emit CodeView 
> > > > > when the MS
> > > > > // C++ ABI is not in use.
> > > > > ```
> > > > > 
> > > > > I think type identifiers are pretty crucial for CodeView

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added inline comments.



Comment at: llvm/lib/Transforms/IPO/AlwaysInliner.cpp:95
 
-  // Remember to try and delete this function afterward. This both avoids
-  // re-walking the rest of the module and avoids dealing with any iterator
-  // invalidation issues while deleting functions.
-  InlinedFunctions.push_back();
+  if (F.hasFnAttribute(Attribute::AlwaysInline))
+// Remember to try and delete this function afterward. This both avoids

aeubanks wrote:
> xbolva00 wrote:
> > avoid DCE of internal functions without always_inline; check test pr2945 in 
> > always-inline.ll
> no need to change in this patch, but it looks like that was a past 
> limitation, removing any dead internal function should be fine (subject to 
> comdats). either we should not delete any function or we should attempt to 
> remove any function we can
Thanks for info, changed to delete them.



Comment at: llvm/test/Transforms/Inline/always-inline.ll:150
 
+define i32 @outer7b() {
+; CHECK-LABEL: @outer7b(

aeubanks wrote:
> s/CHECK-CALL/CHECK/g should be good enough? any reason for outer7b? it's 
> exactly the same as outer7a
Yes, simplified.


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

https://reviews.llvm.org/D117965

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

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 updated this revision to Diff 402997.

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

https://reviews.llvm.org/D117965

Files:
  clang/test/CodeGen/flatten.c
  clang/test/CodeGenCXX/flatten.cpp
  llvm/lib/Transforms/IPO/AlwaysInliner.cpp
  llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
  llvm/test/Transforms/Inline/always-inline.ll

Index: llvm/test/Transforms/Inline/always-inline.ll
===
--- llvm/test/Transforms/Inline/always-inline.ll
+++ llvm/test/Transforms/Inline/always-inline.ll
@@ -1,14 +1,11 @@
-; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
 ;
 ; Ensure the threshold has no impact on these decisions.
-; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
-; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
+; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
 ;
 ; The new pass manager doesn't re-use any threshold based infrastructure for
-; the always inliner, but test that we get the correct result. The new PM
-; always inliner also doesn't support inlining call-site alwaysinline
-; annotations. It isn't clear that this is a reasonable use case for
-; 'alwaysinline'.
+; the always inliner, but test that we get the correct result.
 ; RUN: opt < %s -inline-threshold=0 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
 ; RUN: opt < %s -inline-threshold=2000 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
 ; RUN: opt < %s -inline-threshold=-2000 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
@@ -26,12 +23,6 @@
ret i32 %r
 }
 
-; The always inliner can't DCE arbitrary internal functions. PR2945
-define internal i32 @pr2945() nounwind {
-; CHECK-LABEL: @pr2945(
-  ret i32 0
-}
-
 define internal void @inner2(i32 %N) alwaysinline {
 ; CHECK-NOT: @inner2(
   %P = alloca i32, i32 %N
@@ -146,10 +137,9 @@
   ret i32 1
 }
 define i32 @outer7() {
-; CHECK-CALL-LABEL: @outer7(
-; CHECK-CALL-NOT: call
-; CHECK-CALL: ret
-
+; CHECK-LABEL: @outer7(
+; CHECK-NOT: call
+; CHECK: ret
%r = call i32 @inner7() alwaysinline
ret i32 %r
 }
Index: llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
===
--- llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
+++ llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
@@ -3,9 +3,7 @@
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.12.0"
 
-; CHECK: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
-; CHECK-NEXT: entry:
-; CHECK-NEXT:  unreachable
+; CHECK-NOT: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
 
 define internal {i8*, i32} @f(i8* %buffer, i32* %array) {
 entry:
Index: llvm/lib/Transforms/IPO/AlwaysInliner.cpp
===
--- llvm/lib/Transforms/IPO/AlwaysInliner.cpp
+++ llvm/lib/Transforms/IPO/AlwaysInliner.cpp
@@ -54,13 +54,13 @@
 if (F.isPresplitCoroutine())
   continue;
 
-if (!F.isDeclaration() && F.hasFnAttribute(Attribute::AlwaysInline) &&
-isInlineViable(F).isSuccess()) {
+if (!F.isDeclaration() && isInlineViable(F).isSuccess()) {
   Calls.clear();
 
   for (User *U : F.users())
 if (auto *CB = dyn_cast(U))
-  if (CB->getCalledFunction() == )
+  if (CB->getCalledFunction() ==  &&
+  CB->hasFnAttr(Attribute::AlwaysInline))
 Calls.insert(CB);
 
   for (CallBase *CB : Calls) {
Index: clang/test/CodeGenCXX/flatten.cpp
===
--- clang/test/CodeGenCXX/flatten.cpp
+++ clang/test/CodeGenCXX/flatten.cpp
@@ -1,7 +1,3 @@
-// UNSUPPORTED: experimental-new-pass-manager
-// See the comment for CodeGen/flatten.c on why this is unsupported with the new
-// PM.
-
 // RUN: %clang_cc1 -triple=x86_64-linux-gnu -std=c++11 %s -emit-llvm -o - | FileCheck %s
 
 void f(void) {}
Index: clang/test/CodeGen/flatten.c
===
--- clang/test/CodeGen/flatten.c
+++ clang/test/CodeGen/flatten.c
@@ -1,9 +1,3 @@
-// UNSUPPORTED: experimental-new-pass-manager
-// Currently, different code seems to be intentionally generated under the new
-// PM since we alwaysinline functions and not callsites under new PM.
-// Under new PM, f() will not be inlined from g() since f is not marked as

[PATCH] D117939: [clang-tidy] Add more documentation about check development

2022-01-25 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

Aside from the unit testing bit, I think this is fantastic! (And the unit 
testing bit may also be fantastic, I just think it needs more explicit 
discussion with a wider audience.)




Comment at: clang-tools-extra/docs/clang-tidy/Contributing.rst:301-317
+The Transformer library allows you to write a check that transforms source 
code by
+expressing the transformation as a ``RewriteRule``.  The Transformer library 
provides
+functions for composing edits to source code to create rewrite rules.  Unless 
you need
+to perform low-level source location manipulation, you may want to consider 
writing your
+check with the Transformer library.  The `Clang Transformer Tutorial
+`_ describes the 
Transformer
+library in detail.

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > LegalizeAdulthood wrote:
> > > aaron.ballman wrote:
> > > > I think this documentation is really good, but at the same time, I 
> > > > don't think we have any clang-tidy checks that make use of the 
> > > > transformer library currently. I don't see a reason we shouldn't 
> > > > document this more prominently, but I'd like to hear from @ymandel 
> > > > and/or @alexfh whether they think the library is ready for officially 
> > > > supported use within clang-tidy and whether we need any sort of broader 
> > > > community discussion. (I don't see any issues here, just crossing t's 
> > > > and dotting i's in terms of process.)
> > > There are at least two checks that use the Transformer library currently.
> > The only mentions of `TransformerClangTidyCheck.h` that I can find are in 
> > `ClangTransformerTutorial.rst` and `clang-formatted-files.txt`, so if there 
> > are other checks using this functionality, they're not following what's 
> > documented here.
> `CleanupCtadCheck`, `StringFindStrContainsCheck`, and 
> `StringviewNullptrCheck` all derive from `TransformerClangTidyCheck`.
> 
> The first two are in the `abseil` module and the last is in the `bugprone` 
> module.
Oh, interesting, thanks for pointing that out! It turns out that that `clang` 
and `clang-tools-extra` are different sibling directories and searching `clang` 
for things you expect to find in `clang-tools-extra` is not very helpful. :-D

My concerns are no longer a concern here.



Comment at: clang-tools-extra/docs/clang-tidy/Contributing.rst:360-361
+
+Private custom matchers are a good example of auxiliary support code for your 
check
+that is best tested with a unit test.  It will be easier to test your matchers 
or
+other support classes by writing a unit test than by writing a ``FileCheck`` 
integration

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > LegalizeAdulthood wrote:
> > > aaron.ballman wrote:
> > > > Do we have any private matchers that are unit tested? My understanding 
> > > > was that the public matchers were all unit tested, but that the 
> > > > matchers which are local to a check are not exposed via a header file, 
> > > > and so they're not really unit testable.
> > > I just did this for my switch/case/label update to simplify boolean 
> > > expressions.
> > > You do have to expose them via a header file, which isn't a big deal.
> > > You do have to expose them via a header file, which isn't a big deal.
> > 
> > Then they become part of the public interface for the check and anything 
> > which includes the header file has to do heavy template instantiation work 
> > that contributes more symbols to the built library. In general, we don't 
> > expect private matchers to be unit tested -- we expect the tests for the 
> > check to exercise the matcher appropriately.
> Look at my review to see how I handled it; the matchers are in a seperate
> header file, in my case `SimplifyBooleanExprMatchers.h` and aren't exposed
> to consumers of the check.  The matchers header is only included by the
> implementation and the matcher tests.
> 
Thanks for pointing out how you're doing it in one of your checks -- I still 
don't think we should document that we expect people to unit test private 
matchers unless clang-tidy reviewers are on board with the idea in general. 
IMO, that's putting a burden on check authors and all the reviewers to do 
something that's never been suggested before (let alone documented as a best 
practice) -- that's worthy of open discussion instead of adding it to a patch 
intended to document current practices.


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

https://reviews.llvm.org/D117939

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

[PATCH] D117238: [C2x] Add BITINT_MAXWIDTH support

2022-01-25 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added inline comments.



Comment at: clang/lib/Frontend/InitPreprocessor.cpp:917
 
+  Builder.defineMacro("__BITINT_MAXWIDTH__", Twine(TI.getMaxBitIntWidth()));
+

Could you do an assert that TI.getMaxBitIntWidth() is not greater than the LLVM 
maximum (just somewhere, here seemed to make the most sense).


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

https://reviews.llvm.org/D117238

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

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

Thanks, addressed review comments.

> we should reconsider the attribute support

I agree.


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

https://reviews.llvm.org/D117965

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

[PATCH] D45438: [CodeView] Enable debugging of captured variables within C++ lambdas

2022-01-25 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added inline comments.



Comment at: lib/CodeGen/CGDebugInfo.cpp:812-814
+  // CodeView types with C++ mangling need a type identifier.
+  if (CGM.getCodeGenOpts().EmitCodeView)
+return true;

dblaikie wrote:
> bwyma wrote:
> > dblaikie wrote:
> > > rnk wrote:
> > > > rnk wrote:
> > > > > dblaikie wrote:
> > > > > > Just came across this code today - it's /probably/ a problem for 
> > > > > > LTO. LLVM IR linking depends on the identifier to determine if two 
> > > > > > structs are the same for linkage purposes - so if an identifier is 
> > > > > > added for a non-linkage (local/not externally visible) type, LLVM 
> > > > > > will consider them to be the same even though they're unrelated:
> > > > > > ```
> > > > > > namespace { struct t1 { int i; int j; }; }
> > > > > > t1 v1;
> > > > > > void *v3 = 
> > > > > > ```
> > > > > > ```
> > > > > > namespace { struct t1 { int i; }; }
> > > > > > t1 v1;
> > > > > > void *v2 = 
> > > > > > ```
> > > > > > ```
> > > > > > $ clang++-tot -emit-llvm -S a.cpp b.cpp -g -gcodeview  && 
> > > > > > ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && 
> > > > > > ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep 
> > > > > > "\"t1\""
> > > > > > !8 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > > "t1", scope: !9, file: !3, line: 1, size: 64, flags: 
> > > > > > DIFlagTypePassByValue, elements: !10, identifier: 
> > > > > > "_ZTSN12_GLOBAL__N_12t1E")
> > > > > > $ clang++-tot -emit-llvm -S a.cpp b.cpp -g && 
> > > > > > ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && 
> > > > > > ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep 
> > > > > > "\"t1\""
> > > > > > !8 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > > "t1", scope: !9, file: !3, line: 1, size: 64, flags: 
> > > > > > DIFlagTypePassByValue, elements: !10)
> > > > > > !21 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > > "t1", scope: !9, file: !17, line: 1, size: 32, flags: 
> > > > > > DIFlagTypePassByValue, elements: !22)
> > > > > > ```
> > > > > > 
> > > > > > So in linking, now both `a.cpp` and `b.cpp` refer to a single `t1` 
> > > > > > type (in this case, it looks like the first one - the 64 bit wide 
> > > > > > one).
> > > > > > 
> > > > > > If CodeView actually can't represent these two distinct types with 
> > > > > > the same name in the same object file, so be it? But this looks 
> > > > > > like it's likely to cause problems for consumers/users.
> > > > > If you use the MSVC ABI, we will assign unique identifiers to these 
> > > > > two structs:
> > > > > ```
> > > > > !9 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: 
> > > > > "t1", scope: !10, file: !7, line: 1, size: 64, flags: 
> > > > > DIFlagTypePassByValue, elements: !11, identifier: 
> > > > > ".?AUt1@?A0xF964240C@@")
> > > > > ```
> > > > > 
> > > > > The `A0xF964240C` is set up here, and it is based on the source file 
> > > > > path (the hash will only be unique when source file paths are unique 
> > > > > across the build):
> > > > > https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/MicrosoftMangle.cpp#L464
> > > > > ```
> > > > >   // It's important to make the mangled names unique because, when 
> > > > > CodeView
> > > > >   // debug info is in use, the debugger uses mangled type names to 
> > > > > distinguish
> > > > >   // between otherwise identically named types in anonymous 
> > > > > namespaces.
> > > > > ```
> > > > > 
> > > > > Maybe this should use a "is MSVC ABI" check instead, since that is 
> > > > > what controls whether the identifier will be unique, and the 
> > > > > unique-ness is what matters for LTO and PDBs.
> > > > After thinking about it some more, see the comment I added here: 
> > > > rG59320fc9d78237a5f9fdd6a5030d6554bb6976ce
> > > > 
> > > > ```
> > > > // If the type is not externally visible, it should be unique to the 
> > > > current TU,
> > > > // and should not need an identifier to participate in type 
> > > > deduplication.
> > > > // However, when emitting CodeView, the format internally uses these
> > > > // unique type name identifers for references between debug info. For 
> > > > example,
> > > > // the method of a class in an anonymous namespace uses the identifer 
> > > > to refer
> > > > // to its parent class. The Microsoft C++ ABI attempts to provide 
> > > > unique names
> > > > // for such types, so when emitting CodeView, always use identifiers 
> > > > for C++
> > > > // types. This may create problems when attempting to emit CodeView 
> > > > when the MS
> > > > // C++ ABI is not in use.
> > > > ```
> > > > 
> > > > I think type identifiers are pretty crucial for CodeView functionality. 
> > > > The debugger won't be able to link a method to its class without them. 
> > > > Therefore, I think it's better to leave this as it is. The bad 
> > > > experience of duplicate type identifiers is

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

2022-01-25 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 updated this revision to Diff 402994.
xbolva00 retitled this revision from "[AlwaysInliner] Enable call site inlining 
to make flatten attribute working again (PR53360)" to "[AlwaysInliner] Enable 
call site inlining to make flatten attribute working again (#53360)".
Herald added a subscriber: pengfei.

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

https://reviews.llvm.org/D117965

Files:
  clang/test/CodeGen/flatten.c
  clang/test/CodeGenCXX/flatten.cpp
  llvm/lib/Transforms/IPO/AlwaysInliner.cpp
  llvm/test/CodeGen/X86/x86-cmov-converter.ll
  llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
  llvm/test/Transforms/Inline/always-inline.ll

Index: llvm/test/Transforms/Inline/always-inline.ll
===
--- llvm/test/Transforms/Inline/always-inline.ll
+++ llvm/test/Transforms/Inline/always-inline.ll
@@ -1,14 +1,11 @@
-; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=0 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
 ;
 ; Ensure the threshold has no impact on these decisions.
-; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
-; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-CALL
+; RUN: opt < %s -inline-threshold=2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
+; RUN: opt < %s -inline-threshold=-2000 -always-inline -enable-new-pm=0 -S | FileCheck %s --check-prefix=CHECK
 ;
 ; The new pass manager doesn't re-use any threshold based infrastructure for
-; the always inliner, but test that we get the correct result. The new PM
-; always inliner also doesn't support inlining call-site alwaysinline
-; annotations. It isn't clear that this is a reasonable use case for
-; 'alwaysinline'.
+; the always inliner, but test that we get the correct result.
 ; RUN: opt < %s -inline-threshold=0 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
 ; RUN: opt < %s -inline-threshold=2000 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
 ; RUN: opt < %s -inline-threshold=-2000 -passes=always-inline -S | FileCheck %s --check-prefix=CHECK
@@ -26,12 +23,6 @@
ret i32 %r
 }
 
-; The always inliner can't DCE arbitrary internal functions. PR2945
-define internal i32 @pr2945() nounwind {
-; CHECK-LABEL: @pr2945(
-  ret i32 0
-}
-
 define internal void @inner2(i32 %N) alwaysinline {
 ; CHECK-NOT: @inner2(
   %P = alloca i32, i32 %N
@@ -146,10 +137,9 @@
   ret i32 1
 }
 define i32 @outer7() {
-; CHECK-CALL-LABEL: @outer7(
-; CHECK-CALL-NOT: call
-; CHECK-CALL: ret
-
+; CHECK-LABEL: @outer7(
+; CHECK-NOT: call
+; CHECK: ret
%r = call i32 @inner7() alwaysinline
ret i32 %r
 }
Index: llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
===
--- llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
+++ llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
@@ -3,9 +3,7 @@
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.12.0"
 
-; CHECK: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
-; CHECK-NEXT: entry:
-; CHECK-NEXT:  unreachable
+; CHECK-NOT: define internal { i8*, i32 } @f(i8* %buffer, i32* %array)
 
 define internal {i8*, i32} @f(i8* %buffer, i32* %array) {
 entry:
Index: llvm/test/CodeGen/X86/x86-cmov-converter.ll
===
--- llvm/test/CodeGen/X86/x86-cmov-converter.ll
+++ llvm/test/CodeGen/X86/x86-cmov-converter.ll
@@ -1,3 +1,4 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -mtriple=x86_64-pc-linux -x86-cmov-converter=true -verify-machineinstrs -disable-block-placement < %s | FileCheck -allow-deprecated-dag-overlap %s
 
 
@@ -101,11 +102,34 @@
 
 %struct.Node = type { i32, %struct.Node*, %struct.Node* }
 
-; CHECK-LABEL: CmovInHotPath
-; CHECK-NOT: cmov
-; CHECK: jg
-
 define void @CmovInHotPath(i32 %n, i32 %a, i32 %b, i32* nocapture %c, i32* nocapture readnone %d) #0 {
+; CHECK-LABEL: CmovInHotPath:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:testl %edi, %edi
+; CHECK-NEXT:jle .LBB0_5
+; CHECK-NEXT:  # %bb.1: # %for.body.preheader
+; CHECK-NEXT:movl %edi, %r8d
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:  .LBB0_2: # %for.body
+; CHECK-NEXT:# =>This Inner Loop Header: Depth=1
+; CHECK-NEXT:movl (%rcx,%rdi,4), %eax
+; CHECK-NEXT:leal 1(%rax), %r9d
+; CHECK-NEXT:imull %esi, %eax
+; CHECK-NEXT:movl $10, %r10d
+; CHECK-NEXT:cmpl %edx, %eax
+; CHECK-NEXT:jg .LBB0_4
+; CHECK-NEXT:  #

[PATCH] D116966: [analyzer] Don't specify PLUGIN_TOOL for analyzer plugins

2022-01-25 Thread Aleksandr Platonov via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG491c154677bc: [analyzer] Dont specify PLUGIN_TOOL for 
analyzer plugins (authored by ArcsinX).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116966

Files:
  clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeLists.txt
  clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeLists.txt
  clang/lib/Analysis/plugins/SampleAnalyzer/CMakeLists.txt


Index: clang/lib/Analysis/plugins/SampleAnalyzer/CMakeLists.txt
===
--- clang/lib/Analysis/plugins/SampleAnalyzer/CMakeLists.txt
+++ clang/lib/Analysis/plugins/SampleAnalyzer/CMakeLists.txt
@@ -3,7 +3,7 @@
   )
 
 set(LLVM_EXPORTED_SYMBOL_FILE 
${CMAKE_CURRENT_SOURCE_DIR}/SampleAnalyzerPlugin.exports)
-add_llvm_library(SampleAnalyzerPlugin MODULE BUILDTREE_ONLY 
MainCallChecker.cpp PLUGIN_TOOL clang)
+add_llvm_library(SampleAnalyzerPlugin MODULE BUILDTREE_ONLY 
MainCallChecker.cpp)
 
 clang_target_link_libraries(SampleAnalyzerPlugin PRIVATE
   clangAnalysis
Index: clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeLists.txt
===
--- clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeLists.txt
+++ clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeLists.txt
@@ -3,7 +3,7 @@
   )
 
 set(LLVM_EXPORTED_SYMBOL_FILE 
${CMAKE_CURRENT_SOURCE_DIR}/CheckerOptionHandlingAnalyzerPlugin.exports)
-add_llvm_library(CheckerOptionHandlingAnalyzerPlugin MODULE BUILDTREE_ONLY 
CheckerOptionHandling.cpp PLUGIN_TOOL clang)
+add_llvm_library(CheckerOptionHandlingAnalyzerPlugin MODULE BUILDTREE_ONLY 
CheckerOptionHandling.cpp)
 
 clang_target_link_libraries(CheckerOptionHandlingAnalyzerPlugin PRIVATE
   clangAnalysis
Index: clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeLists.txt
===
--- clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeLists.txt
+++ clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeLists.txt
@@ -3,7 +3,7 @@
   )
 
 set(LLVM_EXPORTED_SYMBOL_FILE 
${CMAKE_CURRENT_SOURCE_DIR}/CheckerDependencyHandlingAnalyzerPlugin.exports)
-add_llvm_library(CheckerDependencyHandlingAnalyzerPlugin MODULE BUILDTREE_ONLY 
CheckerDependencyHandling.cpp PLUGIN_TOOL clang)
+add_llvm_library(CheckerDependencyHandlingAnalyzerPlugin MODULE BUILDTREE_ONLY 
CheckerDependencyHandling.cpp)
 
 clang_target_link_libraries(CheckerDependencyHandlingAnalyzerPlugin PRIVATE
   clangAnalysis


Index: clang/lib/Analysis/plugins/SampleAnalyzer/CMakeLists.txt
===
--- clang/lib/Analysis/plugins/SampleAnalyzer/CMakeLists.txt
+++ clang/lib/Analysis/plugins/SampleAnalyzer/CMakeLists.txt
@@ -3,7 +3,7 @@
   )
 
 set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/SampleAnalyzerPlugin.exports)
-add_llvm_library(SampleAnalyzerPlugin MODULE BUILDTREE_ONLY MainCallChecker.cpp PLUGIN_TOOL clang)
+add_llvm_library(SampleAnalyzerPlugin MODULE BUILDTREE_ONLY MainCallChecker.cpp)
 
 clang_target_link_libraries(SampleAnalyzerPlugin PRIVATE
   clangAnalysis
Index: clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeLists.txt
===
--- clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeLists.txt
+++ clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeLists.txt
@@ -3,7 +3,7 @@
   )
 
 set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/CheckerOptionHandlingAnalyzerPlugin.exports)
-add_llvm_library(CheckerOptionHandlingAnalyzerPlugin MODULE BUILDTREE_ONLY CheckerOptionHandling.cpp PLUGIN_TOOL clang)
+add_llvm_library(CheckerOptionHandlingAnalyzerPlugin MODULE BUILDTREE_ONLY CheckerOptionHandling.cpp)
 
 clang_target_link_libraries(CheckerOptionHandlingAnalyzerPlugin PRIVATE
   clangAnalysis
Index: clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeLists.txt
===
--- clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeLists.txt
+++ clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeLists.txt
@@ -3,7 +3,7 @@
   )
 
 set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/CheckerDependencyHandlingAnalyzerPlugin.exports)
-add_llvm_library(CheckerDependencyHandlingAnalyzerPlugin MODULE BUILDTREE_ONLY CheckerDependencyHandling.cpp PLUGIN_TOOL clang)
+add_llvm_library(CheckerDependencyHandlingAnalyzerPlugin MODULE BUILDTREE_ONLY CheckerDependencyHandling.cpp)
 
 clang_target_link_libraries(CheckerDependencyHandlingAnalyzerPlugin PRIVATE
   clangAnalysis
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 491c154 - [analyzer] Don't specify PLUGIN_TOOL for analyzer plugins

2022-01-25 Thread Aleksandr Platonov via cfe-commits


Author: Aleksandr Platonov
Date: 2022-01-25T23:05:00+03:00
New Revision: 491c154677bcf0fba3c91fdaa7897a48ab605327

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

LOG: [analyzer] Don't specify PLUGIN_TOOL for analyzer plugins

Analyzer plugins explicitly export clang_registerCheckers and 
clang_analyzerAPIVersionString symbols, so we don't need to specify a tool to 
link agains.

Also, without this patch MSVC build fails with cmake flags 
-DLLVM_ENABLE_PLUGINS=On -DCLANG_PLUGINS_SUPPORT=On 
-DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=On
```
[936/936] Linking CXX shared module bin\SampleAnalyzerPlugin.dll
FAILED: bin/SampleAnalyzerPlugin.dll
cmd.exe /C "cd . && "D:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll 
--intdir=tools\clang\lib\Analysis\plugins\SampleAnalyzer\CMakeFiles\SampleAnalyzerPlugin.dir
 --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\rc.exe 
--mt=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\mt.exe --manifests  -- 
C:\PROGRA~2\MICROS~4\2019\COMMUN~1\VC\Tools\MSVC\1428~1.299\bin\Hostx64\x64\link.exe
 /nologo 
tools\clang\lib\Analysis\plugins\SampleAnalyzer\CMakeFiles\SampleAnalyzerPlugin.dir\MainCallChecker.cpp.obj
  /out:bin\SampleAnalyzerPlugin.dll /implib:lib\SampleAnalyzerPlugin.lib 
/pdb:bin\SampleAnalyzerPlugin.pdb /dll /version:0.0 /machine:x64 
/INCREMENTAL:NO  
/DEF:"D:/work/llvm-project-original/build-plugins/tools/clang/lib/Analysis/plugins/SampleAnalyzer/SampleAnalyzerPlugin.def"
  lib\clang.lib  lib\clangAnalysis.lib  lib\clangAST.lib  
lib\clangStaticAnalyzerCore.lib  lib\clangStaticAnalyzerFrontend.lib  
lib\clangStaticAnalyzerCheckers.lib  lib\clangStaticAnalyzerCore.lib  
lib\clangCrossTU.lib  lib\clangIndex.lib  lib\clangFormat.lib  
lib\clangToolingInclusions.lib  lib\clangFrontend.lib  lib\clangDriver.lib  
version.lib  lib\clangParse.lib  lib\clangSerialization.lib  lib\clangSema.lib  
lib\clangAnalysis.lib  lib\clangEdit.lib  lib\LLVMOption.lib  
lib\clangToolingCore.lib  lib\clangRewrite.lib  lib\clangASTMatchers.lib  
lib\clangAST.lib  lib\clangLex.lib  lib\clangBasic.lib  
lib\LLVMFrontendOpenMP.lib  lib\LLVMScalarOpts.lib  
lib\LLVMAggressiveInstCombine.lib  lib\LLVMInstCombine.lib  
lib\LLVMTransformUtils.lib  lib\LLVMAnalysis.lib  lib\LLVMProfileData.lib  
lib\LLVMDebugInfoDWARF.lib  lib\LLVMObject.lib  lib\LLVMBitReader.lib  
lib\LLVMCore.lib  lib\LLVMRemarks.lib  lib\LLVMBitstreamReader.lib  
lib\LLVMMCParser.lib  lib\LLVMMC.lib  lib\LLVMDebugInfoCodeView.lib  
lib\LLVMTextAPI.lib  lib\LLVMBinaryFormat.lib  lib\LLVMSupport.lib  psapi.lib  
shell32.lib  ole32.lib  uuid.lib  advapi32.lib  delayimp.lib  
-delayload:shell32.dll  -delayload:ole32.dll  lib\LLVMDemangle.lib  
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib 
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  && cd ."
LINK: command 
"C:\PROGRA~2\MICROS~4\2019\COMMUN~1\VC\Tools\MSVC\1428~1.299\bin\Hostx64\x64\link.exe
 /nologo 
tools\clang\lib\Analysis\plugins\SampleAnalyzer\CMakeFiles\SampleAnalyzerPlugin.dir\MainCallChecker.cpp.obj
 /out:bin\SampleAnalyzerPlugin.dll /implib:lib\SampleAnalyzerPlugin.lib 
/pdb:bin\SampleAnalyzerPlugin.pdb /dll /version:0.0 /machine:x64 
/INCREMENTAL:NO 
/DEF:D:/work/llvm-project-original/build-plugins/tools/clang/lib/Analysis/plugins/SampleAnalyzer/SampleAnalyzerPlugin.def
 lib\clang.lib lib\clangAnalysis.lib lib\clangAST.lib 
lib\clangStaticAnalyzerCore.lib lib\clangStaticAnalyzerFrontend.lib 
lib\clangStaticAnalyzerCheckers.lib lib\clangStaticAnalyzerCore.lib 
lib\clangCrossTU.lib lib\clangIndex.lib lib\clangFormat.lib 
lib\clangToolingInclusions.lib lib\clangFrontend.lib lib\clangDriver.lib 
version.lib lib\clangParse.lib lib\clangSerialization.lib lib\clangSema.lib 
lib\clangAnalysis.lib lib\clangEdit.lib lib\LLVMOption.lib 
lib\clangToolingCore.lib lib\clangRewrite.lib lib\clangASTMatchers.lib 
lib\clangAST.lib lib\clangLex.lib lib\clangBasic.lib lib\LLVMFrontendOpenMP.lib 
lib\LLVMScalarOpts.lib lib\LLVMAggressiveInstCombine.lib 
lib\LLVMInstCombine.lib lib\LLVMTransformUtils.lib lib\LLVMAnalysis.lib 
lib\LLVMProfileData.lib lib\LLVMDebugInfoDWARF.lib lib\LLVMObject.lib 
lib\LLVMBitReader.lib lib\LLVMCore.lib lib\LLVMRemarks.lib 
lib\LLVMBitstreamReader.lib lib\LLVMMCParser.lib lib\LLVMMC.lib 
lib\LLVMDebugInfoCodeView.lib lib\LLVMTextAPI.lib lib\LLVMBinaryFormat.lib 
lib\LLVMSupport.lib psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib 
delayimp.lib -delayload:shell32.dll -delayload:ole32.dll lib\LLVMDemangle.lib 
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib 
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST 
/MANIFESTFILE:bin\SampleAnalyzerPlugin.dll.manifest" failed (exit code 1169) 
with the following output:
clangStaticAnalyzerCore.lib(BugReporter.cpp.obj) : error LNK2005: "public: 
__cdecl clang::ento::PathSensitiveBugReport::PathSensitiveBugReport(class

[PATCH] D118153: [CUDA][HIP] Do not treat host var address as constant in device compilation

2022-01-25 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

In D118153#3270122 , @tra wrote:

> LGTM.
>
> Do we need to do anything special about `__managed__` vars?

Right `__managed__` var is special. Its address is set by runtime, therefore it 
is not a constant. nvcc does not treat it as constant either. 
https://godbolt.org/z/jK534MxfG I will fix it.

BTW I just found a regression related to templates in 
CodeGenCUDA/host-used-device-var.cu. I will fix that and update this patch.

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

https://reviews.llvm.org/D118153

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

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

2022-01-25 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:497
+// Pack expansion is only allowed in the variadic argument at the end.
+const size_t attrNumArgs = attributeNumberOfArguments(*AttrName);
+if (ArgExprs.size() + I + 1 < attrNumArgs) {

aaron.ballman wrote:
> Coding style nits.
We don't typically use top-level `const`, so that should go as well.



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

steffenlarsen wrote:
> aaron.ballman wrote:
> > steffenlarsen wrote:
> > > aaron.ballman wrote:
> > > > Not that I think this is a bad change, but it seems unrelated to the 
> > > > patch. Can you explain why you made the change?
> > > Admittedly I am not sure why it is needed, but in the previous version of 
> > > the parsing for attribute parameters it does the typo-correction 
> > > immediately after parsing the expression and if this isn't added a 
> > > handful of tests fail.
> > Ah, thanks for the info! So this is basically doing the same work as what's 
> > done on line 3410 in the late failure case -- I wonder if this should 
> > actually be tied to the `FailImmediatelyOnInvalidExpr` parameter instead of 
> > having its own parameter?
> They could be unified in the current version, but I don't think there is an 
> actual relation between them.
Do we fail tests if this isn't conditionalized at all (we always do the early 
typo correction)? (I'd like to avoid adding the new parameter because I'm not 
certain how a caller would determine whether they do or do not want that 
behavior. If we need the parameter, then so be it, but it seems like this is 
something generally useful.)



Comment at: clang/test/Parser/cxx0x-attributes.cpp:262
 
-template void variadic() {
+template  void variadic() {
   void bar [[noreturn...]] (); // expected-error {{attribute 'noreturn' cannot 
be used as an attribute pack}}

You can back out the whitespace changes for an ever-so-slightly smaller patch. 
:-D



Comment at: clang/test/Parser/cxx0x-attributes.cpp:276-277
+  void foz [[clang::annotate("E", 1, 2, 3, Is...)]] ();
+  void fiz [[clang::annotate("F", Is..., 1, 2, 3)]] ();
+  void fir [[clang::annotate("G", 1, Is..., 2, 3)]] ();
+}

Shouldn't these cases also give the `// expected-error {{pack expansion in 
'annotate' may only be applied to the last argument}}` diagnostic?


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

https://reviews.llvm.org/D114439

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

[PATCH] D116377: [libTooling] Adds more support for constructing object access expressions.

2022-01-25 Thread Yitzhak Mandelbaum 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 rG0944c196c58f: [libTooling] Adds more support for 
constructing object access expressions. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116377

Files:
  clang/include/clang/Tooling/Transformer/SourceCodeBuilders.h
  clang/lib/Tooling/Transformer/SourceCodeBuilders.cpp
  clang/lib/Tooling/Transformer/Stencil.cpp
  clang/unittests/Tooling/SourceCodeBuildersTest.cpp
  clang/unittests/Tooling/StencilTest.cpp

Index: clang/unittests/Tooling/StencilTest.cpp
===
--- clang/unittests/Tooling/StencilTest.cpp
+++ clang/unittests/Tooling/StencilTest.cpp
@@ -36,10 +36,13 @@
 namespace N { class C {}; }
 namespace { class AnonC {}; }
 struct S { int Field; };
-struct Smart {
-  S* operator->() const;
-  S& operator*() const;
+namespace std {
+template 
+struct unique_ptr {
+  T* operator->() const;
+  T& operator*() const;
 };
+}
   )cc";
   return (Preface + ExtraPreface + "auto stencil_test_snippet = []{" +
   StatementCode + "};")
@@ -326,32 +329,15 @@
 TEST_F(StencilTest, MaybeDerefSmartPointer) {
   StringRef Id = "id";
   std::string Snippet = R"cc(
-Smart x;
+std::unique_ptr x;
 x;
   )cc";
   testExpr(Id, Snippet, maybeDeref(Id), "*x");
 }
 
-// Tests that unique_ptr specifically is handled.
-TEST_F(StencilTest, MaybeDerefSmartPointerUniquePtr) {
-  StringRef Id = "id";
-  // We deliberately specify `unique_ptr` as empty to verify that it matches
-  // because of its name, rather than its contents.
-  StringRef ExtraPreface =
-  "namespace std { template  class unique_ptr {}; }\n";
-  StringRef Snippet = R"cc(
-std::unique_ptr x;
-x;
-  )cc";
-  auto StmtMatch = matchStmt(Snippet, expr().bind(Id), ExtraPreface);
-  ASSERT_TRUE(StmtMatch);
-  EXPECT_THAT_EXPECTED(maybeDeref(Id)->eval(StmtMatch->Result),
-   HasValue(std::string("*x")));
-}
-
 TEST_F(StencilTest, MaybeDerefSmartPointerFromMemberExpr) {
   StringRef Id = "id";
-  std::string Snippet = "Smart x; x->Field;";
+  std::string Snippet = "std::unique_ptr x; x->Field;";
   auto StmtMatch =
   matchStmt(Snippet, memberExpr(hasObjectExpression(expr().bind(Id;
   ASSERT_TRUE(StmtMatch);
@@ -381,12 +367,12 @@
 
 TEST_F(StencilTest, MaybeAddressOfSmartPointer) {
   StringRef Id = "id";
-  testExpr(Id, "Smart x; x;", maybeAddressOf(Id), "x");
+  testExpr(Id, "std::unique_ptr x; x;", maybeAddressOf(Id), "x");
 }
 
 TEST_F(StencilTest, MaybeAddressOfSmartPointerFromMemberCall) {
   StringRef Id = "id";
-  std::string Snippet = "Smart x; x->Field;";
+  std::string Snippet = "std::unique_ptr x; x->Field;";
   auto StmtMatch =
   matchStmt(Snippet, memberExpr(hasObjectExpression(expr().bind(Id;
   ASSERT_TRUE(StmtMatch);
@@ -396,7 +382,7 @@
 
 TEST_F(StencilTest, MaybeAddressOfSmartPointerDerefNoCancel) {
   StringRef Id = "id";
-  testExpr(Id, "Smart x; *x;", maybeAddressOf(Id), "&*x");
+  testExpr(Id, "std::unique_ptr x; *x;", maybeAddressOf(Id), "&*x");
 }
 
 TEST_F(StencilTest, AccessOpValue) {
@@ -446,7 +432,7 @@
 
 TEST_F(StencilTest, AccessOpSmartPointer) {
   StringRef Snippet = R"cc(
-Smart x;
+std::unique_ptr x;
 x;
   )cc";
   StringRef Id = "id";
@@ -455,7 +441,7 @@
 
 TEST_F(StencilTest, AccessOpSmartPointerDereference) {
   StringRef Snippet = R"cc(
-Smart x;
+std::unique_ptr x;
 *x;
   )cc";
   StringRef Id = "id";
@@ -464,7 +450,7 @@
 
 TEST_F(StencilTest, AccessOpSmartPointerMemberCall) {
   StringRef Snippet = R"cc(
-Smart x;
+std::unique_ptr x;
 x->Field;
   )cc";
   StringRef Id = "id";
Index: clang/unittests/Tooling/SourceCodeBuildersTest.cpp
===
--- clang/unittests/Tooling/SourceCodeBuildersTest.cpp
+++ clang/unittests/Tooling/SourceCodeBuildersTest.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "clang/Tooling/Transformer/SourceCodeBuilders.h"
+#include "clang/AST/Type.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Tooling/Tooling.h"
@@ -24,8 +25,23 @@
 
 // Create a valid translation unit from a statement.
 static std::string wrapSnippet(StringRef StatementCode) {
-  return ("struct S { S(); S(int); int field; };\n"
+  return ("namespace std {\n"
+  "template  struct unique_ptr {\n"
+  "  T* operator->() const;\n"
+  "  T& operator*() const;\n"
+  "};\n"
+  "template  struct shared_ptr {\n"
+  "  T* operator->() const;\n"
+  "  T& operator*() const;\n"
+  "};\n"
+  "}\n"
+  "struct A { void super();

[clang] 0944c19 - [libTooling] Adds more support for constructing object access expressions.

2022-01-25 Thread Yitzhak Mandelbaum via cfe-commits


Author: Yitzhak Mandelbaum
Date: 2022-01-25T19:43:36Z
New Revision: 0944c196c58f62299540983e2d10cd7bef60691a

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

LOG: [libTooling] Adds more support for constructing object access expressions.

This patch adds a `buildAccess` function, which constructs a string with the
proper operator to use based on the expression's form and type. It also adds two
predicates related to smart pointers, which are needed by `buildAccess` but are
also of general value.

We deprecate `buildDot` and `buildArrow` in favor of the more general
`buildAccess`. These will be removed in a future patch.

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

Added: 


Modified: 
clang/include/clang/Tooling/Transformer/SourceCodeBuilders.h
clang/lib/Tooling/Transformer/SourceCodeBuilders.cpp
clang/lib/Tooling/Transformer/Stencil.cpp
clang/unittests/Tooling/SourceCodeBuildersTest.cpp
clang/unittests/Tooling/StencilTest.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Transformer/SourceCodeBuilders.h 
b/clang/include/clang/Tooling/Transformer/SourceCodeBuilders.h
index b6d9bd0e2d5d3..ab0eb71ef44e2 100644
--- a/clang/include/clang/Tooling/Transformer/SourceCodeBuilders.h
+++ b/clang/include/clang/Tooling/Transformer/SourceCodeBuilders.h
@@ -43,6 +43,15 @@ inline bool needParensBeforeDotOrArrow(const Expr ) {
 /// Determines whether printing this expression to the right of a unary 
operator
 /// requires a parentheses to preserve its meaning.
 bool needParensAfterUnaryOperator(const Expr );
+
+// Recognizes known types (and sugared versions thereof) that overload the `*`
+// and `->` operator. Below is the list of currently included types, but it is
+// subject to change:
+//
+// * std::unique_ptr, std::shared_ptr, std::weak_ptr,
+// * std::optional, absl::optional, llvm::Optional,
+// * absl::StatusOr, llvm::Expected.
+bool isKnownPointerLikeType(QualType Ty, ASTContext );
 /// @}
 
 /// \name Basic code-string generation utilities.
@@ -69,6 +78,8 @@ llvm::Optional buildAddressOf(const Expr ,
 ///  `x` becomes `x.`
 ///  `*a` becomes `a->`
 ///  `a+b` becomes `(a+b).`
+///
+/// DEPRECATED. Use `buildAccess`.
 llvm::Optional buildDot(const Expr , const ASTContext );
 
 /// Adds an arrow to the end of the given expression, but adds parentheses
@@ -77,8 +88,32 @@ llvm::Optional buildDot(const Expr , const 
ASTContext );
 ///  `x` becomes `x->`
 ///  `` becomes `a.`
 ///  `a+b` becomes `(a+b)->`
+///
+/// DEPRECATED. Use `buildAccess`.
 llvm::Optional buildArrow(const Expr ,
const ASTContext );
+
+/// Specifies how to classify pointer-like types -- like values or like 
pointers
+/// -- with regard to generating member-access syntax.
+enum class PLTClass : bool {
+  Value,
+  Pointer,
+};
+
+/// Adds an appropriate access operator (`.`, `->` or nothing, in the case of
+/// implicit `this`) to the end of the given expression. Adds parentheses when
+/// needed by the syntax and simplifies when possible. If `PLTypeClass` is
+/// `Pointer`, for known pointer-like types (see `isKnownPointerLikeType`),
+/// treats `operator->` and `operator*` like the built-in `->` and `*`
+/// operators.
+///
+///  `x` becomes `x->` or `x.`, depending on `E`'s type
+///  `a+b` becomes `(a+b)->` or `(a+b).`, depending on `E`'s type
+///  `` becomes `a.`
+///  `*a` becomes `a->`
+llvm::Optional
+buildAccess(const Expr , ASTContext ,
+PLTClass Classification = PLTClass::Pointer);
 /// @}
 
 } // namespace tooling

diff  --git a/clang/lib/Tooling/Transformer/SourceCodeBuilders.cpp 
b/clang/lib/Tooling/Transformer/SourceCodeBuilders.cpp
index a1c99b60216b7..65ade4387a5eb 100644
--- a/clang/lib/Tooling/Transformer/SourceCodeBuilders.cpp
+++ b/clang/lib/Tooling/Transformer/SourceCodeBuilders.cpp
@@ -10,6 +10,8 @@
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Tooling/Transformer/SourceCode.h"
 #include "llvm/ADT/Twine.h"
 #include 
@@ -60,6 +62,16 @@ bool tooling::needParensAfterUnaryOperator(const Expr ) {
   return false;
 }
 
+bool tooling::isKnownPointerLikeType(QualType Ty, ASTContext ) {
+  using namespace ast_matchers;
+  const auto PointerLikeTy = type(hasUnqualifiedDesugaredType(
+  recordType(hasDeclaration(cxxRecordDecl(hasAnyName(
+  "::std::unique_ptr", "::std::shared_ptr", "::std::weak_ptr",
+  "::std::optional", "::absl::optional", "::llvm::Optional",
+  "absl::StatusOr", "::llvm::Expected"));
+  return match(PointerLikeTy, Ty, Context).size() > 0;
+}
+
 llvm::Optional tooling::buildParens(const Expr ,

[PATCH] D116377: [libTooling] Adds more support for constructing object access expressions.

2022-01-25 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

ymandel updated this revision to Diff 402984.
ymandel added a comment.
Herald added a subscriber: JDevlieghere.

fix bad previous snapshot


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116377

Files:
  clang/include/clang/Tooling/Transformer/SourceCodeBuilders.h
  clang/lib/Tooling/Transformer/SourceCodeBuilders.cpp
  clang/lib/Tooling/Transformer/Stencil.cpp
  clang/unittests/Tooling/SourceCodeBuildersTest.cpp
  clang/unittests/Tooling/StencilTest.cpp

Index: clang/unittests/Tooling/StencilTest.cpp
===
--- clang/unittests/Tooling/StencilTest.cpp
+++ clang/unittests/Tooling/StencilTest.cpp
@@ -36,10 +36,13 @@
 namespace N { class C {}; }
 namespace { class AnonC {}; }
 struct S { int Field; };
-struct Smart {
-  S* operator->() const;
-  S& operator*() const;
+namespace std {
+template 
+struct unique_ptr {
+  T* operator->() const;
+  T& operator*() const;
 };
+}
   )cc";
   return (Preface + ExtraPreface + "auto stencil_test_snippet = []{" +
   StatementCode + "};")
@@ -326,32 +329,15 @@
 TEST_F(StencilTest, MaybeDerefSmartPointer) {
   StringRef Id = "id";
   std::string Snippet = R"cc(
-Smart x;
+std::unique_ptr x;
 x;
   )cc";
   testExpr(Id, Snippet, maybeDeref(Id), "*x");
 }
 
-// Tests that unique_ptr specifically is handled.
-TEST_F(StencilTest, MaybeDerefSmartPointerUniquePtr) {
-  StringRef Id = "id";
-  // We deliberately specify `unique_ptr` as empty to verify that it matches
-  // because of its name, rather than its contents.
-  StringRef ExtraPreface =
-  "namespace std { template  class unique_ptr {}; }\n";
-  StringRef Snippet = R"cc(
-std::unique_ptr x;
-x;
-  )cc";
-  auto StmtMatch = matchStmt(Snippet, expr().bind(Id), ExtraPreface);
-  ASSERT_TRUE(StmtMatch);
-  EXPECT_THAT_EXPECTED(maybeDeref(Id)->eval(StmtMatch->Result),
-   HasValue(std::string("*x")));
-}
-
 TEST_F(StencilTest, MaybeDerefSmartPointerFromMemberExpr) {
   StringRef Id = "id";
-  std::string Snippet = "Smart x; x->Field;";
+  std::string Snippet = "std::unique_ptr x; x->Field;";
   auto StmtMatch =
   matchStmt(Snippet, memberExpr(hasObjectExpression(expr().bind(Id;
   ASSERT_TRUE(StmtMatch);
@@ -381,12 +367,12 @@
 
 TEST_F(StencilTest, MaybeAddressOfSmartPointer) {
   StringRef Id = "id";
-  testExpr(Id, "Smart x; x;", maybeAddressOf(Id), "x");
+  testExpr(Id, "std::unique_ptr x; x;", maybeAddressOf(Id), "x");
 }
 
 TEST_F(StencilTest, MaybeAddressOfSmartPointerFromMemberCall) {
   StringRef Id = "id";
-  std::string Snippet = "Smart x; x->Field;";
+  std::string Snippet = "std::unique_ptr x; x->Field;";
   auto StmtMatch =
   matchStmt(Snippet, memberExpr(hasObjectExpression(expr().bind(Id;
   ASSERT_TRUE(StmtMatch);
@@ -396,7 +382,7 @@
 
 TEST_F(StencilTest, MaybeAddressOfSmartPointerDerefNoCancel) {
   StringRef Id = "id";
-  testExpr(Id, "Smart x; *x;", maybeAddressOf(Id), "&*x");
+  testExpr(Id, "std::unique_ptr x; *x;", maybeAddressOf(Id), "&*x");
 }
 
 TEST_F(StencilTest, AccessOpValue) {
@@ -446,7 +432,7 @@
 
 TEST_F(StencilTest, AccessOpSmartPointer) {
   StringRef Snippet = R"cc(
-Smart x;
+std::unique_ptr x;
 x;
   )cc";
   StringRef Id = "id";
@@ -455,7 +441,7 @@
 
 TEST_F(StencilTest, AccessOpSmartPointerDereference) {
   StringRef Snippet = R"cc(
-Smart x;
+std::unique_ptr x;
 *x;
   )cc";
   StringRef Id = "id";
@@ -464,7 +450,7 @@
 
 TEST_F(StencilTest, AccessOpSmartPointerMemberCall) {
   StringRef Snippet = R"cc(
-Smart x;
+std::unique_ptr x;
 x->Field;
   )cc";
   StringRef Id = "id";
Index: clang/unittests/Tooling/SourceCodeBuildersTest.cpp
===
--- clang/unittests/Tooling/SourceCodeBuildersTest.cpp
+++ clang/unittests/Tooling/SourceCodeBuildersTest.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "clang/Tooling/Transformer/SourceCodeBuilders.h"
+#include "clang/AST/Type.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Tooling/Tooling.h"
@@ -24,8 +25,23 @@
 
 // Create a valid translation unit from a statement.
 static std::string wrapSnippet(StringRef StatementCode) {
-  return ("struct S { S(); S(int); int field; };\n"
+  return ("namespace std {\n"
+  "template  struct unique_ptr {\n"
+  "  T* operator->() const;\n"
+  "  T& operator*() const;\n"
+  "};\n"
+  "template  struct shared_ptr {\n"
+  "  T* operator->() const;\n"
+  "  T& operator*() const;\n"
+  "};\n"
+  "}\n"
+  "struct A { void super(); };\n"
+  "struct S : public A { S(); S(int); int Field; };\n"
   "S operator+(const S , const S );\n"
+

[PATCH] D118023: Corrected fragment size for tf32 LD B matrix.

2022-01-25 Thread Artem Belevich 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 rG0ad19a833177: [CUDA,NVPTX] Corrected fragment size for tf32 
LD B matrix. (authored by JackAKirk, committed by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118023

Files:
  clang/lib/CodeGen/CGBuiltin.cpp


Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -17190,7 +17190,7 @@
   case NVPTX::BI__mma_tf32_m16n16k8_ld_a:
 return MMA_LDST(4, m16n16k8_load_a_tf32);
   case NVPTX::BI__mma_tf32_m16n16k8_ld_b:
-return MMA_LDST(2, m16n16k8_load_b_tf32);
+return MMA_LDST(4, m16n16k8_load_b_tf32);
   case NVPTX::BI__mma_tf32_m16n16k8_ld_c:
 return MMA_LDST(8, m16n16k8_load_c_f32);
 


Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -17190,7 +17190,7 @@
   case NVPTX::BI__mma_tf32_m16n16k8_ld_a:
 return MMA_LDST(4, m16n16k8_load_a_tf32);
   case NVPTX::BI__mma_tf32_m16n16k8_ld_b:
-return MMA_LDST(2, m16n16k8_load_b_tf32);
+return MMA_LDST(4, m16n16k8_load_b_tf32);
   case NVPTX::BI__mma_tf32_m16n16k8_ld_c:
 return MMA_LDST(8, m16n16k8_load_c_f32);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 0ad19a8 - [CUDA, NVPTX] Corrected fragment size for tf32 LD B matrix.

2022-01-25 Thread Artem Belevich via cfe-commits


Author: JackAKirk
Date: 2022-01-25T11:29:19-08:00
New Revision: 0ad19a833177861be55fefaff725ab89c8695d01

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

LOG: [CUDA,NVPTX] Corrected fragment size for tf32 LD B matrix.

Signed-off-by: JackAKirk 

Reviewed By: tra

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

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index cd35e7cbe76f7..a80a55e054a3b 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -17190,7 +17190,7 @@ static NVPTXMmaLdstInfo getNVPTXMmaLdstInfo(unsigned 
BuiltinID) {
   case NVPTX::BI__mma_tf32_m16n16k8_ld_a:
 return MMA_LDST(4, m16n16k8_load_a_tf32);
   case NVPTX::BI__mma_tf32_m16n16k8_ld_b:
-return MMA_LDST(2, m16n16k8_load_b_tf32);
+return MMA_LDST(4, m16n16k8_load_b_tf32);
   case NVPTX::BI__mma_tf32_m16n16k8_ld_c:
 return MMA_LDST(8, m16n16k8_load_c_f32);
 



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

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

2022-01-25 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

In D117616#3270205 , @tstellar wrote:

> So to summarize: this will change the ABI of clang built objects from clang13 
> -> clang14 in order to make clang14 compatible with gcc?

That's the idea, yes. (only for non-pod members of packed structs)

I /think/ we've done this sort of thing in the past when we've found corner 
case ABI differences between clang and gcc - but I don't have concrete examples 
to link to off hand.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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

[PATCH] D117965: [AlwaysInliner] Enable call site inlining to make flatten attribute working again (PR53360)

2022-01-25 Thread Arthur Eubanks via Phabricator via cfe-commits

aeubanks added a comment.

sounds good for the purposes of going back to what we had before, but we should 
reconsider the attribute support




Comment at: llvm/lib/Transforms/IPO/AlwaysInliner.cpp:95
 
-  // Remember to try and delete this function afterward. This both avoids
-  // re-walking the rest of the module and avoids dealing with any iterator
-  // invalidation issues while deleting functions.
-  InlinedFunctions.push_back();
+  if (F.hasFnAttribute(Attribute::AlwaysInline))
+// Remember to try and delete this function afterward. This both avoids

xbolva00 wrote:
> avoid DCE of internal functions without always_inline; check test pr2945 in 
> always-inline.ll
no need to change in this patch, but it looks like that was a past limitation, 
removing any dead internal function should be fine (subject to comdats). either 
we should not delete any function or we should attempt to remove any function 
we can



Comment at: llvm/test/Transforms/Inline/always-inline.ll:150
 
+define i32 @outer7b() {
+; CHECK-LABEL: @outer7b(

s/CHECK-CALL/CHECK/g should be good enough? any reason for outer7b? it's 
exactly the same as outer7a


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117965

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

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

2022-01-25 Thread Tom Stellard via Phabricator via cfe-commits

tstellar added a comment.

So to summarize: this will change the ABI of clang built objects from clang13 
-> clang14 in order to make clang14 compatible with gcc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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

[PATCH] D118169: [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

2022-01-25 Thread Dawid Jurczak via Phabricator via cfe-commits

yurai007 created this revision.
yurai007 added reviewers: nikic, xbolva00, erichkeane, craig.topper, aeubanks, 
Tyker.
Herald added a subscriber: pengfei.
yurai007 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

CodeGenModule::DeferredDecls std::map operator[] seem to be hot especially 
while code generating huge compilation units.
In such cases using DenseMap instead gives observable compile time improvement. 
Patch was tested on Linux build with default config acting as benchmark.
Build was performed on isolated CPU cores in silent x86-64 Linux environment 
following: https://llvm.org/docs/Benchmarking.html#linux rules.
Compile time statistics diff produced by perf and time before and after change 
are following:
instructions -0.15%, cycles -0.7%, max-rss +0.65%.
Using StringMap instead DenseMap doesn't bring any visible gains.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118169

Files:
  clang/lib/CodeGen/CodeGenModule.h


Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -335,7 +335,7 @@
   /// for emission and therefore should only be output if they are actually
   /// used. If a decl is in this, then it is known to have not been referenced
   /// yet.
-  std::map DeferredDecls;
+  llvm::DenseMap DeferredDecls;
 
   /// This is a list of deferred decls which we have seen that *are* actually
   /// referenced. These get code generated when the module is done.


Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -335,7 +335,7 @@
   /// for emission and therefore should only be output if they are actually
   /// used. If a decl is in this, then it is known to have not been referenced
   /// yet.
-  std::map DeferredDecls;
+  llvm::DenseMap DeferredDecls;
 
   /// This is a list of deferred decls which we have seen that *are* actually
   /// referenced. These get code generated when the module is done.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

1 2 3 >

1 - 100 of 222 matches

Mail list logo