date:20220119

[PATCH] D117398: [clang-format] Fix bug in parsing `operator<` with template

2022-01-19 Thread Marek Kurdej 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 rG560eb2277bb5: [clang-format] Fix bug in parsing 
`operator` with template (authored by pjessesco, committed by curdeius).

Changed prior to commit:
  https://reviews.llvm.org/D117398?vs=400782=401526#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117398

Files:
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -9463,6 +9463,10 @@
   verifyFormat("operator SomeType();");
   verifyFormat("operator SomeType();");
   verifyFormat("operator SomeType>();");
+  verifyFormat("operator< <>();");
+  verifyFormat("operator<< <>();");
+  verifyFormat("< <>");
+
   verifyFormat("void *operator new(std::size_t size);");
   verifyFormat("void *operator new[](std::size_t size);");
   verifyFormat("void operator delete(void *ptr);");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3346,6 +3346,9 @@
 if (Right.is(tok::l_brace) && Right.is(BK_BracedInit) &&
 !Left.opensScope() && Style.SpaceBeforeCpp11BracedList)
   return true;
+if (Left.is(tok::less) && Left.is(TT_OverloadedOperator) &&
+Right.is(TT_TemplateOpener))
+  return true;
   } else if (Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) {
 if (Right.is(tok::period) &&
Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -429,11 +429,18 @@
   if (Tokens.size() < 3)
 return false;
 
+  auto First = Tokens.end() - 3;
   bool FourthTokenIsLess = false;
-  if (Tokens.size() > 3)
-FourthTokenIsLess = (Tokens.end() - 4)[0]->is(tok::less);
 
-  auto First = Tokens.end() - 3;
+  if (Tokens.size() > 3) {
+auto Fourth = (Tokens.end() - 4)[0];
+FourthTokenIsLess = Fourth->is(tok::less);
+
+// Do not remove a whitespace between the two "<" e.g. "operator< <>".
+if (First[2]->is(tok::greater) && Fourth->is(tok::kw_operator))
+  return false;
+  }
+
   if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
   First[0]->isNot(tok::less) || FourthTokenIsLess)
 return false;


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -9463,6 +9463,10 @@
   verifyFormat("operator SomeType();");
   verifyFormat("operator SomeType();");
   verifyFormat("operator SomeType>();");
+  verifyFormat("operator< <>();");
+  verifyFormat("operator<< <>();");
+  verifyFormat("< <>");
+
   verifyFormat("void *operator new(std::size_t size);");
   verifyFormat("void *operator new[](std::size_t size);");
   verifyFormat("void operator delete(void *ptr);");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3346,6 +3346,9 @@
 if (Right.is(tok::l_brace) && Right.is(BK_BracedInit) &&
 !Left.opensScope() && Style.SpaceBeforeCpp11BracedList)
   return true;
+if (Left.is(tok::less) && Left.is(TT_OverloadedOperator) &&
+Right.is(TT_TemplateOpener))
+  return true;
   } else if (Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) {
 if (Right.is(tok::period) &&
Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -429,11 +429,18 @@
   if (Tokens.size() < 3)
 return false;
 
+  auto First = Tokens.end() - 3;
   bool FourthTokenIsLess = false;
-  if (Tokens.size() > 3)
-FourthTokenIsLess = (Tokens.end() - 4)[0]->is(tok::less);
 
-  auto First = Tokens.end() - 3;
+  if (Tokens.size() > 3) {
+auto Fourth = (Tokens.end() - 4)[0];
+FourthTokenIsLess = Fourth->is(tok::less);
+
+// Do not remove a whitespace between the two "<" e.g. "operator< <>".
+if (First[2]->is(tok::greater) && Fourth->is(tok::kw_operator))
+  return false;
+  }
+
   if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
   First[0]->isNot(tok::less) || FourthTokenIsLess)
 return false;
___
cfe-commits mailing list

[clang] 560eb22 - [clang-format] Fix bug in parsing `operator<` with template

2022-01-19 Thread Marek Kurdej via cfe-commits


Author: Jino Park
Date: 2022-01-20T08:59:04+01:00
New Revision: 560eb2277bb5aea0982ce5f90321788cda3fe4b3

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

LOG: [clang-format] Fix bug in parsing `operator<` with template

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

This patch handles a bug when parsing a below example code :

```
template  class S;

template  bool operator<(S const , S const ) {
  return x.i < y.i;
}

template  class S {
  int i = 42;
  friend bool operator< <>(S const &, S const &);
};

int main() { return S{} < S{}; }
```
which parse `< <>` as `<< >`, not `< <>` in terms of tokens as discussed in 
discord.

1. Add a condition in `tryMergeLessLess()` considering `operator` keyword and 
`>`
2. Force to leave a whitespace between `tok::less` and a template opener
3. Add unit test

Reviewed By: MyDeveloperDay, curdeius

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

Added: 


Modified: 
clang/lib/Format/FormatTokenLexer.cpp
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatTokenLexer.cpp 
b/clang/lib/Format/FormatTokenLexer.cpp
index 7736a7042f862..04629fec1bcaf 100644
--- a/clang/lib/Format/FormatTokenLexer.cpp
+++ b/clang/lib/Format/FormatTokenLexer.cpp
@@ -429,11 +429,18 @@ bool FormatTokenLexer::tryMergeLessLess() {
   if (Tokens.size() < 3)
 return false;
 
+  auto First = Tokens.end() - 3;
   bool FourthTokenIsLess = false;
-  if (Tokens.size() > 3)
-FourthTokenIsLess = (Tokens.end() - 4)[0]->is(tok::less);
 
-  auto First = Tokens.end() - 3;
+  if (Tokens.size() > 3) {
+auto Fourth = (Tokens.end() - 4)[0];
+FourthTokenIsLess = Fourth->is(tok::less);
+
+// Do not remove a whitespace between the two "<" e.g. "operator< <>".
+if (First[2]->is(tok::greater) && Fourth->is(tok::kw_operator))
+  return false;
+  }
+
   if (First[2]->is(tok::less) || First[1]->isNot(tok::less) ||
   First[0]->isNot(tok::less) || FourthTokenIsLess)
 return false;

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 7948dd105ee8b..71f29e8c010e5 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -3346,6 +3346,9 @@ bool TokenAnnotator::spaceRequiredBefore(const 
AnnotatedLine ,
 if (Right.is(tok::l_brace) && Right.is(BK_BracedInit) &&
 !Left.opensScope() && Style.SpaceBeforeCpp11BracedList)
   return true;
+if (Left.is(tok::less) && Left.is(TT_OverloadedOperator) &&
+Right.is(TT_TemplateOpener))
+  return true;
   } else if (Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) {
 if (Right.is(tok::period) &&

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index b8645b8896d2a..6bd417388fc7d 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -9463,6 +9463,10 @@ TEST_F(FormatTest, UnderstandsOverloadedOperators) {
   verifyFormat("operator SomeType();");
   verifyFormat("operator SomeType();");
   verifyFormat("operator SomeType>();");
+  verifyFormat("operator< <>();");
+  verifyFormat("operator<< <>();");
+  verifyFormat("< <>");
+
   verifyFormat("void *operator new(std::size_t size);");
   verifyFormat("void *operator new[](std::size_t size);");
   verifyFormat("void operator delete(void *ptr);");



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

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

2022-01-19 Thread Yueh-Ting Chen via Phabricator via cfe-commits

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

Rebase to latest main.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113336

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


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


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

[PATCH] D117398: [clang-format] Fix bug in parsing `operator<` with template

2022-01-19 Thread Marek Kurdej via Phabricator via cfe-commits

curdeius added a comment.

Or I'll add it when landing.


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

https://reviews.llvm.org/D117398

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

[PATCH] D117398: [clang-format] Fix bug in parsing `operator<` with template

2022-01-19 Thread Marek Kurdej via Phabricator via cfe-commits

curdeius added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:9466
   verifyFormat("operator SomeType>();");
+  verifyFormat("operator< <>();");
+  verifyFormat("< <>");

Looking at other related bug reports, I think that we should test `operator<< 
<>();` as well. Could you add it please?


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

https://reviews.llvm.org/D117398

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

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

2022-01-19 Thread Yueh-Ting Chen via Phabricator via cfe-commits

eopXD abandoned this revision.
eopXD added a comment.

This revision is no longer needed as zvamo and zvlsseg will be removed from 
arch string.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112986

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

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

2022-01-19 Thread Carlos Galvez via Phabricator via cfe-commits

carlosgalvezp added a comment.

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




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

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



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

Why not `SmallVector`? Sounds like the `Impl` is some "private" implementation?



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

Why not `SmallVector`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116085

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

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

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.td:137
+
+def GPR : RegisterClass<"RISCV", [XLenVT], 32, GPRAllocationList> {
   let RegInfos = XLenRI;

Does putting this back the way it was and using "(add GPR)" in GPRF16, GPRF32, 
and GPRF64 work?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93298

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

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

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117468

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

[PATCH] D112408: [RISCV] Add the zve extension according to the v1.0 spec

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: llvm/test/CodeGen/RISCV/rvv/vloxseg-rv32.ll:2
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=riscv32 -mattr=+d,+experimental-zvlsseg,+zfh \
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zve64d,+f,+d,+zfh \
 ; RUN: -verify-machineinstrs < %s | FileCheck %s

eopXD wrote:
> achieveartificialintelligence wrote:
> > Do we need `+f` here?
> Yes. D should imply F now. Let me create a another patch for it as the 
> current patch is for zve.
D already implies F in RISCV.td which is what is used for -mattr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

[PATCH] D112408: [RISCV] Add the zve extension according to the v1.0 spec

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

[PATCH] D112408: [RISCV] Add the zve extension according to the v1.0 spec

2022-01-19 Thread Yueh-Ting Chen via Phabricator via cfe-commits

eopXD added inline comments.



Comment at: llvm/test/CodeGen/RISCV/rvv/vloxseg-rv32.ll:2
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=riscv32 -mattr=+d,+experimental-zvlsseg,+zfh \
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zve64d,+f,+d,+zfh \
 ; RUN: -verify-machineinstrs < %s | FileCheck %s

achieveartificialintelligence wrote:
> Do we need `+f` here?
Yes. D should imply F now. Let me create a another patch for it as the current 
patch is for zve.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

[PATCH] D112408: [RISCV] Add the zve extension according to the v1.0 spec

2022-01-19 Thread Shao-Ce SUN via Phabricator via cfe-commits

achieveartificialintelligence added inline comments.



Comment at: llvm/test/CodeGen/RISCV/rvv/vloxseg-rv32.ll:2
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=riscv32 -mattr=+d,+experimental-zvlsseg,+zfh \
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zve64d,+f,+d,+zfh \
 ; RUN: -verify-machineinstrs < %s | FileCheck %s

Do we need `+f` here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

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

2022-01-19 Thread David Majnemer via Phabricator via cfe-commits

majnemer added inline comments.



Comment at: clang/test/CodeGenCXX/dllimport.cpp:2
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-msvc   
-fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o 
- %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M32 %s
-// RUN: %clang_cc1 -disable-noundef-analysis -triple x86_64-windows-msvc 
-fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o 
- %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M64 %s
+// RUN: %clang_cc1 -disable-noundef-analysis -triple x86_64-windows-msvc 
-fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o 
- %s -DMSABI -w | FileCheck --check-prefix=MSC64 --check-prefix=M64 %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-gnu
-fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o 
- %s -w | FileCheck --check-prefix=GNU --check-prefix=G32 %s

Why did this check-prefix change to `MSC64`? There is already a unique prefix 
for this `RUN` line: `M64`.


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

https://reviews.llvm.org/D117569

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

[PATCH] D112408: [RISCV] Add the zve extension according to the v1.0 spec

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:744
 static const char *ImpliedExtsZfh[] = {"zfhmin"};
+static const char *ImpliedExtsZve64d[] = {"zve64f", "d"};
+static const char *ImpliedExtsZve64f[] = {"zve64x", "zve32f"};

I think we need to drop the implication of "f" here and "d" on zve64f. Move 
them to V



Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.h:195
+  bool hasVInstructionsF32() const { return HasStdExtZve32f && HasStdExtF; }
+  // FIXME: Consider Zfinx in the future
+  bool hasVInstructionsF64() const { return HasStdExtZve64d && HasStdExtD; }

Zfinx -> Zdinx


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

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

2022-01-19 Thread David Majnemer via Phabricator via cfe-commits

majnemer added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:2219
+  Info.getLangOpts().CPlusPlus && !isForManglingOnly(Kind) &&
+  Var->hasAttr())
 // FIXME: Diagnostic!

The summary and the bug both mention dllimport but this is examining dllexport. 
Is this intended? If so, please update the comment above this if-statement.


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

https://reviews.llvm.org/D117569

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

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

2022-01-19 Thread David Majnemer via Phabricator via cfe-commits

majnemer requested changes to this revision.
majnemer added a comment.
This revision now requires changes to proceed.

I have a question regarding how this work with respect to the dllimport 
semantics known by the linker.
IIUC, we will now allow a program like:

  extern int __declspec(dllimport) dll_import_int;
  constexpr int& dll_import_constexpr_ref = dll_import_int;
  int& get() {
  return dll_import_constexpr_ref;
  }

Here, `get` will load `dll_import_constexpr_ref`. However, what will 
`dll_import_constexpr_ref` hold? It ought to hold the contents of 
`__imp_?dll_import_int@@3HA`. However, we can't dereference 
`__imp_?dll_import_int@@3HA` to get to its contents.


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

https://reviews.llvm.org/D117569

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

[PATCH] D116906: [OpenMP][AMDGPU] Optimize the linked in math libraries

2022-01-19 Thread Johannes Doerfert 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 rG6f2ee1ca5e39: [OpenMP][AMDGPU] Optimize the linked in math 
libraries (authored by jdoerfert).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116906

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


Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -16,6 +16,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/InputInfo.h"
 #include "clang/Driver/Options.h"
+#include "clang/Driver/Tool.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FormatAdapters.h"
@@ -95,9 +96,9 @@
 if (II.isFilename())
   CmdArgs.push_back(II.getFilename());
 
+  bool HasLibm = false;
   if (Args.hasArg(options::OPT_l)) {
 auto Lm = Args.getAllArgValues(options::OPT_l);
-bool HasLibm = false;
 for (auto  : Lm) {
   if (Lib == "m") {
 HasLibm = true;
@@ -143,6 +144,26 @@
   C.addCommand(std::make_unique(
   JA, *this, ResponseFileSupport::AtFileCurCP(), Exec, CmdArgs, Inputs,
   InputInfo(, Args.MakeArgString(OutputFileName;
+
+  // If we linked in libm definitions late we run another round of 
optimizations
+  // to inline the definitions and fold what is foldable.
+  if (HasLibm) {
+ArgStringList OptCmdArgs;
+const char *OptOutputFileName =
+getOutputFileName(C, OutputFilePrefix, "-linked-opt", "bc");
+addLLCOptArg(Args, OptCmdArgs);
+OptCmdArgs.push_back(OutputFileName);
+OptCmdArgs.push_back("-o");
+OptCmdArgs.push_back(OptOutputFileName);
+const char *OptExec =
+Args.MakeArgString(getToolChain().GetProgramPath("opt"));
+C.addCommand(std::make_unique(
+JA, *this, ResponseFileSupport::AtFileCurCP(), OptExec, OptCmdArgs,
+InputInfo(, Args.MakeArgString(OutputFileName)),
+InputInfo(, Args.MakeArgString(OptOutputFileName;
+OutputFileName = OptOutputFileName;
+  }
+
   return OutputFileName;
 }
 


Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -16,6 +16,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/InputInfo.h"
 #include "clang/Driver/Options.h"
+#include "clang/Driver/Tool.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FormatAdapters.h"
@@ -95,9 +96,9 @@
 if (II.isFilename())
   CmdArgs.push_back(II.getFilename());
 
+  bool HasLibm = false;
   if (Args.hasArg(options::OPT_l)) {
 auto Lm = Args.getAllArgValues(options::OPT_l);
-bool HasLibm = false;
 for (auto  : Lm) {
   if (Lib == "m") {
 HasLibm = true;
@@ -143,6 +144,26 @@
   C.addCommand(std::make_unique(
   JA, *this, ResponseFileSupport::AtFileCurCP(), Exec, CmdArgs, Inputs,
   InputInfo(, Args.MakeArgString(OutputFileName;
+
+  // If we linked in libm definitions late we run another round of optimizations
+  // to inline the definitions and fold what is foldable.
+  if (HasLibm) {
+ArgStringList OptCmdArgs;
+const char *OptOutputFileName =
+getOutputFileName(C, OutputFilePrefix, "-linked-opt", "bc");
+addLLCOptArg(Args, OptCmdArgs);
+OptCmdArgs.push_back(OutputFileName);
+OptCmdArgs.push_back("-o");
+OptCmdArgs.push_back(OptOutputFileName);
+const char *OptExec =
+Args.MakeArgString(getToolChain().GetProgramPath("opt"));
+C.addCommand(std::make_unique(
+JA, *this, ResponseFileSupport::AtFileCurCP(), OptExec, OptCmdArgs,
+InputInfo(, Args.MakeArgString(OutputFileName)),
+InputInfo(, Args.MakeArgString(OptOutputFileName;
+OutputFileName = OptOutputFileName;
+  }
+
   return OutputFileName;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 6f2ee1c - [OpenMP][AMDGPU] Optimize the linked in math libraries

2022-01-19 Thread Johannes Doerfert via cfe-commits


Author: Johannes Doerfert
Date: 2022-01-19T23:36:36-06:00
New Revision: 6f2ee1ca5e39b4286f7eb1aeb63b408f952f93c9

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

LOG: [OpenMP][AMDGPU] Optimize the linked in math libraries

Once we linked in math files, potentially even if we link in only other
"system libraries", we want to optimize the code again. This is not only
reasonable but also helps to hide various problems with the missing
attribute annotations in the math libraries.

Reviewed By: JonChesterfield

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

Added: 


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

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp 
b/clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
index 983d40636b0cd..6899f9360da5d 100644
--- a/clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -16,6 +16,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/InputInfo.h"
 #include "clang/Driver/Options.h"
+#include "clang/Driver/Tool.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FormatAdapters.h"
@@ -95,9 +96,9 @@ const char *AMDGCN::OpenMPLinker::constructLLVMLinkCommand(
 if (II.isFilename())
   CmdArgs.push_back(II.getFilename());
 
+  bool HasLibm = false;
   if (Args.hasArg(options::OPT_l)) {
 auto Lm = Args.getAllArgValues(options::OPT_l);
-bool HasLibm = false;
 for (auto  : Lm) {
   if (Lib == "m") {
 HasLibm = true;
@@ -143,6 +144,26 @@ const char *AMDGCN::OpenMPLinker::constructLLVMLinkCommand(
   C.addCommand(std::make_unique(
   JA, *this, ResponseFileSupport::AtFileCurCP(), Exec, CmdArgs, Inputs,
   InputInfo(, Args.MakeArgString(OutputFileName;
+
+  // If we linked in libm definitions late we run another round of 
optimizations
+  // to inline the definitions and fold what is foldable.
+  if (HasLibm) {
+ArgStringList OptCmdArgs;
+const char *OptOutputFileName =
+getOutputFileName(C, OutputFilePrefix, "-linked-opt", "bc");
+addLLCOptArg(Args, OptCmdArgs);
+OptCmdArgs.push_back(OutputFileName);
+OptCmdArgs.push_back("-o");
+OptCmdArgs.push_back(OptOutputFileName);
+const char *OptExec =
+Args.MakeArgString(getToolChain().GetProgramPath("opt"));
+C.addCommand(std::make_unique(
+JA, *this, ResponseFileSupport::AtFileCurCP(), OptExec, OptCmdArgs,
+InputInfo(, Args.MakeArgString(OutputFileName)),
+InputInfo(, Args.MakeArgString(OptOutputFileName;
+OutputFileName = OptOutputFileName;
+  }
+
   return OutputFileName;
 }
 



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

[PATCH] D117746: [CMake] Pass CMAKE_C/CXX_COMPILER_LAUNCHER down to cross-compile and runtime build

2022-01-19 Thread Yuanfang Chen via Phabricator via cfe-commits

ychen created this revision.
ychen added a reviewer: dexonsmith.
Herald added a subscriber: mgorny.
ychen requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Similar to D59032 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117746

Files:
  clang/runtime/CMakeLists.txt
  llvm/cmake/modules/CrossCompile.cmake


Index: llvm/cmake/modules/CrossCompile.cmake
===
--- llvm/cmake/modules/CrossCompile.cmake
+++ llvm/cmake/modules/CrossCompile.cmake
@@ -70,6 +70,8 @@
   add_custom_command(OUTPUT 
${${project_name}_${target_name}_BUILD}/CMakeCache.txt
 COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}"
 -DCMAKE_MAKE_PROGRAM="${CMAKE_MAKE_PROGRAM}"
+-DCMAKE_C_COMPILER_LAUNCHER="${CMAKE_C_COMPILER_LAUNCHER}"
+-DCMAKE_CXX_COMPILER_LAUNCHER="${CMAKE_CXX_COMPILER_LAUNCHER}"
 ${CROSS_TOOLCHAIN_FLAGS_${target_name}} ${CMAKE_CURRENT_SOURCE_DIR}
 ${CROSS_TOOLCHAIN_FLAGS_${project_name}_${target_name}}
 -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE
Index: clang/runtime/CMakeLists.txt
===
--- clang/runtime/CMakeLists.txt
+++ clang/runtime/CMakeLists.txt
@@ -78,6 +78,8 @@
-DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
+   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
+   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
-DLLVM_LIT_ARGS=${LLVM_LIT_ARGS}

-DCOMPILER_RT_OUTPUT_DIR=${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}


Index: llvm/cmake/modules/CrossCompile.cmake
===
--- llvm/cmake/modules/CrossCompile.cmake
+++ llvm/cmake/modules/CrossCompile.cmake
@@ -70,6 +70,8 @@
   add_custom_command(OUTPUT ${${project_name}_${target_name}_BUILD}/CMakeCache.txt
 COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}"
 -DCMAKE_MAKE_PROGRAM="${CMAKE_MAKE_PROGRAM}"
+-DCMAKE_C_COMPILER_LAUNCHER="${CMAKE_C_COMPILER_LAUNCHER}"
+-DCMAKE_CXX_COMPILER_LAUNCHER="${CMAKE_CXX_COMPILER_LAUNCHER}"
 ${CROSS_TOOLCHAIN_FLAGS_${target_name}} ${CMAKE_CURRENT_SOURCE_DIR}
 ${CROSS_TOOLCHAIN_FLAGS_${project_name}_${target_name}}
 -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE
Index: clang/runtime/CMakeLists.txt
===
--- clang/runtime/CMakeLists.txt
+++ clang/runtime/CMakeLists.txt
@@ -78,6 +78,8 @@
-DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
+   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
+   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
-DLLVM_LIT_ARGS=${LLVM_LIT_ARGS}
-DCOMPILER_RT_OUTPUT_DIR=${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117744: [Driver] Remove obsoleted -gz=zlib-gnu

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

MaskRay updated this revision to Diff 401498.
MaskRay added a comment.

fix a comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117744

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/amdgcn-gz-options.cl
  clang/test/Driver/compress-noias.c
  clang/test/Driver/compress.c
  clang/tools/driver/cc1as_main.cpp

Index: clang/tools/driver/cc1as_main.cpp
===
--- clang/tools/driver/cc1as_main.cpp
+++ clang/tools/driver/cc1as_main.cpp
@@ -228,7 +228,6 @@
 llvm::StringSwitch(A->getValue())
 .Case("none", llvm::DebugCompressionType::None)
 .Case("zlib", llvm::DebugCompressionType::Z)
-.Case("zlib-gnu", llvm::DebugCompressionType::GNU)
 .Default(llvm::DebugCompressionType::None);
   }
 
Index: clang/test/Driver/compress.c
===
--- clang/test/Driver/compress.c
+++ clang/test/Driver/compress.c
@@ -29,11 +29,6 @@
 // CHECK-OPT_GZ_EQ_ZLIB: {{.* "-cc1(as)?".* "--compress-debug-sections=zlib"}}
 // CHECK-OPT_GZ_EQ_ZLIB: "--compress-debug-sections=zlib"
 
-// RUN: %clang -### -target x86_64-unknown-linux-gnu -gz=zlib-gnu -x assembler %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// RUN: %clang -### -target x86_64-unknown-linux-gnu -gz=zlib-gnu %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: {{.* "-cc1(as)?".* "--compress-debug-sections=zlib-gnu"}}
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: "--compress-debug-sections=zlib-gnu"
-
 // RUN: %clang -### -fintegrated-as -gz=invalid -x assembler -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_INVALID %s
 // RUN: %clang -### -fintegrated-as -gz=invalid -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_INVALID %s
 // CHECK-OPT_GZ_EQ_INVALID: error: unsupported argument 'invalid' to option 'gz='
Index: clang/test/Driver/compress-noias.c
===
--- clang/test/Driver/compress-noias.c
+++ clang/test/Driver/compress-noias.c
@@ -27,10 +27,6 @@
 // RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=zlib -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB %s
 // CHECK-OPT_GZ_EQ_ZLIB: "--compress-debug-sections=zlib"
 
-// RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=zlib-gnu -x assembler -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=zlib-gnu -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: "--compress-debug-sections=zlib-gnu"
-
 // RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=invalid -x assembler -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_INVALID %s
 // RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=invalid -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_INVALID %s
 // CHECK-OPT_GZ_EQ_INVALID: error: unsupported argument 'invalid' to option 'gz='
Index: clang/test/Driver/amdgcn-gz-options.cl
===
--- clang/test/Driver/amdgcn-gz-options.cl
+++ clang/test/Driver/amdgcn-gz-options.cl
@@ -9,8 +9,3 @@
 // RUN: %clang -### -target amdgcn-amd-amdhsa -gz=zlib %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB %s
 // CHECK-OPT_GZ_EQ_ZLIB: {{.* "-cc1(as)?".* "--compress-debug-sections=zlib"}}
 // CHECK-OPT_GZ_EQ_ZLIB: "--compress-debug-sections=zlib"
-
-// RUN: %clang -### -target amdgcn-amd-amdhsa -gz=zlib-gnu -x assembler %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// RUN: %clang -### -target amdgcn-amd-amdhsa -gz=zlib-gnu %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: {{.* "-cc1(as)?".* "--compress-debug-sections=zlib-gnu"}}
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: "--compress-debug-sections=zlib-gnu"
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -694,7 +694,7 @@
   CmdArgs.push_back("--compress-debug-sections");
 } else {
   StringRef Value = A->getValue();
-  if (Value == "none" || Value == "zlib" || Value == "zlib-gnu") {
+  if (Value == "none" || Value == "zlib") {
 CmdArgs.push_back(
 Args.MakeArgString("--compress-debug-sections=" + Twine(Value)));
   } else {
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -286,13 +286,13 @@
 const

[PATCH] D117744: [Driver] Remove obsoleted -gz=zlib-gnu

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

MaskRay created this revision.
MaskRay added reviewers: compnerd, yaxunl.
Herald added subscribers: dang, jvesely.
Herald added a reviewer: ctetreau.
MaskRay requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

GCC added -gz=zlib-gnu in 2014 for -gz meaning change (.zdebug =>
SHF_COMPRESSED) and the legacy zlib-gnu hasn't gain adoption.

According to Debian Code Search, no project uses -gz=zlib-gnu (valgrind has a
configure to use -gz=zlib). Any possible -gz=zlib-gnu user can switch to -gz
smoothly (supported by integrated assemblers for many years; binutils 2.26).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117744

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/amdgcn-gz-options.cl
  clang/test/Driver/compress-noias.c
  clang/test/Driver/compress.c
  clang/tools/driver/cc1as_main.cpp

Index: clang/tools/driver/cc1as_main.cpp
===
--- clang/tools/driver/cc1as_main.cpp
+++ clang/tools/driver/cc1as_main.cpp
@@ -228,7 +228,6 @@
 llvm::StringSwitch(A->getValue())
 .Case("none", llvm::DebugCompressionType::None)
 .Case("zlib", llvm::DebugCompressionType::Z)
-.Case("zlib-gnu", llvm::DebugCompressionType::GNU)
 .Default(llvm::DebugCompressionType::None);
   }
 
Index: clang/test/Driver/compress.c
===
--- clang/test/Driver/compress.c
+++ clang/test/Driver/compress.c
@@ -29,11 +29,6 @@
 // CHECK-OPT_GZ_EQ_ZLIB: {{.* "-cc1(as)?".* "--compress-debug-sections=zlib"}}
 // CHECK-OPT_GZ_EQ_ZLIB: "--compress-debug-sections=zlib"
 
-// RUN: %clang -### -target x86_64-unknown-linux-gnu -gz=zlib-gnu -x assembler %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// RUN: %clang -### -target x86_64-unknown-linux-gnu -gz=zlib-gnu %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: {{.* "-cc1(as)?".* "--compress-debug-sections=zlib-gnu"}}
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: "--compress-debug-sections=zlib-gnu"
-
 // RUN: %clang -### -fintegrated-as -gz=invalid -x assembler -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_INVALID %s
 // RUN: %clang -### -fintegrated-as -gz=invalid -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_INVALID %s
 // CHECK-OPT_GZ_EQ_INVALID: error: unsupported argument 'invalid' to option 'gz='
Index: clang/test/Driver/compress-noias.c
===
--- clang/test/Driver/compress-noias.c
+++ clang/test/Driver/compress-noias.c
@@ -27,10 +27,6 @@
 // RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=zlib -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB %s
 // CHECK-OPT_GZ_EQ_ZLIB: "--compress-debug-sections=zlib"
 
-// RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=zlib-gnu -x assembler -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=zlib-gnu -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: "--compress-debug-sections=zlib-gnu"
-
 // RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=invalid -x assembler -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_INVALID %s
 // RUN: %clang -### -target i686-unknown-linux-gnu -fno-integrated-as -gz=invalid -c %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_INVALID %s
 // CHECK-OPT_GZ_EQ_INVALID: error: unsupported argument 'invalid' to option 'gz='
Index: clang/test/Driver/amdgcn-gz-options.cl
===
--- clang/test/Driver/amdgcn-gz-options.cl
+++ clang/test/Driver/amdgcn-gz-options.cl
@@ -9,8 +9,3 @@
 // RUN: %clang -### -target amdgcn-amd-amdhsa -gz=zlib %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB %s
 // CHECK-OPT_GZ_EQ_ZLIB: {{.* "-cc1(as)?".* "--compress-debug-sections=zlib"}}
 // CHECK-OPT_GZ_EQ_ZLIB: "--compress-debug-sections=zlib"
-
-// RUN: %clang -### -target amdgcn-amd-amdhsa -gz=zlib-gnu -x assembler %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// RUN: %clang -### -target amdgcn-amd-amdhsa -gz=zlib-gnu %s 2>&1 | FileCheck -check-prefix CHECK-OPT_GZ_EQ_ZLIB_GNU %s
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: {{.* "-cc1(as)?".* "--compress-debug-sections=zlib-gnu"}}
-// CHECK-OPT_GZ_EQ_ZLIB_GNU: "--compress-debug-sections=zlib-gnu"
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -694,7 +694,7 @@
   CmdArgs.push_back("--compress-debug-sections");
 } else {
   StringRef Value = A->getValue();
-  if (Value ==

[PATCH] D115848: tidy-llvm

2022-01-19 Thread Chris Bieneman via Phabricator via cfe-commits

beanz added a comment.

Sorry I’m a bit late here. If you want to use clang-tidy on a CMake built 
project (like LLVM) you can use CMake’s built-in support for clang-tidy:

https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_CLANG_TIDY.html

This will run clang-tidy during the project build with each compile invocation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115848

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

[PATCH] D116015: [PowerPC] Add generic fnmsub intrinsic

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

qiucf added a comment.

In D116015#3203067 , @nemanjai wrote:

> Converting more generic code to target-specific intrinsics is sometimes 
> necessary to ensure the generic IR doesn't get transformed in a way that is 
> disadvantageous. I believe that the description of this review claims that to 
> be the case for these negated FMA's. The obvious disadvantage of producing 
> target-specific intrinsics is that the optimizer knows nothing about them so 
> no advantageous transformations can happen either (i.e. hiding the semantics 
> from the optimizer is sometimes a good thing and sometimes a bad thing).
>
> The description of this patch includes no test case that shows the optimizer 
> performing an undesirable transformation. So the motivation for making the 
> front end produce more opaque code is not at all clear.

Here's a pretty simple case: `vector float foo(vector float a, vector float b, 
vector float c, vector float d) { return __builtin_vsx_xvnmsubasp(c, d, a*b); }`

It current produces `xvnegsp+xvmulsp+xvnmaddasp`, after this patch it produces 
`xvmulsp+xvnmsubasp`. In some complicated cases, we can see much more 
unexpected instructions generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116015

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

[PATCH] D117724: [RISCV] Remove Zvlsseg extension.

2022-01-19 Thread Yueh-Ting Chen via Phabricator via cfe-commits

eopXD added a comment.

Thank you for doing this patch, I was about to do it after I land zve.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117724

___
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-19 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added a comment.

Ping:)


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] D93298: [RISCV] add the MC layer support of Zfinx extension

2022-01-19 Thread Shao-Ce SUN via Phabricator via cfe-commits

achieveartificialintelligence added a comment.

Ping. Any other suggestions?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93298

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

[PATCH] D117740: [NFC][clang] Simplify `isOneOf` function

2022-01-19 Thread Shao-Ce SUN via Phabricator via cfe-commits

achieveartificialintelligence created this revision.
achieveartificialintelligence added reviewers: alexfh, danielmarjamaki.
achieveartificialintelligence requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117740

Files:
  clang/include/clang/Lex/Token.h


Index: clang/include/clang/Lex/Token.h
===
--- clang/include/clang/Lex/Token.h
+++ clang/include/clang/Lex/Token.h
@@ -99,9 +99,8 @@
   bool isOneOf(tok::TokenKind K1, tok::TokenKind K2) const {
 return is(K1) || is(K2);
   }
-  template 
-  bool isOneOf(tok::TokenKind K1, tok::TokenKind K2, Ts... Ks) const {
-return is(K1) || isOneOf(K2, Ks...);
+  template  bool isOneOf(tok::TokenKind K1, Ts... Ks) const {
+return is(K1) || isOneOf(Ks...);
   }
 
   /// Return true if this is a raw identifier (when lexing


Index: clang/include/clang/Lex/Token.h
===
--- clang/include/clang/Lex/Token.h
+++ clang/include/clang/Lex/Token.h
@@ -99,9 +99,8 @@
   bool isOneOf(tok::TokenKind K1, tok::TokenKind K2) const {
 return is(K1) || is(K2);
   }
-  template 
-  bool isOneOf(tok::TokenKind K1, tok::TokenKind K2, Ts... Ks) const {
-return is(K1) || isOneOf(K2, Ks...);
+  template  bool isOneOf(tok::TokenKind K1, Ts... Ks) const {
+return is(K1) || isOneOf(Ks...);
   }
 
   /// Return true if this is a raw identifier (when lexing
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2022-01-19 Thread gehry via Phabricator via cfe-commits

Sockke updated this revision to Diff 401470.
Sockke added a comment.

Improve some description.


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

https://reviews.llvm.org/D107450

Files:
  clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp
  clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/test/clang-tidy/checkers/performance-move-const-arg.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance-move-const-arg.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/performance-move-const-arg.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/performance-move-const-arg.cpp
@@ -246,3 +246,97 @@
   };
   f(MoveSemantics());
 }
+
+void showInt(int &);
+void showInt(int v1, int &);
+void showPointer(const char *&);
+void showPointer2(const char *const &);
+void showTriviallyCopyable(TriviallyCopyable &);
+void showTriviallyCopyablePointer(const TriviallyCopyable *&);
+void testFunctions() {
+  int a = 10;
+  showInt(std::move(a));
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: std::move of the variable 'a' of the trivially-copyable type 'int' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-10]]:20: note: consider changing the 1st parameter of 'showInt' from 'int &&' to 'const int &'
+  showInt(int());
+  showInt(a, std::move(a));
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: std::move of the variable 'a' of the trivially-copyable type 'int' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-13]]:28: note: consider changing the 2nd parameter of 'showInt' from 'int &&' to 'const int &'
+  const char* s = "";
+  showPointer(std::move(s));
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: std::move of the variable 's' of the trivially-copyable type 'const char *' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-16]]:32: note: consider changing the 1st parameter of 'showPointer' from 'const char *&&' to 'const char *'
+  showPointer2(std::move(s)); 
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: std::move of the variable 's' of the trivially-copyable type 'const char *' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-18]]:39: note: consider changing the 1st parameter of 'showPointer2' from 'const char *const &&' to 'const char *const'
+  TriviallyCopyable *obj = new TriviallyCopyable();
+  showTriviallyCopyable(std::move(*obj));
+  // CHECK-MESSAGES: :[[@LINE-1]]:25: warning: std::move of the expression of the trivially-copyable type 'TriviallyCopyable' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-21]]:48: note: consider changing the 1st parameter of 'showTriviallyCopyable' from 'TriviallyCopyable &&' to 'const TriviallyCopyable &'
+  showTriviallyCopyablePointer(std::move(obj));
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning: std::move of the variable 'obj' of the trivially-copyable type 'TriviallyCopyable *' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-23]]:62: note: consider changing the 1st parameter of 'showTriviallyCopyablePointer' from 'const TriviallyCopyable *&&' to 'const TriviallyCopyable *'
+}
+template 
+void forwardToShowInt(T && t) {
+  showInt(static_cast(t));
+}
+void testTemplate() {
+  int a = 10;
+  forwardToShowInt(std::move(a));
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: std::move of the variable 'a' of the trivially-copyable type 'int' has no effect [performance-move-const-arg]
+}
+
+struct Tmp {
+  Tmp();
+  Tmp(int &);
+  Tmp(int v1, int &);
+  Tmp(const char *&);
+  Tmp(TriviallyCopyable&& obj);
+  Tmp(const TriviallyCopyable *&);
+  void showTmp(TriviallyCopyable&& t);
+  static void showTmpStatic(TriviallyCopyable&& t);
+};
+void testMethods() {
+  Tmp t;
+  int a = 10;
+  Tmp t1(std::move(a));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: std::move of the variable 'a' of the trivially-copyable type 'int' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-13]]:13: note: consider changing the 1st parameter of 'Tmp' from 'int &&' to 'const int &'
+  Tmp t2(a, std::move(a));
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: std::move of the variable 'a' of the trivially-copyable type 'int' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-15]]:21: note: consider changing the 2nd parameter of 'Tmp' from 'int &&' to 'const int &'
+  const char* s = "";
+  Tmp t3(std::move(s));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: std::move of the variable 's' of the trivially-copyable type 'const char *' has no effect [performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-18]]:21: note: consider changing the 1st parameter of 'Tmp' from 'const char *&&' to 'const char *'
+  TriviallyCopyable *obj = new TriviallyCopyable();
+  Tmp t4(std::move(*obj));
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: std::move of

[PATCH] D117724: [RISCV] Remove Zvlsseg extension.

2022-01-19 Thread Kito Cheng via Phabricator via cfe-commits

kito-cheng added a comment.

Few more grep result (by `grep zvlsseg  * -Rin`), I think should remove:

  clang/include/clang/Basic/riscv_vector.td:218:  // Sub extension of vector 
spec. Currently only support Zvlsseg.
  clang/include/clang/Basic/riscv_vector.td:221:  // Number of fields for 
Zvlsseg.
  clang/include/clang/Basic/riscv_vector.td:1570:let RequiredExtensions = 
["Zvlsseg"] in {

We've some predictor named with `zvlsseg` like `IsZvlsseg` and 
`isRVVSpillForZvlsseg`, maybe rename to `SegmentVectorRegister` or 
`VectorRegisterGroup`?

Optional, nice to rename:

  clang/include/clang/Basic/RISCVVTypes.def:33:// - NF is the number of fields 
(NFIELDS) used in the Zvlsseg instructions
  llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp:293:  auto ZvlssegInfo = 
TII->isRVVSpillForZvlsseg(MBBI->getOpcode());
  llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp:294:  if (!ZvlssegInfo)
  llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp:296:  unsigned NF = 
ZvlssegInfo->first;
  llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp:297:  unsigned LMUL = 
ZvlssegInfo->second;
  llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp:338:  auto ZvlssegInfo = 
TII->isRVVSpillForZvlsseg(MBBI->getOpcode());
  llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp:339:  if (!ZvlssegInfo)
  llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp:341:  unsigned NF = 
ZvlssegInfo->first;
  llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp:342:  unsigned LMUL = 
ZvlssegInfo->second;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:222:  // FIXME: The COPY of 
subregister of Zvlsseg register will not be able
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:458:  bool IsZvlsseg = true;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:474:IsZvlsseg = false;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:477:IsZvlsseg = false;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:480:IsZvlsseg = false;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:483:IsZvlsseg = false;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:519:if (IsZvlsseg) {
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:520:  // For spilling/reloading 
Zvlsseg registers, append the dummy field for
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:552:  bool IsZvlsseg = true;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:568:IsZvlsseg = false;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:571:IsZvlsseg = false;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:574:IsZvlsseg = false;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:577:IsZvlsseg = false;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:612:if (IsZvlsseg) {
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:613:  // For spilling/reloading 
Zvlsseg registers, append the dummy field for
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:1051:unsigned NF = 
isRVVSpillForZvlsseg(Opcode)->first;
  llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:1880:  
!isRVVWholeLoadStore(Opcode) && !isRVVSpillForZvlsseg(Opcode))
  
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:1888:RISCVInstrInfo::isRVVSpillForZvlsseg(unsigned
 Opcode) const {
  llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:273:  auto ZvlssegInfo = 
TII->isRVVSpillForZvlsseg(MI.getOpcode());
  llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:274:  if (ZvlssegInfo) {
  llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:277:uint32_t ShiftAmount = 
Log2_32(ZvlssegInfo->second);
  llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:282:// The last argument of 
pseudo spilling opcode for zvlsseg is the length of
  llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:283:// one element of zvlsseg 
types. For example, for vint32m2x2_t, it will be
  llvm/lib/Target/RISCV/RISCVInstrInfo.h:178:  isRVVSpillForZvlsseg(unsigned 
Opcode) const;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117724

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

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

2022-01-19 Thread Chenbing.Zheng via Phabricator via cfe-commits

Chenbing.Zheng marked 8 inline comments as done.
Chenbing.Zheng added a comment.

In D117468#3255546 , @craig.topper 
wrote:

> In D117468#3253879 , 
> @Chenbing.Zheng wrote:
>
>> In D117468#3253493 , @craig.topper 
>> wrote:
>>
>>> Out of curiosity, what is your interest in Zbt? Do you work for a company 
>>> that is implementing this extension in hardware?
>>
>> My company has not implementing this extension，but may be in the future. I'm 
>> just doing a pre-research.
>
> The Zbt extensions and the other un-ratified extension from the old Bitmanip 
> spec have not seen any active discussion for at least the last 6-9 months. If 
> that continues, it starts to raise questions about whether llvm should 
> continue to support and extension that does not appear to be on a path to 
> ratification. I've asked for a discussion on this topic at the next RISCV 
> LLVM bi-weekly sync meeting tomorrow morning US time. calendar link here 
> https://llvm.org/docs/GettingInvolved.html#online-sync-ups

Thanks a lot, I will keep watching it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117468

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

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

2022-01-19 Thread Chenbing.Zheng via Phabricator via cfe-commits

Chenbing.Zheng updated this revision to Diff 401468.
Chenbing.Zheng added a comment.

modify tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117468

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

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

[PATCH] D117246: [OpenMP] Add support for linking AMDGPU images

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

jhuber6 updated this revision to Diff 401466.
jhuber6 added a comment.

Updating after upstreaming a portion of this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117246

Files:
  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
@@ -512,7 +512,7 @@
   // Create a new file to write the linked device image to.
   SmallString<128> TempFile;
   if (std::error_code EC = sys::fs::createTemporaryFile(
-  TheTriple.getArchName() + "-" + Arch, "cubin", TempFile))
+  "lto-" + TheTriple.getArchName() + "-" + Arch, "cubin", TempFile))
 return createFileError(TempFile, EC);
   TempFiles.push_back(static_cast(TempFile));
 
@@ -590,6 +590,50 @@
   return static_cast(TempFile);
 }
 } // namespace nvptx
+namespace amdgcn {
+Expected link(ArrayRef InputFiles,
+   ArrayRef LinkerArgs, Triple TheTriple,
+   StringRef Arch) {
+  // AMDGPU uses the lld binary to link device object files.
+  ErrorOr LLDPath =
+  sys::findProgramByName("lld", sys::path::parent_path(LinkerExecutable));
+  if (!LLDPath)
+LLDPath = sys::findProgramByName("lld");
+  if (!LLDPath)
+return createStringError(LLDPath.getError(),
+ "Unable to find 'lld' in path");
+
+  // Create a new file to write the linked device image to.
+  SmallString<128> TempFile;
+  if (std::error_code EC = sys::fs::createTemporaryFile(
+  TheTriple.getArchName() + "-" + Arch + "-image", "out", TempFile))
+return createFileError(TempFile, EC);
+  TempFiles.push_back(static_cast(TempFile));
+
+  SmallVector CmdArgs;
+  CmdArgs.push_back(*LLDPath);
+  CmdArgs.push_back("-flavor");
+  CmdArgs.push_back("gnu");
+  CmdArgs.push_back("--no-undefined");
+  CmdArgs.push_back("-shared");
+  CmdArgs.push_back("-o");
+  CmdArgs.push_back(TempFile);
+
+  // Copy system library paths used by the host linker.
+  for (StringRef Arg : LinkerArgs)
+if (Arg.startswith("-L"))
+  CmdArgs.push_back(Arg);
+
+  // Add extracted input files.
+  for (StringRef Input : InputFiles)
+CmdArgs.push_back(Input);
+
+  if (sys::ExecuteAndWait(*LLDPath, CmdArgs))
+return createStringError(inconvertibleErrorCode(), "'lld' failed");
+
+  return static_cast(TempFile);
+}
+} // namespace amdgcn
 
 Expected linkDevice(ArrayRef InputFiles,
  ArrayRef LinkerArgs,
@@ -599,7 +643,7 @@
   case Triple::nvptx64:
 return nvptx::link(InputFiles, LinkerArgs, TheTriple, Arch);
   case Triple::amdgcn:
-// TODO: AMDGCN linking support.
+return amdgcn::link(InputFiles, LinkerArgs, TheTriple, Arch);
   case Triple::x86:
   case Triple::x86_64:
 // TODO: x86 linking support.


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -512,7 +512,7 @@
   // Create a new file to write the linked device image to.
   SmallString<128> TempFile;
   if (std::error_code EC = sys::fs::createTemporaryFile(
-  TheTriple.getArchName() + "-" + Arch, "cubin", TempFile))
+  "lto-" + TheTriple.getArchName() + "-" + Arch, "cubin", TempFile))
 return createFileError(TempFile, EC);
   TempFiles.push_back(static_cast(TempFile));
 
@@ -590,6 +590,50 @@
   return static_cast(TempFile);
 }
 } // namespace nvptx
+namespace amdgcn {
+Expected link(ArrayRef InputFiles,
+   ArrayRef LinkerArgs, Triple TheTriple,
+   StringRef Arch) {
+  // AMDGPU uses the lld binary to link device object files.
+  ErrorOr LLDPath =
+  sys::findProgramByName("lld", sys::path::parent_path(LinkerExecutable));
+  if (!LLDPath)
+LLDPath = sys::findProgramByName("lld");
+  if (!LLDPath)
+return createStringError(LLDPath.getError(),
+ "Unable to find 'lld' in path");
+
+  // Create a new file to write the linked device image to.
+  SmallString<128> TempFile;
+  if (std::error_code EC = sys::fs::createTemporaryFile(
+  TheTriple.getArchName() + "-" + Arch + "-image", "out", TempFile))
+return createFileError(TempFile, EC);
+  TempFiles.push_back(static_cast(TempFile));
+
+  SmallVector CmdArgs;
+  CmdArgs.push_back(*LLDPath);
+  CmdArgs.push_back("-flavor");
+  CmdArgs.push_back("gnu");
+  CmdArgs.push_back("--no-undefined");
+  CmdArgs.push_back("-shared");
+  CmdArgs.push_back("-o");
+  CmdArgs.push_back(TempFile);
+
+  // Copy system library paths used by the host linker.
+  for (StringRef Arg : LinkerArgs)
+if (Arg.startswith("-L"))
+

[PATCH] D117137: [Driver] Add CUDA support for --offline param

2022-01-19 Thread Daniele Castagna via Phabricator via cfe-commits

dcastagna added a comment.

In D117137#3238275 , @tra wrote:

> I think instead of setting the triple directly from the command line, we 
> should start with adding another `--cuda-gpu-arch` (AKA --offload-arch)  
> variant and derive the triple and other parameters from it.

As discussed via IM, I uploaded a patch that extends the command line options 
--offload instead of introducing a new flag.
@tra, what do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117137

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

[PATCH] D117137: [Driver] Add CUDA support for --offline param

2022-01-19 Thread Daniele Castagna via Phabricator via cfe-commits

dcastagna updated this revision to Diff 401461.
dcastagna retitled this revision from "[Driver] Add a flag cuda-device-triple" 
to "[Driver] Add CUDA support for --offline param".
dcastagna edited the summary of this revision.
dcastagna added a comment.

Using already existing --offload parameters instead of adding a new one


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117137

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/cuda-device-triple.cu

Index: clang/test/Driver/cuda-device-triple.cu
===
--- /dev/null
+++ clang/test/Driver/cuda-device-triple.cu
@@ -0,0 +1,8 @@
+// REQUIRES: clang-driver
+
+// RUN: %clang -### -emit-llvm --cuda-device-only \
+// RUN:   -nocudalib -nocudainc --offload=spirv32-unknown-unknown -c %s 2>&1 | FileCheck %s
+
+// CHECK: clang{{.*}}" "-cc1" "-triple" "spirv32-unknown-unknown" {{.*}} "-fcuda-is-device" {{.*}}
+
+
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -102,39 +102,59 @@
 using namespace llvm::opt;
 
 static llvm::Optional
-getHIPOffloadTargetTriple(const Driver , const ArgList ) {
-  if (Args.hasArg(options::OPT_offload_EQ)) {
-auto HIPOffloadTargets = Args.getAllArgValues(options::OPT_offload_EQ);
-
-// HIP compilation flow does not support multiple targets for now. We need
-// the HIPActionBuilder (and possibly the CudaActionBuilder{,Base}too) to
-// support multiple tool chains first.
-switch (HIPOffloadTargets.size()) {
+getOffloadTargetTriple(const Driver , const ArgList ) {
+  auto OffloadTargets = Args.getAllArgValues(options::OPT_offload_EQ);
+  // Offload compilation flow does not support multiple targets for now. We
+  // need the HIPActionBuilder (and possibly the CudaActionBuilder{,Base}too)
+  // to support multiple tool chains first.
+  switch (OffloadTargets.size()) {
 default:
-  D.Diag(diag::err_drv_only_one_offload_target_supported_in) << "HIP";
+  D.Diag(diag::err_drv_only_one_offload_target_supported_in) << "";
   return llvm::None;
 case 0:
   D.Diag(diag::err_drv_invalid_or_unsupported_offload_target) << "";
   return llvm::None;
 case 1:
   break;
-}
-llvm::Triple TT(HIPOffloadTargets[0]);
-if (TT.getArch() == llvm::Triple::amdgcn &&
-TT.getVendor() == llvm::Triple::AMD &&
-TT.getOS() == llvm::Triple::AMDHSA)
-  return TT;
-if (TT.getArch() == llvm::Triple::spirv64 &&
-TT.getVendor() == llvm::Triple::UnknownVendor &&
-TT.getOS() == llvm::Triple::UnknownOS)
-  return TT;
-D.Diag(diag::err_drv_invalid_or_unsupported_offload_target)
-<< HIPOffloadTargets[0];
-return llvm::None;
   }
+  return llvm::Triple(OffloadTargets[0]);
+}
 
-  static const llvm::Triple T("amdgcn-amd-amdhsa"); // Default HIP triple.
-  return T;
+static llvm::Optional
+getNVIDIAOffloadTargetTriple(const Driver , const ArgList , const llvm::Triple ) {
+  if (!Args.hasArg(options::OPT_offload_EQ)) {
+return llvm::Triple(HostTriple.isArch64Bit() ? "nvptx64-nvidia-cuda" : "nvptx-nvidia-cuda");
+  }
+  auto TT = getOffloadTargetTriple(D, Args);
+  if (TT &&
+  (TT->getArch() == llvm::Triple::spirv32 ||
+   TT->getArch() == llvm::Triple::spirv64)) {
+return TT;
+  }
+  D.Diag(diag::err_drv_invalid_or_unsupported_offload_target)
+  << TT->str();
+  return llvm::None;
+}
+static llvm::Optional
+getHIPOffloadTargetTriple(const Driver , const ArgList ) {
+  if (!Args.hasArg(options::OPT_offload_EQ)) {
+static const llvm::Triple T("amdgcn-amd-amdhsa"); // Default HIP triple.
+return T;
+  }
+  auto TT =  getOffloadTargetTriple(D, Args);
+  if (!TT)
+return llvm::None;
+  if (TT->getArch() == llvm::Triple::amdgcn &&
+  TT->getVendor() == llvm::Triple::AMD &&
+  TT->getOS() == llvm::Triple::AMDHSA)
+return TT;
+  if (TT->getArch() == llvm::Triple::spirv64 &&
+  TT->getVendor() == llvm::Triple::UnknownVendor &&
+  TT->getOS() == llvm::Triple::UnknownOS)
+return TT;
+  D.Diag(diag::err_drv_invalid_or_unsupported_offload_target)
+  << TT->str();
+  return llvm::None;
 }
 
 // static
@@ -704,17 +724,17 @@
   if (IsCuda) {
 const ToolChain *HostTC = C.getSingleOffloadToolChain();
 const llvm::Triple  = HostTC->getTriple();
-StringRef DeviceTripleStr;
 auto OFK = Action::OFK_Cuda;
-DeviceTripleStr =
-HostTriple.isArch64Bit() ? "nvptx64-nvidia-cuda" : "nvptx-nvidia-cuda";
-llvm::Triple CudaTriple(DeviceTripleStr);
+auto CudaTriple =
+getNVIDIAOffloadTargetTriple(*this, C.getInputArgs(), HostTriple);
+if (!CudaTriple)
+  return;
 // Use the CUDA and host triples as the key into the ToolChains map,
 // because the device toolchain we

[PATCH] D117087: [C++20] [Coroutines] Implement return value optimization for get_return_object

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

ChuanqiXu added a comment.

gentle ping~


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117087

___
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-19 Thread Chuanqi Xu via Phabricator via cfe-commits

ChuanqiXu added a comment.

@Quuxplusone @aaron.ballman gentle ping~


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] D115610: [C++20] [Modules] Don't create multiple global module fragment

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

ChuanqiXu added a comment.

@rsmith gentle ping~


Repository:
  rG LLVM Github Monorepo

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] D117520: [clang-format] Fix SeparateDefinitionBlocks issues

2022-01-19 Thread ksyx via Phabricator via cfe-commits

ksyx updated this revision to Diff 401460.
ksyx added a comment.

Apply suggestion from clangfmt


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

https://reviews.llvm.org/D117520

Files:
  clang/lib/Format/DefinitionBlockSeparator.cpp
  clang/lib/Format/DefinitionBlockSeparator.h
  clang/unittests/Format/DefinitionBlockSeparatorTest.cpp

Index: clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
===
--- clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
+++ clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
@@ -128,6 +128,59 @@
"\n"
"enum Bar { FOOBAR, BARFOO };\n",
Style);
+
+  FormatStyle BreakAfterReturnTypeStyle = Style;
+  BreakAfterReturnTypeStyle.AlwaysBreakAfterReturnType = FormatStyle::RTBS_All;
+  // Test uppercased long typename
+  verifyFormat("class Foo {\n"
+   "  void\n"
+   "  Bar(int t, int p) {\n"
+   "int r = t + p;\n"
+   "return r;\n"
+   "  }\n"
+   "\n"
+   "  LONGTYPENAME\n"
+   "  Foobar(int t, int p) {\n"
+   "int r = t * p;\n"
+   "return r;\n"
+   "  }\n"
+   "}\n",
+   BreakAfterReturnTypeStyle);
+}
+
+TEST_F(DefinitionBlockSeparatorTest, CommentBlock) {
+  FormatStyle Style = getLLVMStyle();
+  Style.SeparateDefinitionBlocks = FormatStyle::SDS_Always;
+  std::string Prefix = "enum Foo { FOO, BAR };\n"
+   "\n"
+   "/*\n"
+   "test1\n"
+   "test2\n"
+   "*/\n"
+   "int foo(int i, int j) {\n"
+   "  int r = i + j;\n"
+   "  return r;\n"
+   "}\n";
+  std::string Suffix = "enum Bar { FOOBAR, BARFOO };\n"
+   "\n"
+   "/* Comment block in one line*/\n"
+   "int bar3(int j, int k) {\n"
+   "  // A comment\n"
+   "  int r = j % k;\n"
+   "  return r;\n"
+   "}\n";
+  std::string CommentedCode = "/*\n"
+  "int bar2(int j, int k) {\n"
+  "  int r = j / k;\n"
+  "  return r;\n"
+  "}\n"
+  "*/\n";
+  verifyFormat(removeEmptyLines(Prefix) + "\n" + CommentedCode + "\n" +
+   removeEmptyLines(Suffix),
+   Style, Prefix + "\n" + CommentedCode + "\n" + Suffix);
+  verifyFormat(removeEmptyLines(Prefix) + "\n" + CommentedCode +
+   removeEmptyLines(Suffix),
+   Style, Prefix + "\n" + CommentedCode + Suffix);
 }
 
 TEST_F(DefinitionBlockSeparatorTest, UntouchBlockStartStyle) {
@@ -172,13 +225,15 @@
   FormatStyle NeverStyle = getLLVMStyle();
   NeverStyle.SeparateDefinitionBlocks = FormatStyle::SDS_Never;
 
-  auto TestKit = MakeUntouchTest("#ifdef FOO\n\n", "\n#elifndef BAR\n\n",
- "\n#endif\n\n", false);
+  auto TestKit = MakeUntouchTest("/* FOOBAR */\n"
+ "#ifdef FOO\n\n",
+ "\n#elifndef BAR\n\n", "\n#endif\n\n", false);
   verifyFormat(TestKit.first, AlwaysStyle, TestKit.second);
   verifyFormat(TestKit.second, NeverStyle, removeEmptyLines(TestKit.second));
 
-  TestKit =
-  MakeUntouchTest("#ifdef FOO\n", "#elifndef BAR\n", "#endif\n", false);
+  TestKit = MakeUntouchTest("/* FOOBAR */\n"
+"#ifdef FOO\n",
+"#elifndef BAR\n", "#endif\n", false);
   verifyFormat(TestKit.first, AlwaysStyle, TestKit.second);
   verifyFormat(TestKit.second, NeverStyle, removeEmptyLines(TestKit.second));
 
@@ -210,7 +265,7 @@
   "test1\n"
   "test2\n"
   "*/\n"
-  "int foo(int i, int j) {\n"
+  "/*const*/ int foo(int i, int j) {\n"
   "  int r = i + j;\n"
   "  return r;\n"
   "}\n"
@@ -222,8 +277,10 @@
   "// Comment line 2\n"
   "// Comment line 3\n"
   "int bar(int j, int k) {\n"
-  "  int r = j * k;\n"
-  "  return r;\n"
+  "  {\n"
+  "int r = j * k;\n"
+  "return r;\n"
+  "  }\n"
   "}\n"
   "\n"
   "int bar2(int j, int k) {\n"
@@ -234,7 +291,7 @@
   "/* Comment block in one line*/\n"
   "enum Bar { FOOBAR, BARFOO };\n"
   "\n"
-  "int bar3(int j, int k)

[PATCH] D112903: [C++20] [Module] Fix bug47116 and implement [module.interface]/p6

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

ChuanqiXu added a comment.

@aaron.ballman @urnathan gentle ping~


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

https://reviews.llvm.org/D112903

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

[PATCH] D117634: [OpenMP] Expand short verisions of OpenMP offloading triples

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rG28d718602ad2: [OpenMP] Expand short verisions of OpenMP 
offloading triples (authored by jhuber6).

Changed prior to commit:
  https://reviews.llvm.org/D117634?vs=401357=401454#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117634

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/fat_archive_nvptx.cpp
  openmp/libomptarget/DeviceRTL/CMakeLists.txt


Index: openmp/libomptarget/DeviceRTL/CMakeLists.txt
===
--- openmp/libomptarget/DeviceRTL/CMakeLists.txt
+++ openmp/libomptarget/DeviceRTL/CMakeLists.txt
@@ -227,7 +227,7 @@
 
 # Generate a Bitcode library for all the compute capabilities the user 
requested
 foreach(sm ${nvptx_sm_list})
-  compileDeviceRTLLibrary(sm_${sm} nvptx -target nvptx64 -Xclang 
-target-feature -Xclang +ptx61 "-D__CUDA_ARCH__=${sm}0")
+  compileDeviceRTLLibrary(sm_${sm} nvptx -target nvptx64-nvidia-cuda -Xclang 
-target-feature -Xclang +ptx61 "-D__CUDA_ARCH__=${sm}0")
 endforeach()
 
 foreach(mcpu ${amdgpu_mcpus})
Index: clang/test/Driver/fat_archive_nvptx.cpp
===
--- clang/test/Driver/fat_archive_nvptx.cpp
+++ clang/test/Driver/fat_archive_nvptx.cpp
@@ -6,9 +6,9 @@
 
 // Given a FatArchive, clang-offload-bundler should be called to create a
 // device specific archive, which should be passed to clang-nvlink-wrapper.
-// RUN: %clang -O2 -### -fopenmp -fopenmp-targets=nvptx64 %s 
-L%S/Inputs/openmp_static_device_link -lFatArchive 2>&1 | FileCheck %s
-// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "nvptx64"{{.*}}"-target-cpu" 
"[[GPU:sm_[0-9]+]]"{{.*}}"-o" "[[HOSTBC:.*.s]]" "-x" "c++"{{.*}}.cpp
-// CHECK: clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}/Inputs/openmp_static_device_link/libFatArchive.a" 
"-targets=openmp-nvptx64-[[GPU]]" "-outputs=[[DEVICESPECIFICARCHIVE:.*.a]]" 
"-allow-missing-bundles"
+// RUN: %clang -O2 -### -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda %s 
-L%S/Inputs/openmp_static_device_link -lFatArchive 2>&1 | FileCheck %s
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" 
"nvptx64-nvidia-cuda"{{.*}}"-target-cpu" "[[GPU:sm_[0-9]+]]"{{.*}}"-o" 
"[[HOSTBC:.*.s]]" "-x" "c++"{{.*}}.cpp
+// CHECK: clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}/Inputs/openmp_static_device_link/libFatArchive.a" 
"-targets=openmp-nvptx64-nvidia-cuda-[[GPU]]" 
"-outputs=[[DEVICESPECIFICARCHIVE:.*.a]]" "-allow-missing-bundles"
 // CHECK: clang-nvlink-wrapper{{.*}}"-o" "{{.*}}.out" "-arch" "[[GPU]]" 
"{{.*}}[[DEVICESPECIFICARCHIVE]]"
 // expected-no-diagnostics
 
@@ -72,8 +72,8 @@
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx908 -c func_1.c -o func_1_gfx908.o
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 -c func_2.c -o func_2_gfx906.o
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx908 -c func_2.c -o func_2_gfx908.o
-clang -O2 -fopenmp -fopenmp-targets=nvptx64 -c func_1.c -o func_1_nvptx.o
-clang -O2 -fopenmp -fopenmp-targets=nvptx64 -c func_2.c -o func_2_nvptx.o
+clang -O2 -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -c func_1.c -o 
func_1_nvptx.o
+clang -O2 -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -c func_2.c -o 
func_2_nvptx.o
 
 2. Create a fat archive by combining all the object file(s)
 llvm-ar cr libFatArchive.a func_1_gfx906.o func_1_gfx908.o func_2_gfx906.o 
func_2_gfx908.o func_1_nvptx.o func_2_nvptx.o
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -774,6 +774,18 @@
   llvm::Triple TT(Val);
   std::string NormalizedName = TT.normalize();
 
+  // We want to expand the shortened versions of the triples passed in 
to
+  // the values used for the bitcode libraries for convenience.
+  if (TT.getVendor() == llvm::Triple::UnknownVendor ||
+  TT.getOS() == llvm::Triple::UnknownOS) {
+if (TT.getArch() == llvm::Triple::nvptx)
+  TT = llvm::Triple("nvptx-nvidia-cuda");
+else if (TT.getArch() == llvm::Triple::nvptx64)
+  TT = llvm::Triple("nvptx64-nvidia-cuda");
+else if (TT.getArch() == llvm::Triple::amdgcn)
+  TT = llvm::Triple("amdgcn-amd-amdhsa");
+  }
+
   // Make sure we don't have a duplicate triple.
   auto Duplicate = FoundNormalizedTriples.find(NormalizedName);
   if (Duplicate != FoundNormalizedTriples.end()) {


Index: openmp/libomptarget/DeviceRTL/CMakeLists.txt
===
--- openmp/libomptarget/DeviceRTL/CMakeLists.txt

[clang] 28d7186 - [OpenMP] Expand short verisions of OpenMP offloading triples

2022-01-19 Thread Joseph Huber via cfe-commits


Author: Joseph Huber
Date: 2022-01-19T20:26:37-05:00
New Revision: 28d718602ad2bddbfcb445fff46bcbbdd0788471

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

LOG: [OpenMP] Expand short verisions of OpenMP offloading triples

The OpenMP offloading libraries are built with fixed triples and linked
in during compile time. This would cause un-helpful errors if the user
passed in the wrong expansion of the triple used for the bitcode
library. because we only support these triples for OpenMP offloading we
can normalize them to the full verion used in the bitcode library.

Reviewed By: jdoerfert, JonChesterfield

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/fat_archive_nvptx.cpp
openmp/libomptarget/DeviceRTL/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 82d67a8b8b1ab..c7314e11c7865 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -774,6 +774,18 @@ void Driver::CreateOffloadingDeviceToolChains(Compilation 
,
   llvm::Triple TT(Val);
   std::string NormalizedName = TT.normalize();
 
+  // We want to expand the shortened versions of the triples passed in 
to
+  // the values used for the bitcode libraries for convenience.
+  if (TT.getVendor() == llvm::Triple::UnknownVendor ||
+  TT.getOS() == llvm::Triple::UnknownOS) {
+if (TT.getArch() == llvm::Triple::nvptx)
+  TT = llvm::Triple("nvptx-nvidia-cuda");
+else if (TT.getArch() == llvm::Triple::nvptx64)
+  TT = llvm::Triple("nvptx64-nvidia-cuda");
+else if (TT.getArch() == llvm::Triple::amdgcn)
+  TT = llvm::Triple("amdgcn-amd-amdhsa");
+  }
+
   // Make sure we don't have a duplicate triple.
   auto Duplicate = FoundNormalizedTriples.find(NormalizedName);
   if (Duplicate != FoundNormalizedTriples.end()) {

diff  --git a/clang/test/Driver/fat_archive_nvptx.cpp 
b/clang/test/Driver/fat_archive_nvptx.cpp
index 4c937520f05e1..a46c44ff998cc 100644
--- a/clang/test/Driver/fat_archive_nvptx.cpp
+++ b/clang/test/Driver/fat_archive_nvptx.cpp
@@ -6,9 +6,9 @@
 
 // Given a FatArchive, clang-offload-bundler should be called to create a
 // device specific archive, which should be passed to clang-nvlink-wrapper.
-// RUN: %clang -O2 -### -fopenmp -fopenmp-targets=nvptx64 %s 
-L%S/Inputs/openmp_static_device_link -lFatArchive 2>&1 | FileCheck %s
-// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "nvptx64"{{.*}}"-target-cpu" 
"[[GPU:sm_[0-9]+]]"{{.*}}"-o" "[[HOSTBC:.*.s]]" "-x" "c++"{{.*}}.cpp
-// CHECK: clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}/Inputs/openmp_static_device_link/libFatArchive.a" 
"-targets=openmp-nvptx64-[[GPU]]" "-outputs=[[DEVICESPECIFICARCHIVE:.*.a]]" 
"-allow-missing-bundles"
+// RUN: %clang -O2 -### -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda %s 
-L%S/Inputs/openmp_static_device_link -lFatArchive 2>&1 | FileCheck %s
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" 
"nvptx64-nvidia-cuda"{{.*}}"-target-cpu" "[[GPU:sm_[0-9]+]]"{{.*}}"-o" 
"[[HOSTBC:.*.s]]" "-x" "c++"{{.*}}.cpp
+// CHECK: clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}/Inputs/openmp_static_device_link/libFatArchive.a" 
"-targets=openmp-nvptx64-nvidia-cuda-[[GPU]]" 
"-outputs=[[DEVICESPECIFICARCHIVE:.*.a]]" "-allow-missing-bundles"
 // CHECK: clang-nvlink-wrapper{{.*}}"-o" "{{.*}}.out" "-arch" "[[GPU]]" 
"{{.*}}[[DEVICESPECIFICARCHIVE]]"
 // expected-no-diagnostics
 
@@ -72,8 +72,8 @@ void func_present(float* in, float* out, unsigned n){
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx908 -c func_1.c -o func_1_gfx908.o
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 -c func_2.c -o func_2_gfx906.o
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx908 -c func_2.c -o func_2_gfx908.o
-clang -O2 -fopenmp -fopenmp-targets=nvptx64 -c func_1.c -o func_1_nvptx.o
-clang -O2 -fopenmp -fopenmp-targets=nvptx64 -c func_2.c -o func_2_nvptx.o
+clang -O2 -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -c func_1.c -o 
func_1_nvptx.o
+clang -O2 -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -c func_2.c -o 
func_2_nvptx.o
 
 2. Create a fat archive by combining all the object file(s)
 llvm-ar cr libFatArchive.a func_1_gfx906.o func_1_gfx908.o func_2_gfx906.o 
func_2_gfx908.o func_1_nvptx.o func_2_nvptx.o

diff  --git a/openmp/libomptarget/DeviceRTL/CMakeLists.txt 
b/openmp/libomptarget/DeviceRTL/CMakeLists.txt
index a3c65362792ce..8185727ab84c2 100644
---

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

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

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

Address Craig's comment. Thanks.


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-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmacc-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmsac-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmsac-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmsub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmsub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmacc-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmacc-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmsac-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmsac-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmsub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfnmsub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwmacc-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwmacc-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwmsac-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwmsac-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwnmacc-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwnmacc-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwnmsac-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwnmsac-rv64.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] D117647: [RISCV] Add destination operand for RVV nomask load intrinsics.

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

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

Address Craig's comments, thanks!


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-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/unmasked-tu-rv64.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] D117520: [clang-format] Fix SeparateDefinitionBlocks issues

2022-01-19 Thread ksyx via Phabricator via cfe-commits

ksyx updated this revision to Diff 401445.
ksyx marked an inline comment as done.
ksyx added a comment.

- Apply suggestions from clangfmt
- Split assertion conditions


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

https://reviews.llvm.org/D117520

Files:
  clang/lib/Format/DefinitionBlockSeparator.cpp
  clang/lib/Format/DefinitionBlockSeparator.h
  clang/unittests/Format/DefinitionBlockSeparatorTest.cpp

Index: clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
===
--- clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
+++ clang/unittests/Format/DefinitionBlockSeparatorTest.cpp
@@ -128,6 +128,59 @@
"\n"
"enum Bar { FOOBAR, BARFOO };\n",
Style);
+
+  FormatStyle BreakAfterReturnTypeStyle = Style;
+  BreakAfterReturnTypeStyle.AlwaysBreakAfterReturnType = FormatStyle::RTBS_All;
+  // Test uppercased long typename
+  verifyFormat("class Foo {\n"
+   "  void\n"
+   "  Bar(int t, int p) {\n"
+   "int r = t + p;\n"
+   "return r;\n"
+   "  }\n"
+   "\n"
+   "  LONGTYPENAME\n"
+   "  Foobar(int t, int p) {\n"
+   "int r = t * p;\n"
+   "return r;\n"
+   "  }\n"
+   "}\n",
+  BreakAfterReturnTypeStyle);
+}
+
+TEST_F(DefinitionBlockSeparatorTest, CommentBlock) {
+  FormatStyle Style = getLLVMStyle();
+  Style.SeparateDefinitionBlocks = FormatStyle::SDS_Always;
+  std::string Prefix = "enum Foo { FOO, BAR };\n"
+   "\n"
+   "/*\n"
+   "test1\n"
+   "test2\n"
+   "*/\n"
+   "int foo(int i, int j) {\n"
+   "  int r = i + j;\n"
+   "  return r;\n"
+   "}\n";
+  std::string Suffix = "enum Bar { FOOBAR, BARFOO };\n"
+   "\n"
+   "/* Comment block in one line*/\n"
+   "int bar3(int j, int k) {\n"
+   "  // A comment\n"
+   "  int r = j % k;\n"
+   "  return r;\n"
+   "}\n";
+  std::string CommentedCode = "/*\n"
+  "int bar2(int j, int k) {\n"
+  "  int r = j / k;\n"
+  "  return r;\n"
+  "}\n"
+  "*/\n";
+  verifyFormat(removeEmptyLines(Prefix) + "\n" + CommentedCode + "\n" +
+   removeEmptyLines(Suffix),
+   Style, Prefix + "\n" + CommentedCode + "\n" + Suffix);
+  verifyFormat(removeEmptyLines(Prefix) + "\n" + CommentedCode +
+   removeEmptyLines(Suffix),
+   Style, Prefix + "\n" + CommentedCode + Suffix);
 }
 
 TEST_F(DefinitionBlockSeparatorTest, UntouchBlockStartStyle) {
@@ -172,13 +225,15 @@
   FormatStyle NeverStyle = getLLVMStyle();
   NeverStyle.SeparateDefinitionBlocks = FormatStyle::SDS_Never;
 
-  auto TestKit = MakeUntouchTest("#ifdef FOO\n\n", "\n#elifndef BAR\n\n",
- "\n#endif\n\n", false);
+  auto TestKit = MakeUntouchTest("/* FOOBAR */\n"
+ "#ifdef FOO\n\n",
+ "\n#elifndef BAR\n\n", "\n#endif\n\n", false);
   verifyFormat(TestKit.first, AlwaysStyle, TestKit.second);
   verifyFormat(TestKit.second, NeverStyle, removeEmptyLines(TestKit.second));
 
-  TestKit =
-  MakeUntouchTest("#ifdef FOO\n", "#elifndef BAR\n", "#endif\n", false);
+  TestKit = MakeUntouchTest("/* FOOBAR */\n"
+"#ifdef FOO\n",
+"#elifndef BAR\n", "#endif\n", false);
   verifyFormat(TestKit.first, AlwaysStyle, TestKit.second);
   verifyFormat(TestKit.second, NeverStyle, removeEmptyLines(TestKit.second));
 
@@ -210,7 +265,7 @@
   "test1\n"
   "test2\n"
   "*/\n"
-  "int foo(int i, int j) {\n"
+  "/*const*/ int foo(int i, int j) {\n"
   "  int r = i + j;\n"
   "  return r;\n"
   "}\n"
@@ -222,8 +277,10 @@
   "// Comment line 2\n"
   "// Comment line 3\n"
   "int bar(int j, int k) {\n"
-  "  int r = j * k;\n"
-  "  return r;\n"
+  "  {\n"
+  "int r = j * k;\n"
+  "return r;\n"
+  "  }\n"
   "}\n"
   "\n"
   "int bar2(int j, int k) {\n"
@@ -234,7 +291,7 @@
   "/* Comment block in one line*/\n"
   "enum Bar { FOOBAR, BARFOO };\n"

[clang] aba5b91 - Re-land [CodeView] Add full repro to LF_BUILDINFO record

2022-01-19 Thread Alexandre Ganea via cfe-commits


Author: Alexandre Ganea
Date: 2022-01-19T19:44:37-05:00
New Revision: aba5b91b699c556da0ee04418321b581bd33611e

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

LOG: Re-land [CodeView] Add full repro to LF_BUILDINFO record

This patch writes the full -cc1 command into the resulting .OBJ, like MSVC 
does. This allows for external tools (Recode, Live++) to rebuild a source file 
without any external dependency but the .OBJ itself (other than the compiler) 
and without knowledge of the build system.

The LF_BUILDINFO record stores a full path to the compiler, the PWD (CWD at 
program startup), a relative or absolute path to the source, and the full CC1 
command line. The stored command line is self-standing (does not depend on the 
environment). In the same way, MSVC doesn't exactly store the provided 
command-line, but an expanded version (a somehow equivalent of CC1) which is 
also self-standing.

For more information see PR36198 and D43002.

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

Added: 
clang/test/CodeGen/debug-info-codeview-buildinfo.c

Modified: 
clang/cmake/caches/BaremetalARM.cmake
clang/cmake/caches/CrossWinToARMLinux.cmake
clang/cmake/caches/Fuchsia-stage2.cmake
lld/test/COFF/Inputs/pdb_lines_1_relative.yaml
lld/test/COFF/Inputs/pdb_lines_2_relative.yaml
lld/test/COFF/pdb-relative-source-lines.test
llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
llvm/test/DebugInfo/COFF/build-info.ll
llvm/test/DebugInfo/COFF/global-type-hashes.ll
llvm/test/DebugInfo/COFF/types-basic.ll
llvm/test/DebugInfo/COFF/types-data-members.ll

Removed: 




diff  --git a/clang/cmake/caches/BaremetalARM.cmake 
b/clang/cmake/caches/BaremetalARM.cmake
index 85295d9db392a..e44355cfcbd74 100644
--- a/clang/cmake/caches/BaremetalARM.cmake
+++ b/clang/cmake/caches/BaremetalARM.cmake
@@ -31,6 +31,7 @@ set(LLVM_TOOLCHAIN_TOOLS
   llvm-dwarfdump
   llvm-nm
   llvm-objdump
+  llvm-pdbutil
   llvm-ranlib
   llvm-readobj
   llvm-size

diff  --git a/clang/cmake/caches/CrossWinToARMLinux.cmake 
b/clang/cmake/caches/CrossWinToARMLinux.cmake
index f015c67e3b9ce..dd03a37b4b8f9 100644
--- a/clang/cmake/caches/CrossWinToARMLinux.cmake
+++ b/clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -182,6 +182,7 @@ set(LLVM_TOOLCHAIN_TOOLS
   llvm-lib
   llvm-nm
   llvm-objdump
+  llvm-pdbutil
   llvm-profdata
   llvm-ranlib
   llvm-readobj

diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index 0d572b670541e..de8ac89fbfaa0 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -277,6 +277,7 @@ set(LLVM_TOOLCHAIN_TOOLS
   llvm-objcopy
   llvm-objdump
   llvm-otool
+  llvm-pdbutil
   llvm-profdata
   llvm-rc
   llvm-ranlib

diff  --git a/clang/test/CodeGen/debug-info-codeview-buildinfo.c 
b/clang/test/CodeGen/debug-info-codeview-buildinfo.c
new file mode 100644
index 0..93810e829c6d9
--- /dev/null
+++ b/clang/test/CodeGen/debug-info-codeview-buildinfo.c
@@ -0,0 +1,26 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang_cl --target=i686-windows-msvc /c /Z7 /Fo%t.obj -- %s
+// RUN: llvm-pdbutil dump --types %t.obj | FileCheck %s
+// RUN: %clang_cl --target=i686-windows-msvc /c /Z7 /Fo%t.obj 
-fdebug-compilation-dir=. -- %s
+// RUN: llvm-pdbutil dump --types %t.obj | FileCheck %s --check-prefix RELATIVE
+
+int main() { return 42; }
+
+// CHECK:   Types (.debug$T)
+// CHECK: 
+// CHECK: 0x[[PWD:.+]] | LF_STRING_ID [size = {{.+}}] ID: , String: 
[[PWDVAL:.+]]
+// CHECK: 0x[[FILEPATH:.+]] | LF_STRING_ID [size = {{.+}}] ID: , 
String: [[FILEPATHVAL:.+[\\/]debug-info-codeview-buildinfo.c]]
+// CHECK: 0x[[ZIPDB:.+]] | LF_STRING_ID [size = {{.+}}] ID: , String:
+// CHECK: 0x[[TOOL:.+]] | LF_STRING_ID [size = {{.+}}] ID: , String: 
[[TOOLVAL:.+[\\/]clang.*]]
+// CHECK: 0x[[CMDLINE:.+]] | LF_STRING_ID [size = {{.+}}] ID: , 
String: "-cc1
+// CHECK: 0x{{.+}} | LF_BUILDINFO [size = {{.+}}]
+// CHECK:  0x[[PWD]]: `[[PWDVAL]]`
+// CHECK:  0x[[TOOL]]: `[[TOOLVAL]]`
+// CHECK:  0x[[FILEPATH]]: `[[FILEPATHVAL]]`
+// CHECK:  0x[[ZIPDB]]: ``
+// CHECK:  0x[[CMDLINE]]: `"-cc1
+
+// RELATIVE:   Types (.debug$T)
+// RELATIVE: 
+// RELATIVE: 0x{{.+}} | LF_BUILDINFO [size = {{.+}}]
+// RELATIVE:  0x{{.+}}: `.`

diff  --git a/lld/test/COFF/Inputs/pdb_lines_1_relative.yaml 
b/lld/test/COFF/Inputs/pdb_lines_1_relative.yaml
index 947de419d6b8b..9a6b192e1d0d2 100644
--- a/lld/test/COFF/Inputs/pdb_lines_1_relative.yaml
+++ b/lld/test/COFF/Inputs/pdb_lines_1_relative.yaml
@@ -19,6 +19,7 @@

[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

2022-01-19 Thread Alexandre Ganea 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 rGaba5b91b699c: Re-land [CodeView] Add full repro to 
LF_BUILDINFO record (authored by aganea).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80833

Files:
  clang/cmake/caches/BaremetalARM.cmake
  clang/cmake/caches/CrossWinToARMLinux.cmake
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/test/CodeGen/debug-info-codeview-buildinfo.c
  lld/test/COFF/Inputs/pdb_lines_1_relative.yaml
  lld/test/COFF/Inputs/pdb_lines_2_relative.yaml
  lld/test/COFF/pdb-relative-source-lines.test
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/test/DebugInfo/COFF/build-info.ll
  llvm/test/DebugInfo/COFF/global-type-hashes.ll
  llvm/test/DebugInfo/COFF/types-basic.ll
  llvm/test/DebugInfo/COFF/types-data-members.ll

Index: llvm/test/DebugInfo/COFF/types-data-members.ll
===
--- llvm/test/DebugInfo/COFF/types-data-members.ll
+++ llvm/test/DebugInfo/COFF/types-data-members.ll
@@ -727,14 +727,22 @@
 ; ASM: .asciz	"t.cpp" # StringData
 ; ASM: .byte	242
 ; ASM: .byte	241
-; ASM: # BuildInfo (0x1022)
+; ASM: # StringId (0x1022)
+; ASM: .short	0xa # Record length
+; ASM: .short	0x1605  # Record kind: LF_STRING_ID
+; ASM: .long	0x0 # Id
+; ASM: .byte0   # StringData
+; ASM: .byte	243
+; ASM: .byte	242
+; ASM: .byte	241
+; ASM: # BuildInfo (0x1023)
 ; ASM: .short	0x1a# Record length
 ; ASM: .short	0x1603  # Record kind: LF_BUILDINFO
 ; ASM: .short	0x5 # NumArgs
 ; ASM: .long	0x1020  # Argument: D:\src\llvm\build
 ; ASM: .long	0x0 # Argument
 ; ASM: .long	0x1021  # Argument: t.cpp
-; ASM: .long	0x0 # Argument
+; ASM: .long	0x1022  # Argument
 ; ASM: .long	0x0 # Argument
 ; ASM: .byte	242
 ; ASM: .byte	241
Index: llvm/test/DebugInfo/COFF/types-basic.ll
===
--- llvm/test/DebugInfo/COFF/types-basic.ll
+++ llvm/test/DebugInfo/COFF/types-basic.ll
@@ -511,14 +511,22 @@
 ; ASM: .asciz	"t.cpp" # StringData
 ; ASM: .byte	242
 ; ASM: .byte	241
-; ASM: # BuildInfo (0x1015)
+; ASM: # StringId (0x1015)
+; ASM: .short	0xa # Record length
+; ASM: .short	0x1605  # Record kind: LF_STRING_ID
+; ASM: .long	0x0 # Id
+; ASM: .byte0   # StringData
+; ASM: .byte	243
+; ASM: .byte	242
+; ASM: .byte	241
+; ASM: # BuildInfo (0x1016)
 ; ASM: .short	0x1a# Record length
 ; ASM: .short	0x1603  # Record kind: LF_BUILDINFO
 ; ASM: .short	0x5 # NumArgs
 ; ASM: .long	0x1013  # Argument: D:\src\llvm\build
 ; ASM: .long	0x0 # Argument
 ; ASM: .long	0x1014  # Argument: t.cpp
-; ASM: .long	0x0 # Argument
+; ASM: .long	0x1015  # Argument
 ; ASM: .long	0x0 # Argument
 ; ASM: .byte	242
 ; ASM: .byte	241
Index: llvm/test/DebugInfo/COFF/global-type-hashes.ll
===
--- llvm/test/DebugInfo/COFF/global-type-hashes.ll
+++ llvm/test/DebugInfo/COFF/global-type-hashes.ll
@@ -295,7 +295,8 @@
 ; YAML: - 4470750F2E319329
 ; YAML: - 0FB556FD1FAB66D7
 ; YAML: - 5970EFB4874D0F3F
-; YAML: - EDB1D74C120CF44A
+; YAML: - D8EF11198C33843F
+; YAML: - D81F744D7366282B
 ; ...
 
 
Index: llvm/test/DebugInfo/COFF/build-info.ll
===
--- llvm/test/DebugInfo/COFF/build-info.ll
+++ llvm/test/DebugInfo/COFF/build-info.ll
@@ -5,7 +5,7 @@
 ; CHECK-NEXT:  0x{{.*}}: `D:\src\scopes\clang`
 ; CHECK-NEXT:  : ``
 ; CHECK-NEXT:  0x{{.*}}: `D:\src\scopes\foo.cpp`
-; CHECK-NEXT:  : ``
+; CHECK-NEXT:  0x{{.*}}: ``
 ; CHECK-NEXT:  : ``
 
 ; CHECK: {{.*}} | S_BUILDINFO [size = 8] BuildId = `[[INFO_IDX]]`
Index: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
+++ llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
@@ -68,6 +68,7 @@
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/SMLoc.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "llvm/Target/TargetLoweringObjectFile.h"
@@ -889,6 +890,34 @@
   return TypeTable.writeLeafType(SIR);
 }
 
+static std::string flattenCommandLine(ArrayRef Args,
+

[PATCH] D117730: [DNM][VFS] Do not overwrite the path when nesting RedirectingFileSystems

2022-01-19 Thread Ben Barham via Phabricator via cfe-commits

bnbarham created this revision.
Herald added subscribers: dexonsmith, hiraditya.
bnbarham requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

86e2af8043c7728710a711b623f27425801a36c3 
 aimed to 
preserve the original
relative path when falling back to the external filesystem. But when
there's nested `RedirectingFileSystems` this results in the outer-most
VFS overwriting the path of a lower VFS.

For example, take a directory remapping overlay of `A -> B` and another
of `B -> C` where both have `use-external-names` set. If `A/foo` is
requested this will map `A/foo` to `B/foo` to `C/foo` but when this
result returns to the `A -> B` VFS, it will then remap the `Status` and
`File` to `B/foo` instead.

This is only a partial fix - it fixes `openFileForRead`, but `status`
and `getRealPath` would need equivalent changes. I'm putting up this
partial PR to gather opinions on whether this seems reasonable first.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117730

Files:
  clang/test/VFS/directory.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/FileCollector.cpp
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -63,11 +63,13 @@
   return make_error_code(llvm::errc::no_such_file_or_directory);
 return I->second;
   }
-  ErrorOr>
-  openFileForRead(const Twine ) override {
-auto S = status(Path);
-if (S)
-  return std::unique_ptr(new DummyFile{*S});
+  ErrorOr> openFileForReadImpl(
+  const Twine , const Twine ) override {
+auto S = status(LookupPath);
+if (S) {
+  auto FixedS = vfs::Status::copyWithNewName(*S, OriginalPath);
+  return std::unique_ptr(new DummyFile{FixedS});
+}
 return S.getError();
   }
   llvm::ErrorOr getCurrentWorkingDirectory() const override {
@@ -2708,6 +2710,80 @@
   EXPECT_FALSE(FS->exists(_c.path("c")));
 }
 
+TEST_F(VFSFromYAMLTest, MultipleRemappedDirectories) {
+  // Test the interaction of two overlays where one maps back to the other,
+  // ie. `a` -> `b` and then `b` -> `a`. This should always use `a` if it
+  // exists and fallback to `b` otherwise.
+
+  IntrusiveRefCntPtr Both(new DummyFileSystem());
+  Both->addDirectory("//root/a");
+  Both->addRegularFile("//root/a/f");
+  Both->addDirectory("//root/b");
+  Both->addRegularFile("//root/b/f");
+
+  IntrusiveRefCntPtr AOnly(new DummyFileSystem());
+  AOnly->addDirectory("//root/a");
+  AOnly->addRegularFile("//root/a/f");
+
+  IntrusiveRefCntPtr BOnly(new DummyFileSystem());
+  BOnly->addDirectory("//root/b");
+  BOnly->addRegularFile("//root/b/f");
+
+  auto AToBStr = "{ 'roots': [\n"
+ "  {\n"
+ "'type': 'directory-remap',\n"
+ "'name': '//root/a',\n"
+ "'external-contents': '//root/b'\n"
+ "  }"
+ "]}";
+  auto BToAStr = "{ 'roots': [\n"
+ "  {\n"
+ "'type': 'directory-remap',\n"
+ "'name': '//root/b',\n"
+ "'external-contents': '//root/a'\n"
+ "  }"
+ "]}";
+
+  auto ExpectPath = [&](vfs::FileSystem , StringRef Expected) {
+auto AF = FS.openFileForRead("//root/a/f");
+ASSERT_FALSE(AF.getError());
+auto AFName = (*AF)->getName();
+ASSERT_FALSE(AFName.getError());
+EXPECT_EQ(Expected.str(), AFName.get());
+
+auto AS = FS.status("//root/a/f");
+ASSERT_FALSE(AS.getError());
+EXPECT_EQ(Expected.str(), AS->getName());
+
+auto BF = FS.openFileForRead("//root/b/f");
+ASSERT_FALSE(BF.getError());
+auto BName = (*BF)->getName();
+ASSERT_FALSE(BName.getError());
+EXPECT_EQ(Expected.str(), BName.get());
+
+auto BS = FS.status("//root/b/f");
+ASSERT_FALSE(BS.getError());
+EXPECT_EQ(Expected.str(), BS->getName());
+  };
+
+  IntrusiveRefCntPtr BothFS =
+  getFromYAMLString(AToBStr, getFromYAMLString(BToAStr, Both));
+  ASSERT_TRUE(BothFS.get() != nullptr);
+  ExpectPath(*BothFS, "//root/a/f");
+
+  IntrusiveRefCntPtr OnlyAFS =
+  getFromYAMLString(AToBStr, getFromYAMLString(BToAStr, AOnly));
+  ASSERT_TRUE(OnlyAFS.get() != nullptr);
+  ExpectPath(*OnlyAFS, "//root/a/f");
+
+  IntrusiveRefCntPtr OnlyBFS =
+  getFromYAMLString(AToBStr, getFromYAMLString(BToAStr, BOnly));
+  ASSERT_TRUE(OnlyBFS.get() != nullptr);
+  ExpectPath(*OnlyBFS, "//root/b/f");
+
+  EXPECT_EQ(0, NumDiagnostics);
+}
+
 TEST(VFSFromRemappedFilesTest, Basic) {
   IntrusiveRefCntPtr BaseFS =
   new vfs::InMemoryFileSystem;
Index: llvm/lib/Support/VirtualFileSystem.cpp

[PATCH] D117056: [clangd] Properly compute framework-style include spelling

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

sammccall added a comment.

This looks good now, only blocker is dropping the change to LookupFile somehow.

Is it valuable to land this before the imminent 14 branch cut? I think it's OK 
but as an indexing change a crash has the possibility to be really disruptive, 
and most of the rest of us aren't regularly dogfooding this on Mac.
I'd suggest we only land it before the branch if you feel like you can test 
this on a reasonable variety of code in the next few weeks. WDYT?




Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:293
+   HeaderSearch ,
+   FrameworkHeaderPath ) {
+auto Res = CacheFrameworkToUmbrellaHeaderSpelling.try_emplace(Framework);

I'd suggest only passing the CharacteristicKind HeadersDir here rather than the 
whole FileEntry + HeaderPath.
Or failing that, being very explicit that these are just for an *example* 
header.

(The confusing part/trap here is that we're computing something based on one 
input, and then caching it so that it will be used for other inputs, without 
verifying that they would produce the same answer)



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:309
+if (StatErr) {
+  *CachedSpelling = "";
+  return llvm::None;

nit: this is a no-op



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:326
+auto Path = FE->getName();
+auto It = CachePathToFrameworkSpelling.find(Path);
+if (It != CachePathToFrameworkSpelling.end())

any reason not to also try_emplace here and reuse the iterator below?



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:334
+  // them. Cache the failure as well so we won't do this again for the same
+  // header.
+  CachePathToFrameworkSpelling[Path] = "";

We're (deliberately?) bypassing the umbrella cache here, say why private 
headers shouldn't be replaced by the umbrella header?
Presumably because they're not exported by it...



Comment at: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp:712
+}
+
 TEST_F(SymbolCollectorTest, Locations) {

Add a test that private headers are not replaced by the umbrella?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117056

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

[PATCH] D116385: [clangd] Code action for creating an ObjC initializer

2022-01-19 Thread David Goldman via Phabricator via cfe-commits

dgoldman added a comment.

PTAL, let me know what you think regarding the edits, had to make sure it works 
even if we generate multiple edits in the same file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116385

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

[PATCH] D117056: [clangd] Properly compute framework-style include spelling

2022-01-19 Thread David Goldman via Phabricator via cfe-commits

dgoldman added inline comments.



Comment at: clang/lib/Lex/HeaderSearch.cpp:1052
 HFI.IndexHeaderMapHeader = 1;
+} else if (CurDir->isFramework()) {
+  size_t SlashPos = Filename.find('/');

sammccall wrote:
> This looks like a separate change, and should have a test in clang.
Will try to split out + add a test tomorrow


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117056

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

[PATCH] D117724: [RISCV] Remove Zvlsseg extension.

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: llvm/test/MC/RISCV/rvv/zvlsseg.s:11
 # RUN: llvm-mc -triple=riscv64 -filetype=obj --mattr=+experimental-v \
 # RUN:   --mattr=+experimental-zvlsseg %s \
 # RUN:   | llvm-objdump -d - | FileCheck %s --check-prefix=CHECK-UNKNOWN

khchen wrote:
> I think we need to remove +experimental-zvlsseg? 
> It seems like giving the wrong mattr would not cause any error.
Thanks I guess I should have grepped the test directory.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117724

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

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Devin Jeanpierre via Phabricator via cfe-commits

devin.jeanpierre added a comment.

@rsmith I've pulled+rebased again to avoid the (looks like pre-existing) 
failure. Copy-pasting the wording on 
https://llvm.org/docs/MyFirstTypoFix.html#commit-by-proxy: I don’t have commit 
access, can you land this patch for me? Please use “Devin Jeanpierre 
jeanpierr...@google.com” to commit the change.

(I normally use the jeanpierreda email alias for external stuff, so that my 
internal username doesn't leak.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732

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

[PATCH] D117724: [RISCV] Remove Zvlsseg extension.

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

khchen added inline comments.



Comment at: llvm/test/MC/RISCV/rvv/zvlsseg.s:11
 # RUN: llvm-mc -triple=riscv64 -filetype=obj --mattr=+experimental-v \
 # RUN:   --mattr=+experimental-zvlsseg %s \
 # RUN:   | llvm-objdump -d - | FileCheck %s --check-prefix=CHECK-UNKNOWN

I think we need to remove +experimental-zvlsseg? 
It seems like giving the wrong mattr would not cause any error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117724

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

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

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td:2187
+multiclass VPseudoTernaryNoMaskNoPolicyhttps://reviews.llvm.org/D117681/new/

https://reviews.llvm.org/D117681

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

[PATCH] D117056: [clangd] Properly compute framework-style include spelling

2022-01-19 Thread David Goldman via Phabricator via cfe-commits

dgoldman added inline comments.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:295
+if (!R.second && !R.first->second.empty()) {
+  // Framework has known umbrella spelling, cache it for this header as
+  // well.

sammccall wrote:
> Why? Seems like just looking up the umbrella first would be simpler and just 
> as efficient.
To give a proper spelling for private framework headers (although maybe the 
framework import would be more useful than a non-framework import? I dunno)



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:303
+  SpellingR.first->second = "";
+  R.first->second = "";
+  return R.first->second;

sammccall wrote:
> if the header we happened to see first is PrivateHeaders, then you're caching 
> the fact that this framework has no umbrella header.
> 
> There's a design decision here: is the path of any single header sufficient 
> to decide whether a framework has an umbrella? If not, the cache needs to 
> work differently.
Fixed



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:308
+
+SmallString<256> UmbrellaPath(Info.HeadersDir);
+llvm::sys::path::append(UmbrellaPath, Framework + ".h");

sammccall wrote:
> comment here on what an umbrella header is and why we care
Added a comment to the top of getFrameworkUmbrellaSpelling



Comment at: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp:762
+  Header, Main,
+  {"-iframeworkwithsysroot", FrameworksPath, "-xobjective-c++"});
+  EXPECT_THAT(Symbols, UnorderedElementsAre(

sammccall wrote:
> OOC, is "withsysroot" needed here?
Changed, should have been iframework to add a system framework path


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117056

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

[PATCH] D117056: [clangd] Properly compute framework-style include spelling

2022-01-19 Thread David Goldman via Phabricator via cfe-commits

dgoldman updated this revision to Diff 401422.
dgoldman marked 18 inline comments as done.
dgoldman added a comment.

Changes for review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117056

Files:
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
  clang/lib/Lex/HeaderSearch.cpp

Index: clang/lib/Lex/HeaderSearch.cpp
===
--- clang/lib/Lex/HeaderSearch.cpp
+++ clang/lib/Lex/HeaderSearch.cpp
@@ -1049,6 +1049,11 @@
 getUniqueFrameworkName(StringRef(Filename.begin(), SlashPos));
   if (CurDir->isIndexHeaderMap())
 HFI.IndexHeaderMapHeader = 1;
+} else if (CurDir->isFramework()) {
+  size_t SlashPos = Filename.find('/');
+  if (SlashPos != StringRef::npos)
+HFI.Framework =
+getUniqueFrameworkName(StringRef(Filename.begin(), SlashPos));
 }
 
 if (checkMSVCHeaderSearch(Diags, MSFE ? >getFileEntry() : nullptr,
Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -663,6 +663,53 @@
   QName("Cat::meow"), QName("Cat::pur")));
 }
 
+TEST_F(SymbolCollectorTest, ObjCFrameworkIncludeHeader) {
+  CollectorOpts.CollectIncludePath = true;
+  auto FrameworksPath = testPath("Frameworks/");
+  std::string FrameworkHeader = R"(
+__attribute((objc_root_class))
+@interface NSObject
+@end
+  )";
+  InMemoryFileSystem->addFile(
+  testPath("Frameworks/Foundation.framework/Headers/NSObject.h"), 0,
+  llvm::MemoryBuffer::getMemBuffer(FrameworkHeader));
+
+  std::string Header = R"(
+#import 
+
+@interface Container : NSObject
+@end
+  )";
+  std::string Main = "";
+  TestFileName = testPath("test.m");
+  runSymbolCollector(Header, Main, {"-F", FrameworksPath, "-xobjective-c++"});
+  EXPECT_THAT(Symbols, UnorderedElementsAre(
+   AllOf(QName("NSObject"),
+ IncludeHeader("\"Foundation/NSObject.h\"")),
+   AllOf(QName("Container";
+
+  // After adding the umbrella header, we should use that spelling instead.
+  std::string UmbrellaHeader = R"(
+#import 
+  )";
+  InMemoryFileSystem->addFile(
+  testPath("Frameworks/Foundation.framework/Headers/Foundation.h"), 0,
+  llvm::MemoryBuffer::getMemBuffer(UmbrellaHeader));
+  runSymbolCollector(Header, Main, {"-F", FrameworksPath, "-xobjective-c++"});
+  EXPECT_THAT(Symbols, UnorderedElementsAre(
+   AllOf(QName("NSObject"),
+ IncludeHeader("\"Foundation/Foundation.h\"")),
+   AllOf(QName("Container";
+
+  runSymbolCollector(Header, Main,
+ {"-iframework", FrameworksPath, "-xobjective-c++"});
+  EXPECT_THAT(Symbols, UnorderedElementsAre(
+   AllOf(QName("NSObject"),
+ IncludeHeader("")),
+   AllOf(QName("Container";
+}
+
 TEST_F(SymbolCollectorTest, Locations) {
   Annotations Header(R"cpp(
 // Declared in header, defined in main.
Index: clang-tools-extra/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -193,6 +193,8 @@
   llvm::DenseMap CacheFEToURI;
   llvm::StringMap CachePathToURI;
   llvm::DenseMap CacheFIDToInclude;
+  llvm::StringMap CachePathToFrameworkSpelling;
+  llvm::StringMap CacheFrameworkToUmbrellaHeaderSpelling;
 
 public:
   HeaderFileURICache(Preprocessor *, const SourceManager ,
@@ -249,6 +251,112 @@
 return R.first->second;
   }
 
+  struct FrameworkHeaderPath {
+// Path to the Headers dir e.g. /Frameworks/Foundation.framework/Headers/
+llvm::StringRef HeadersDir;
+// Subpath relative to the Headers dir, e.g. NSObject.h
+llvm::StringRef HeaderSubpath;
+  };
+
+  llvm::Optional
+  splitFrameworkHeaderPath(llvm::StringRef Path) {
+using namespace llvm::sys;
+path::reverse_iterator I = path::rbegin(Path);
+path::reverse_iterator Prev = I;
+path::reverse_iterator E = path::rend(Path);
+while (I != E) {
+  if (*I == "Headers") {
+auto PrefixLen = Prev - E;
+FrameworkHeaderPath HeaderPath;
+HeaderPath.HeadersDir = Path.substr(0, PrefixLen);
+HeaderPath.HeaderSubpath = Path.substr(PrefixLen);
+return HeaderPath;
+  }
+  // We don't currently support handling the private headers dir, just
+  // return early.
+  if (*I == "PrivateHeaders") {
+return llvm::None;
+  }
+  Prev = I;
+  ++I;
+

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

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:1238
   unsigned CurOp = 2;
+  bool IsTU = false;
+  if ((IntNo != Intrinsic::riscv_vlm &&

```
bool IsTU = IntNo != Intrinsic::riscv_vlm && 
(!Node->getOperand(CurOp).isUndef() || IsMasked);
```

NOTE: I changed it so IsMask is also only checked when it's not vlm. That makes 
the non vlm part of the condition look like the other intrinsic handling 
earlier.



Comment at: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:1251
   addVectorLoadStoreOperands(Node, Log2SEW, DL, CurOp, IsMasked, IsStrided,
- Operands, /*IsLoad=*/true);
+ Operands, /*IsLoad=*/true, 
/*IndexVT=*/nullptr);
 

Why aren't we using the default value for IndexVT now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117647

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

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Devin Jeanpierre via Phabricator via cfe-commits

devin.jeanpierre updated this revision to Diff 401419.
devin.jeanpierre added a comment.

pull/rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/attr-trivial-abi.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -8,7 +8,7 @@
 #define TRAIT_IS_FALSE(Trait, Type) static_assert(!Trait(Type), "")
 #define TRAIT_IS_TRUE_2(Trait, Type1, Type2) static_assert(Trait(Type1, Type2), "")
 #define TRAIT_IS_FALSE_2(Trait, Type1, Type2) static_assert(!Trait(Type1, Type2), "")
-  
+
 struct HasStrong { id obj; };
 struct HasWeak { __weak id obj; };
 struct HasUnsafeUnretained { __unsafe_unretained id obj; };
@@ -208,3 +208,12 @@
 TRAIT_IS_FALSE_2(__is_trivially_constructible, HasWeak, HasWeak&&);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained&&);
+
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __unsafe_unretained id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasStrong);
+TRAIT_IS_FALSE(__is_trivially_relocatable, HasWeak);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasUnsafeUnretained);
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -12,7 +12,7 @@
 #define TRAIT_IS_FALSE(Trait, Type) char JOIN2(Trait,__LINE__)[Trait(Type)? -1 : 1]
 #define TRAIT_IS_TRUE_2(Trait, Type1, Type2) char JOIN2(Trait,__LINE__)[Trait(Type1, Type2)? 1 : -1]
 #define TRAIT_IS_FALSE_2(Trait, Type1, Type2) char JOIN2(Trait,__LINE__)[Trait(Type1, Type2)? -1 : 1]
-  
+
 struct HasStrong { id obj; };
 struct HasWeak { __weak id obj; };
 struct HasUnsafeUnretained { __unsafe_unretained id obj; };
@@ -213,3 +213,11 @@
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained&&);
 
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __unsafe_unretained id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasStrong);
+TRAIT_IS_FALSE(__is_trivially_relocatable, HasWeak);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasUnsafeUnretained);
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -2854,3 +2854,64 @@
 #undef T16384
 #undef T32768
 } // namespace type_trait_expr_numargs_overflow
+
+namespace is_trivially_relocatable {
+
+static_assert(!__is_trivially_relocatable(void), "");
+static_assert(__is_trivially_relocatable(int), "");
+static_assert(__is_trivially_relocatable(int[]), "");
+
+enum Enum {};
+static_assert(__is_trivially_relocatable(Enum), "");
+static_assert(__is_trivially_relocatable(Enum[]), "");
+
+union Union {int x;};
+static_assert(__is_trivially_relocatable(Union), "");
+static_assert(__is_trivially_relocatable(Union[]), "");
+
+struct Trivial {};
+static_assert(__is_trivially_relocatable(Trivial), "");
+static_assert(__is_trivially_relocatable(Trivial[]), "");
+
+struct Incomplete; // expected-note {{forward declaration of 'is_trivially_relocatable::Incomplete'}}
+bool unused = __is_trivially_relocatable(Incomplete); // expected-error {{incomplete type}}
+
+struct NontrivialDtor {
+  ~NontrivialDtor() {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialDtor), "");
+static_assert(!__is_trivially_relocatable(NontrivialDtor[]), "");
+
+struct NontrivialCopyCtor {
+  NontrivialCopyCtor(const NontrivialCopyCtor&) {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialCopyCtor), "");
+static_assert(!__is_trivially_relocatable(NontrivialCopyCtor[]), "");
+
+struct NontrivialMoveCtor {
+  NontrivialMoveCtor(NontrivialMoveCtor&&) {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialMoveCtor), "");

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

2022-01-19 Thread Nathan Chancellor via Phabricator via cfe-commits

nathanchance added a comment.

In D117717#3256293 , @MaskRay wrote:

> Assuming scan-build is clang/tools/scan-build, which is in tree and can be 
> fixed instead.

Yes, that is the one.

> I am not familiar with it, but from
>
>> However, this caused issues with scan-build, as GCC is used as the compiler 
>> but clang is invoked after it with all the -f options that GCC was.
>
> if scan-build+GCC takes all GCC recognized options and forwards them to 
> Clang, I think it is a generally infeasible model.
> GCC has dozens of options not recognized by Clang...

I can barely read Perl but it seems like that is what the script does:

https://github.com/llvm/llvm-project/blob/058d2123792da54ae7460fea0946d2c90a032e1c/clang/tools/scan-build/libexec/ccc-analyzer#L661-L664

I don't really know what the fix is for that on the `scan-build` side of things 
(how do you decide what flags should be passed through or not?). If there is 
someone who should be looped in, please do so.

I agree that this is an infeasible model to support so I have commented on the 
kernel patch that brought this up: 
https://lore.kernel.org/r/YeiaAgQ+gbZYTMwD@archlinux-ax161/

I'll abandon this depending on what others have to say.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117717

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

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

2022-01-19 Thread Zahira Ammarguellat via Phabricator via cfe-commits

zahiraam updated this revision to Diff 401415.

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

https://reviews.llvm.org/D117569

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

Index: clang/test/SemaCXX/dllimport-constexpr.cpp
===
--- clang/test/SemaCXX/dllimport-constexpr.cpp
+++ clang/test/SemaCXX/dllimport-constexpr.cpp
@@ -40,7 +40,6 @@
 // constexpr initialization doesn't work for dllimport things.
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (*constexpr_import_func)() = _func;
-// expected-error@+1{{must be initialized by a constant expression}}
 constexpr int *constexpr_import_int = _int;
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (Foo::*constexpr_memptr)() = ::imported_method;
@@ -60,3 +59,8 @@
   // expected-note@+1 {{requested here}}
   StaticConstexpr::g_fp();
 }
+
+void foo() {
+  extern int __declspec(dllimport) dll_import_int;
+  constexpr int& dll_import_constexpr_ref = dll_import_int;
+}
Index: clang/test/SemaCXX/PR19955.cpp
===
--- clang/test/SemaCXX/PR19955.cpp
+++ clang/test/SemaCXX/PR19955.cpp
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -triple i686-mingw32 -verify -std=c++11 %s
 
 extern int __attribute__((dllimport)) var;
-constexpr int *varp =  // expected-error {{must be initialized by a constant expression}}
+constexpr int *varp = 
 
 extern __attribute__((dllimport)) void fun();
 constexpr void (*funp)(void) =  // expected-error {{must be initialized by a constant expression}}
Index: clang/test/CodeGenCXX/dllimport.cpp
===
--- clang/test/CodeGenCXX/dllimport.cpp
+++ clang/test/CodeGenCXX/dllimport.cpp
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M32 %s
-// RUN: %clang_cc1 -disable-noundef-analysis -triple x86_64-windows-msvc -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M64 %s
+// RUN: %clang_cc1 -disable-noundef-analysis -triple x86_64-windows-msvc -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC64 --check-prefix=M64 %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-gnu-fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -w | FileCheck --check-prefix=GNU --check-prefix=G32 %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple x86_64-windows-gnu  -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -w | FileCheck --check-prefix=GNU %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -fms-compatibility-version=18.00 -emit-llvm -std=c++1y -O1 -disable-llvm-passes -o - %s -DMSABI -w | FileCheck --check-prefix=MO1 --check-prefix=M18 %s
@@ -39,30 +39,34 @@
 
 // Import declaration.
 // MSC-DAG: @"?ExternGlobalDecl@@3HA" = external dllimport global i32
+// MSC64-DAG: @"?ExternGlobalDecl@@3HA" = external dllimport global i32
 // GNU-DAG: @ExternGlobalDecl= external dllimport global i32
 __declspec(dllimport) extern int ExternGlobalDecl;
 USEVAR(ExternGlobalDecl)
 
 // dllimport implies a declaration.
 // MSC-DAG: @"?GlobalDecl@@3HA" = external dllimport global i32
+// MSC64-DAG: @"?GlobalDecl@@3HA" = external dllimport global i32
 // GNU-DAG: @GlobalDecl= external dllimport global i32
 __declspec(dllimport) int GlobalDecl;
 USEVAR(GlobalDecl)
 
 // Redeclarations
 // MSC-DAG: @"?GlobalRedecl1@@3HA" = external dllimport global i32
+// MSC64-DAG: @"?GlobalRedecl1@@3HA" = external dllimport global i32
 // GNU-DAG: @GlobalRedecl1= external dllimport global i32
 __declspec(dllimport) extern int GlobalRedecl1;
 __declspec(dllimport) extern int GlobalRedecl1;
 USEVAR(GlobalRedecl1)
 
 // MSC-DAG: @"?GlobalRedecl2a@@3HA" = external dllimport global i32
+// MSC64-DAG: @"?GlobalRedecl2a@@3HA" = external dllimport global i32
 // GNU-DAG: @GlobalRedecl2a= external dllimport global i32
 __declspec(dllimport) int GlobalRedecl2a;
 __declspec(dllimport) int GlobalRedecl2a;
 USEVAR(GlobalRedecl2a)
 
-// M32-DAG: @"?GlobalRedecl2b@@3PAHA"   = external dllimport global i32*
+// MSC-DAG: @"?GlobalRedecl2b@@3PAHA"   = external dllimport global i32*
 // M64-DAG: @"?GlobalRedecl2b@@3PEAHEA" = external dllimport global i32*
 // GNU-DAG: @GlobalRedecl2b= external dllimport global i32*
 int

[PATCH] D117522: [clang-tidy] Add modernize-macro-to-enum check

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

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

- Tweak documentation, make sure sphinx runs without errors


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

https://reviews.llvm.org/D117522

Files:
  clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
  clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
  clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.h
  clang-tools-extra/clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-macro-to-enum/modernize-macro-to-enum.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-macro-to-enum/modernize-macro-to-enum2.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-macro-to-enum/modernize-macro-to-enum3.h
  clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
@@ -0,0 +1,137 @@
+// RUN: %check_clang_tidy %s modernize-macro-to-enum %t -- -- -I%S/Inputs/modernize-macro-to-enum
+
+#if 1
+#include "modernize-macro-to-enum.h"
+
+// These macros are skipped due to being inside a conditional compilation block.
+#define GOO_RED 1
+#define GOO_GREEN 2
+#define GOO_BLUE 3
+
+#endif
+
+#define RED 0xFF
+#define GREEN 0x00FF00
+#define BLUE 0xFF
+// CHECK-MESSAGES: :[[@LINE-3]]:1: warning: Replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-4]]:9: warning: Macro 'RED' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-4]]:9: warning: Macro 'GREEN' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-4]]:9: warning: Macro 'BLUE' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: RED = 0xFF,
+// CHECK-FIXES-NEXT: GREEN = 0x00FF00,
+// CHECK-FIXES-NEXT: BLUE = 0xFF
+// CHECK-FIXES-NEXT: };
+
+// Verify that comments are preserved.
+#define CoordModeOrigin 0   /* relative to the origin */
+#define CoordModePrevious   1   /* relative to previous point */
+// CHECK-MESSAGES: :[[@LINE-2]]:1: warning: Replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-3]]:9: warning: Macro 'CoordModeOrigin' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-3]]:9: warning: Macro 'CoordModePrevious' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: CoordModeOrigin = 0,   /* relative to the origin */
+// CHECK-FIXES-NEXT: CoordModePrevious =   1   /* relative to previous point */
+// CHECK-FIXES-NEXT: };
+
+// Verify that multiline comments are preserved.
+#define BadDrawable 9   /* parameter not a Pixmap or Window */
+#define BadAccess   10  /* depending on context:
+- key/button already grabbed
+- attempt to free an illegal 
+  cmap entry 
+- attempt to store into a read-only 
+  color map entry. */
+// - attempt to modify the access control
+//   list from other than the local host.
+//
+#define BadAlloc11  /* insufficient resources */
+// CHECK-MESSAGES: :[[@LINE-11]]:1: warning: Replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-12]]:9: warning: Macro 'BadDrawable' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-12]]:9: warning: Macro 'BadAccess' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-4]]:9: warning: Macro 'BadAlloc' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: BadDrawable = 9,   /* parameter not a Pixmap or Window */
+// CHECK-FIXES-NEXT: BadAccess =   10,  /* depending on context:
+// CHECK-FIXES-NEXT: - key/button already grabbed
+// CHECK-FIXES-NEXT: - attempt to free an illegal 
+// CHECK-FIXES-NEXT:   cmap entry 
+// CHECK-FIXES-NEXT: - attempt to store into a read-only 
+// CHECK-FIXES-NEXT:   color map entry. */
+// CHECK-FIXES-NEXT: // - attempt to modify the access control
+// CHECK-FIXES-NEXT: //   list from other than the local host.
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: BadAlloc =11  /*

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

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

sammccall added a comment.

In D116786#3247800 , @kadircet wrote:

> a drive by concern around possible flakiness of the interaction. have you 
> checked how does it look like when the user is still forming the initializer? 
> it might be annoying if their cursor kept jumping around while they're 
> editing the (possibly half-formed) initializer.

Hmm, just tested and this is definitely a thing.
The biggest problem seems to be typing something that causes all prior 
designators to disappear.
This happens when you add an invalid expression to the init list, e.g a partial 
identifier you're typing.
(RecoveryExpr doesn't help here unless we can determine the type - dependent 
initlistexprs are not semantically analyzed).

Any ideas? :-(




Comment at: clang-tools-extra/clangd/InlayHints.cpp:71
+if (BasesI != BasesE)
+  return false; // Bases can't be designated. Should we make one up?
+if (FieldsI != FieldsE) {

nridge wrote:
> We could consider using the type name of the base (but I also get the 
> impression that aggregate initialization with bases is uncommon enough to not 
> worry about right now)
Yeah, I think this is rare.
Given that, I'd rather not create the confusion by having these hints be 
almost-but-not-quite-always valid syntax.



Comment at: clang-tools-extra/clangd/InlayHints.cpp:81
+   // std::array x = {1,2,3}. Designators not strictly valid!
+   (OneField && isReservedName(FieldName
+return true;

nridge wrote:
> Should we try to more specifically restrict this to the case where the one 
> field is an array? Otherwise skipping the field name feels a bit arbitrary.
I modeled this after `isIdiomaticBraceElisionEntity` in SemaInit.cpp, which 
doesn't have this restriction.
(Though I didn't bother to implement the "base only" case, and restricted it to 
fields with reserved names).

I can change it if you want, though note that this is only eliding reserved 
names, and we *fail* (refuse to produce a designator) for reserved names 
otherwise.



Comment at: clang-tools-extra/clangd/InlayHints.cpp:145
+
+if (!Fields.append(Prefix, BraceElidedSubobject != nullptr))
+  continue; // no designator available for this subobject

nridge wrote:
> aside: `Prefix` on this line is a great use case for the 
> `UsedAsMutableReference` modifier. Now, if only we could somehow integrate 
> clangd's semantic highlighting into Phabricator...
Agree. I've also wondered about using `` as an inlay-hint instead of a token 
modifier.



Comment at: clang-tools-extra/clangd/InlayHints.cpp:404
+SourcePrefix = SourcePrefix.rtrim(IgnoreChars);
+ParamName = ParamName.trim(IgnoreChars);
 // Other than that, the comment must contain exactly ParamName.

nridge wrote:
> Why do we need to trim `ParamName`?
We're just passing in the designator string here, it may be `.foo=` and I want 
to match `/*foo*/` and `/*foo=*/` as well as `/*.foo=*/`.

I'd consider adding `[]` here too, to allow `/*1=*/` to match `[1]=`.



Comment at: clang-tools-extra/clangd/unittests/InlayHintTests.cpp:660
+ExpectedHint{".x=", "x"}, ExpectedHint{".y=", "y"},
+ExpectedHint{"[0]=", "0"}, ExpectedHint{"[1]=", "1"});
+}

nridge wrote:
> I wonder how useful these array-index hints are.
> 
> Unlike the struct case, they're not taking information present "elsewhere" 
> (field names from the structure declaration) and making it available in the 
> initializer, they're just taking information already present in the 
> initializer and making it more explicit.
> 
> On the other hand, I guess if it's important that you initialize the element 
> at index 15 in particular to some value, these hints help ensure you don't 
> make an off-by-one error...
> they're just taking information already present in the initializer and making 
> it more explicit

This is usually true but not always, e.g.

```
struct Point { float x, y, z; };
Point shape[] = {
  /*[0].x=*/1.0,
  /*[0].y=*/0.3,
  /*[0].z=*/0.3,
  /*[1].x=*/0.3,
  /*[1].y=*/0.1,
  /*[1].z=*/0.6,
  ...
};
```

We could try some other behavior:
 - don't emit a hint if there's any array component
 - don't emit a hint if there's exactly one array component and nothing else
 - have array vs field designators separately configurable

I'm not sure how this will feel in practice. I quite like the idea of having 
them initially, but turning this category off by default to give a chance to 
dogfood and reevaluate


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116786

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

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

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

sammccall updated this revision to Diff 401410.
sammccall marked 8 inline comments as done.
sammccall added a comment.

Address comments, rebase.
This category is *off* by default.


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(
+template

[clang-tools-extra] 058d212 - [clang-tidy] Use literal block instead of code block (NFC)

2022-01-19 Thread via cfe-commits


Author: Richard
Date: 2022-01-19T15:23:48-07:00
New Revision: 058d2123792da54ae7460fea0946d2c90a032e1c

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

LOG: [clang-tidy] Use literal block instead of code block (NFC)

I used a C++ code block in check documentation to show example
output from clang-tidy, but since the example output isn't
kosher C++, sphinx didn't like that when it went to syntax
highlight the block.  So switch to a literal block instead
and forego any highlighting.

Fixes build error


Added: 


Modified: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst 
b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
index ca7e54429c236..6c05a9f704ca4 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
@@ -26,9 +26,7 @@ Examples:
   #define DLLEXPORTS __declspec(dllimport)
   #endif
 
-results in the following warnings:
-
-.. code-block:: c++
+results in the following warnings::
 
   4 warnings generated.
   test.cpp:1:9: warning: macro 'C' used to declare a constant; consider using 
a 'constexpr' constant [cppcoreguidelines-macro-usage]



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

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

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

MaskRay added a comment.

Assuming scan-build is clang/tools/scan-build, which is in tree and can be 
fixed instead.
I am not familiar with it, but from

> However, this caused issues with scan-build, as GCC is used as the compiler 
> but clang is invoked after it with all the -f options that GCC was.

if scan-build+GCC takes all GCC recognized options and forwards them to Clang, 
I think it is a generally infeasible model.
GCC has dozens of options not recognized by Clang...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117717

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

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Richard Smith - zygoloid via Phabricator via cfe-commits

rsmith added inline comments.



Comment at: clang/test/SemaCXX/attr-trivial-abi.cpp:9-11
+// On Windows, trivial relocatability depends only on a trivial copy 
constructor existing.
+// In this case, it is implicitly deleted. Similar concerns apply to later 
tests.
+static_assert(!__is_trivially_relocatable(a), "");

devin.jeanpierre wrote:
> Quuxplusone wrote:
> > devin.jeanpierre wrote:
> > > Quuxplusone wrote:
> > > > (1) Why should Windows be different from everyone else here?
> > > > (2) AFAIK, a user-defined move ctor means the copy ctor is //not 
> > > > implicitly declared//, but it's not //deleted//; so I think this 
> > > > comment is slightly wrong.
> > > > (2) AFAIK, a user-defined move ctor means the copy ctor is not 
> > > > implicitly declared, but it's not deleted; so I think this comment is 
> > > > slightly wrong.
> > > Sorry, I get that confused a lot. :)
> > > 
> > > > (1) Why should Windows be different from everyone else here?
> > > In this change so far, an object is only considered trivially relocatable 
> > > if it's trivial for calls, and Windows is non-conforming wrt what it 
> > > considers trivial for calls: it won't consider something trivial for 
> > > calls if it isn't trivially copyable.
> > > 
> > > Code: https://clang.llvm.org/doxygen/SemaDeclCXX_8cpp_source.html#l06558
> > > 
> > > It surprised me too. This is a good motivator IMO to support something 
> > > like your proposal, and have types be trivially relocatable that aren't 
> > > trivial for calls. This allows, as you mention elsewhere, for 
> > > optimizations that aren't ABI-breaking, and for e.g. non-conforming 
> > > platforms like this to still take advantage of trivial relocatability.
> > > In this change so far, an object is only considered trivially relocatable 
> > > if it's trivial for calls, and Windows [has a calling convention that's 
> > > different from the Itanium C++ ABI's calling convention]: it won't 
> > > consider something trivial for calls if it isn't trivially copyable.
> > 
> > Ah, I see, and I agree with your logic here. It's unintuitive but only for 
> > the same reasons we've already hashed over: we're introducing an 
> > `__is_trivially_relocatable(T)` that gives zero false-positives, but (for 
> > now) frequent false-negatives, and this just happens to be one 
> > //additional// source of false negatives on Win32 specifically. (And I keep 
> > tripping over it because this frequent-false-negative 
> > `__is_trivially_relocatable(T)` is named the same as D50119's "perfect" 
> > discriminator.)
> > 
> > Everyone's on board with the idea that we're promising to preserve the true 
> > positives forever, but at the same time we're expecting that we might 
> > //someday// fix the false negatives, right? I.e., nobody's expecting 
> > `!__is_trivially_relocatable(a)` to remain true on Win32 forever? (I'm 
> > pretty sure we're all on board with this.)
> > Everyone's on board with the idea that we're promising to preserve the true 
> > positives forever, but at the same time we're expecting that we might 
> > someday fix the false negatives, right? I.e., nobody's expecting 
> > !__is_trivially_relocatable(a) to remain true on Win32 forever? (I'm 
> > pretty sure we're all on board with this.)
> 
> +1
> 
> My hope is that future changes can fix the false negatives -- either with 
> explicit annotations (like `[[trivially_relocatable]`), or with improved 
> automatic inference, etc.
> 
> (For example, we could imagine marking types as trivially relocatable if they 
> have *a* trivial (for calls) copy or move constructor and a trivial (for 
> calls) destructor, even if they also have a nontrivial move or copy 
> destructor. This would be a superset of trivial-for-calls types on all 
> platforms, and especially Windows.)
> Everyone's on board with the idea that we're promising to preserve the true 
> positives forever, but at the same time we're expecting that we might 
> //someday// fix the false negatives, right? I.e., nobody's expecting 
> `!__is_trivially_relocatable(a)` to remain true on Win32 forever? (I'm 
> pretty sure we're all on board with this.)

+1 from me too. Users of `__is_trivially_relocatable` should expect it to start 
returning `true` for more trivially-relocatable types over time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732

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

[libunwind] 429a717 - [cmake] Move HandleOutOfTreeLLVM to common cmake utils

2022-01-19 Thread John Ericson via cfe-commits


Author: John Ericson
Date: 2022-01-19T22:05:23Z
New Revision: 429a717ea5ec141b5c0c93c2c53097dccf67e05a

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

LOG: [cmake] Move HandleOutOfTreeLLVM to common cmake utils

This is better than libunwind and libcxxabi fishing it out of libcxx's
module directory.

It is done in prepartion for a better version of D117537 which deduplicates
CMake logic instead of just renaming to avoid a name clash.

Reviewed By: phosek, #libunwind, #libc_abi, Ericson2314

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

Added: 
cmake/Modules/HandleOutOfTreeLLVM.cmake

Modified: 
libcxxabi/CMakeLists.txt
libunwind/CMakeLists.txt

Removed: 
libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake



diff  --git a/libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake 
b/cmake/Modules/HandleOutOfTreeLLVM.cmake
similarity index 97%
rename from libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake
rename to cmake/Modules/HandleOutOfTreeLLVM.cmake
index 588d48efd412b..edffe572e091e 100644
--- a/libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake
+++ b/cmake/Modules/HandleOutOfTreeLLVM.cmake
@@ -1,5 +1,5 @@
 if (NOT DEFINED LLVM_PATH)
-  set(LLVM_PATH ${CMAKE_CURRENT_LIST_DIR}/../../../llvm CACHE PATH "" FORCE)
+  set(LLVM_PATH ${CMAKE_CURRENT_LIST_DIR}/../../llvm CACHE PATH "" FORCE)
 endif()
 
 if(NOT IS_DIRECTORY ${LLVM_PATH})

diff  --git a/libcxxabi/CMakeLists.txt b/libcxxabi/CMakeLists.txt
index 6b3bcef2851da..78f486418af79 100644
--- a/libcxxabi/CMakeLists.txt
+++ b/libcxxabi/CMakeLists.txt
@@ -37,10 +37,6 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR 
LIBCXXABI_STANDALONE_B
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
   set(PACKAGE_BUGREPORT "llvm-b...@lists.llvm.org")
 
-  # Add the CMake module path of libcxx so we can reuse 
HandleOutOfTreeLLVM.cmake
-  set(LIBCXXABI_LIBCXX_CMAKE_PATH "${LIBCXXABI_LIBCXX_PATH}/cmake/Modules")
-  list(APPEND CMAKE_MODULE_PATH "${LIBCXXABI_LIBCXX_CMAKE_PATH}")
-
   # In a standalone build, we don't have llvm to automatically generate the
   # llvm-lit script for us.  So we need to provide an explicit directory that
   # the configurator should write the script into.

diff  --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index 340a103a4abe8..03bd316d331cb 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -37,10 +37,6 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR 
LIBUNWIND_STANDALONE_B
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
   set(PACKAGE_BUGREPORT "llvm-b...@lists.llvm.org")
 
-  # Add the CMake module path of libcxx so we can reuse 
HandleOutOfTreeLLVM.cmake
-  set(LIBUNWIND_LIBCXX_CMAKE_PATH "${LIBUNWIND_LIBCXX_PATH}/cmake/Modules")
-  list(APPEND CMAKE_MODULE_PATH "${LIBUNWIND_LIBCXX_CMAKE_PATH}")
-
   # In a standalone build, we don't have llvm to automatically generate the
   # llvm-lit script for us.  So we need to provide an explicit directory that
   # the configurator should write the script into.



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

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

2022-01-19 Thread Nathan Chancellor via Phabricator via cfe-commits

nathanchance added a comment.

In D117717#3256180 , @MaskRay wrote:

> Clang has a long list of ignored options but most were added during the 
> catch-up phase when Clang strove to be a competitor compiler.
> I think for new ignored options there needs to be some higher standard.
> From Debian Code Search 
> https://codesearch.debian.net/search?q=fconserve-stack=0=2 and 
> internal code search, I believe this is a fairly obscure option.
> Shall we fix the projects instead?

I'll give a little background:

The Linux kernel has a `make` macro called `cc-option` that invokes the 
compiler with a flag and if the flag is supported, it adds it to the kernel's 
CFLAGS variable. Nick recently went through and cleaned up the use of this 
macro, as it can slow down build times if it is used excessively, especially 
with incremental compiles because this macro runs during each invocation of 
`make`: https://git.kernel.org/linus/7d73c3e9c51400d3e0e755488050804e4d44737a. 
This flag was one of the ones that was cleaned up; it was moved into a block 
that is only built when GCC is used as the compiler because we know this flag 
is not supported with `clang` so there is no point in testing for it. However, 
this caused issues with `scan-build`, as GCC is used as the compiler but 
`clang` is invoked after it with all the `-f` options that GCC was.

The kernel can add back the `cc-option` call (and likely will to workaround 
this problem) but all that is going to do is drop this flag during the 
`scan-build` process, which may result in higher stack usage.

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

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117717

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

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

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

MaskRay added a comment.

Clang has a long list of ignored options but most were added during the 
catch-up phase when Clang strove to be a competitor compiler.
I think for new ignored options there needs to be some higher standard.
From Debian Code Search 
https://codesearch.debian.net/search?q=fconserve-stack=0=2 and 
internal code search, I believe this is a fairly obscure option.
Shall we fix the projects instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117717

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

[PATCH] D117348: [Preprocessor] Reduce the memory overhead of `#define` directives

2022-01-19 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith added inline comments.



Comment at: clang/lib/Lex/MacroInfo.cpp:33
+
+// MacroInfo is expected to take 40 bytes on platforms with an 8 byte pointer.
+template  class MacroInfoSizeChecker {

aaron.ballman wrote:
> dexonsmith wrote:
> > aaron.ballman wrote:
> > > Should we do this dance for 32-bit systems as well?
> > Do I remember correctly that `SourceLocation`'s size recently became 
> > configurable? Or maybe it will be soon? Should that be factored in somehow?
> Are you thinking about this review https://reviews.llvm.org/D97204 or 
> something else?
Yes, I think that's the one.


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

https://reviews.llvm.org/D117348

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

[PATCH] D114966: [clang][deps] Split stat and file content caches

2022-01-19 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

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

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114966

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

[PATCH] D70549: [OPENMP]Fix PR41826: symbols visibility in device code.

2022-01-19 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added a comment.

In D70549#3256063 , @JonChesterfield 
wrote:

> @ABataev @jhuber6 and I would like to change this to annotate variables with 
> whatever visibility the user asked for.
>
> Can you recall if the concern about premption here was for the deviceRTL, in 
> which case it can be comprehensively dealt with by internalizing the 
> deviceRTL symbols, or for user defined things in which case we want whatever 
> the linker flag -Bsymbolic maps onto as an IR construct.

Hi, check the original PR, it has all required details. Maybe add a check that 
if the device is same as the host, then add hidden visibility (to avoid 
problems with the standard libs etc.), otherwise keep it as is?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70549

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

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Devin Jeanpierre via Phabricator via cfe-commits

devin.jeanpierre added a comment.

In D114732#3256046 , 
@devin.jeanpierre wrote:

> Sorry, I missed your other comments. Let me know if there's anything else I 
> didn't address.

I just noticed that there's a "Done" checkbox next to each comment, and it 
isn't automatically checked if I reply to it -- I suppose I should be checking 
these so that it's easier to keep track of what's left to do? Sorry, this is my 
first time using phabricator!




Comment at: clang/test/SemaCXX/attr-trivial-abi.cpp:9-11
+// On Windows, trivial relocatability depends only on a trivial copy 
constructor existing.
+// In this case, it is implicitly deleted. Similar concerns apply to later 
tests.
+static_assert(!__is_trivially_relocatable(a), "");

Quuxplusone wrote:
> devin.jeanpierre wrote:
> > Quuxplusone wrote:
> > > (1) Why should Windows be different from everyone else here?
> > > (2) AFAIK, a user-defined move ctor means the copy ctor is //not 
> > > implicitly declared//, but it's not //deleted//; so I think this comment 
> > > is slightly wrong.
> > > (2) AFAIK, a user-defined move ctor means the copy ctor is not implicitly 
> > > declared, but it's not deleted; so I think this comment is slightly wrong.
> > Sorry, I get that confused a lot. :)
> > 
> > > (1) Why should Windows be different from everyone else here?
> > In this change so far, an object is only considered trivially relocatable 
> > if it's trivial for calls, and Windows is non-conforming wrt what it 
> > considers trivial for calls: it won't consider something trivial for calls 
> > if it isn't trivially copyable.
> > 
> > Code: https://clang.llvm.org/doxygen/SemaDeclCXX_8cpp_source.html#l06558
> > 
> > It surprised me too. This is a good motivator IMO to support something like 
> > your proposal, and have types be trivially relocatable that aren't trivial 
> > for calls. This allows, as you mention elsewhere, for optimizations that 
> > aren't ABI-breaking, and for e.g. non-conforming platforms like this to 
> > still take advantage of trivial relocatability.
> > In this change so far, an object is only considered trivially relocatable 
> > if it's trivial for calls, and Windows [has a calling convention that's 
> > different from the Itanium C++ ABI's calling convention]: it won't consider 
> > something trivial for calls if it isn't trivially copyable.
> 
> Ah, I see, and I agree with your logic here. It's unintuitive but only for 
> the same reasons we've already hashed over: we're introducing an 
> `__is_trivially_relocatable(T)` that gives zero false-positives, but (for 
> now) frequent false-negatives, and this just happens to be one //additional// 
> source of false negatives on Win32 specifically. (And I keep tripping over it 
> because this frequent-false-negative `__is_trivially_relocatable(T)` is named 
> the same as D50119's "perfect" discriminator.)
> 
> Everyone's on board with the idea that we're promising to preserve the true 
> positives forever, but at the same time we're expecting that we might 
> //someday// fix the false negatives, right? I.e., nobody's expecting 
> `!__is_trivially_relocatable(a)` to remain true on Win32 forever? (I'm 
> pretty sure we're all on board with this.)
> Everyone's on board with the idea that we're promising to preserve the true 
> positives forever, but at the same time we're expecting that we might someday 
> fix the false negatives, right? I.e., nobody's expecting 
> !__is_trivially_relocatable(a) to remain true on Win32 forever? (I'm 
> pretty sure we're all on board with this.)

+1

My hope is that future changes can fix the false negatives -- either with 
explicit annotations (like `[[trivially_relocatable]`), or with improved 
automatic inference, etc.

(For example, we could imagine marking types as trivially relocatable if they 
have *a* trivial (for calls) copy or move constructor and a trivial (for calls) 
destructor, even if they also have a nontrivial move or copy destructor. This 
would be a superset of trivial-for-calls types on all platforms, and especially 
Windows.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732

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

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

2022-01-19 Thread Nathan Chancellor via Phabricator via cfe-commits

nathanchance created this revision.
nathanchance added reviewers: aaron.ballman, MaskRay, srhines.
Herald added a subscriber: dang.
nathanchance requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This flag is used when building the Linux kernel with GCC. When the
kernel is built with scan-build (which defaults to GCC for the compiler
step), ccc-analyzer passes along all '-f' flags it sees from the
compiler step, which causes the clang invocation to fail because this
flag is completely unrecognized.

Add this flag to the clang_ignored_gcc_optimization_f_Group so that it
is recognized and does not cause the analyzer step of ccc-analyzer to
fail.

Link: 
https://lore.kernel.org/r/20220119135147.1859982-1-amadeuszx.slawin...@linux.intel.com


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D117717

Files:
  clang/include/clang/Driver/Options.td
  clang/test/Driver/clang_f_opts.c


Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -307,6 +307,7 @@
 // RUN: -malign-functions=100 \
 // RUN: -malign-loops=100 \
 // RUN: -malign-jumps=100 \
+// RUN: -fconserve-stack -fno-conserve-stack  \
 // RUN: %s 2>&1 | FileCheck --check-prefix=IGNORE %s
 // IGNORE-NOT: error: unknown argument
 
@@ -372,6 +373,8 @@
 // RUN: -fno-devirtualize-speculatively   \
 // RUN: -fslp-vectorize-aggressive\
 // RUN: -fno-slp-vectorize-aggressive \
+// RUN: -fconserve-stack  \
+// RUN: -fno-conserve-stack   \
 // RUN: %s 2>&1 | FileCheck --check-prefix=CHECK-WARNING %s
 // CHECK-WARNING-DAG: optimization flag '-finline-limit=1000' is not supported
 // CHECK-WARNING-DAG: optimization flag '-finline-limit' is not supported
@@ -432,6 +435,8 @@
 // CHECK-WARNING-DAG: optimization flag '-fno-devirtualize-speculatively' is 
not supported
 // CHECK-WARNING-DAG: the flag '-fslp-vectorize-aggressive' has been 
deprecated and will be ignored
 // CHECK-WARNING-DAG: the flag '-fno-slp-vectorize-aggressive' has been 
deprecated and will be ignored
+// CHECK-WARNING-DAG: optimization flag '-fconserve-stack' is not supported
+// CHECK-WARNING-DAG: optimization flag '-fno-conserve-stack' is not supported
 
 // Test that we mute the warning on these
 // RUN: %clang -### -finline-limit=1000 -Wno-invalid-command-line-argument 
 \
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4473,6 +4473,7 @@
 defm caller_saves : BooleanFFlag<"caller-saves">, 
Group;
 defm reorder_blocks : BooleanFFlag<"reorder-blocks">, 
Group;
 defm branch_count_reg : BooleanFFlag<"branch-count-reg">, 
Group;
+defm conserve_stack : BooleanFFlag<"conserve-stack">, 
Group;
 defm default_inline : BooleanFFlag<"default-inline">, 
Group;
 defm fat_lto_objects : BooleanFFlag<"fat-lto-objects">, 
Group;
 defm float_store : BooleanFFlag<"float-store">, 
Group;


Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -307,6 +307,7 @@
 // RUN: -malign-functions=100 \
 // RUN: -malign-loops=100 \
 // RUN: -malign-jumps=100 \
+// RUN: -fconserve-stack -fno-conserve-stack  \
 // RUN: %s 2>&1 | FileCheck --check-prefix=IGNORE %s
 // IGNORE-NOT: error: unknown argument
 
@@ -372,6 +373,8 @@
 // RUN: -fno-devirtualize-speculatively   \
 // RUN: -fslp-vectorize-aggressive\
 // RUN: -fno-slp-vectorize-aggressive \
+// RUN: -fconserve-stack  \
+// RUN: -fno-conserve-stack   \
 // RUN: %s 2>&1 | FileCheck --check-prefix=CHECK-WARNING %s
 // CHECK-WARNING-DAG: optimization flag '-finline-limit=1000' is not supported
 // CHECK-WARNING-DAG: optimization flag '-finline-limit' is not supported
@@ -432,6 +435,8 @@
 // CHECK-WARNING-DAG: optimization flag '-fno-devirtualize-speculatively' is not supported
 // CHECK-WARNING-DAG: the flag '-fslp-vectorize-aggressive' has been deprecated and will be ignored
 //

[PATCH] D70549: [OPENMP]Fix PR41826: symbols visibility in device code.

2022-01-19 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added subscribers: jhuber6, JonChesterfield.
JonChesterfield added a comment.
Herald added subscribers: asavonic, sstefan1, yaxunl.

@ABataev @jhuber6 and I would like to change this to annotate variables with 
whatever visibility the user asked for.

Can you recall if the concern about premption here was for the deviceRTL, in 
which case it can be comprehensively dealt with by internalizing the deviceRTL 
symbols, or for user defined things in which case we want whatever the linker 
flag -Bsymbolic maps onto as an IR construct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70549

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

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Devin Jeanpierre via Phabricator via cfe-commits

devin.jeanpierre updated this revision to Diff 401379.
devin.jeanpierre added a comment.

Fix copy-paste error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/attr-trivial-abi.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -8,7 +8,7 @@
 #define TRAIT_IS_FALSE(Trait, Type) static_assert(!Trait(Type), "")
 #define TRAIT_IS_TRUE_2(Trait, Type1, Type2) static_assert(Trait(Type1, Type2), "")
 #define TRAIT_IS_FALSE_2(Trait, Type1, Type2) static_assert(!Trait(Type1, Type2), "")
-  
+
 struct HasStrong { id obj; };
 struct HasWeak { __weak id obj; };
 struct HasUnsafeUnretained { __unsafe_unretained id obj; };
@@ -208,3 +208,12 @@
 TRAIT_IS_FALSE_2(__is_trivially_constructible, HasWeak, HasWeak&&);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained&&);
+
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __unsafe_unretained id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasStrong);
+TRAIT_IS_FALSE(__is_trivially_relocatable, HasWeak);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasUnsafeUnretained);
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -12,7 +12,7 @@
 #define TRAIT_IS_FALSE(Trait, Type) char JOIN2(Trait,__LINE__)[Trait(Type)? -1 : 1]
 #define TRAIT_IS_TRUE_2(Trait, Type1, Type2) char JOIN2(Trait,__LINE__)[Trait(Type1, Type2)? 1 : -1]
 #define TRAIT_IS_FALSE_2(Trait, Type1, Type2) char JOIN2(Trait,__LINE__)[Trait(Type1, Type2)? -1 : 1]
-  
+
 struct HasStrong { id obj; };
 struct HasWeak { __weak id obj; };
 struct HasUnsafeUnretained { __unsafe_unretained id obj; };
@@ -213,3 +213,11 @@
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained&&);
 
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __unsafe_unretained id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasStrong);
+TRAIT_IS_FALSE(__is_trivially_relocatable, HasWeak);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasUnsafeUnretained);
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -2854,3 +2854,64 @@
 #undef T16384
 #undef T32768
 } // namespace type_trait_expr_numargs_overflow
+
+namespace is_trivially_relocatable {
+
+static_assert(!__is_trivially_relocatable(void), "");
+static_assert(__is_trivially_relocatable(int), "");
+static_assert(__is_trivially_relocatable(int[]), "");
+
+enum Enum {};
+static_assert(__is_trivially_relocatable(Enum), "");
+static_assert(__is_trivially_relocatable(Enum[]), "");
+
+union Union {int x;};
+static_assert(__is_trivially_relocatable(Union), "");
+static_assert(__is_trivially_relocatable(Union[]), "");
+
+struct Trivial {};
+static_assert(__is_trivially_relocatable(Trivial), "");
+static_assert(__is_trivially_relocatable(Trivial[]), "");
+
+struct Incomplete; // expected-note {{forward declaration of 'is_trivially_relocatable::Incomplete'}}
+bool unused = __is_trivially_relocatable(Incomplete); // expected-error {{incomplete type}}
+
+struct NontrivialDtor {
+  ~NontrivialDtor() {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialDtor), "");
+static_assert(!__is_trivially_relocatable(NontrivialDtor[]), "");
+
+struct NontrivialCopyCtor {
+  NontrivialCopyCtor(const NontrivialCopyCtor&) {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialCopyCtor), "");
+static_assert(!__is_trivially_relocatable(NontrivialCopyCtor[]), "");
+
+struct NontrivialMoveCtor {
+  NontrivialMoveCtor(NontrivialMoveCtor&&) {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialMoveCtor), "");

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Devin Jeanpierre via Phabricator via cfe-commits

devin.jeanpierre added a comment.

Sorry, I missed your other comments. Let me know if there's anything else I 
didn't address.




Comment at: clang/test/SemaCXX/attr-trivial-abi.cpp:146
+#ifdef _WIN32
+static_assert(!__is_trivially_relocatable(CopyDeleted), "");
+#else

Quuxplusone wrote:
> I think you meant `s/CopyDeleted/S20/` here.
Ugh, copy-paste. Thanks, done.



Comment at: clang/test/SemaCXX/type-traits.cpp:2862
+static_assert(__is_trivially_relocatable(int), "");
+static_assert(__is_trivially_relocatable(int[]), "");
+

Quuxplusone wrote:
> It's mildly surprising that an incomplete type can be trivially relocatable; 
> but it doesn't really matter, since nobody can be depending on this answer. 
> (`int[]` is not movable or destructible, so it's not relocatable — never mind 
> //trivially// relocatable.)
I think it is consistent with the other type traits in C++ -- for example, this 
assert would also pass:

```
static_assert(std::is_trivially_copyable_v, "");
```

The important thing is that this line fails to compile:

```
struct Incomplete;
bool unused = __is_trivially_relocatable(Incomplete);
```



Comment at: clang/test/SemaObjCXX/objc-weak-type-traits.mm:213-214
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);

Quuxplusone wrote:
> IIUC (which I probably don't): Both `__strong id` and `__weak id` //are// 
> trivially relocatable in the p1144 sense, but only `__strong id` is 
> trivial-for-purposes-of-ABI, and that's why only `__strong id` is being 
> caught here. Yes/no?
`__weak` can't be trivially relocatable in any proposal, because their address 
is registered in a runtime table, so that they can be nulled out when the 
object is deleted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732

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

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Arthur O'Dwyer via Phabricator via cfe-commits

Quuxplusone added inline comments.



Comment at: clang/test/SemaCXX/attr-trivial-abi.cpp:9-11
+// On Windows, trivial relocatability depends only on a trivial copy 
constructor existing.
+// In this case, it is implicitly deleted. Similar concerns apply to later 
tests.
+static_assert(!__is_trivially_relocatable(a), "");

devin.jeanpierre wrote:
> Quuxplusone wrote:
> > (1) Why should Windows be different from everyone else here?
> > (2) AFAIK, a user-defined move ctor means the copy ctor is //not implicitly 
> > declared//, but it's not //deleted//; so I think this comment is slightly 
> > wrong.
> > (2) AFAIK, a user-defined move ctor means the copy ctor is not implicitly 
> > declared, but it's not deleted; so I think this comment is slightly wrong.
> Sorry, I get that confused a lot. :)
> 
> > (1) Why should Windows be different from everyone else here?
> In this change so far, an object is only considered trivially relocatable if 
> it's trivial for calls, and Windows is non-conforming wrt what it considers 
> trivial for calls: it won't consider something trivial for calls if it isn't 
> trivially copyable.
> 
> Code: https://clang.llvm.org/doxygen/SemaDeclCXX_8cpp_source.html#l06558
> 
> It surprised me too. This is a good motivator IMO to support something like 
> your proposal, and have types be trivially relocatable that aren't trivial 
> for calls. This allows, as you mention elsewhere, for optimizations that 
> aren't ABI-breaking, and for e.g. non-conforming platforms like this to still 
> take advantage of trivial relocatability.
> In this change so far, an object is only considered trivially relocatable if 
> it's trivial for calls, and Windows [has a calling convention that's 
> different from the Itanium C++ ABI's calling convention]: it won't consider 
> something trivial for calls if it isn't trivially copyable.

Ah, I see, and I agree with your logic here. It's unintuitive but only for the 
same reasons we've already hashed over: we're introducing an 
`__is_trivially_relocatable(T)` that gives zero false-positives, but (for now) 
frequent false-negatives, and this just happens to be one //additional// source 
of false negatives on Win32 specifically. (And I keep tripping over it because 
this frequent-false-negative `__is_trivially_relocatable(T)` is named the same 
as D50119's "perfect" discriminator.)

Everyone's on board with the idea that we're promising to preserve the true 
positives forever, but at the same time we're expecting that we might 
//someday// fix the false negatives, right? I.e., nobody's expecting 
`!__is_trivially_relocatable(a)` to remain true on Win32 forever? (I'm 
pretty sure we're all on board with this.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732

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

[PATCH] D117634: [OpenMP] Expand short verisions of OpenMP offloading triples

2022-01-19 Thread Jon Chesterfield via Phabricator via cfe-commits

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

LG, thanks!




Comment at: clang/lib/Driver/Driver.cpp:778
+  // We want to normalize the shortened versions of triples passed in 
to
+  // the values used for the bitcode libraries.
+  if (TT.getVendor() == llvm::Triple::UnknownVendor ||

Might be worth mentioning in the comment that this is essentially a user 
convenience feature. We're not so much normalising, as treating 
fopenmp-target=nvtpx64 as an abbreviation for nvptx64-nvidia-cuda


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117634

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

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

2022-01-19 Thread Evgeny Shulgin via Phabricator via cfe-commits

Izaron marked 4 inline comments as done.
Izaron added inline comments.



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

aaron.ballman wrote:
> It'd be good to show an example of:
> ```
> if ! consteval {}
> 
> if ! consteval {} else {}
> ```
> as well so users know what to expect.
> 
> Should there be a matcher so users can distinguish between `if consteval` and 
> `if ! consteval`?
> 
> Test cases for these sort of things would also be appreciated.
Thanks!
> Should there be a matcher so users can distinguish between `if consteval` and 
> `if ! consteval`?
This is an interesting question. I wonder how intensively `if ! consteval` is 
ever going to be used in real life to make a unique matcher for it? I can't 
make up a hypothetical checker that would need it.

Let's see what other fellow reviewers think about it =)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117613

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

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

2022-01-19 Thread Evgeny Shulgin via Phabricator via cfe-commits

Izaron updated this revision to Diff 401365.
Izaron added a comment.

Fixed commit (with clang-format)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117613

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -1790,6 +1790,35 @@
   EXPECT_TRUE(matches("void f() noexcept;", functionProtoType(isNoThrow(;
 }
 
+TEST_P(ASTMatchersTest, IsConsteval) {
+  if (!GetParam().isCXX20OrLater())
+return;
+
+  EXPECT_TRUE(matches("consteval int bar();",
+  functionDecl(hasName("bar"), isConsteval(;
+  EXPECT_TRUE(notMatches("constexpr int bar();",
+ functionDecl(hasName("bar"), isConsteval(;
+  EXPECT_TRUE(
+  notMatches("int bar();", functionDecl(hasName("bar"), isConsteval(;
+}
+
+TEST_P(ASTMatchersTest, IsConsteval_MatchesIfConsteval) {
+  if (!GetParam().isCXX20OrLater())
+return;
+
+  EXPECT_TRUE(matches("void baz() { if consteval {} }", ifStmt(isConsteval(;
+  EXPECT_TRUE(
+  matches("void baz() { if ! consteval {} }", ifStmt(isConsteval(;
+  EXPECT_TRUE(matches("void baz() { if ! consteval {} else {} }",
+  ifStmt(isConsteval(;
+  EXPECT_TRUE(
+  matches("void baz() { if not consteval {} }", ifStmt(isConsteval(;
+  EXPECT_TRUE(notMatches("void baz() { if constexpr(1 > 0) {} }",
+ ifStmt(isConsteval(;
+  EXPECT_TRUE(
+  notMatches("void baz() { if (1 > 0) {} }", ifStmt(isConsteval(;
+}
+
 TEST_P(ASTMatchersTest, IsConstexpr) {
   if (!GetParam().isCXX11OrLater()) {
 return;
Index: clang/lib/ASTMatchers/Dynamic/Registry.cpp
===
--- clang/lib/ASTMatchers/Dynamic/Registry.cpp
+++ clang/lib/ASTMatchers/Dynamic/Registry.cpp
@@ -404,6 +404,7 @@
   REGISTER_MATCHER(isComparisonOperator);
   REGISTER_MATCHER(isConst);
   REGISTER_MATCHER(isConstQualified);
+  REGISTER_MATCHER(isConsteval);
   REGISTER_MATCHER(isConstexpr);
   REGISTER_MATCHER(isCopyAssignmentOperator);
   REGISTER_MATCHER(isCopyConstructor);
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -5170,6 +5170,24 @@
   return FnTy->isNothrow();
 }
 
+/// Matches consteval function declarations and if consteval.
+///
+/// Given:
+/// \code
+///   consteval int a();
+///   void b() { if consteval {} }
+///   void c() { if ! consteval {} }
+///   void d() { if ! consteval {} else {} }
+/// \endcode
+/// functionDecl(isConsteval())
+///   matches the declaration of "int a()".
+/// ifStmt(isConsteval())
+///   matches the if statement in "void b()", "void c()", "void d()".
+AST_POLYMORPHIC_MATCHER(isConsteval,
+AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl, IfStmt)) {
+  return Node.isConsteval();
+}
+
 /// Matches constexpr variable and function declarations,
 ///and if constexpr.
 ///
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -4201,6 +4201,21 @@
 
 
 
+Matcherhttps://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html;>FunctionDeclisConsteval
+Matches consteval function declarations and if consteval.
+
+Given:
+  consteval int a();
+  void b() { if consteval {} }
+  void c() { if ! consteval {} }
+  void d() { if ! consteval {} else {} }
+functionDecl(isConsteval())
+  matches the declaration of "int a()".
+ifStmt(isConsteval())
+  matches the if statement in "void b()", "void c()", "void d()".
+
+
+
 Matcherhttps://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html;>FunctionDeclisConstexpr
 Matches constexpr variable and function declarations,
and if constexpr.
@@ -4473,6 +4488,21 @@
 
 
 
+Matcherhttps://clang.llvm.org/doxygen/classclang_1_1IfStmt.html;>IfStmtisConsteval
+Matches consteval function declarations and if consteval.
+
+Given:
+  consteval int a();
+  void b() { if consteval {} }
+  void c() { if ! consteval {} }
+  void d() { if ! consteval {} else {} }
+functionDecl(isConsteval())
+  matches the declaration of "int a()".
+ifStmt(isConsteval())
+  matches the if statement in "void b()", "void c()", "void d()".
+
+
+
 Matcherhttps://clang.llvm.org/doxygen/classclang_1_1IfStmt.html;>IfStmtisConstexpr
 Matches constexpr variable and function declarations,
and if

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

2022-01-19 Thread ksyx via Phabricator via cfe-commits

ksyx added inline comments.



Comment at: clang/lib/Format/DefinitionBlockSeparator.cpp:134
+  OperateIndex + 1 < Lines.size()) {
+// UnwrappedLineParser's recognition of free-standing macro like
+// Q_OBJECT may also recognize some uppercased type names that may be

HazardyKnusperkeks wrote:
> Shouldn't we set a type for such cases instead of repeating the detection 
> code here?
Here I actually did a few more checks to limit the impact to the minimum but I 
am happy to do that if that's necessary.



Comment at: clang/lib/Format/DefinitionBlockSeparator.cpp:135
+// UnwrappedLineParser's recognition of free-standing macro like
+// Q_OBJECT may also recognize some uppercased type names that may be
+// used as return type as that kind of macros, which is a bit hard to

HazardyKnusperkeks wrote:
> As a Qt user who also wants to use your patch, please add a test for that 
> case. ;)
For `Q_OBJECT` if used as pattern like this:
```
class X : ... {
  Q_OBJECT
public:
  // ...
}
```
I think this patch has no effect on this? The comment here is just a repetition 
of that in unwrapped parser



Comment at: clang/unittests/Format/DefinitionBlockSeparatorTest.cpp:143
+  "\n"
+  "  LONGTYPENAME\n"
+  "  Foobar(int t, int p) {\n"

HazardyKnusperkeks wrote:
> Maybe really use HRESULT? People will know what that should be.
It actually does not matter what type name it is as long as it is an identifier 
with >=5 characters and all uppercased


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

https://reviews.llvm.org/D117520

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

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

2022-01-19 Thread Evgeny Shulgin via Phabricator via cfe-commits

Izaron updated this revision to Diff 401363.
Izaron added a comment.

Fixed commit


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117613

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -1790,6 +1790,32 @@
   EXPECT_TRUE(matches("void f() noexcept;", functionProtoType(isNoThrow(;
 }
 
+TEST_P(ASTMatchersTest, IsConsteval) {
+  if (!GetParam().isCXX20OrLater())
+return;
+
+  EXPECT_TRUE(matches("consteval int bar();",
+  functionDecl(hasName("bar"), isConsteval(;
+  EXPECT_TRUE(notMatches("constexpr int bar();",
+ functionDecl(hasName("bar"), isConsteval(;
+  EXPECT_TRUE(
+  notMatches("int bar();", functionDecl(hasName("bar"), isConsteval(;
+}
+
+TEST_P(ASTMatchersTest, IsConsteval_MatchesIfConsteval) {
+  if (!GetParam().isCXX20OrLater())
+return;
+
+  EXPECT_TRUE(matches("void baz() { if consteval {} }", ifStmt(isConsteval(;
+  EXPECT_TRUE(matches("void baz() { if ! consteval {} }", ifStmt(isConsteval(;
+  EXPECT_TRUE(matches("void baz() { if ! consteval {} else {} }", ifStmt(isConsteval(;
+  EXPECT_TRUE(matches("void baz() { if not consteval {} }", ifStmt(isConsteval(;
+  EXPECT_TRUE(notMatches("void baz() { if constexpr(1 > 0) {} }",
+ ifStmt(isConsteval(;
+  EXPECT_TRUE(
+  notMatches("void baz() { if (1 > 0) {} }", ifStmt(isConsteval(;
+}
+
 TEST_P(ASTMatchersTest, IsConstexpr) {
   if (!GetParam().isCXX11OrLater()) {
 return;
Index: clang/lib/ASTMatchers/Dynamic/Registry.cpp
===
--- clang/lib/ASTMatchers/Dynamic/Registry.cpp
+++ clang/lib/ASTMatchers/Dynamic/Registry.cpp
@@ -404,6 +404,7 @@
   REGISTER_MATCHER(isComparisonOperator);
   REGISTER_MATCHER(isConst);
   REGISTER_MATCHER(isConstQualified);
+  REGISTER_MATCHER(isConsteval);
   REGISTER_MATCHER(isConstexpr);
   REGISTER_MATCHER(isCopyAssignmentOperator);
   REGISTER_MATCHER(isCopyConstructor);
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -5170,6 +5170,24 @@
   return FnTy->isNothrow();
 }
 
+/// Matches consteval function declarations and if consteval.
+///
+/// Given:
+/// \code
+///   consteval int a();
+///   void b() { if consteval {} }
+///   void c() { if ! consteval {} }
+///   void d() { if ! consteval {} else {} }
+/// \endcode
+/// functionDecl(isConsteval())
+///   matches the declaration of "int a()".
+/// ifStmt(isConsteval())
+///   matches the if statement in "void b()", "void c()", "void d()".
+AST_POLYMORPHIC_MATCHER(isConsteval,
+AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl, IfStmt)) {
+  return Node.isConsteval();
+}
+
 /// Matches constexpr variable and function declarations,
 ///and if constexpr.
 ///
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -4201,6 +4201,21 @@
 
 
 
+Matcherhttps://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html;>FunctionDeclisConsteval
+Matches consteval function declarations and if consteval.
+
+Given:
+  consteval int a();
+  void b() { if consteval {} }
+  void c() { if ! consteval {} }
+  void d() { if ! consteval {} else {} }
+functionDecl(isConsteval())
+  matches the declaration of "int a()".
+ifStmt(isConsteval())
+  matches the if statement in "void b()", "void c()", "void d()".
+
+
+
 Matcherhttps://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html;>FunctionDeclisConstexpr
 Matches constexpr variable and function declarations,
and if constexpr.
@@ -4473,6 +4488,21 @@
 
 
 
+Matcherhttps://clang.llvm.org/doxygen/classclang_1_1IfStmt.html;>IfStmtisConsteval
+Matches consteval function declarations and if consteval.
+
+Given:
+  consteval int a();
+  void b() { if consteval {} }
+  void c() { if ! consteval {} }
+  void d() { if ! consteval {} else {} }
+functionDecl(isConsteval())
+  matches the declaration of "int a()".
+ifStmt(isConsteval())
+  matches the if statement in "void b()", "void c()", "void d()".
+
+
+
 Matcherhttps://clang.llvm.org/doxygen/classclang_1_1IfStmt.html;>IfStmtisConstexpr
 Matches constexpr variable and function declarations,
and if constexpr.
___

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

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

aaron.ballman added a comment.

Thanks for this, I think it's shaping up well!




Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:723
+def err_attribute_argument_parm_pack_not_supported : Error<
+  "attribute %0 does not support pack expansion in arguments">;
+def err_attribute_parm_pack_last_argument_only : Error<





Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:725
+def err_attribute_parm_pack_last_argument_only : Error<
+  "pack expansion in %0 is restricted to argument %1 or later">;
 def err_ms_declspec_type : Error<





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

I'm a bit surprised this logic moved -- are there no times when we'd need it 
within the new `else` clause?



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) {

Coding style nits.



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

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



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

Not that I think this is a bad change, but it seems unrelated to the patch. Can 
you explain why you made the change?



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

steffenlarsen wrote:
> erichkeane wrote:
> > What is the point of this change?
> It makes more sense for the new test cases to get expressions rather than 
> types and since `Ts` wasn't used for its contents it did not seem like an 
> intrusive change.
Non-type templates are different from type templates, so I don't really want to 
lose the test coverage for that (if nothing else, it ensures the parser doesn't 
explode when it encounters one). It's fine to add a `variadic_nttp()` function 
or something along those lines.


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] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

2022-01-19 Thread Florian Hahn via Phabricator via cfe-commits

fhahn added inline comments.



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

nlopes wrote:
> ab wrote:
> > Hmm, if I'm reading this right, this overwrites the `nonnull 
> > dereferenceable align` attributes separately computed for `this` around 
> > l2335, right? (or `inalloca` and `sret` before that)
> > 
> > It sounds like an ancient bug, that's only exposed because `noundef` ends 
> > up triggering this logic much more often?
> > 
> > Many of our downstream tests hit this. The hacked up patch seems to do the 
> > job; ideally we'd feed the previously-computed attrs when constructing the 
> > AttrBuilder (which would also fix the padding argument), but we'd need to 
> > match up the IR args first.  Maybe that's fine as a special-case for arg 0 
> > though
> nice catch! It's an ancient bug where arg 0 is overwritten.
Is anybody looking into a fix or should we revert the patch until this can be 
properly addressed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

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

2022-01-19 Thread Björn Schäpers via Phabricator via cfe-commits

HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/DefinitionBlockSeparator.cpp:120
 const auto MayPrecedeDefinition = [&](const int Direction = -1) {
+  assert(Direction >= -1 && Direction <= 1);
   const size_t OperateIndex = OpeningLineIndex + Direction;

Split into two asserts, then one would know which did not hold.



Comment at: clang/lib/Format/DefinitionBlockSeparator.cpp:134
+  OperateIndex + 1 < Lines.size()) {
+// UnwrappedLineParser's recognition of free-standing macro like
+// Q_OBJECT may also recognize some uppercased type names that may be

Shouldn't we set a type for such cases instead of repeating the detection code 
here?



Comment at: clang/lib/Format/DefinitionBlockSeparator.cpp:135
+// UnwrappedLineParser's recognition of free-standing macro like
+// Q_OBJECT may also recognize some uppercased type names that may be
+// used as return type as that kind of macros, which is a bit hard to

As a Qt user who also wants to use your patch, please add a test for that case. 
;)



Comment at: clang/unittests/Format/DefinitionBlockSeparatorTest.cpp:143
+  "\n"
+  "  LONGTYPENAME\n"
+  "  Foobar(int t, int p) {\n"

Maybe really use HRESULT? People will know what that should be.


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

https://reviews.llvm.org/D117520

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

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Devin Jeanpierre via Phabricator via cfe-commits

devin.jeanpierre added a comment.

CI test finished successfully before windows setup did . My workplace's 
Windows VMs are a bit hosed at the moment...

In D114732#3253416 , @Quuxplusone 
wrote:

> In D114732#3253142 , 
> @devin.jeanpierre wrote:
>
>> OK, while I'm struggling to set up a new Windows machine so I can make sure 
>> this works on Windows...  @Quuxplusone, after this is merged, do you want to 
>> rebase D67524  on top of this, or should I? 
>> I can review it -- I think when I looked at it, I only had two ideas for 
>> changes:
>>
>> 1. May need to guard all of these optimizations on the allocator being the 
>> standard allocator, since otherwise the change in the number of 
>> constructor/destructor calls would be observable to more than just the 
>> annotated type.
>
> My intent is that the type-traits `__has_trivial_construct` and 
> `__has_trivial_destroy` already handle that. The standard `std::allocator` 
> has a trivial `construct` and `destroy`, but so do lots of user-defined 
> allocators.

Fair, I'm sorry for missing that detail.

>> 2. changing `std::swap` to correctly handle potentially-overlapping-objects. 
>> My thought is we could test that there's no reusable tail padding.
>>
>> First draft: `has_unique_object_representations` is conservative -- on the 
>> Itanium ABI, "POD for the purposes of layout" types can have padding which 
>> isn't reused when it's a potentially overlapping subobject.
>
> I'd //like// something that triggers successfully even when there are 
> internal padding bytes, e.g. `struct TR { int x; std::string y; }`. (But 
> anything is better than nothing. I'm going to keep maintaining my branch for 
> the foreseeable future, so I can keep doing my thing no matter what 
> half-measure makes it into trunk.)

Well, we must do something. In particular, consider this code:

  // class to make it non-POD for the purpose of layout
  class X { int64_t a; int8_t b;};
  class Y : public X {int8_t c;};

  Y y1 = ...;
  Y y2 = ;
  X& x1 = y1;
  X& x2 = y2;

  std::swap(x1, x2);

Here, at least in some implementations, `c` will live inside the tail padding 
of `X`. Without any special guarding, if `swap` used a `memcpy` with 
`sizeof(x1)` etc., then it would overwrite the padding bytes, which include 
`z`. I don't think swap should do this.

>> Second draft: check by hand:
>>
>>   
>>   struct TestStruct {
>> [[no_unique_address]] T x;
>> // not sure if this needs to be a bitfield or anything like that, but 
>> the idea is this.
>> char extra_byte;
>>   };
>>   bool has_padding = sizeof(TestStruct) == sizeof(T);
>
> If this works, then either my mental model of `[[no_unique_address]]` is 
> wrong or my mental model of tail padding is wrong. I would expect more like
>
>   template struct DerivedFrom : public T { char extra_byte; };
>   template requires is_final_v struct DerivedFrom { char 
> x[sizeof(T)+1]; }; // definitely no objects in the tail padding if it's final
>   bool has_padding = sizeof(DerivedFrom) == sizeof(T);
>
> If `T` is final, then it can't have stuff in its tail padding, I think: 
> https://godbolt.org/z/69sjf15MY

Unfortunately, even if `T` is final, it can have things in its tail padding: 
`[[no_unique_address]]` allows all the same optimizations as a base class, 
including reuse of tail padding and ECBO. See e.g. the cppreference page 
.

The reason your godbolt link shows them having the same size is that the `A` 
struct is "POD for the purpose of layout". In the Itanium ABI, POD types are 
laid out as normal, but their tail padding isn't reused in any circumstances 
(not for subclasses either -- so try e.g. removing final and using inheritance, 
and the assertion still passes: https://godbolt.org/z/MWrMoEbvb). If you make 
that a `class` instead of a `struct`, it isn't POD for the purpose of layout 
(due to private members), and the assertion fails now that the tail padding can 
be reused: https://godbolt.org/z/5edfqrK47

However, I think you're right that this isn't enough -- I don't believe it's 
guaranteed that inheritance and `[[no_unique_address]]` use padding in the 
exact same way, so you probably need to try both just to be safe.

> Anyway, that seems like a reasonable path in the name of getting something 
> merged. My //personal// druthers is that the Standard should just admit that 
> `std::swap` was never meant to work on polymorphic objects, so therefore it 
> can assume it's never swapping `Derived` objects via `Base&`, so therefore it 
> can assume tail padding is not an issue, so therefore no metaprogramming is 
> needed and it can just always do the efficient thing (which is therefore what 
> I've implemented in D67524 ). But I know 
> that's unlikely to ever happen.

I don't think it

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

2022-01-19 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

Works nicely now...

LGTM


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

https://reviews.llvm.org/D117520

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

[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

2022-01-19 Thread Devin Jeanpierre via Phabricator via cfe-commits

devin.jeanpierre updated this revision to Diff 401358.
devin.jeanpierre added a comment.

Clarify Windows comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/attr-trivial-abi.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -8,7 +8,7 @@
 #define TRAIT_IS_FALSE(Trait, Type) static_assert(!Trait(Type), "")
 #define TRAIT_IS_TRUE_2(Trait, Type1, Type2) static_assert(Trait(Type1, Type2), "")
 #define TRAIT_IS_FALSE_2(Trait, Type1, Type2) static_assert(!Trait(Type1, Type2), "")
-  
+
 struct HasStrong { id obj; };
 struct HasWeak { __weak id obj; };
 struct HasUnsafeUnretained { __unsafe_unretained id obj; };
@@ -208,3 +208,12 @@
 TRAIT_IS_FALSE_2(__is_trivially_constructible, HasWeak, HasWeak&&);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained&&);
+
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __unsafe_unretained id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasStrong);
+TRAIT_IS_FALSE(__is_trivially_relocatable, HasWeak);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasUnsafeUnretained);
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -12,7 +12,7 @@
 #define TRAIT_IS_FALSE(Trait, Type) char JOIN2(Trait,__LINE__)[Trait(Type)? -1 : 1]
 #define TRAIT_IS_TRUE_2(Trait, Type1, Type2) char JOIN2(Trait,__LINE__)[Trait(Type1, Type2)? 1 : -1]
 #define TRAIT_IS_FALSE_2(Trait, Type1, Type2) char JOIN2(Trait,__LINE__)[Trait(Type1, Type2)? -1 : 1]
-  
+
 struct HasStrong { id obj; };
 struct HasWeak { __weak id obj; };
 struct HasUnsafeUnretained { __unsafe_unretained id obj; };
@@ -213,3 +213,11 @@
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained&&);
 
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __unsafe_unretained id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasStrong);
+TRAIT_IS_FALSE(__is_trivially_relocatable, HasWeak);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasUnsafeUnretained);
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -2854,3 +2854,64 @@
 #undef T16384
 #undef T32768
 } // namespace type_trait_expr_numargs_overflow
+
+namespace is_trivially_relocatable {
+
+static_assert(!__is_trivially_relocatable(void), "");
+static_assert(__is_trivially_relocatable(int), "");
+static_assert(__is_trivially_relocatable(int[]), "");
+
+enum Enum {};
+static_assert(__is_trivially_relocatable(Enum), "");
+static_assert(__is_trivially_relocatable(Enum[]), "");
+
+union Union {int x;};
+static_assert(__is_trivially_relocatable(Union), "");
+static_assert(__is_trivially_relocatable(Union[]), "");
+
+struct Trivial {};
+static_assert(__is_trivially_relocatable(Trivial), "");
+static_assert(__is_trivially_relocatable(Trivial[]), "");
+
+struct Incomplete; // expected-note {{forward declaration of 'is_trivially_relocatable::Incomplete'}}
+bool unused = __is_trivially_relocatable(Incomplete); // expected-error {{incomplete type}}
+
+struct NontrivialDtor {
+  ~NontrivialDtor() {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialDtor), "");
+static_assert(!__is_trivially_relocatable(NontrivialDtor[]), "");
+
+struct NontrivialCopyCtor {
+  NontrivialCopyCtor(const NontrivialCopyCtor&) {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialCopyCtor), "");
+static_assert(!__is_trivially_relocatable(NontrivialCopyCtor[]), "");
+
+struct NontrivialMoveCtor {
+  NontrivialMoveCtor(NontrivialMoveCtor&&) {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialMoveCtor), "");

[PATCH] D117634: [OpenMP] Expand short verisions of OpenMP offloading triples

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

jhuber6 updated this revision to Diff 401357.
jhuber6 edited the summary of this revision.
jhuber6 added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changing approach to simply expand the triple where we parse it for OpenMP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117634

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/fat_archive_nvptx.cpp
  openmp/libomptarget/DeviceRTL/CMakeLists.txt


Index: openmp/libomptarget/DeviceRTL/CMakeLists.txt
===
--- openmp/libomptarget/DeviceRTL/CMakeLists.txt
+++ openmp/libomptarget/DeviceRTL/CMakeLists.txt
@@ -227,7 +227,7 @@
 
 # Generate a Bitcode library for all the compute capabilities the user 
requested
 foreach(sm ${nvptx_sm_list})
-  compileDeviceRTLLibrary(sm_${sm} nvptx -target nvptx64 -Xclang 
-target-feature -Xclang +ptx61 "-D__CUDA_ARCH__=${sm}0")
+  compileDeviceRTLLibrary(sm_${sm} nvptx -target nvptx64-nvidia-cuda -Xclang 
-target-feature -Xclang +ptx61 "-D__CUDA_ARCH__=${sm}0")
 endforeach()
 
 foreach(mcpu ${amdgpu_mcpus})
Index: clang/test/Driver/fat_archive_nvptx.cpp
===
--- clang/test/Driver/fat_archive_nvptx.cpp
+++ clang/test/Driver/fat_archive_nvptx.cpp
@@ -6,9 +6,9 @@
 
 // Given a FatArchive, clang-offload-bundler should be called to create a
 // device specific archive, which should be passed to clang-nvlink-wrapper.
-// RUN: %clang -O2 -### -fopenmp -fopenmp-targets=nvptx64 %s 
-L%S/Inputs/openmp_static_device_link -lFatArchive 2>&1 | FileCheck %s
-// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "nvptx64"{{.*}}"-target-cpu" 
"[[GPU:sm_[0-9]+]]"{{.*}}"-o" "[[HOSTBC:.*.s]]" "-x" "c++"{{.*}}.cpp
-// CHECK: clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}/Inputs/openmp_static_device_link/libFatArchive.a" 
"-targets=openmp-nvptx64-[[GPU]]" "-outputs=[[DEVICESPECIFICARCHIVE:.*.a]]" 
"-allow-missing-bundles"
+// RUN: %clang -O2 -### -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda %s 
-L%S/Inputs/openmp_static_device_link -lFatArchive 2>&1 | FileCheck %s
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" 
"nvptx64-nvidia-cuda"{{.*}}"-target-cpu" "[[GPU:sm_[0-9]+]]"{{.*}}"-o" 
"[[HOSTBC:.*.s]]" "-x" "c++"{{.*}}.cpp
+// CHECK: clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}/Inputs/openmp_static_device_link/libFatArchive.a" 
"-targets=openmp-nvptx64-nvidia-cuda-[[GPU]]" 
"-outputs=[[DEVICESPECIFICARCHIVE:.*.a]]" "-allow-missing-bundles"
 // CHECK: clang-nvlink-wrapper{{.*}}"-o" "{{.*}}.out" "-arch" "[[GPU]]" 
"{{.*}}[[DEVICESPECIFICARCHIVE]]"
 // expected-no-diagnostics
 
@@ -72,8 +72,8 @@
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx908 -c func_1.c -o func_1_gfx908.o
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 -c func_2.c -o func_2_gfx906.o
 clang -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx908 -c func_2.c -o func_2_gfx908.o
-clang -O2 -fopenmp -fopenmp-targets=nvptx64 -c func_1.c -o func_1_nvptx.o
-clang -O2 -fopenmp -fopenmp-targets=nvptx64 -c func_2.c -o func_2_nvptx.o
+clang -O2 -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -c func_1.c -o 
func_1_nvptx.o
+clang -O2 -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -c func_2.c -o 
func_2_nvptx.o
 
 2. Create a fat archive by combining all the object file(s)
 llvm-ar cr libFatArchive.a func_1_gfx906.o func_1_gfx908.o func_2_gfx906.o 
func_2_gfx908.o func_1_nvptx.o func_2_nvptx.o
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -774,6 +774,18 @@
   llvm::Triple TT(Val);
   std::string NormalizedName = TT.normalize();
 
+  // We want to normalize the shortened versions of triples passed in 
to
+  // the values used for the bitcode libraries.
+  if (TT.getVendor() == llvm::Triple::UnknownVendor ||
+  TT.getOS() == llvm::Triple::UnknownOS) {
+if (TT.getArch() == llvm::Triple::nvptx)
+  TT = llvm::Triple("nvptx-nvidia-cuda");
+else if (TT.getArch() == llvm::Triple::nvptx64)
+  TT = llvm::Triple("nvptx64-nvidia-cuda");
+else if (TT.getArch() == llvm::Triple::amdgcn)
+  TT = llvm::Triple("amdgcn-amd-amdhsa");
+  }
+
   // Make sure we don't have a duplicate triple.
   auto Duplicate = FoundNormalizedTriples.find(NormalizedName);
   if (Duplicate != FoundNormalizedTriples.end()) {


Index: openmp/libomptarget/DeviceRTL/CMakeLists.txt
===
--- openmp/libomptarget/DeviceRTL/CMakeLists.txt
+++

[PATCH] D112408: [RISCV] Add the zve extension according to the v1.0 spec

2022-01-19 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCV.td:186
+   "with maximal 32 EEW and F extension)",
+   [FeatureStdExtZve32x, FeatureStdExtF]>;
+def HasStdExtZve32f : Predicate<"SubTarget->hasStdExtZve32f()">;

Zve32f requires F or Zfinx. It can't imply F.



Comment at: llvm/lib/Target/RISCV/RISCV.td:206
+   "with maximal 64 EEW, F and D extension)",
+   [FeatureStdExtZve64f, FeatureStdExtD]>;
+def HasStdExtZve64d : Predicate<"SubTarget->hasStdExtZve64d()">;

Zve64d requires D or Zdinx. It can't imply D.



Comment at: llvm/lib/Target/RISCV/RISCV.td:209
+
+def FeatureStdExtV
+: SubtargetFeature<"experimental-v", "HasStdExtV", "true",

V can imply F and D though I think.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoV.td:864
+
+let Predicates = [IsRV64, HasVInstructionsI64] in {
+// Vector Unit-Stride Instructions

Only the indexed load/stores require RV64 for EEW=64. Sorry I missed that when 
I caught it for the segment load/store.



Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.h:192
+  bool hasVInstructionsI64() const { return HasStdExtZve64x; }
+  bool hasVInstructionsF16() const { return HasStdExtZve32x && HasStdExtZfh; }
+  bool hasVInstructionsF32() const { return HasStdExtZve32f; }

Zve32f I think since Zfh requires F.



Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.h:193
+  bool hasVInstructionsF16() const { return HasStdExtZve32x && HasStdExtZfh; }
+  bool hasVInstructionsF32() const { return HasStdExtZve32f; }
+  bool hasVInstructionsF64() const { return HasStdExtZve64d; }

I think we need to check HasStdExtF with Zve32f with a FIXME to consider 
HasStdExtZfinx in the future.



Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.h:194
+  bool hasVInstructionsF32() const { return HasStdExtZve32f; }
+  bool hasVInstructionsF64() const { return HasStdExtZve64d; }
   // F16 and F64 both require F32.

I think we need to check HasStdExtD with Zve64d with a FIXME to consider 
HasStdExtZdinx in the future


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

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

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

This revision was automatically updated to reflect the committed changes.
LegalizeAdulthood marked an inline comment as done.
Closed by commit rGd83ecd77cc0f: [clang-tidy] Narrow cppguidelines-macro-usage 
to actual constants (authored by LegalizeAdulthood).

Changed prior to commit:
  https://reviews.llvm.org/D116386?vs=401242=401349#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116386

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
  clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-macro-usage.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-macro-usage.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-macro-usage.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-macro-usage.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s cppcoreguidelines-macro-usage %t -- -header-filter=.* -system-headers --
+// RUN: %check_clang_tidy %s cppcoreguidelines-macro-usage -std=c++17-or-later %t -- -header-filter=.* -system-headers --
 
 #ifndef INCLUDE_GUARD
 #define INCLUDE_GUARD
@@ -6,6 +6,21 @@
 #define PROBLEMATIC_CONSTANT 0
 // CHECK-MESSAGES: [[@LINE-1]]:9: warning: macro 'PROBLEMATIC_CONSTANT' used to declare a constant; consider using a 'constexpr' constant
 
+#define PROBLEMATIC_CONSTANT_CHAR '0'
+// CHECK-MESSAGES: [[@LINE-1]]:9: warning: macro 'PROBLEMATIC_CONSTANT_CHAR' used to declare a constant; consider using a 'constexpr' constant
+
+#define PROBLEMATIC_CONSTANT_WIDE_CHAR L'0'
+// CHECK-MESSAGES: [[@LINE-1]]:9: warning: macro 'PROBLEMATIC_CONSTANT_WIDE_CHAR' used to declare a constant; consider using a 'constexpr' constant
+
+#define PROBLEMATIC_CONSTANT_UTF8_CHAR u8'0'
+// CHECK-MESSAGES: [[@LINE-1]]:9: warning: macro 'PROBLEMATIC_CONSTANT_UTF8_CHAR' used to declare a constant; consider using a 'constexpr' constant
+
+#define PROBLEMATIC_CONSTANT_UTF16_CHAR u'0'
+// CHECK-MESSAGES: [[@LINE-1]]:9: warning: macro 'PROBLEMATIC_CONSTANT_UTF16_CHAR' used to declare a constant; consider using a 'constexpr' constant
+
+#define PROBLEMATIC_CONSTANT_UTF32_CHAR U'0'
+// CHECK-MESSAGES: [[@LINE-1]]:9: warning: macro 'PROBLEMATIC_CONSTANT_UTF32_CHAR' used to declare a constant; consider using a 'constexpr' constant
+
 #define PROBLEMATIC_FUNCTION(x, y) ((a) > (b) ? (a) : (b))
 // CHECK-MESSAGES: [[@LINE-1]]:9: warning: function-like macro 'PROBLEMATIC_FUNCTION' used; consider a 'constexpr' template function
 
@@ -15,4 +30,17 @@
 #define PROBLEMATIC_VARIADIC2(x, ...) (__VA_ARGS__)
 // CHECK-MESSAGES: [[@LINE-1]]:9: warning: variadic macro 'PROBLEMATIC_VARIADIC2' used; consider using a 'constexpr' variadic template function
 
+// These are all examples of common macros that shouldn't have constexpr suggestions.
+#define COMMA ,
+
+#define NORETURN [[noreturn]]
+
+#define DEPRECATED attribute((deprecated))
+
+#if LIB_EXPORTS
+#define DLLEXPORTS __declspec(dllexport)
+#else
+#define DLLEXPORTS __declspec(dllimport)
+#endif
+
 #endif
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
@@ -7,10 +7,40 @@
 constructs exist for the task.
 
 The relevant sections in the C++ Core Guidelines are
-`Enum.1 `_,
-`ES.30 `_,
-`ES.31 `_ and
-`ES.33 `_.
+`ES.31 `_, and
+`ES.32 `_.
+
+Examples:
+
+.. code-block:: c++
+
+  #define C 0
+  #define F1(x, y) ((a) > (b) ? (a) : (b))
+  #define F2(...) (__VA_ARGS__)
+  #define COMMA ,
+  #define NORETURN [[noreturn]]
+  #define DEPRECATED attribute((deprecated))
+  #if LIB_EXPORTS
+  #define DLLEXPORTS __declspec(dllexport)
+  #else
+  #define DLLEXPORTS __declspec(dllimport)
+  #endif
+
+results in the following warnings:
+
+.. code-block:: c++
+
+  4 warnings generated.
+  test.cpp:1:9: warning: macro 'C' used to declare a constant;

[clang-tools-extra] d83ecd7 - [clang-tidy] Narrow cppguidelines-macro-usage to actual constants

2022-01-19 Thread via cfe-commits


Author: Richard
Date: 2022-01-19T12:28:22-07:00
New Revision: d83ecd77cc0f16cb5fbabe03d37829893ac8b56d

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

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

Previously, any macro that didn't look like a varargs macro
or a function style macro was reported with a warning that
it should be replaced with a constexpr const declaration.
This is only reasonable when the macro body contains constants
and not expansions like ",", "[[noreturn]]", "__declspec(xxx)",
etc.

So instead of always issuing a warning about every macro that
doesn't look like a varargs or function style macro, examine the
tokens in the macro and only warn about the macro if it contains
only comment and constant tokens.

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

Fixes #39945

Added: 


Modified: 
clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-macro-usage.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
index a6f6ca4c1abd6..94a646c7fca03 100644
--- a/clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
+++ b/clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
@@ -14,25 +14,25 @@
 #include "llvm/Support/Regex.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 namespace tidy {
 namespace cppcoreguidelines {
 
-namespace {
-
-bool isCapsOnly(StringRef Name) {
-  return std::all_of(Name.begin(), Name.end(), [](const char C) {
-if (std::isupper(C) || std::isdigit(C) || C == '_')
-  return true;
-return false;
+static bool isCapsOnly(StringRef Name) {
+  return llvm::all_of(Name, [](const char C) {
+return std::isupper(C) || std::isdigit(C) || C == '_';
   });
 }
 
+namespace {
+
 class MacroUsageCallbacks : public PPCallbacks {
 public:
   MacroUsageCallbacks(MacroUsageCheck *Check, const SourceManager ,
-  StringRef RegExpStr, bool CapsOnly, bool 
IgnoreCommandLine)
+  StringRef RegExpStr, bool CapsOnly,
+  bool IgnoreCommandLine)
   : Check(Check), SM(SM), RegExp(RegExpStr), CheckCapsOnly(CapsOnly),
 IgnoreCommandLineMacros(IgnoreCommandLine) {}
   void MacroDefined(const Token ,
@@ -79,21 +79,24 @@ void MacroUsageCheck::registerPPCallbacks(const 
SourceManager ,
 }
 
 void MacroUsageCheck::warnMacro(const MacroDirective *MD, StringRef MacroName) 
{
-  StringRef Message =
-  "macro '%0' used to declare a constant; consider using a 'constexpr' "
-  "constant";
-
-  /// A variadic macro is function-like at the same time. Therefore variadic
-  /// macros are checked first and will be excluded for the function-like
-  /// diagnostic.
-  if (MD->getMacroInfo()->isVariadic())
+  const MacroInfo *Info = MD->getMacroInfo();
+  StringRef Message;
+
+  if (llvm::all_of(Info->tokens(), std::mem_fn(::isLiteral)))
+Message = "macro '%0' used to declare a constant; consider using a "
+  "'constexpr' constant";
+  // A variadic macro is function-like at the same time. Therefore variadic
+  // macros are checked first and will be excluded for the function-like
+  // diagnostic.
+  else if (Info->isVariadic())
 Message = "variadic macro '%0' used; consider using a 'constexpr' "
   "variadic template function";
-  else if (MD->getMacroInfo()->isFunctionLike())
+  else if (Info->isFunctionLike())
 Message = "function-like macro '%0' used; consider a 'constexpr' template "
   "function";
 
-  diag(MD->getLocation(), Message) << MacroName;
+  if (!Message.empty())
+diag(MD->getLocation(), Message) << MacroName;
 }
 
 void MacroUsageCheck::warnNaming(const MacroDirective *MD,

diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 098edd90b725f..683e914b7e863 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -83,6 +83,9 @@ Improvements to clang-tidy
 - Generalized the `modernize-use-default-member-init` check to handle 
non-default
   constructors.
 
+- Eliminated false positives for `cppcoreguidelines-macro-usage` by restricting
+  the warning about using constants to only macros that expand to literals.
+
 New checks
 ^^
 

diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst 
b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
index 29e60cc88fa2f..ca7e54429c236 100644
---

[PATCH] D117049: [OpenMP] Add support for embedding bitcode images in wrapper tool

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

jhuber6 added a comment.

In D117049#3255748 , @saiislam wrote:

> It seems that this patch along with D117156 
>  and D117246 
>  is giving `patch application failed` error 
> [https://buildkite.com/llvm-project/diff-checks/builds/82688].
> `arc patch` is also giving the same error.

I think what happened is I didn't include a small fix patch I had locally in 
the list somewhere which made the diffs not apply. I could probably try to 
squash them and reapply if it's important.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117049

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

[PATCH] D117049: [OpenMP] Add support for embedding bitcode images in wrapper tool

2022-01-19 Thread Saiyedul Islam via Phabricator via cfe-commits

saiislam added a comment.

It seems that this patch along with D117156  
and D117246  is giving `patch application 
failed` error [https://buildkite.com/llvm-project/diff-checks/builds/82688].
`arc patch` is also giving the same error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117049

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

[PATCH] D117706: [openmp] Unconditionally set march commandline argument

2022-01-19 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

Landed with you as author and me as reviewer as that seems a more accurate 
statement than the default. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117706

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

[PATCH] D117706: [openmp] Unconditionally set march commandline argument

2022-01-19 Thread Jon Chesterfield via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa9935b5db706: [openmp] Unconditionally set march commandline 
argument (authored by jhuber6, committed by JonChesterfield).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117706

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


Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -285,10 +285,22 @@
 
   const OptTable  = getDriver().getOpts();
 
-  if (DeviceOffloadKind != Action::OFK_OpenMP) {
-for (Arg *A : Args) {
-  DAL->append(A);
+  if (DeviceOffloadKind == Action::OFK_OpenMP) {
+for (Arg *A : Args)
+  if (!llvm::is_contained(*DAL, A))
+DAL->append(A);
+
+std::string Arch = DAL->getLastArgValue(options::OPT_march_EQ).str();
+if (Arch.empty()) {
+  checkSystemForAMDGPU(Args, *this, Arch);
+  DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_march_EQ), Arch);
 }
+
+return DAL;
+  }
+
+  for (Arg *A : Args) {
+DAL->append(A);
   }
 
   if (!BoundArch.empty()) {


Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -285,10 +285,22 @@
 
   const OptTable  = getDriver().getOpts();
 
-  if (DeviceOffloadKind != Action::OFK_OpenMP) {
-for (Arg *A : Args) {
-  DAL->append(A);
+  if (DeviceOffloadKind == Action::OFK_OpenMP) {
+for (Arg *A : Args)
+  if (!llvm::is_contained(*DAL, A))
+DAL->append(A);
+
+std::string Arch = DAL->getLastArgValue(options::OPT_march_EQ).str();
+if (Arch.empty()) {
+  checkSystemForAMDGPU(Args, *this, Arch);
+  DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_march_EQ), Arch);
 }
+
+return DAL;
+  }
+
+  for (Arg *A : Args) {
+DAL->append(A);
   }
 
   if (!BoundArch.empty()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] a9935b5 - [openmp] Unconditionally set march commandline argument

2022-01-19 Thread Jon Chesterfield via cfe-commits


Author: Joseph Huber
Date: 2022-01-19T19:14:47Z
New Revision: a9935b5db706c89182fa3a3e10f30237fb6c4ec5

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

LOG: [openmp] Unconditionally set march commandline argument

Extracted from D117246. This reflects the march value used by the
compile back into the toolchain arguments, letting downstream processes
such as LTO rely on it being present. Subsequent patches should also be able
to remove the two other calls to checkSystemForAMDGPU.

Reviewed By: jonchesterfield

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

Added: 


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

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp 
b/clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
index 198e3546d4fa2..983d40636b0cd 100644
--- a/clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -285,10 +285,22 @@ llvm::opt::DerivedArgList 
*AMDGPUOpenMPToolChain::TranslateArgs(
 
   const OptTable  = getDriver().getOpts();
 
-  if (DeviceOffloadKind != Action::OFK_OpenMP) {
-for (Arg *A : Args) {
-  DAL->append(A);
+  if (DeviceOffloadKind == Action::OFK_OpenMP) {
+for (Arg *A : Args)
+  if (!llvm::is_contained(*DAL, A))
+DAL->append(A);
+
+std::string Arch = DAL->getLastArgValue(options::OPT_march_EQ).str();
+if (Arch.empty()) {
+  checkSystemForAMDGPU(Args, *this, Arch);
+  DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_march_EQ), Arch);
 }
+
+return DAL;
+  }
+
+  for (Arg *A : Args) {
+DAL->append(A);
   }
 
   if (!BoundArch.empty()) {



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

[PATCH] D117706: [openmp] Unconditionally set march commandline argument

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

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

LGTM, with this you should be able to replace calls for the AMDGPU arch with 
querying the ToolChain args, e.g. 
`TCArgs.getLastArgValue(options::OPT_march_EQ)`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117706

___
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 214 matches

Mail list logo