[PATCH] D157174: [clang][Interp] Convert logical binop operands to bool

2023-08-04 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, erichkeane, shafik, cor3ntin.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Move the logic for this into `visitBool`, where it belongs.  Then convert the 
logical binary operator operands to bool using `visitBool()` and the result 
back to int, if needed (which it is in C).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157174

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp

Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -480,18 +480,19 @@
   BinaryOperatorKind Op = E->getOpcode();
   const Expr *LHS = E->getLHS();
   const Expr *RHS = E->getRHS();
+  std::optional T = classify(E->getType());
 
   if (Op == BO_LOr) {
 // Logical OR. Visit LHS and only evaluate RHS if LHS was FALSE.
 LabelTy LabelTrue = this->getLabel();
 LabelTy LabelEnd = this->getLabel();
 
-if (!this->visit(LHS))
+if (!this->visitBool(LHS))
   return false;
 if (!this->jumpTrue(LabelTrue))
   return false;
 
-if (!this->visit(RHS))
+if (!this->visitBool(RHS))
   return false;
 if (!this->jump(LabelEnd))
   return false;
@@ -501,35 +502,36 @@
 this->fallthrough(LabelEnd);
 this->emitLabel(LabelEnd);
 
-if (DiscardResult)
-  return this->emitPopBool(E);
-
-return true;
-  }
-
-  // Logical AND.
-  // Visit LHS. Only visit RHS if LHS was TRUE.
-  LabelTy LabelFalse = this->getLabel();
-  LabelTy LabelEnd = this->getLabel();
+  } else {
+assert(Op == BO_LAnd);
+// Logical AND.
+// Visit LHS. Only visit RHS if LHS was TRUE.
+LabelTy LabelFalse = this->getLabel();
+LabelTy LabelEnd = this->getLabel();
 
-  if (!this->visit(LHS))
-return false;
-  if (!this->jumpFalse(LabelFalse))
-return false;
+if (!this->visitBool(LHS))
+  return false;
+if (!this->jumpFalse(LabelFalse))
+  return false;
 
-  if (!this->visit(RHS))
-return false;
-  if (!this->jump(LabelEnd))
-return false;
+if (!this->visitBool(RHS))
+  return false;
+if (!this->jump(LabelEnd))
+  return false;
 
-  this->emitLabel(LabelFalse);
-  this->emitConstBool(false, E);
-  this->fallthrough(LabelEnd);
-  this->emitLabel(LabelEnd);
+this->emitLabel(LabelFalse);
+this->emitConstBool(false, E);
+this->fallthrough(LabelEnd);
+this->emitLabel(LabelEnd);
+  }
 
   if (DiscardResult)
 return this->emitPopBool(E);
 
+  // For C, cast back to integer type.
+  assert(T);
+  if (T != PT_Bool)
+return this->emitCast(PT_Bool, *T, E);
   return true;
 }
 
@@ -902,17 +904,9 @@
   LabelTy LabelEnd = this->getLabel();   // Label after the operator.
   LabelTy LabelFalse = this->getLabel(); // Label for the false expr.
 
-  if (!this->visit(Condition))
+  if (!this->visitBool(Condition))
 return false;
 
-  // C special case: Convert to bool because our jump ops need that.
-  // TODO: We probably want this to be done in visitBool().
-  if (std::optional CondT = classify(Condition->getType());
-  CondT && CondT != PT_Bool) {
-if (!this->emitCast(*CondT, PT_Bool, E))
-  return false;
-  }
-
   if (!this->jumpFalse(LabelFalse))
 return false;
 
@@ -1650,11 +1644,29 @@
 
 template 
 bool ByteCodeExprGen::visitBool(const Expr *E) {
-  if (std::optional T = classify(E->getType())) {
-return visit(E);
-  } else {
-return this->bail(E);
+  std::optional T = classify(E->getType());
+  if (!T)
+return false;
+
+  if (!this->visit(E))
+return false;
+
+  if (T == PT_Bool)
+return true;
+
+  // Convert pointers to bool.
+  if (T == PT_Ptr || T == PT_FnPtr) {
+if (!this->emitNull(*T, E))
+  return false;
+return this->emitNE(*T, E);
   }
+
+  // Or Floats.
+  if (T == PT_Float)
+return this->emitCastFloatingIntegralBool(E);
+
+  // Or anything else we can.
+  return this->emitCast(*T, PT_Bool, E);
 }
 
 template 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142569: [OpenMP] Introduce kernel environment

2023-08-04 Thread Dhruva Chakrabarti via Phabricator via cfe-commits
dhruvachak added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:4065
+  Constant *KernelEnvironmentGV = new GlobalVariable(
+  M, KernelEnvironment, /* IsConstant */ true, 
GlobalValue::ExternalLinkage,
+  KernelEnvironmentInitializer, KernelEnvironmentName,

tianshilei1992 wrote:
> dhruvachak wrote:
> > Is there a reason this has to be ExternalLinkage? Can we use 
> > GlobalValue::WeakAnyLinkage here? The external linkage leads to multiply 
> > defined linker errors downstream on test cases that have a target region in 
> > a header file. For some reason, the problem does not repro on the main 
> > branch. 
> > @tianshilei1992 @jdoerfert 
> It has been fixed.
> It has been fixed.

Thanks. I hadn't pulled, so did not see it earlier.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142569

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


[PATCH] D157170: [clang][AST]Don't increase depth in friend tempalte class declaration

2023-08-04 Thread Qizhi Hu via Phabricator via cfe-commits
jcsxky created this revision.
jcsxky added reviewers: a.sidorin, shafik, balazske, steakhal, aaron.ballman, 
Michael137.
jcsxky added projects: clang, clang-c.
Herald added a project: All.
jcsxky requested review of this revision.
Herald added a subscriber: cfe-commits.

Don't increase template parameter's depth when it's a friend declaration in 
template class. The reason is that this member(template class) should match the 
previous class definition and when import from external ast file, type of them 
should be equivalence.
See import issue 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157170

Files:
  clang/lib/Parse/ParseTemplate.cpp
  clang/unittests/AST/ASTImporterTest.cpp


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -4212,6 +4212,56 @@
   EXPECT_TRUE(Imported->getPreviousDecl());
 }
 
+TEST_P(ImportFriendClasses, SkipFriendTemplateDeclaration) {
+  Decl *ToTU = getToTuDecl(
+  R"(
+  template 
+  class A;
+
+  template 
+  class A {
+  public:
+template 
+friend class A;
+
+A(T x):x(x) {}
+
+  private:
+T x;
+  };
+  )",
+  Lang_CXX11);
+
+  auto *Fwd = FirstDeclMatcher().match(
+  ToTU, classTemplateDecl(hasName("A")));
+  Decl *FromTU = getTuDecl(
+  R"(
+  template 
+  class A;
+
+  template 
+  class A {
+  public:
+template 
+friend class A;
+
+A(T x):x(x) {}
+
+  private:
+T x;
+  };
+
+  A a1(0);
+  )",
+  Lang_CXX11, "input1.cc");
+  auto *FromA = FirstDeclMatcher().match(
+  FromTU, classTemplateDecl(hasName("A")));
+  auto *ToA = Import(FromA, Lang_CXX11);
+  EXPECT_TRUE(ToA);
+  EXPECT_EQ(Fwd->getTemplatedDecl()->getTypeForDecl(),
+ToA->getTemplatedDecl()->getTypeForDecl());
+}
+
 TEST_P(ImportFriendClasses,
ImportOfClassTemplateDefinitionShouldConnectToFwdFriend) {
   Decl *ToTU = getToTuDecl(
Index: clang/lib/Parse/ParseTemplate.cpp
===
--- clang/lib/Parse/ParseTemplate.cpp
+++ clang/lib/Parse/ParseTemplate.cpp
@@ -127,8 +127,30 @@
 // Parse the '<' template-parameter-list '>'
 SourceLocation LAngleLoc, RAngleLoc;
 SmallVector TemplateParams;
+
+bool SeeFriendKeyWord = false;
+{
+  SmallVector TemplateParams;
+  SourceLocation LAngleLoc, RAngleLoc;
+  RevertingTentativeParsingAction TPA(*this);
+  MultiParseScope TemplateParamScopesTmp(*this);
+  if (ParseTemplateParameters(TemplateParamScopesTmp,
+  CurTemplateDepthTracker.getDepth(),
+  TemplateParams, LAngleLoc, RAngleLoc)) {
+// returns true don't need process
+// returns false, blowe 'ParseTemplateParameters' will do it after
+// revert
+  }
+  // skip outmost declaration
+  if (Tok.is(tok::kw_friend) && CurTemplateDepthTracker.getDepth() > 0) {
+SeeFriendKeyWord = true;
+  }
+}
+
 if (ParseTemplateParameters(TemplateParamScopes,
-CurTemplateDepthTracker.getDepth(),
+SeeFriendKeyWord
+? CurTemplateDepthTracker.getDepth() - 1
+: CurTemplateDepthTracker.getDepth(),
 TemplateParams, LAngleLoc, RAngleLoc)) {
   // Skip until the semi-colon or a '}'.
   SkipUntil(tok::r_brace, StopAtSemi | StopBeforeMatch);


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -4212,6 +4212,56 @@
   EXPECT_TRUE(Imported->getPreviousDecl());
 }
 
+TEST_P(ImportFriendClasses, SkipFriendTemplateDeclaration) {
+  Decl *ToTU = getToTuDecl(
+  R"(
+  template 
+  class A;
+
+  template 
+  class A {
+  public:
+template 
+friend class A;
+
+A(T x):x(x) {}
+
+  private:
+T x;
+  };
+  )",
+  Lang_CXX11);
+
+  auto *Fwd = FirstDeclMatcher().match(
+  ToTU, classTemplateDecl(hasName("A")));
+  Decl *FromTU = getTuDecl(
+  R"(
+  template 
+  class A;
+
+  template 
+  class A {
+  public:
+template 
+friend class A;
+
+A(T x):x(x) {}
+
+  private:
+T x;
+  };
+
+  A a1(0);
+  )",
+  Lang_CXX11, "input1.cc");
+  auto *FromA = FirstDeclMatcher().match(
+  FromTU, classTemplateDecl(hasName("A")));
+ 

[PATCH] D142569: [OpenMP] Introduce kernel environment

2023-08-04 Thread Shilei Tian via Phabricator via cfe-commits
tianshilei1992 added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:4065
+  Constant *KernelEnvironmentGV = new GlobalVariable(
+  M, KernelEnvironment, /* IsConstant */ true, 
GlobalValue::ExternalLinkage,
+  KernelEnvironmentInitializer, KernelEnvironmentName,

dhruvachak wrote:
> Is there a reason this has to be ExternalLinkage? Can we use 
> GlobalValue::WeakAnyLinkage here? The external linkage leads to multiply 
> defined linker errors downstream on test cases that have a target region in a 
> header file. For some reason, the problem does not repro on the main branch. 
> @tianshilei1992 @jdoerfert 
It has been fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142569

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


[PATCH] D140760: [clang-tidy] Support begin/end free functions in modernize-loop-convert

2023-08-04 Thread Chris Cotter via Phabricator via cfe-commits
ccotter updated this revision to Diff 547433.
ccotter marked 2 inline comments as done.
ccotter added a comment.

- Feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140760

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize/loop-convert.rst
  
clang-tools-extra/test/clang-tidy/checkers/modernize/Inputs/loop-convert/structures.h
  clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-basic.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-negative.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-negative.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-negative.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-negative.cpp
@@ -5,6 +5,22 @@
 // CHECK-FIXES-NOT: for ({{.*[^:]:[^:].*}})
 // CHECK-MESSAGES-NOT: modernize-loop-convert
 
+namespace somenamespace {
+  template  auto begin(T& t) -> decltype(t.begin());
+  template  auto begin(const T& t) -> decltype(t.begin());
+  template  auto end(T& t) -> decltype(t.end());
+  template  auto end(const T& t) -> decltype(t.end());
+  template  auto size(const T& t) -> decltype(t.size());
+} // namespace somenamespace
+
+struct SomeClass {
+  template  static auto begin(T& t) -> decltype(t.begin());
+  template  static auto begin(const T& t) -> decltype(t.begin());
+  template  static auto end(T& t) -> decltype(t.end());
+  template  static auto end(const T& t) -> decltype(t.end());
+  template  static auto size(const T& t) -> decltype(t.size());
+};
+
 namespace Negative {
 
 const int N = 6;
@@ -92,7 +108,7 @@
   }
 }
 
-}
+} // namespace Negative
 
 namespace NegativeIterator {
 
@@ -103,6 +119,10 @@
 struct BadBeginEnd : T {
   iterator notBegin();
   iterator notEnd();
+  iterator begin(int);
+  iterator end(int);
+  iterator begin();
+  iterator end();
 };
 
 void notBeginOrEnd() {
@@ -112,6 +132,9 @@
 
   for (T::iterator I = Bad.begin(), E = Bad.notEnd();  I != E; ++I)
 int K = *I;
+
+  for (T::iterator I = Bad.begin(0), E = Bad.end(0);  I != E; ++I)
+int K = *I;
 }
 
 void badLoopShapes() {
@@ -202,6 +225,8 @@
   T Other;
   for (T::iterator I = Tt.begin(), E = Other.end();  I != E; ++I)
 int K = *I;
+  for (T::iterator I = begin(Tt), E = end(Other);  I != E; ++I)
+int K = *I;
 
   for (T::iterator I = Other.begin(), E = Tt.end();  I != E; ++I)
 int K = *I;
@@ -214,6 +239,24 @@
 MutableVal K = *I;
 }
 
+void mixedMemberAndADL() {
+  for (T::iterator I = Tt.begin(), E = end(Tt);  I != E; ++I)
+int K = *I;
+  for (T::iterator I = begin(Tt), E = Tt.end();  I != E; ++I)
+int K = *I;
+  for (T::iterator I = std::begin(Tt), E = Tt.end();  I != E; ++I)
+int K = *I;
+  for (T::iterator I = std::begin(Tt), E = end(Tt);  I != E; ++I)
+int K = *I;
+}
+
+void nonADLOrStdCalls() {
+  for (T::iterator I = SomeClass::begin(Tt), E = SomeClass::end(Tt);  I != E; ++I)
+int K = *I;
+  for (T::iterator I = somenamespace::begin(Tt), E = somenamespace::end(Tt);  I != E; ++I)
+int K = *I;
+}
+
 void wrongIterators() {
   T::iterator Other;
   for (T::iterator I = Tt.begin(), E = Tt.end(); I != Other; ++I)
@@ -379,6 +422,13 @@
 Sum += V[I];
 }
 
+void nonADLOrStdCalls() {
+  for (int I = 0, E = somenamespace::size(V); E != I; ++I)
+printf("Fibonacci number is %d\n", V[I]);
+  for (int I = 0, E = SomeClass::size(V); E != I; ++I)
+printf("Fibonacci number is %d\n", V[I]);
+}
+
 // Checks to see that non-const member functions are not called on the container
 // object.
 // These could be conceivably allowed with a lower required confidence level.
Index: clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-basic.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-basic.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-basic.cpp
@@ -445,6 +445,41 @@
   // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto & I : Dpp)
   // CHECK-FIXES-NEXT: printf("%d\n", I->X);
+
+  for (S::iterator It = begin(Ss), E = end(Ss); It != E; ++It) {
+printf("s0 has value %d\n", (*It).X);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & It : Ss)
+  // CHECK-FIXES-NEXT: printf("s0 has value %d\n", It.X);
+
+  for (S::iterator It = std::begin(Ss), E = std::end(Ss); It != E; ++It) {
+printf("s1 has value %d\n", (*It).X);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & It : Ss)
+  // CHECK-FIXES-NEXT: printf("s1 has value %d\n", It.X);
+
+  for 

[PATCH] D153059: [-Wunsafe-buffer-usage] Group parameter fix-its

2023-08-04 Thread Ziqing Luo via Phabricator via cfe-commits
ziqingluo-90 added inline comments.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:1891-1892
+  for (unsigned i = 0; i < NumParms; i++) {
+if (!ParmsMask[i])
+  continue;
+

NoQ wrote:
> Speaking of [[ https://reviews.llvm.org/D156762#inline-1517322 |my comment on 
> the other patch]].
> 
> Can we simply ask `Strategy` about the strategy for `FD->getParamDecl(i)` 
> instead of passing a mask?
> 
> Eventually we'll have to do that anyway, given how different parameters can 
> be assigned different strategies.
Yes.  I think using `Strategy` is the correct way to do it.  

Can I make it a follow-up patch?  I noticed that this line needs to be fixed:
```
  Strategy NaiveStrategy = getNaiveStrategy(UnsafeVars);
```
The `UnsafeVars` is the set of variables associated to all matched 
`FixableGadget`s.  There can be variables that is safe and do not need fix.  
Their strategy is set to `std::span` currently which is not correct.  With this 
line being fixed, we can have examples like
```
void f(int * p) {
  int * q;
   q = p;
   p[5] = 5;
}
```
where `q`'s strategy is `WONTFIX` and `p`'s strategy is `std::span`.  The 
expression `q = p` can be fixed to `q = p.data()`.  It  currently has an empty 
fix-it, which is incorrect.


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

https://reviews.llvm.org/D153059

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


[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

2023-08-04 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

In D156928#4562412 , @yaxunl wrote:

> Some control variables are per-module. Clang cannot emit control variables 
> that have different values for different modules. Intrinsics should work 
> since it can take an argument as its value.

Sure it can. In the most limited case, we could exactly replace the variables 
imported from source IR in the device libs based on command line variables with 
the same globals with the same flags. That would be NFC except it would no 
longer matter if the devicertl source was present.

There's just also other better things to be done as well, like not burning ABI 
decisions in the front end, or not using magic variables at all. But it's 
definitely not necessary to write constants in IR files that encode the same 
information as the command line flag. That's a whole indirect no-op that 
doesn't need to be there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928

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


[PATCH] D153059: [-Wunsafe-buffer-usage] Group parameter fix-its

2023-08-04 Thread Ziqing Luo via Phabricator via cfe-commits
ziqingluo-90 updated this revision to Diff 547425.

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

https://reviews.llvm.org/D153059

Files:
  clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Analysis/UnsafeBufferUsage.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-multi-parm-span.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp

Index: clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp
@@ -36,7 +36,7 @@
 void * voidPtrCall(void);
 char * charPtrCall(void);
 
-void testArraySubscripts(int *p, int **pp) { // expected-note{{change type of 'pp' to 'std::span' to preserve bounds information}}
+void testArraySubscripts(int *p, int **pp) {
 // expected-warning@-1{{'p' is an unsafe pointer used for buffer access}}
 // expected-warning@-2{{'pp' is an unsafe pointer used for buffer access}}
   foo(p[1], // expected-note{{used in buffer access here}}
@@ -109,7 +109,6 @@
   sizeof(decltype(p[1])));  // no-warning
 }
 
-// expected-note@+1{{change type of 'a' to 'std::span' to preserve bounds information}}
 void testQualifiedParameters(const int * p, const int * const q, const int a[10], const int b[10][10]) {
   // expected-warning@-1{{'p' is an unsafe pointer used for buffer access}}
   // expected-warning@-2{{'q' is an unsafe pointer used for buffer access}}
Index: clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
@@ -29,8 +29,7 @@
   int tmp;
   tmp = p[5] + q[5];
 }
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:2-[[@LINE-1]]:2}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void twoParms(int *p, int * q) {return twoParms(std::span(p, <# size #>), q);}\n"
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-2]]:2-[[@LINE-2]]:2}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void twoParms(int *p, int * q) {return twoParms(p, std::span(q, <# size #>));}\n"
+// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:2-[[@LINE-1]]:2}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void twoParms(int *p, int * q) {return twoParms(std::span(p, <# size #>), std::span(q, <# size #>));}\n"
 
 void ptrToConst(const int * x) {
   // CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:17-[[@LINE-1]]:30}:"std::span x"
@@ -100,22 +99,30 @@
 // namned
   } NAMED_S;
 
+
   // FIXME: `decltype(ANON_S)` represents an unnamed type but it can
   // be referred as "`decltype(ANON_S)`", so the analysis should
   // fix-it.
-  void decltypeSpecifier(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,
- decltype(NAMED_S) ** rr) {
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-2]]:26-[[@LINE-2]]:41}:"std::span p"
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-3]]:65-[[@LINE-3]]:86}:"std::span r"
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-3]]:26-[[@LINE-3]]:49}:"std::span rr"
+  // As parameter `q` cannot be fixed, fixes to parameters are all being given up.
+  void decltypeSpecifierAnon(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,
+			 decltype(NAMED_S) ** rr) {
+// CHECK-NOT: fix-it:{{.*}}:{[[@LINE-1]]
 if (++p) {}
 if (++q) {}
 if (++r) {}
 if (++rr) {}
   }
-  // CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:4-[[@LINE-1]]:4}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void decltypeSpecifier(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,\n{{.*}}decltype(NAMED_S) ** rr) {return decltypeSpecifier(std::span(p, <# size #>), q, r, rr);}\n
-  // CHECK-DAG: fix-it:{{.*}}:{[[@LINE-2]]:4-[[@LINE-2]]:4}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void decltypeSpecifier(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,\n{{.*}}decltype(NAMED_S) ** rr) {return decltypeSpecifier(p, q, std::span(r, <# size #>), rr);}\n"
-  // CHECK-DAG: fix-it:{{.*}}:{[[@LINE-3]]:4-[[@LINE-3]]:4}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void decltypeSpecifier(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,\n{{.*}}decltype(NAMED_S) ** rr) {return decltypeSpecifier(p, q, r, std::span(rr, <# size #>));}\n"
+  // CHECK-NOT: fix-it:{{.*}}:{[[@LINE-1]]
+
+  void decltypeSpecifier(decltype(C) * p, decltype(NAMED_S) * r, decltype(NAMED_S) ** rr) {
+// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:26-[[@LINE-1]]:41}:"std::span p"
+// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-2]]:43-[[@LINE-2]]:64}:"std::span r"
+// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-3]]:66-[[@LINE-3]]:89}:"std::span rr"
+if (++p) {}
+if (++r) {}
+if (++rr) {}
+  }
+  // CHECK-DAG: 

[PATCH] D153059: [-Wunsafe-buffer-usage] Group parameter fix-its

2023-08-04 Thread Ziqing Luo via Phabricator via cfe-commits
ziqingluo-90 updated this revision to Diff 547422.
ziqingluo-90 marked an inline comment as done.
ziqingluo-90 added a comment.

Address comments.


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

https://reviews.llvm.org/D153059

Files:
  clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Analysis/UnsafeBufferUsage.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-multi-parm-span.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp

Index: clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp
@@ -36,7 +36,7 @@
 void * voidPtrCall(void);
 char * charPtrCall(void);
 
-void testArraySubscripts(int *p, int **pp) { // expected-note{{change type of 'pp' to 'std::span' to preserve bounds information}}
+void testArraySubscripts(int *p, int **pp) {
 // expected-warning@-1{{'p' is an unsafe pointer used for buffer access}}
 // expected-warning@-2{{'pp' is an unsafe pointer used for buffer access}}
   foo(p[1], // expected-note{{used in buffer access here}}
@@ -109,7 +109,6 @@
   sizeof(decltype(p[1])));  // no-warning
 }
 
-// expected-note@+1{{change type of 'a' to 'std::span' to preserve bounds information}}
 void testQualifiedParameters(const int * p, const int * const q, const int a[10], const int b[10][10]) {
   // expected-warning@-1{{'p' is an unsafe pointer used for buffer access}}
   // expected-warning@-2{{'q' is an unsafe pointer used for buffer access}}
Index: clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
===
--- clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-parm-span.cpp
@@ -29,8 +29,7 @@
   int tmp;
   tmp = p[5] + q[5];
 }
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:2-[[@LINE-1]]:2}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void twoParms(int *p, int * q) {return twoParms(std::span(p, <# size #>), q);}\n"
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-2]]:2-[[@LINE-2]]:2}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void twoParms(int *p, int * q) {return twoParms(p, std::span(q, <# size #>));}\n"
+// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:2-[[@LINE-1]]:2}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void twoParms(int *p, int * q) {return twoParms(std::span(p, <# size #>), std::span(q, <# size #>));}\n"
 
 void ptrToConst(const int * x) {
   // CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:17-[[@LINE-1]]:30}:"std::span x"
@@ -100,22 +99,30 @@
 // namned
   } NAMED_S;
 
+
   // FIXME: `decltype(ANON_S)` represents an unnamed type but it can
   // be referred as "`decltype(ANON_S)`", so the analysis should
   // fix-it.
-  void decltypeSpecifier(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,
- decltype(NAMED_S) ** rr) {
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-2]]:26-[[@LINE-2]]:41}:"std::span p"
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-3]]:65-[[@LINE-3]]:86}:"std::span r"
-// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-3]]:26-[[@LINE-3]]:49}:"std::span rr"
+  // As parameter `q` cannot be fixed, fixes to parameters are all being given up.
+  void decltypeSpecifierAnon(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,
+			 decltype(NAMED_S) ** rr) {
+// CHECK-NOT: fix-it:{{.*}}:{[[@LINE-1]]
 if (++p) {}
 if (++q) {}
 if (++r) {}
 if (++rr) {}
   }
-  // CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:4-[[@LINE-1]]:4}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void decltypeSpecifier(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,\n{{.*}}decltype(NAMED_S) ** rr) {return decltypeSpecifier(std::span(p, <# size #>), q, r, rr);}\n
-  // CHECK-DAG: fix-it:{{.*}}:{[[@LINE-2]]:4-[[@LINE-2]]:4}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void decltypeSpecifier(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,\n{{.*}}decltype(NAMED_S) ** rr) {return decltypeSpecifier(p, q, std::span(r, <# size #>), rr);}\n"
-  // CHECK-DAG: fix-it:{{.*}}:{[[@LINE-3]]:4-[[@LINE-3]]:4}:"\n{{\[}}{{\[}}clang::unsafe_buffer_usage{{\]}}{{\]}} void decltypeSpecifier(decltype(C) * p, decltype(ANON_S) * q, decltype(NAMED_S) * r,\n{{.*}}decltype(NAMED_S) ** rr) {return decltypeSpecifier(p, q, r, std::span(rr, <# size #>));}\n"
+  // CHECK-NOT: fix-it:{{.*}}:{[[@LINE-1]]
+
+  void decltypeSpecifier(decltype(C) * p, decltype(NAMED_S) * r, decltype(NAMED_S) ** rr) {
+// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-1]]:26-[[@LINE-1]]:41}:"std::span p"
+// CHECK-DAG: fix-it:{{.*}}:{[[@LINE-2]]:43-[[@LINE-2]]:64}:"std::span r"
+// CHECK-DAG: 

[PATCH] D156749: [modules] Fix error about the same module being defined in different .pcm files when using VFS overlays.

2023-08-04 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai added a comment.

In D156749#4561803 , @jansvoboda11 
wrote:

> My suggestion is to use the actual real on-disk path. Not 
> `FileEntryRef::getName()`, but something that always behaves as if 
> `use-external-name` was set to `true`. I believe this would handle your 
> VFS/VFS-use-external-name-true/VFS-use-external-name-false problem. It would 
> also handle another pitfall: two compilations with distinct VFS overlays that 
> redirect two different as-requested module map paths into the same on-disk 
> path.

Do you suggest doing it for the hashing or for ASTWriter or both? We are 
already doing some module map path canonicalization (added a comment in 
corresponding place) but it's not pure on-disk path, it takes into account VFS.




Comment at: clang/lib/Lex/HeaderSearch.cpp:259-260
 // to lower-case in case we're on a case-insensitive file system.
 SmallString<128> CanonicalPath(ModuleMapPath);
 if (getModuleMap().canonicalizeModuleMapPath(CanonicalPath))
   return {};

Sort of canonicalization and obtaining real on-disk path we are doing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156749

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


[PATCH] D142569: [OpenMP] Introduce kernel environment

2023-08-04 Thread Dhruva Chakrabarti via Phabricator via cfe-commits
dhruvachak added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:4065
+  Constant *KernelEnvironmentGV = new GlobalVariable(
+  M, KernelEnvironment, /* IsConstant */ true, 
GlobalValue::ExternalLinkage,
+  KernelEnvironmentInitializer, KernelEnvironmentName,

Is there a reason this has to be ExternalLinkage? Can we use 
GlobalValue::WeakAnyLinkage here? The external linkage leads to multiply 
defined linker errors downstream on test cases that have a target region in a 
header file. For some reason, the problem does not repro on the main branch. 
@tianshilei1992 @jdoerfert 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142569

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


[PATCH] D157164: [clang-tidy] Add fix-it support to `llvmlibc-inline-function-decl`

2023-08-04 Thread Roland McGrath via Phabricator via cfe-commits
mcgrathr created this revision.
mcgrathr added reviewers: abrachet, Caslyn, sivachandra, michaelrj.
Herald added subscribers: PiotrZSL, carlosgalvezp, xazax.hun.
Herald added a reviewer: njames93.
Herald added a project: All.
mcgrathr requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

This is very simplistic and could be more thorough by replacing
an existing `LIBC_INLINE` in the wrong location or a redunant
`inline` when inserting the right macro use.  But as is this
suffices to automatically apply fixes for most or all of the
instances in the libc tree today and get working results (despite
some superfluous `inline` keywords left behind).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157164

Files:
  clang-tools-extra/clang-tidy/llvmlibc/InlineFunctionDeclCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp

Index: clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp
===
--- clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp
+++ clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp
@@ -17,11 +17,13 @@
 
 constexpr long long addll(long long a, long long b) {
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: 'addll' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+// CHECK-FIXES: LIBC_INLINE constexpr long long addll(long long a, long long b) {
   return a + b;
 }
 
 inline unsigned long addul(unsigned long a, unsigned long b) {
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: 'addul' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+// CHECK-FIXES: LIBC_INLINE inline unsigned long addul(unsigned long a, unsigned long b) {
   return a + b;
 }
 
@@ -30,11 +32,13 @@
 public:
   MyClass() : A(123) {}
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'MyClass' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+  // CHECK-FIXES:   LIBC_INLINE MyClass() : A(123) {}
 
   LIBC_INLINE MyClass(int V) : A(V) {}
 
   constexpr operator int() const { return A; }
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'operator int' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+  // CHECK-FIXES:   LIBC_INLINE constexpr operator int() const { return A; }
 
   LIBC_INLINE bool operator==(const MyClass ) {
 return RHS.A == A;
@@ -42,6 +46,7 @@
 
   static int getVal(const MyClass ) {
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'getVal' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+  // CHECK-FIXES:   LIBC_INLINE static int getVal(const MyClass ) {
 return V.A;
   }
 
@@ -51,6 +56,7 @@
 
   constexpr static int addInt(MyClass , int A) {
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'addInt' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+  // CHECK-FIXES:   LIBC_INLINE constexpr static int addInt(MyClass , int A) {
 return V.A += A;
   }
 
@@ -78,6 +84,7 @@
 
 inline void badSimpleFunction() {}
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: 'badSimpleFunction' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+// CHECK-FIXES: LIBC_INLINE inline void badSimpleFunction() {}
 
 void LIBC_INLINE badSimpleFunctionWrongLocation() {}
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: 'badSimpleFunctionWrongLocation' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
@@ -93,6 +100,7 @@
 
 template  inline void badTemplateFunction() {}
 // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: 'badTemplateFunction' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+// CHECK-FIXES: template  LIBC_INLINE inline void badTemplateFunction() {}
 
 template  void LIBC_INLINE badTemplateFunctionWrongLocation() {}
 // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: 'badTemplateFunctionWrongLocation' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
@@ -108,9 +116,11 @@
 
 template  inline void badVariadicFunction() {}
 // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: 'badVariadicFunction' must be tagged with the LIBC_INLINE macro; the macro should be placed at the beginning of the declaration [llvmlibc-inline-function-decl]
+// CHECK-FIXES: 

[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

2023-08-04 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D156928#4562239 , @JonChesterfield 
wrote:

> Or, the front end could define those objects directly, without importing IR 
> files that define the objects with the content clang used to choose the 
> object file. E.g. instead of the argument daz=off (spelled differently) 
> finding a file called daz.off.ll that defines variable called daz with a 
> value 0, that argument could define that variable. I think @jhuber6 has a 
> partial patch trying to do that.
>
> If we were more ambitious, we could use intrinsics that are folded reliably 
> at O0 instead of magic variables that hopefully get constant folded. That 
> would kill a bunch of O0 bugs.
>
> In general though, splicing magic variables in the front end seems unlikely 
> to be performance critical relative to splicing them in at the start of the 
> backend.

Some control variables are per-module. Clang cannot emit control variables that 
have different values for different modules. Intrinsics should work since it 
can take an argument as its value.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928

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


[clang] 606b77d - Fix test hip-runtime-libs-msvc.hip

2023-08-04 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2023-08-04T19:54:37-04:00
New Revision: 606b77d82d95b723fdf965e772af507d4099289d

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

LOG: Fix test hip-runtime-libs-msvc.hip

Fix failure at https://lab.llvm.org/buildbot/#/builders/216/builds/25114

due to missing ROCm

Added: 


Modified: 
clang/test/Driver/hip-runtime-libs-msvc.hip

Removed: 




diff  --git a/clang/test/Driver/hip-runtime-libs-msvc.hip 
b/clang/test/Driver/hip-runtime-libs-msvc.hip
index 34a7d36919c3b5..8085e77d457e56 100644
--- a/clang/test/Driver/hip-runtime-libs-msvc.hip
+++ b/clang/test/Driver/hip-runtime-libs-msvc.hip
@@ -8,7 +8,7 @@
 // RUN:   | FileCheck %s
 
 // Test HIP runtime lib is linked without --hip-link when there is HIP input 
file.
-// RUN: %clang -### --target=x86_64-pc-windows-msvc \
+// RUN: %clang -### --target=x86_64-pc-windows-msvc -nogpuinc -nogpulib \
 // RUN:   --rocm-path=%S/Inputs/rocm %s 2>&1 \
 // RUN:   | FileCheck %s
 



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


[PATCH] D156762: [-Wunsafe-buffer-usage][NFC] Refactor `getFixIts`---where fix-its are generated

2023-08-04 Thread Ziqing Luo via Phabricator via cfe-commits
ziqingluo-90 updated this revision to Diff 547405.
ziqingluo-90 marked 6 inline comments as done.
ziqingluo-90 added a comment.

Address comments.


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

https://reviews.llvm.org/D156762

Files:
  clang/lib/Analysis/UnsafeBufferUsage.cpp

Index: clang/lib/Analysis/UnsafeBufferUsage.cpp
===
--- clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -2142,16 +2142,30 @@
   });
 }
 
-static bool impossibleToFixForVar(const FixableGadgetSets ,
-  const Strategy ,
-  const VarDecl * Var) {
-  for (const auto  : FixablesForAllVars.byVar.find(Var)->second) {
-std::optional Fixits = F->getFixits(S);
-if (!Fixits) {
-  return true;
+// Erases variables in `FixItsForVariable`, if such a variable has an unfixable
+// group mate.  A variable `v` is unfixable iff `FixItsForVariable` does not
+// contain `v`.
+static void eraseVarsForUnfixableGroupMates(
+std::map ,
+const VariableGroupsManager ) {
+  // Variables will be removed from `FixItsForVariable`:
+  SmallVector ToErase;
+
+  for (auto [VD, Ignore] : FixItsForVariable) {
+VarGrpRef Grp = VarGrpMgr.getGroupOfVar(VD);
+if (llvm::any_of(Grp,
+ [](const VarDecl *GrpMember) -> bool {
+   return FixItsForVariable.find(GrpMember) ==
+  FixItsForVariable.end();
+ })) {
+  // At least one group member cannot be fixed, so we have to erase the
+  // whole group:
+  for (const VarDecl *Member : Grp)
+ToErase.push_back(Member);
 }
   }
-  return false;
+  for (auto *VarToErase : ToErase)
+FixItsForVariable.erase(VarToErase);
 }
 
 static std::map
@@ -2160,7 +2174,14 @@
   /* The function decl under analysis */ const Decl *D,
   const DeclUseTracker , UnsafeBufferUsageHandler ,
   const VariableGroupsManager ) {
+  // `FixItsForVariable` will map each variable to a set of fix-its directly
+  // associated to the variable itself.  Fix-its of distinct variables in
+  // `FixItsForVariable` are disjoint.
   std::map FixItsForVariable;
+
+  // Populate `FixItsForVariable` with fix-its directly associated with each
+  // variable.  Fix-its directly associated to a variable 'v' are the ones
+  // produced by the `FixableGadget`s whose claimed variable is 'v'.
   for (const auto &[VD, Fixables] : FixablesForAllVars.byVar) {
 FixItsForVariable[VD] =
 fixVariable(VD, S.lookup(VD), D, Tracker, Ctx, Handler);
@@ -2170,64 +2191,36 @@
   FixItsForVariable.erase(VD);
   continue;
 }
-bool ImpossibleToFix = false;
-llvm::SmallVector FixItsForVD;
 for (const auto  : Fixables) {
   std::optional Fixits = F->getFixits(S);
-  if (!Fixits) {
-#ifndef NDEBUG
-Handler.addDebugNoteForVar(
-VD, F->getBaseStmt()->getBeginLoc(),
-("gadget '" + F->getDebugName() + "' refused to produce a fix")
-.str());
-#endif
-ImpossibleToFix = true;
-break;
-  } else {
-const FixItList CorrectFixes = Fixits.value();
-FixItsForVD.insert(FixItsForVD.end(), CorrectFixes.begin(),
-   CorrectFixes.end());
-  }
-}
 
-if (ImpossibleToFix) {
-  FixItsForVariable.erase(VD);
-  continue;
-}
-
-
-   {
-  const auto VarGroupForVD = VarGrpMgr.getGroupOfVar(VD);
-  for (const VarDecl * V : VarGroupForVD) {
-if (V == VD) {
-  continue;
-}
-if (impossibleToFixForVar(FixablesForAllVars, S, V)) {
-  ImpossibleToFix = true;
-  break;
-}
-  }
-
-  if (ImpossibleToFix) {
-FixItsForVariable.erase(VD);
-for (const VarDecl * V : VarGroupForVD) {
-  FixItsForVariable.erase(V);
-}
+  if (Fixits) {
+FixItsForVariable[VD].insert(FixItsForVariable[VD].end(),
+ Fixits->begin(), Fixits->end());
 continue;
   }
-}
-FixItsForVariable[VD].insert(FixItsForVariable[VD].end(),
- FixItsForVD.begin(), FixItsForVD.end());
-
-// Fix-it shall not overlap with macros or/and templates:
-if (overlapWithMacro(FixItsForVariable[VD]) ||
-clang::internal::anyConflict(FixItsForVariable[VD],
- Ctx.getSourceManager())) {
+#ifndef NDEBUG
+  Handler.addDebugNoteForVar(
+  VD, F->getBaseStmt()->getBeginLoc(),
+  ("gadget '" + F->getDebugName() + "' refused to produce a fix")
+  .str());
+#endif  
   FixItsForVariable.erase(VD);
-  continue;
+  break;
 }
   }
 
+  // `FixItsForVariable` now contains only variables that can be
+  // fixed. A variable can be fixed if its' declaration and all Fixables
+  // 

[PATCH] D153071: [clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

2023-08-04 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9824ec875cec: [clang][dataflow] Refactor `DataflowWorklist` 
types and add a WTO version. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153071

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
  clang/unittests/Analysis/CFGTest.cpp

Index: clang/unittests/Analysis/CFGTest.cpp
===
--- clang/unittests/Analysis/CFGTest.cpp
+++ clang/unittests/Analysis/CFGTest.cpp
@@ -6,13 +6,15 @@
 //
 //===--===//
 
+#include "clang/Analysis/CFG.h"
 #include "CFGBuildResult.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Analysis/Analyses/IntervalPartition.h"
 #include "clang/Analysis/AnalysisDeclContext.h"
-#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowWorklist.h"
 #include "clang/Tooling/Tooling.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 #include 
@@ -244,6 +246,8 @@
 TEST(CFG, Worklists) {
   const char *Code = "int f(bool cond) {\n"
  "  int a = 5;\n"
+ "  while (a < 6)\n"
+ "++a;\n"
  "  if (cond)\n"
  "a += 1;\n"
  "  return a;\n"
@@ -272,6 +276,30 @@
ForwardNodes.begin()));
   }
 
+  // RPO: 876321054
+  // WTO: 876534210
+  // So, we construct the WTO order accordingly from the reference order.
+  std::vector WTOOrder = {
+  ReferenceOrder[0], ReferenceOrder[1], ReferenceOrder[2],
+  ReferenceOrder[7], ReferenceOrder[3], ReferenceOrder[8],
+  ReferenceOrder[4], ReferenceOrder[5], ReferenceOrder[6]};
+
+  {
+using ::testing::ElementsAreArray;
+std::optional WTO = getIntervalWTO(*CFG);
+ASSERT_TRUE(WTO);
+WTOCompare WCmp(*WTO);
+WTODataflowWorklist WTOWorklist(*CFG, WCmp);
+for (const auto *B : *CFG)
+  WTOWorklist.enqueueBlock(B);
+
+std::vector WTONodes;
+while (const CFGBlock *B = WTOWorklist.dequeue())
+  WTONodes.push_back(B);
+
+EXPECT_THAT(WTONodes, ElementsAreArray(WTOOrder));
+  }
+
   std::reverse(ReferenceOrder.begin(), ReferenceOrder.end());
 
   {
Index: clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
@@ -12,6 +12,7 @@
 #ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWWORKLIST_H
 #define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWWORKLIST_H
 
+#include "clang/Analysis/Analyses/IntervalPartition.h"
 #include "clang/Analysis/Analyses/PostOrderCFGView.h"
 #include "clang/Analysis/CFG.h"
 #include "llvm/ADT/PriorityQueue.h"
@@ -21,16 +22,13 @@
 /// on the order defined by 'Comp'.
 template  class DataflowWorklistBase {
   llvm::BitVector EnqueuedBlocks;
-  PostOrderCFGView *POV;
   llvm::PriorityQueue, Comp>
   WorkList;
 
 public:
-  DataflowWorklistBase(const CFG , PostOrderCFGView *POV, Comp C)
-  : EnqueuedBlocks(Cfg.getNumBlockIDs()), POV(POV), WorkList(C) {}
-
-  const PostOrderCFGView *getCFGView() const { return POV; }
+  DataflowWorklistBase(const CFG , Comp C)
+  : EnqueuedBlocks(Cfg.getNumBlockIDs()), WorkList(C) {}
 
   void enqueueBlock(const CFGBlock *Block) {
 if (Block && !EnqueuedBlocks[Block->getBlockID()]) {
@@ -62,7 +60,7 @@
 struct ForwardDataflowWorklist
 : DataflowWorklistBase {
   ForwardDataflowWorklist(const CFG , PostOrderCFGView *POV)
-  : DataflowWorklistBase(Cfg, POV,
+  : DataflowWorklistBase(Cfg,
  ReversePostOrderCompare{POV->getComparator()}) {}
 
   ForwardDataflowWorklist(const CFG , AnalysisDeclContext )
@@ -74,6 +72,19 @@
   }
 };
 
+/// A worklist implementation for forward dataflow analysis based on a weak
+/// topological ordering of the nodes. The worklist cannot contain the same
+/// block multiple times at once.
+struct WTODataflowWorklist : DataflowWorklistBase {
+  WTODataflowWorklist(const CFG , const WTOCompare )
+  : DataflowWorklistBase(Cfg, Cmp) {}
+
+  void enqueueSuccessors(const CFGBlock *Block) {
+for (auto B : Block->succs())
+  enqueueBlock(B);
+  }
+};
+
 /// A worklist implementation for backward dataflow analysis. The enqueued
 /// block will be dequeued in post order. The worklist cannot contain the same
 /// block multiple times at once.
@@ -81,8 +92,7 @@
 : DataflowWorklistBase {
   BackwardDataflowWorklist(const CFG , AnalysisDeclContext )
   : DataflowWorklistBase(
-Cfg, Ctx.getAnalysis(),
-Ctx.getAnalysis()->getComparator()) {}
+Cfg, 

[clang] 9824ec8 - [clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

2023-08-04 Thread Yitzhak Mandelbaum via cfe-commits

Author: Yitzhak Mandelbaum
Date: 2023-08-04T23:29:08Z
New Revision: 9824ec875cecc533d55c1f11c0c0440520c34464

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

LOG: [clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

Removes dependency of the DataflowWorklistBase type on the PostOrderCFGView. The
base had no particular connection to this order -- looks like it was included as
a convenience to the two derived classes rather than because it belonged there
conceptually. Removing it cleans up the base class a bit and makes it suitable
to extension with the new WTODataflowWorklist class.

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

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
clang/unittests/Analysis/CFGTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
index e926adf6f0b2a9..f1d05743bf7f12 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
@@ -12,6 +12,7 @@
 #ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWWORKLIST_H
 #define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWWORKLIST_H
 
+#include "clang/Analysis/Analyses/IntervalPartition.h"
 #include "clang/Analysis/Analyses/PostOrderCFGView.h"
 #include "clang/Analysis/CFG.h"
 #include "llvm/ADT/PriorityQueue.h"
@@ -21,16 +22,13 @@ namespace clang {
 /// on the order defined by 'Comp'.
 template  class DataflowWorklistBase {
   llvm::BitVector EnqueuedBlocks;
-  PostOrderCFGView *POV;
   llvm::PriorityQueue, Comp>
   WorkList;
 
 public:
-  DataflowWorklistBase(const CFG , PostOrderCFGView *POV, Comp C)
-  : EnqueuedBlocks(Cfg.getNumBlockIDs()), POV(POV), WorkList(C) {}
-
-  const PostOrderCFGView *getCFGView() const { return POV; }
+  DataflowWorklistBase(const CFG , Comp C)
+  : EnqueuedBlocks(Cfg.getNumBlockIDs()), WorkList(C) {}
 
   void enqueueBlock(const CFGBlock *Block) {
 if (Block && !EnqueuedBlocks[Block->getBlockID()]) {
@@ -62,7 +60,7 @@ struct ReversePostOrderCompare {
 struct ForwardDataflowWorklist
 : DataflowWorklistBase {
   ForwardDataflowWorklist(const CFG , PostOrderCFGView *POV)
-  : DataflowWorklistBase(Cfg, POV,
+  : DataflowWorklistBase(Cfg,
  ReversePostOrderCompare{POV->getComparator()}) {}
 
   ForwardDataflowWorklist(const CFG , AnalysisDeclContext )
@@ -74,6 +72,19 @@ struct ForwardDataflowWorklist
   }
 };
 
+/// A worklist implementation for forward dataflow analysis based on a weak
+/// topological ordering of the nodes. The worklist cannot contain the same
+/// block multiple times at once.
+struct WTODataflowWorklist : DataflowWorklistBase {
+  WTODataflowWorklist(const CFG , const WTOCompare )
+  : DataflowWorklistBase(Cfg, Cmp) {}
+
+  void enqueueSuccessors(const CFGBlock *Block) {
+for (auto B : Block->succs())
+  enqueueBlock(B);
+  }
+};
+
 /// A worklist implementation for backward dataflow analysis. The enqueued
 /// block will be dequeued in post order. The worklist cannot contain the same
 /// block multiple times at once.
@@ -81,8 +92,7 @@ struct BackwardDataflowWorklist
 : DataflowWorklistBase {
   BackwardDataflowWorklist(const CFG , AnalysisDeclContext )
   : DataflowWorklistBase(
-Cfg, Ctx.getAnalysis(),
-Ctx.getAnalysis()->getComparator()) {}
+Cfg, Ctx.getAnalysis()->getComparator()) {}
 
   void enqueuePredecessors(const CFGBlock *Block) {
 for (auto B : Block->preds())

diff  --git a/clang/unittests/Analysis/CFGTest.cpp 
b/clang/unittests/Analysis/CFGTest.cpp
index 7ce35e3fe4a4f4..9fa034a0e472e9 100644
--- a/clang/unittests/Analysis/CFGTest.cpp
+++ b/clang/unittests/Analysis/CFGTest.cpp
@@ -6,13 +6,15 @@
 //
 
//===--===//
 
+#include "clang/Analysis/CFG.h"
 #include "CFGBuildResult.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Analysis/Analyses/IntervalPartition.h"
 #include "clang/Analysis/AnalysisDeclContext.h"
-#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowWorklist.h"
 #include "clang/Tooling/Tooling.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 #include 
@@ -244,6 +246,8 @@ TEST(CFG, ElementRefIterator) {
 TEST(CFG, Worklists) {
   const char *Code = "int f(bool cond) {\n"
  "  int a = 5;\n"
+ "  while (a < 6)\n"
+ "++a;\n"
  "  if (cond)\n"
  "a += 1;\n"
  "  return a;\n"
@@ -272,6 +276,30 

[PATCH] D157157: [clang] Add clang support for Machine Function Splitting on AArch64

2023-08-04 Thread Daniel Hoekwater via Phabricator via cfe-commits
dhoekwater created this revision.
dhoekwater added reviewers: shenhan, xur, snehasish, wenlei, mingmingl.
Herald added subscribers: pengfei, kristof.beyls.
Herald added a project: All.
dhoekwater requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

On x86 targets, -fsplit-machine-functions enables splitting of machine
functions using profile information. This patch rolls out the flag for
AArch64 targets.

Depends on D157124  and D157127 



Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157157

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/fsplit-machine-functions.c


Index: clang/test/Driver/fsplit-machine-functions.c
===
--- clang/test/Driver/fsplit-machine-functions.c
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -1,8 +1,10 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | 
FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck 
-check-prefix=CHECK-NOOPT %s
+// RUN: %clang -### -target aarch64-unknown-linux 
-fprofile-use=default.profdata -fsplit-machine-functions %s -c 2>&1 | FileCheck 
-check-prefix=CHECK-AARCH64 %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 
2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
+// CHECK-AARCH64:   "-fsplit-machine-functions"
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for 
target
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5859,8 +5859,8 @@
 
   if (Arg *A = Args.getLastArg(options::OPT_fsplit_machine_functions,
options::OPT_fno_split_machine_functions)) {
-// This codegen pass is only available on x86-elf targets.
-if (Triple.isX86() && Triple.isOSBinFormatELF()) {
+// This codegen pass is only available on x86 and Arm ELF targets.
+if ((Triple.isX86() || Triple.isAArch64()) && Triple.isOSBinFormatELF()) {
   if (A->getOption().matches(options::OPT_fsplit_machine_functions))
 A->render(Args, CmdArgs);
 } else {


Index: clang/test/Driver/fsplit-machine-functions.c
===
--- clang/test/Driver/fsplit-machine-functions.c
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -1,8 +1,10 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata -fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// RUN: %clang -### -target aarch64-unknown-linux -fprofile-use=default.profdata -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-AARCH64 %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
+// CHECK-AARCH64:   "-fsplit-machine-functions"
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for target
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5859,8 +5859,8 @@
 
   if (Arg *A = Args.getLastArg(options::OPT_fsplit_machine_functions,
options::OPT_fno_split_machine_functions)) {
-// This codegen pass is only available on x86-elf targets.
-if (Triple.isX86() && Triple.isOSBinFormatELF()) {
+// This codegen pass is only available on x86 and Arm ELF targets.
+if ((Triple.isX86() || Triple.isAArch64()) && Triple.isOSBinFormatELF()) {
   if (A->getOption().matches(options::OPT_fsplit_machine_functions))
 A->render(Args, CmdArgs);
 } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D157066: [clang][modules][deps] Create more efficient API for visitation of `ModuleFile` inputs

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/lib/Serialization/ASTReader.cpp:2411
   bool Transient = FI.Transient;
-  StringRef Filename = FI.Filename;
+  StringRef Filename = FI.FilenameAsRequested;
   uint64_t StoredContentHash = FI.ContentHash;

jansvoboda11 wrote:
> benlangmuir wrote:
> > It's not clear to me why this one changed
> This actually maintains the same semantics - `FI.Filename` was previously the 
> as-requested path, now it's the on-disk path. Without changing this line, 
> `FileManager::getFileRef()` would get called with the on-disk path, meaning 
> consumers of this function would get the incorrect path when calling 
> `FileEntryRef::getNameAsRequested()` on the returned file. I recall one 
> clang-scan-deps test failing because of it.
Just remembered: in `ModuleDepCollector.cpp`, we call 
`ModuleMap::getModuleMapFileForUniquing()`. This calls 
`SourceMgr.getFileEntryRefForID()` based on `Module::DefinitionLoc`, which 
triggers deserialization of the associated source location entry and ends up 
calling this function right here. We'd end up with the on-disk module map path 
for modular dependencies.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157066

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


[PATCH] D157076: [clang][ExtractAPI] Add support for C++ class templates and concepts

2023-08-04 Thread Erick Velez via Phabricator via cfe-commits
evelez7 updated this revision to Diff 547389.
evelez7 added a comment.

Abstract the name deduction for generic template args to its own function. It's 
very helpful in other cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157076

Files:
  clang/include/clang/ExtractAPI/API.h
  clang/include/clang/ExtractAPI/DeclarationFragments.h
  clang/include/clang/ExtractAPI/ExtractAPIVisitor.h
  clang/include/clang/ExtractAPI/Serialization/SerializerBase.h
  clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h
  clang/lib/ExtractAPI/API.cpp
  clang/lib/ExtractAPI/DeclarationFragments.cpp
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
  clang/test/ExtractAPI/class_template.cpp
  clang/test/ExtractAPI/class_template_partial_spec.cpp
  clang/test/ExtractAPI/class_template_spec.cpp
  clang/test/ExtractAPI/concept.cpp

Index: clang/test/ExtractAPI/concept.cpp
===
--- /dev/null
+++ clang/test/ExtractAPI/concept.cpp
@@ -0,0 +1,133 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
+// RUN: %clang_cc1 -std=c++20 -extract-api -triple arm64-apple-macosx \
+// RUN:   -x c++-header %t/input.h -o %t/output.json -verify
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+//--- input.h
+template concept Foo = true;
+
+/// expected-no-diagnostics
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {
+  "major": 0,
+  "minor": 5,
+  "patch": 3
+},
+"generator": "?"
+  },
+  "module": {
+"name": "",
+"platform": {
+  "architecture": "arm64",
+  "operatingSystem": {
+"minimumVersion": {
+  "major": 11,
+  "minor": 0,
+  "patch": 0
+},
+"name": "macosx"
+  },
+  "vendor": "apple"
+}
+  },
+  "relationships": [],
+  "symbols": [
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "keyword",
+  "spelling": "template"
+},
+{
+  "kind": "text",
+  "spelling": "<"
+},
+{
+  "kind": "keyword",
+  "spelling": "typename"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "genericParameter",
+  "spelling": "T"
+},
+{
+  "kind": "text",
+  "spelling": "> "
+},
+{
+  "kind": "keyword",
+  "spelling": "concept"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "Foo"
+},
+{
+  "kind": "text",
+  "spelling": ";"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c++",
+"precise": "c:@CT@Foo"
+  },
+  "kind": {
+"displayName": "Concept",
+"identifier": "c++.concept"
+  },
+  "location": {
+"position": {
+  "character": 30,
+  "line": 1
+},
+"uri": "file://INPUT_DIR/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "Foo"
+  }
+],
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "Foo"
+  }
+],
+"title": "Foo"
+  },
+  "pathComponents": [
+"Foo"
+  ],
+  "swiftGenerics": {
+"parameters": [
+  {
+"depth": 0,
+"index": 0,
+"name": "T"
+  }
+]
+  }
+}
+  ]
+}
Index: clang/test/ExtractAPI/class_template_spec.cpp
===
--- /dev/null
+++ clang/test/ExtractAPI/class_template_spec.cpp
@@ -0,0 +1,206 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
+// RUN: %clang_cc1 -extract-api -triple arm64-apple-macosx \
+// RUN:   -x c++-header %t/input.h -o %t/output.json -verify
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+//--- input.h
+template class Foo {};
+
+template<> class Foo {};
+
+/// expected-no-diagnostics
+
+//--- reference.output.json.in
+{
+  "metadata": {
+

[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

2023-08-04 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Or, the front end could define those objects directly, without importing IR 
files that define the objects with the content clang used to choose the object 
file. E.g. instead of the argument daz=off (spelled differently) finding a file 
called daz.off.ll that defines variable called daz with a value 0, that 
argument could define that variable. I think @jhuber6 has a partial patch 
trying to do that.

If we were more ambitious, we could use intrinsics that are folded reliably at 
O0 instead of magic variables that hopefully get constant folded. That would 
kill a bunch of O0 bugs.

In general though, splicing magic variables in the front end seems unlikely to 
be performance critical relative to splicing them in at the start of the 
backend.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928

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


[PATCH] D157150: [Driver] Update BoolOption to handle Visibility. NFC

2023-08-04 Thread Justin Bogner via Phabricator via cfe-commits
bogner created this revision.
bogner added a reviewer: MaskRay.
Herald added a subscriber: mcrosier.
Herald added a reviewer: sscalpone.
Herald added a project: All.
bogner requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This updates the BoolOption family of option definitions to do the
right thing with llvm::opt::Visibility. Since the only meaningful
visibility at this point is llvm::opt::Default, we update PosFlag,
NegFlag, and BothFlags definitions to now specify Default.

The updates to option definitions were done with the following three
sed scripts (one to update Pos/NegFlag, one for BothFlags, and one
that just cleans up whitespace a little):

  sed -E 's/((Pos|Neg)Flag<[A-Za-z]*, \[[^]]*\])(, "|>|,$)/\1, [Default]\3/g'
  sed -E 's/(BothFlags<\[[^]]*\])(, ")/\1, [Default], "/'
  sed -E 's/( *)((Pos|Neg)Flag<.*), ((Pos|Neg)Flag)/\1\2,\n\1\4/'

These are idempotent and should be runnable on downstream versions of
Options.td if needed to update any additional flags that are present.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157150

Files:
  clang/include/clang/Driver/Options.td

Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -381,7 +381,8 @@
 
 // Definition of single command line flag. This is an implementation detail, use
 // SetTrueBy or SetFalseBy instead.
-class FlagDef option_flags,
+class FlagDef option_flags, list option_vis,
   string help, list implied_by_expressions = []> {
   // The polarity. Besides spelling, this also decides whether the TableGen
   // record will be prefixed with "no_".
@@ -390,9 +391,12 @@
   // The value assigned to key path when the flag is present on command line.
   bit Value = value;
 
-  // OptionFlags that control visibility of the flag in different tools.
+  // OptionFlags in different tools.
   list OptionFlags = option_flags;
 
+  // OptionVisibility flags for different tools.
+  list OptionVis = option_vis;
+
   // The help text associated with the flag.
   string Help = help;
 
@@ -401,8 +405,11 @@
 }
 
 // Additional information to be appended to both positive and negative flag.
-class BothFlags option_flags, string help = ""> {
+class BothFlags option_flags,
+list option_vis = [Default],
+string help = ""> {
   list OptionFlags = option_flags;
+  list OptionVis = option_vis;
   string Help = help;
 }
 
@@ -411,23 +418,26 @@
   FlagDef Result
 = FlagDef;
 }
 
 // Definition of the command line flag with positive spelling, e.g. "-ffoo".
-class PosFlag flags = [], string help = "",
-  list implied_by_expressions = []>
-  : FlagDef {}
+class PosFlag flags = [], list vis = [],
+  string help = "", list implied_by_expressions = []>
+  : FlagDef {}
 
 // Definition of the command line flag with negative spelling, e.g. "-fno-foo".
-class NegFlag flags = [], string help = "",
-  list implied_by_expressions = []>
-  : FlagDef {}
+class NegFlag flags = [], list vis = [],
+  string help = "", list implied_by_expressions = []>
+  : FlagDef {}
 
 // Expanded FlagDef that's convenient for creation of TableGen records.
 class FlagDefExpanded
-  : FlagDef {
+  : FlagDef {
   // Name of the TableGen record.
   string RecordName = prefix # !if(flag.Polarity, "", "no_") # name;
 
@@ -445,7 +455,8 @@
 class MarshalledFlagRec
-  : Flag<["-"], flag.Spelling>, Flags, HelpText,
+  : Flag<["-"], flag.Spelling>, Flags, Vis,
+HelpText,
 MarshallingInfoBooleanFlag,
 ImpliedByAnyOf {}
@@ -459,7 +470,7 @@
 multiclass BoolOption> {
+  BothFlags suffix = BothFlags<[]>> {
   defvar flag1 = FlagDefExpanded.Result, prefix,
  NAME, spelling_base>;
 
@@ -490,7 +501,7 @@
 /// CompilerInvocation.
 multiclass BoolFOption> {
+   BothFlags both = BothFlags<[]>> {
   defm NAME : BoolOption<"f", flag_base, kpm, default, flag1, flag2, both>,
   Group;
 }
@@ -501,7 +512,7 @@
 // CompilerInvocation.
 multiclass BoolGOption> {
+   BothFlags both = BothFlags<[]>> {
   defm NAME : BoolOption<"g", flag_base, kpm, default, flag1, flag2, both>,
   Group;
 }
@@ -509,7 +520,7 @@
 // Works like BoolOption except without marshalling
 multiclass BoolOptionWithoutMarshalling> {
+BothFlags suffix = BothFlags<[]>> {
   defvar flag1 = FlagDefExpanded.Result, prefix,
  NAME, spelling_base>;
 
@@ -531,11 +542,11 @@
   defvar implied = !if(flag1.CanBeImplied, flag1, flag2);
 
   def flag1.RecordName : Flag<["-"], flag1.Spelling>, Flags,
- HelpText,
+ Vis, HelpText,
  ImpliedByAnyOf
  {}
   def 

[PATCH] D157149: [Option] Add "Visibility" field and clone the OptTable APIs to use it

2023-08-04 Thread Justin Bogner via Phabricator via cfe-commits
bogner created this revision.
bogner added a reviewer: MaskRay.
Herald added subscribers: pmatos, asb, ormris, kadircet, arphaman, steven_wu, 
hiraditya, sbc100, mcrosier.
Herald added a reviewer: JDevlieghere.
Herald added a reviewer: alexander-shaposhnikov.
Herald added a reviewer: jhenderson.
Herald added projects: lld-macho, All.
Herald added a reviewer: lld-macho.
bogner requested review of this revision.
Herald added subscribers: cfe-commits, llvm-commits, wangpc, aheejin.
Herald added projects: clang, LLVM, clang-tools-extra.

This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.

We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.

Instead, we'll provide an additive model for visibility that's
separate from the other flags, and have the only "subtractive"
visibility flag be "HelpHidden", which can be handled as a special
case.

Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157149

Files:
  clang-tools-extra/clangd/CompileCommands.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  lld/MachO/DriverUtils.cpp
  lld/MinGW/Driver.cpp
  lld/wasm/Driver.cpp
  llvm/include/llvm/Option/OptParser.td
  llvm/include/llvm/Option/OptTable.h
  llvm/include/llvm/Option/Option.h
  llvm/lib/ExecutionEngine/JITLink/COFFDirectiveParser.cpp
  llvm/lib/Option/OptTable.cpp
  llvm/lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
  llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp
  llvm/tools/dsymutil/dsymutil.cpp
  llvm/tools/llvm-cvtres/llvm-cvtres.cpp
  llvm/tools/llvm-cxxfilt/llvm-cxxfilt.cpp
  llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp
  llvm/tools/llvm-dwarfutil/llvm-dwarfutil.cpp
  llvm/tools/llvm-dwp/llvm-dwp.cpp
  llvm/tools/llvm-lipo/llvm-lipo.cpp
  llvm/tools/llvm-mt/llvm-mt.cpp
  llvm/tools/llvm-objcopy/ObjcopyOptions.cpp
  llvm/tools/llvm-rc/llvm-rc.cpp
  llvm/tools/llvm-strings/llvm-strings.cpp
  llvm/tools/llvm-symbolizer/llvm-symbolizer.cpp
  llvm/tools/llvm-tli-checker/llvm-tli-checker.cpp
  llvm/unittests/Option/OptionMarshallingTest.cpp
  llvm/unittests/Option/OptionParsingTest.cpp
  llvm/unittests/Option/Opts.td
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -320,7 +320,7 @@
   OS << "INVALID";
 
 // The other option arguments (unused for groups).
-OS << ", INVALID, nullptr, 0, 0";
+OS << ", INVALID, nullptr, 0, 0, 0";
 
 // The option help text.
 if (!isa(R.getValueInit("HelpText"))) {
@@ -358,8 +358,10 @@
 // The containing option group (if any).
 OS << ", ";
 const ListInit *GroupFlags = nullptr;
+const ListInit *GroupVis = nullptr;
 if (const DefInit *DI = dyn_cast(R.getValueInit("Group"))) {
   GroupFlags = DI->getDef()->getValueAsListInit("Flags");
+  GroupVis = DI->getDef()->getValueAsListInit("Vis");
   OS << getOptionName(*DI->getDef());
 } else
   OS << "INVALID";
@@ -400,6 +402,21 @@
 if (NumFlags == 0)
   OS << '0';
 
+// The option visibility flags.
+OS << ", ";
+int NumVisFlags = 0;
+LI = R.getValueAsListInit("Vis");
+for (Init *I : *LI)
+  OS << (NumVisFlags++ ? " | " : "")
+ << cast(I)->getDef()->getName();
+if (GroupVis) {
+  for (Init *I : *GroupVis)
+OS << (NumVisFlags++ ? " | " : "")
+   << cast(I)->getDef()->getName();
+}
+if (NumVisFlags == 0)
+  OS << '0';
+
 // The option parameter field.
 OS << ", " << R.getValueAsInt("NumArgs");
 
Index: llvm/unittests/Option/Opts.td
===
--- llvm/unittests/Option/Opts.td
+++ llvm/unittests/Option/Opts.td
@@ -4,6 +4,8 @@
 def OptFlag2 : OptionFlag;
 def OptFlag3 : OptionFlag;
 
+def SubtoolVis : OptionVisibility;
+
 def A : Flag<["-"], "A">, HelpText<"The A option">, Flags<[OptFlag1]>;
 def AB : Flag<["-"], "AB">;
 def B : Joined<["-"], "B">, HelpText<"The B option">, MetaVarName<"B">, Flags<[OptFlag2]>;
@@ -35,6 +37,8 @@
 def Cramb : Joined<["/"], "cramb:">, HelpText<"The cramb option">, MetaVarName<"CRAMB">, Flags<[OptFlag1]>;
 def Doopf1 : Flag<["-"], "doopf1">, HelpText<"The doopf1 option">, 

[PATCH] D151567: [LLVM][Support] Report EISDIR when opening a directory on AIX

2023-08-04 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added a comment.

I believe the unit tests should be updated to ensure that we get `EISDIR` when 
opening directories for reading and for writing: 
`llvm/unittests/Support/Path.cpp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151567

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


[PATCH] D151567: [LLVM][Support] Report EISDIR when opening a directory on AIX

2023-08-04 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added inline comments.



Comment at: llvm/lib/Support/Unix/Path.inc:1020
+struct stat Status;
+if (stat(P.begin(), ) == -1) 
+  return std::error_code(errno, std::generic_category());

Please try using `fstat` on the result of `open` to address the comments from 
https://reviews.llvm.org/D156798.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151567

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


[PATCH] D157066: [clang][modules][deps] Create more efficient API for visitation of `ModuleFile` inputs

2023-08-04 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir accepted this revision.
benlangmuir added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/include/clang/Serialization/ModuleFile.h:72
+  bool TopLevel;
+  bool ModuleMap;
 };

jansvoboda11 wrote:
> benlangmuir wrote:
> > Is there something using this new split? It seems like every user is using 
> > `&&` for these
> You're right. I recall needing this on (now probably abandoned) patch, so I 
> thought I might as well add the extra bit now, sine I'm changing the format 
> anyways. I'm fine with removing this.
It's fine, I was just making sure I didn't miss something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157066

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


[PATCH] D153071: [clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

2023-08-04 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

In D153071#4561993 , @xazax.hun wrote:

> Mea culpa. Looks like I did not anticipate non-RPO worklists. Thanks for 
> cleaning this up, looks good to me!

Thanks! Not anticipating the future is pretty standard, no need to apologize. ;)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153071

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


[PATCH] D156426: [HIP] link HIP runtime library without --hip-link

2023-08-04 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Closed by commit rG932c63550ad5: [HIP] link HIP runtime library without 
--hip-link (authored by yaxunl).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D156426?vs=544750=547372#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156426

Files:
  clang/docs/HIPSupport.rst
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/Driver/hip-runtime-libs-linux.hip
  clang/test/Driver/hip-runtime-libs-msvc.hip
  clang/test/Driver/rocm-detect.hip

Index: clang/test/Driver/rocm-detect.hip
===
--- clang/test/Driver/rocm-detect.hip
+++ clang/test/Driver/rocm-detect.hip
@@ -35,32 +35,32 @@
 
 // Test HIP_PATH overrides ROCM_PATH.
 // RUN: env ROCM_PATH=%S/Inputs/rocm HIP_PATH=%t/myhip \
-// RUN:   %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 --hip-link \
+// RUN:   %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 \
 // RUN:   --print-rocm-search-dirs %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=ROCM-ENV,HIP-PATH %s
 
 // Test --hip-path overrides ROCM_PATH.
 // RUN: env ROCM_PATH=%S/Inputs/rocm \
-// RUN:   %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 --hip-link \
+// RUN:   %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 \
 // RUN:   --hip-path=%t/myhip \
 // RUN:   --print-rocm-search-dirs %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=ROCM-ENV,HIP-PATH %s
 
 // Test --hip-path overrides --rocm-path.
-// RUN: %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 --hip-link \
+// RUN: %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 \
 // RUN:   --hip-path=%t/myhip --rocm-path=%S/Inputs/rocm \
 // RUN:   --print-rocm-search-dirs %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=ROCM-ENV,HIP-PATH %s
 
 // Test HIP_PATH overrides --rocm-path.
-// RUN: env HIP_PATH=%t/myhip %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 --hip-link \
+// RUN: env HIP_PATH=%t/myhip %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   --print-rocm-search-dirs %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=ROCM-ENV,HIP-PATH %s
 
 // Test empty HIP_PATH does not override --rocm-path.
 // RUN: env HIP_PATH= \
-// RUN:   %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 --hip-link \
+// RUN:   %clang -### -target x86_64-linux-gnu --offload-arch=gfx1010 \
 // RUN:   --rocm-path=%S/Inputs/rocm --print-rocm-search-dirs %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=ROCM-PATH %s
 
Index: clang/test/Driver/hip-runtime-libs-msvc.hip
===
--- clang/test/Driver/hip-runtime-libs-msvc.hip
+++ clang/test/Driver/hip-runtime-libs-msvc.hip
@@ -7,4 +7,9 @@
 // RUN:   --rocm-path=%S/Inputs/rocm %t.o 2>&1 \
 // RUN:   | FileCheck %s
 
+// Test HIP runtime lib is linked without --hip-link when there is HIP input file.
+// RUN: %clang -### --target=x86_64-pc-windows-msvc \
+// RUN:   --rocm-path=%S/Inputs/rocm %s 2>&1 \
+// RUN:   | FileCheck %s
+
 // CHECK: "-libpath:{{.*Inputs.*rocm.*lib}}" "amdhip64.lib"
Index: clang/test/Driver/hip-runtime-libs-linux.hip
===
--- clang/test/Driver/hip-runtime-libs-linux.hip
+++ clang/test/Driver/hip-runtime-libs-linux.hip
@@ -43,6 +43,11 @@
 // RUN:   --rocm-path=%S/Inputs/rocm %t.o 2>&1 \
 // RUN:   | FileCheck -check-prefixes=NOHIPRT %s
 
+// Test HIP runtime lib is linked without hip-link if there is HIP input file.
+// RUN: %clang -### --target=x86_64-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --rocm-path=%S/Inputs/rocm %s 2>&1 \
+// RUN:   | FileCheck -check-prefixes=ROCM-PATH %s
+
 // ROCM-PATH: "-L[[HIPRT:.*/Inputs/rocm/lib]]" "-lamdhip64"
 // ROCM-RPATH: "-L[[HIPRT:.*/Inputs/rocm/lib]]" "-rpath" "[[HIPRT]]" "-lamdhip64"
 // ROCM-REL: "-L[[HIPRT:.*/opt/rocm-3.10.0/lib]]" "-lamdhip64"
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -315,7 +315,7 @@
 A.renderAsInput(Args, CmdArgs);
   }
 
-  addHIPRuntimeLibArgs(TC, Args, CmdArgs);
+  addHIPRuntimeLibArgs(TC, C, Args, CmdArgs);
 
   TC.addProfileRTLibs(Args, CmdArgs);
 
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -549,7 +549,7 @@
   addLinkerCompressDebugSectionsOption(ToolChain, Args, CmdArgs);
   

[clang] 932c635 - [HIP] link HIP runtime library without --hip-link

2023-08-04 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2023-08-04T18:29:47-04:00
New Revision: 932c63550ad5752ba333a7a4e0045b559c65840b

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

LOG: [HIP] link HIP runtime library without --hip-link

When doing combined compilation/link for HIP source
files, clang should link the HIP runtime library
automatically without --hip-link.

Reviewed by: Siu Chi Chan, Joseph Huber

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

Added: 


Modified: 
clang/docs/HIPSupport.rst
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/CommonArgs.h
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/MSVC.cpp
clang/test/Driver/hip-runtime-libs-linux.hip
clang/test/Driver/hip-runtime-libs-msvc.hip
clang/test/Driver/rocm-detect.hip

Removed: 




diff  --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 4057e1f691593b..8b4649733a9c77 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -67,11 +67,14 @@ To link a HIP program, use this command:
 
clang++ --hip-link --offload-arch=gfx906 sample.o -o sample
 
+In the above command, the ``--hip-link`` flag instructs Clang to link the HIP 
runtime library. However,
+the use of this flag is unnecessary if a HIP input file is already present in 
your program.
+
 For convenience, Clang also supports compiling and linking in a single step:
 
 .. code-block:: shell
 
-   clang++ --hip-link --offload-arch=gfx906 -xhip sample.cpp -o sample
+   clang++ --offload-arch=gfx906 -xhip sample.cpp -o sample
 
 In the above commands, ``gfx906`` is the GPU architecture that the code is 
being compiled for. The supported GPU
 architectures can be found in the `AMDGPU Processor Table 
`_.
@@ -85,7 +88,7 @@ You can use ``--offload-arch=native`` to automatically detect 
the GPU architectu
 
 .. code-block:: shell
 
-   clang++ --hip-link --offload-arch=native -xhip sample.cpp -o sample
+   clang++ --offload-arch=native -xhip sample.cpp -o sample
 
 
 Path Setting for Dependencies

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 358d7565f47c2e..6d38cf2f33053f 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -2428,10 +2428,10 @@ void tools::addOpenMPDeviceRTL(const Driver ,
   << LibOmpTargetName << ArchPrefix;
   }
 }
-void tools::addHIPRuntimeLibArgs(const ToolChain ,
+void tools::addHIPRuntimeLibArgs(const ToolChain , Compilation ,
  const llvm::opt::ArgList ,
  llvm::opt::ArgStringList ) {
-  if (Args.hasArg(options::OPT_hip_link) &&
+  if ((C.getActiveOffloadKinds() & Action::OFK_HIP) &&
   !Args.hasArg(options::OPT_nostdlib) &&
   !Args.hasArg(options::OPT_no_hip_rt)) {
 TC.AddHIPRuntimeLibArgs(Args, CmdArgs);

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.h 
b/clang/lib/Driver/ToolChains/CommonArgs.h
index 6a8de0f1c36d1f..b1c8441226310c 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.h
+++ b/clang/lib/Driver/ToolChains/CommonArgs.h
@@ -138,7 +138,8 @@ void addFortranRuntimeLibraryPath(const ToolChain ,
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList );
 
-void addHIPRuntimeLibArgs(const ToolChain , const llvm::opt::ArgList ,
+void addHIPRuntimeLibArgs(const ToolChain , Compilation ,
+  const llvm::opt::ArgList ,
   llvm::opt::ArgStringList );
 
 const char *getAsNeededOption(const ToolChain , bool as_needed);

diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 485fd67ca53d3e..c8fb05d238782e 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -549,7 +549,7 @@ void tools::gnutools::Linker::ConstructJob(Compilation , 
const JobAction ,
   addLinkerCompressDebugSectionsOption(ToolChain, Args, CmdArgs);
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
-  addHIPRuntimeLibArgs(ToolChain, Args, CmdArgs);
+  addHIPRuntimeLibArgs(ToolChain, C, Args, CmdArgs);
 
   // The profile runtime also needs access to system libraries.
   getToolChain().addProfileRTLibs(Args, CmdArgs);

diff  --git a/clang/lib/Driver/ToolChains/MSVC.cpp 
b/clang/lib/Driver/ToolChains/MSVC.cpp
index a9fe9da4620f80..4966d102c51f1a 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -315,7 +315,7 @@ void visualstudio::Linker::ConstructJob(Compilation , 
const JobAction ,
 A.renderAsInput(Args, CmdArgs);
   }
 
-  addHIPRuntimeLibArgs(TC, Args, CmdArgs);
+  

[PATCH] D157090: [Flang][Sema] Move directive sets to a shared location

2023-08-04 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan added a comment.

This looks OK. The only concern is whether we will lose the ability to inline 
the code for set membership. Can these sets be put in a header file with 
`inline constexpr`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157090

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


[PATCH] D157066: [clang][modules][deps] Create more efficient API for visitation of `ModuleFile` inputs

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/include/clang/Serialization/ModuleFile.h:72
+  bool TopLevel;
+  bool ModuleMap;
 };

benlangmuir wrote:
> Is there something using this new split? It seems like every user is using 
> `&&` for these
You're right. I recall needing this on (now probably abandoned) patch, so I 
thought I might as well add the extra bit now, sine I'm changing the format 
anyways. I'm fine with removing this.



Comment at: clang/lib/Serialization/ASTReader.cpp:2411
   bool Transient = FI.Transient;
-  StringRef Filename = FI.Filename;
+  StringRef Filename = FI.FilenameAsRequested;
   uint64_t StoredContentHash = FI.ContentHash;

benlangmuir wrote:
> It's not clear to me why this one changed
This actually maintains the same semantics - `FI.Filename` was previously the 
as-requested path, now it's the on-disk path. Without changing this line, 
`FileManager::getFileRef()` would get called with the on-disk path, meaning 
consumers of this function would get the incorrect path when calling 
`FileEntryRef::getNameAsRequested()` on the returned file. I recall one 
clang-scan-deps test failing because of it.



Comment at: clang/lib/Serialization/ASTReader.cpp:9323
 
+void ASTReader::visitInputFileInfos(
+serialization::ModuleFile , bool IncludeSystem,

benlangmuir wrote:
> Can we rewrite `visitInputFiles` on top of this?
I can try consolidating these in a follow-up if you're fine with that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157066

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


[PATCH] D157146: [Clang][Docs] Consolidate option hiding in ClangOptionDocEmitter

2023-08-04 Thread Justin Bogner via Phabricator via cfe-commits
bogner created this revision.
bogner added a reviewer: MaskRay.
Herald added a subscriber: mcrosier.
Herald added a project: All.
bogner requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Update the `hasFlag` check to account for an Option's groups to better
match how the option parsing logic works, and instead of checking if a
group has include/exclude flags just check if there are any visible
options in it.

This cleans up some the empty sections that are currently emitted in
clang's option docs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157146

Files:
  clang/utils/TableGen/ClangOptionDocEmitter.cpp

Index: clang/utils/TableGen/ClangOptionDocEmitter.cpp
===
--- clang/utils/TableGen/ClangOptionDocEmitter.cpp
+++ clang/utils/TableGen/ClangOptionDocEmitter.cpp
@@ -31,13 +31,41 @@
 struct Documentation {
   std::vector Groups;
   std::vector Options;
+
+  bool empty() {
+return Groups.empty() && Options.empty();
+  }
 };
 struct DocumentedGroup : Documentation {
   Record *Group;
 };
 
+bool hasFlag(const Record *Option, StringRef OptionFlag) {
+  for (const Record *Flag : Option->getValueAsListOfDefs("Flags"))
+if (Flag->getName() == OptionFlag)
+  return true;
+  if (const DefInit *DI = dyn_cast(Option->getValueInit("Group")))
+for (const Record *Flag : DI->getDef()->getValueAsListOfDefs("Flags"))
+  if (Flag->getName() == OptionFlag)
+return true;
+  return false;
+}
+
+bool isOptionVisible(const Record *Option, const Record *DocInfo) {
+  for (StringRef Exclusion : DocInfo->getValueAsListOfStrings("ExcludedFlags"))
+if (hasFlag(Option, Exclusion))
+  return false;
+  if (!DocInfo->getValue("IncludedFlags"))
+return true;
+  for (StringRef Inclusion : DocInfo->getValueAsListOfStrings("IncludedFlags"))
+if (hasFlag(Option, Inclusion))
+  return true;
+  return false;
+}
+
 // Reorganize the records into a suitable form for emitting documentation.
-Documentation extractDocumentation(RecordKeeper ) {
+Documentation extractDocumentation(RecordKeeper ,
+   const Record *DocInfo) {
   Documentation Result;
 
   // Build the tree of groups. The root in the tree is the fake option group
@@ -124,12 +152,15 @@
   D.Groups.back().Group = G;
   Documentation  = D.Groups.back();
   Base = DocumentationForGroup(G);
+  if (Base.empty())
+D.Groups.pop_back();
 }
 
 auto  = OptionsInGroup[R];
 llvm::sort(Options, CompareByName);
 for (Record *O : Options)
-  D.Options.push_back(DocumentationForOption(O));
+  if (isOptionVisible(O, DocInfo))
+D.Options.push_back(DocumentationForOption(O));
 
 return D;
   };
@@ -161,44 +192,6 @@
 .Default(0);
 }
 
-bool hasFlag(const Record *OptionOrGroup, StringRef OptionFlag) {
-  for (const Record *Flag : OptionOrGroup->getValueAsListOfDefs("Flags"))
-if (Flag->getName() == OptionFlag)
-  return true;
-  return false;
-}
-
-bool isIncluded(const Record *OptionOrGroup, const Record *DocInfo) {
-  assert(DocInfo->getValue("IncludedFlags") && "Missing includeFlags");
-  for (StringRef Inclusion : DocInfo->getValueAsListOfStrings("IncludedFlags"))
-if (hasFlag(OptionOrGroup, Inclusion))
-  return true;
-  return false;
-}
-
-bool isGroupIncluded(const DocumentedGroup , const Record *DocInfo) {
-  if (isIncluded(Group.Group, DocInfo))
-return true;
-  for (auto  : Group.Options)
-if (isIncluded(O.Option, DocInfo))
-  return true;
-  for (auto  : Group.Groups) {
-if (isIncluded(G.Group, DocInfo))
-  return true;
-if (isGroupIncluded(G, DocInfo))
-  return true;
-  }
-  return false;
-}
-
-bool isExcluded(const Record *OptionOrGroup, const Record *DocInfo) {
-  // FIXME: Provide a flag to specify the set of exclusions.
-  for (StringRef Exclusion : DocInfo->getValueAsListOfStrings("ExcludedFlags"))
-if (hasFlag(OptionOrGroup, Exclusion))
-  return true;
-  return false;
-}
-
 std::string escapeRST(StringRef Str) {
   std::string Out;
   for (auto K : Str) {
@@ -319,16 +312,13 @@
   F(Option.Option);
 
   for (auto *Alias : Option.Aliases)
-if (!isExcluded(Alias, DocInfo) && canSphinxCopeWithOption(Option.Option))
+if (isOptionVisible(Alias, DocInfo) &&
+canSphinxCopeWithOption(Option.Option))
   F(Alias);
 }
 
 void emitOption(const DocumentedOption , const Record *DocInfo,
 raw_ostream ) {
-  if (isExcluded(Option.Option, DocInfo))
-return;
-  if (DocInfo->getValue("IncludedFlags") && !isIncluded(Option.Option, DocInfo))
-return;
   if (Option.Option->getValueAsDef("Kind")->getName() == "KIND_UNKNOWN" ||
   Option.Option->getValueAsDef("Kind")->getName() == "KIND_INPUT")
 return;
@@ -401,12 +391,6 @@
 
 void emitGroup(int Depth, const DocumentedGroup , const Record *DocInfo,
raw_ostream ) 

[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

2023-08-04 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D156928#4562023 , @yaxunl wrote:

> In D156928#4561890 , 
> @JonChesterfield wrote:
>
>> In D156928#4561849 , @arsenm wrote:
>>
>>> In D156928#4561811 , 
>>> @JonChesterfield wrote:
>>>
 What does code objects version= none mean?
>>>
>>> Handle any version
>>
>> So... That should be the default, right? Emit IR that the back end 
>> specialises. Or, ideally, the only behaviour as far as the front end is 
>> concerned.
>
> Code in the device library depends on a control variable about the code 
> object version. Specifying the code object version in Clang allows 
> internalizing that variable and optimizing code depending on it as early as 
> possible. Not specifying it with Clang will require an LLVM pass in amdgpu 
> backend to define that control variable after linking and it has to have an 
> external linkage. This may lose optimization. Also, you need a way to not 
> specify it in FE but specify it in BE. This just complicates things without 
> much benefits.

On second thoughts, this may inspire us about eliminating not just the code 
object control variable but all device library control variables.

Basically in Clang we can emit a module flag about required control variables 
and do not link the device libs that implement these control variables.

Then we add an LLVM pass at the very beginning of the optimization pipeline 
which checks that module flag and defines those control variables with internal 
linkage. This way, we should be able to get rid of those control variable 
device libs without losing performance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928

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


[PATCH] D154550: [clang-format] Allow empty loops on a single line.

2023-08-04 Thread Owen Pan via Phabricator via cfe-commits
owenpan added a comment.

In D154550#4529346 , @gedare wrote:

> In D154550#4526386 , @owenpan wrote:
>
>> Like `while (a);`, `while (a) {}` is also an empty loop, so `NonEmpty` is 
>> misleading if it excludes the former but not the latter. IMO we should just 
>> fix the bug without extending the option because any loop with a 
>> single-statement body is a short loop.
>
> Agreed, except that many style guides (notably, K, LLVM, and Google) treat 
> these two cases differently.

LLVM doesn't merge short loops. Google uses `{}` instead of `;` whereas AFAIK 
K does the opposite. I don't know of any major style that requires breaking 
before the null statement and merging the empty block.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154550

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


[PATCH] D157066: [clang][modules][deps] Create more efficient API for visitation of `ModuleFile` inputs

2023-08-04 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir added a subscriber: vsapsai.
benlangmuir added a comment.

CC @vsapsai since he was also making name vs. name-as-requested change in 
modules




Comment at: clang/include/clang/Serialization/ModuleFile.h:72
+  bool TopLevel;
+  bool ModuleMap;
 };

Is there something using this new split? It seems like every user is using `&&` 
for these



Comment at: clang/lib/Serialization/ASTReader.cpp:2411
   bool Transient = FI.Transient;
-  StringRef Filename = FI.Filename;
+  StringRef Filename = FI.FilenameAsRequested;
   uint64_t StoredContentHash = FI.ContentHash;

It's not clear to me why this one changed



Comment at: clang/lib/Serialization/ASTReader.cpp:9323
 
+void ASTReader::visitInputFileInfos(
+serialization::ModuleFile , bool IncludeSystem,

Can we rewrite `visitInputFiles` on top of this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157066

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


[PATCH] D157078: [include-cleaner] Handle files with unnamed buffers

2023-08-04 Thread Lei Huang via Phabricator via cfe-commits
lei added a comment.

This is causing a ld.lld link failure in 
https://lab.llvm.org/buildbot/#/builders/57

  FAILED: 
tools/clang/tools/extra/include-cleaner/unittests/ClangIncludeCleanerTests 
  : && /home/buildbots/clang.15.0.4/bin/clang++ --gcc-toolchain=/usr -fPIC 
-fno-semantic-interposition -fvisibility-inlines-hidden -Werror 
-Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-Wno-nested-anon-types -O3 -DNDEBUG -Wl,--color-diagnostics 
-Wl,--gc-sections 
tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/AnalysisTest.cpp.o
 
tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/FindHeadersTest.cpp.o
 
tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/IncludeSpellerTest.cpp.o
 
tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/LocateSymbolTest.cpp.o
 
tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/RecordTest.cpp.o
 
tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/TypesTest.cpp.o
 
tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/WalkASTTest.cpp.o
 -o tools/clang/tools/extra/include-cleaner/unittests/ClangIncludeCleanerTests  
-Wl,-rpath,/home/buildbots/docker-RHEL84-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/build/lib
  -lpthread  lib/libllvm_gtest_main.so.18git  -lpthread  
lib/libclangIncludeCleaner.so.18git  lib/libclangTesting.so.18git  
lib/libLLVMTestingAnnotations.so.18git  lib/libLLVMTestingSupport.so.18git  
lib/libclangFormat.so.18git  lib/libclangToolingInclusionsStdlib.so.18git  
lib/libllvm_gtest.so.18git  lib/libclangFrontend.so.18git  
lib/libclangAST.so.18git  lib/libclangLex.so.18git  lib/libclangBasic.so.18git  
lib/libLLVMSupport.so.18git  
-Wl,-rpath-link,/home/buildbots/docker-RHEL84-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/build/lib
 && :
  ld.lld: error: undefined symbol: 
clang::PCHContainerOperations::PCHContainerOperations()
  >>> referenced by RecordTest.cpp
  >>>   
tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/RecordTest.cpp.o:(clang::include_cleaner::(anonymous
 namespace)::PragmaIncludeTest_ExportInUnnamedBuffer_Test::TestBody())
  clang-15: error: linker command failed with exit code 1 (use -v to see 
invocation)

Maybe a lib is needed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157078

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


[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

2023-08-04 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D156928#4561890 , @JonChesterfield 
wrote:

> In D156928#4561849 , @arsenm wrote:
>
>> In D156928#4561811 , 
>> @JonChesterfield wrote:
>>
>>> What does code objects version= none mean?
>>
>> Handle any version
>
> So... That should be the default, right? Emit IR that the back end 
> specialises. Or, ideally, the only behaviour as far as the front end is 
> concerned.

Code in the device library depends on a control variable about the code object 
version. Specifying the code object version in Clang allows internalizing that 
variable and optimizing code depending on it as early as possible. Not 
specifying it with Clang will require an LLVM pass in amdgpu backend to define 
that control variable after linking and it has to have an external linkage. 
This may lose optimization. Also, you need a way to not specify it in FE but 
specify it in BE. This just complicates things without much benefits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928

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


[PATCH] D156989: FloatingPointMode: Use -1 for "Dynamic"

2023-08-04 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D156989#4558486 , @sepavloff wrote:

> Support of rounding mode in C standard is based on IEEE-754 model, where 
> rounding mode is a global state and affects all FP operations. The case of 
> two rounding modes does not fit this model. So in C/C++ you anyway need to 
> invent special tools for setting this or that rounding mode or reading them. 
> If static rounding mode is not needed, IEEE-754 rounding mode could be 
> represented by `Dynamic` value.

Correct, I'm not planning on creating special "standard looking" tools. I just 
want the value in the target defined range rather than a black box.

> In IR there are more possibilities to represent many rounding modes. Each 
> constrained intrinsic call contains rounding mode and that mode may be 
> different for different FP types. Actually this model can support the general 
> case. For example, rounding mode for one type can be static but for the other 
> type it can be dynamic. There must be intrinsic functions that set/get 
> rounding mode for different types.

The raw target intrinsic to read the mode register works. Once you're in the 
target range you know you have to do something with target operations

> It looks like adding special bultin functions to get/set rounding mode for 
> different types is enough to support rounding in AMDGPU. In any case IEEE-754 
> rounding mode should be honored, which means that `fegetround` and 
> `FLT_ROUNDS` probably should return negative value, and `fesetround` probably 
> should set all rounding modes. The difference between `Dynamic` and -1 does 
> not matter because `Dynamic` can never be an argument of rounding mode type 
> and `Invalid` (-1) is an error indicator and must not be treated as rounding 
> mode.

My interpretation is fesetround of standard values would set all modes to be 
the same. Once you're outside of the range  it would work correctly to consume 
the same target defined values. "Could not determine" is the same as dynamic, 
so this should just use the standard -1 value instead of 7 just to fit in a 
clang bitfield


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

https://reviews.llvm.org/D156989

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


[PATCH] D153071: [clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

2023-08-04 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

Mea culpa. Looks like I did not anticipate non-RPO worklists. Thanks for 
cleaning this up, looks good to me!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153071

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


[clang] 65e57bb - [FunctionImport] Reduce string duplication (NFC)

2023-08-04 Thread Teresa Johnson via cfe-commits

Author: Teresa Johnson
Date: 2023-08-04T14:43:11-07:00
New Revision: 65e57bbed06d55cab7bb64d54891d33ccb2d4159

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

LOG: [FunctionImport] Reduce string duplication (NFC)

The import/export maps, and the ModuleToDefinedGVSummaries map, are all
indexed by module paths, which are StringRef obtained from the module
summary index, which already has a data structure than owns these
strings (the ModulePathStringTable). Because these other maps are also
StringMap, which makes a copy of the string key, we were keeping
multiple extra copies of the module paths, leading to memory overhead.

Change these to DenseMap keyed by StringRef, and document that the
strings are owned by the index.

The only exception is the llvm-link tool which synthesizes an import list
from command line options, and I have added a string cache to maintain
ownership there.

I measured around 5% memory reduction in the thin link of a large
binary.

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

Added: 


Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/include/llvm/LTO/LTO.h
llvm/include/llvm/Transforms/IPO/FunctionImport.h
llvm/lib/LTO/LTO.cpp
llvm/lib/LTO/ThinLTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/FunctionImport.cpp
llvm/tools/llvm-link/llvm-link.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index cda03d69522d74..e1aa697a7747ff 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -1169,7 +1169,7 @@ static void runThinLTOBackend(
 const clang::TargetOptions , const LangOptions ,
 std::unique_ptr OS, std::string SampleProfile,
 std::string ProfileRemapping, BackendAction Action) {
-  StringMap>
+  DenseMap>
   ModuleToDefinedGVSummaries;
   
CombinedIndex->collectDefinedGVSummariesPerModule(ModuleToDefinedGVSummaries);
 

diff  --git a/llvm/include/llvm/LTO/LTO.h b/llvm/include/llvm/LTO/LTO.h
index 150b31e3e8e40c..be85c40983475f 100644
--- a/llvm/include/llvm/LTO/LTO.h
+++ b/llvm/include/llvm/LTO/LTO.h
@@ -196,7 +196,7 @@ class InputFile {
 /// create a ThinBackend using one of the create*ThinBackend() functions below.
 using ThinBackend = std::function(
 const Config , ModuleSummaryIndex ,
-StringMap ,
+DenseMap ,
 AddStreamFn AddStream, FileCache Cache)>;
 
 /// This ThinBackend runs the individual backend jobs in-process.

diff  --git a/llvm/include/llvm/Transforms/IPO/FunctionImport.h 
b/llvm/include/llvm/Transforms/IPO/FunctionImport.h
index 3e4b3eb30e77b2..559418db05933e 100644
--- a/llvm/include/llvm/Transforms/IPO/FunctionImport.h
+++ b/llvm/include/llvm/Transforms/IPO/FunctionImport.h
@@ -94,8 +94,11 @@ class FunctionImporter {
 
   /// The map contains an entry for every module to import from, the key being
   /// the module identifier to pass to the ModuleLoader. The value is the set 
of
-  /// functions to import.
-  using ImportMapTy = StringMap;
+  /// functions to import. The module identifier strings must be owned
+  /// elsewhere, typically by the in-memory ModuleSummaryIndex the importing
+  /// decisions are made from (the module path for each summary is owned by the
+  /// index's module path string table).
+  using ImportMapTy = DenseMap;
 
   /// The set contains an entry for every global value the module exports.
   using ExportSetTy = DenseSet;
@@ -147,13 +150,18 @@ class FunctionImportPass : public 
PassInfoMixin {
 /// \p ExportLists contains for each Module the set of globals (GUID) that will
 /// be imported by another module, or referenced by such a function. I.e. this
 /// is the set of globals that need to be promoted/renamed appropriately.
+///
+/// The module identifier strings that are the keys of the above two maps
+/// are owned by the in-memory ModuleSummaryIndex the importing decisions
+/// are made from (the module path for each summary is owned by the index's
+/// module path string table).
 void ComputeCrossModuleImport(
 const ModuleSummaryIndex ,
-const StringMap ,
+const DenseMap ,
 function_ref
 isPrevailing,
-StringMap ,
-StringMap );
+DenseMap ,
+DenseMap );
 
 /// Compute all the imports for the given module using the Index.
 ///
@@ -225,7 +233,7 @@ bool convertToDeclaration(GlobalValue );
 /// stable order for bitcode emission.
 void gatherImportedSummariesForModule(
 StringRef ModulePath,
-const StringMap ,
+const DenseMap ,
 const FunctionImporter::ImportMapTy ,
 std::map );
 

diff  --git a/llvm/lib/LTO/LTO.cpp b/llvm/lib/LTO/LTO.cpp
index bc8abb751221ce..06cf3f294513c1 100644
--- a/llvm/lib/LTO/LTO.cpp
+++ b/llvm/lib/LTO/LTO.cpp
@@ -178,7 +178,7 @@ void llvm::computeLTOCacheKey(
 

[PATCH] D156580: [FunctionImport] Reduce string duplication (NFC)

2023-08-04 Thread Teresa Johnson 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 rG65e57bbed06d: [FunctionImport] Reduce string duplication 
(NFC) (authored by tejohnson).

Changed prior to commit:
  https://reviews.llvm.org/D156580?vs=545303=547359#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156580

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/Transforms/IPO/FunctionImport.h
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/FunctionImport.cpp
  llvm/tools/llvm-link/llvm-link.cpp

Index: llvm/tools/llvm-link/llvm-link.cpp
===
--- llvm/tools/llvm-link/llvm-link.cpp
+++ llvm/tools/llvm-link/llvm-link.cpp
@@ -323,6 +323,11 @@
   };
 
   ModuleLazyLoaderCache ModuleLoaderCache(ModuleLoader);
+  // Owns the filename strings used to key into the ImportList. Normally this is
+  // constructed from the index and the strings are owned by the index, however,
+  // since we are synthesizing this data structure from options we need a cache
+  // to own those strings.
+  StringSet<> FileNameStringCache;
   for (const auto  : Imports) {
 // Identify the requested function and its bitcode source file.
 size_t Idx = Import.find(':');
@@ -360,7 +365,8 @@
 if (Verbose)
   errs() << "Importing " << FunctionName << " from " << FileName << "\n";
 
-auto  = ImportList[FileName];
+auto  =
+ImportList[FileNameStringCache.insert(FileName).first->getKey()];
 Entry.insert(F->getGUID());
   }
   auto CachedModuleLoader = [&](StringRef Identifier) {
Index: llvm/lib/Transforms/IPO/FunctionImport.cpp
===
--- llvm/lib/Transforms/IPO/FunctionImport.cpp
+++ llvm/lib/Transforms/IPO/FunctionImport.cpp
@@ -272,7 +272,7 @@
   function_ref
   IsPrevailing;
   FunctionImporter::ImportMapTy 
-  StringMap *const ExportLists;
+  DenseMap *const ExportLists;
 
   bool shouldImportGlobal(const ValueInfo ) {
 const auto  = DefinedGVSummaries.find(VI.getGUID());
@@ -357,7 +357,7 @@
   function_ref
   IsPrevailing,
   FunctionImporter::ImportMapTy ,
-  StringMap *ExportLists)
+  DenseMap *ExportLists)
   : Index(Index), DefinedGVSummaries(DefinedGVSummaries),
 IsPrevailing(IsPrevailing), ImportList(ImportList),
 ExportLists(ExportLists) {}
@@ -403,7 +403,7 @@
 isPrevailing,
 SmallVectorImpl , GlobalsImporter ,
 FunctionImporter::ImportMapTy ,
-StringMap *ExportLists,
+DenseMap *ExportLists,
 FunctionImporter::ImportThresholdsTy ) {
   GVImporter.onImportingSummary(Summary);
   static int ImportCount = 0;
@@ -576,7 +576,7 @@
 isPrevailing,
 const ModuleSummaryIndex , StringRef ModName,
 FunctionImporter::ImportMapTy ,
-StringMap *ExportLists = nullptr) {
+DenseMap *ExportLists = nullptr) {
   // Worklist contains the list of function imported in this module, for which
   // we will analyse the callees and may import further down the callgraph.
   SmallVector Worklist;
@@ -671,10 +671,10 @@
 #endif
 
 #ifndef NDEBUG
-static bool
-checkVariableImport(const ModuleSummaryIndex ,
-StringMap ,
-StringMap ) {
+static bool checkVariableImport(
+const ModuleSummaryIndex ,
+DenseMap ,
+DenseMap ) {
 
   DenseSet FlattenedImports;
 
@@ -702,7 +702,7 @@
   for (auto  : ExportLists)
 for (auto  : ExportPerModule.second)
   if (!FlattenedImports.count(VI.getGUID()) &&
-  IsReadOrWriteOnlyVarNeedingImporting(ExportPerModule.first(), VI))
+  IsReadOrWriteOnlyVarNeedingImporting(ExportPerModule.first, VI))
 return false;
 
   return true;
@@ -712,19 +712,18 @@
 /// Compute all the import and export for every module using the Index.
 void llvm::ComputeCrossModuleImport(
 const ModuleSummaryIndex ,
-const StringMap ,
+const DenseMap ,
 function_ref
 isPrevailing,
-StringMap ,
-StringMap ) {
+DenseMap ,
+DenseMap ) {
   // For each module that has function defined, compute the import/export lists.
   for (const auto  : ModuleToDefinedGVSummaries) {
-auto  = ImportLists[DefinedGVSummaries.first()];
+auto  = ImportLists[DefinedGVSummaries.first];
 LLVM_DEBUG(dbgs() << "Computing import for Module '"
-  << DefinedGVSummaries.first() << "'\n");
+  << DefinedGVSummaries.first << "'\n");
 ComputeImportForModule(DefinedGVSummaries.second, isPrevailing, Index,
-   DefinedGVSummaries.first(), ImportList,
-   );
+   DefinedGVSummaries.first, ImportList, );
   }
 
   // When computing imports we only added the variables and 

[PATCH] D156054: [Clang][Sema] DR722 (nullptr and varargs) and missing -Wvarargs diagnostics

2023-08-04 Thread Mital Ashok via Phabricator via cfe-commits
MitalAshok updated this revision to Diff 547353.
MitalAshok added a comment.

C99 7.15.1.1p2 explicitly allows a char* to be retrieved as a void* with 
va_arg, so the -Wformat-pedantic warning was incorrect.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156054

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/AST/FormatString.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CXX/drs/dr7xx.cpp
  clang/test/CodeGen/xcore-abi.c
  clang/test/Sema/format-strings-pedantic.c
  clang/test/SemaCXX/varargs.cpp
  clang/www/cxx_dr_status.html

Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -4373,7 +4373,7 @@
 https://cplusplus.github.io/CWG/issues/722.html;>722
 CD2
 Can nullptr be passed to an ellipsis?
-Unknown
+Clang 18
   
   
 https://cplusplus.github.io/CWG/issues/726.html;>726
Index: clang/test/SemaCXX/varargs.cpp
===
--- clang/test/SemaCXX/varargs.cpp
+++ clang/test/SemaCXX/varargs.cpp
@@ -55,6 +55,16 @@
   (void)__builtin_va_arg(ap, unsigned int);
 
   (void)__builtin_va_arg(ap, bool); // expected-warning {{second argument to 'va_arg' is of promotable type 'bool'; this va_arg has undefined behavior because arguments will be promoted to 'int'}}
+
+  (void)__builtin_va_arg(ap, float); // expected-warning {{second argument to 'va_arg' is of promotable type 'float'; this va_arg has undefined behavior because arguments will be promoted to 'double'}}
+  (void)__builtin_va_arg(ap, __fp16); // expected-warning {{second argument to 'va_arg' is of promotable type '__fp16'; this va_arg has undefined behavior because arguments will be promoted to 'double'}}
+
+#if __cplusplus >= 201103L
+  (void)__builtin_va_arg(ap, decltype(nullptr)); // expected-warning {{second argument to 'va_arg' is of promotable type 'decltype(nullptr)' (aka 'std::nullptr_t'); this va_arg has undefined behavior because arguments will be promoted to 'void *'}}
+#endif
+
+  (void)__builtin_va_arg(ap, int[3]); // expected-warning {{second argument to 'va_arg' is of promotable type 'int[3]'; this va_arg has undefined behavior because arguments will be promoted to 'int *'}}
+  (void)__builtin_va_arg(ap, const int[3]); // expected-warning {{second argument to 'va_arg' is of promotable type 'const int[3]'; this va_arg has undefined behavior because arguments will be promoted to 'const int *'}}
 }
 
 #if __cplusplus >= 201103L
Index: clang/test/Sema/format-strings-pedantic.c
===
--- clang/test/Sema/format-strings-pedantic.c
+++ clang/test/Sema/format-strings-pedantic.c
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -Wno-format -Wformat-pedantic %s
 // RUN: %clang_cc1 -xobjective-c -fblocks -fsyntax-only -verify -Wno-format -Wformat-pedantic %s
 // RUN: %clang_cc1 -xc++ -fsyntax-only -verify -Wno-format -Wformat-pedantic %s
+// RUN: %clang_cc1 -std=c2x -fsyntax-only -verify -Wno-format -Wformat-pedantic %s
 
 __attribute__((format(printf, 1, 2)))
 int printf(const char *restrict, ...);
@@ -14,7 +15,7 @@
   printf("%p", (id)0); // expected-warning {{format specifies type 'void *' but the argument has type 'id'}}
 #endif
 
-#ifdef __cplusplus
-  printf("%p", nullptr); // expected-warning {{format specifies type 'void *' but the argument has type 'std::nullptr_t'}}
+#if !__is_identifier(nullptr)
+  printf("%p", nullptr);
 #endif
 }
Index: clang/test/CodeGen/xcore-abi.c
===
--- clang/test/CodeGen/xcore-abi.c
+++ clang/test/CodeGen/xcore-abi.c
@@ -76,7 +76,8 @@
   // CHECK: call void @llvm.memcpy.p0.p0.i32(ptr align 4 [[V5]], ptr align 4 [[P]], i32 20, i1 false)
   // CHECK: call void @f(ptr noundef [[V5]])
 
-  int* v6 = va_arg (ap, int[4]);  // an unusual aggregate type
+  // an unusual aggregate type
+  int* v6 = va_arg (ap, int[4]);  // expected-warning{{second argument to 'va_arg' is of promotable type 'int[4]'}}
   f(v6);
   // CHECK: [[I:%[a-z0-9]+]] = load ptr, ptr [[AP]]
   // CHECK: [[P:%[a-z0-9]+]] = load ptr, ptr [[I]]
Index: clang/test/CXX/drs/dr7xx.cpp
===
--- clang/test/CXX/drs/dr7xx.cpp
+++ clang/test/CXX/drs/dr7xx.cpp
@@ -53,6 +53,15 @@
 #endif
 }
 
+namespace dr722 { // dr722: 18
+#if __cplusplus >= 201103L
+  int x = __builtin_printf("%p", nullptr);
+  void f(__builtin_va_list args) {
+__builtin_va_arg(args, decltype(nullptr)); // expected-warning {{second argument to 'va_arg' is of promotable type 'decltype(nullptr)' (aka 'std::nullptr_t'); this va_arg has undefined behavior because arguments will be promoted to 'void *'}}
+  }
+#endif
+}
+
 namespace dr727 { // dr727: partial
   struct A {
 template struct C; // expected-note 6{{here}}

[PATCH] D157129: [NFC] Fix unnecessary copy with auto.

2023-08-04 Thread Srividya Sundaram via Phabricator via cfe-commits
srividya-sundaram updated this revision to Diff 547350.
srividya-sundaram added a comment.

Added 'const' type qualifiers per review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157129

Files:
  clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
  clang/lib/AST/Interp/ByteCodeEmitter.cpp
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/lib/Analysis/FlowSensitive/RecordOps.cpp
  clang/lib/Sema/SemaRISCVVectorLookup.cpp
  clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/ObjCSelfInitChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/ObjCUnusedIVarsChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/SimpleStreamChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/UndefCapturedBlockVarChecker.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  clang/lib/StaticAnalyzer/Core/MemRegion.cpp
  clang/lib/StaticAnalyzer/Core/ProgramState.cpp
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp

Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1089,7 +1089,7 @@
   // BlockDataRegion?  If so, invalidate captured variables that are passed
   // by reference.
   if (const BlockDataRegion *BR = dyn_cast(baseR)) {
-for (auto Var : BR->referenced_vars()) {
+for (auto  : BR->referenced_vars()) {
   const VarRegion *VR = Var.getCapturedRegion();
   const VarDecl *VD = VR->getDecl();
   if (VD->hasAttr() || !VD->hasLocalStorage()) {
@@ -2844,7 +2844,7 @@
 
 // All regions captured by a block are also live.
 if (const BlockDataRegion *BR = dyn_cast(R)) {
-  for (auto Var : BR->referenced_vars())
+  for (auto  : BR->referenced_vars())
 AddToWorkList(Var.getCapturedRegion());
 }
   }
Index: clang/lib/StaticAnalyzer/Core/ProgramState.cpp
===
--- clang/lib/StaticAnalyzer/Core/ProgramState.cpp
+++ clang/lib/StaticAnalyzer/Core/ProgramState.cpp
@@ -627,7 +627,7 @@
 
   // Regions captured by a block are also implicitly reachable.
   if (const BlockDataRegion *BDR = dyn_cast(R)) {
-for (auto Var : BDR->referenced_vars()) {
+for (auto  : BDR->referenced_vars()) {
   if (!scan(Var.getCapturedRegion()))
 return false;
 }
Index: clang/lib/StaticAnalyzer/Core/MemRegion.cpp
===
--- clang/lib/StaticAnalyzer/Core/MemRegion.cpp
+++ clang/lib/StaticAnalyzer/Core/MemRegion.cpp
@@ -492,7 +492,7 @@
 void BlockDataRegion::dumpToStream(raw_ostream ) const {
   os << "block_data{" << BC;
   os << "; ";
-  for (auto Var : referenced_vars())
+  for (auto  : referenced_vars())
 os << "(" << Var.getCapturedRegion() << "<-" << Var.getOriginalRegion()
<< ") ";
   os << '}';
@@ -966,7 +966,7 @@
 if (const auto *BC = dyn_cast(LC)) {
   const auto *BR = static_cast(BC->getData());
   // FIXME: This can be made more efficient.
-  for (auto Var : BR->referenced_vars()) {
+  for (auto  : BR->referenced_vars()) {
 const TypedValueRegion *OrigR = Var.getOriginalRegion();
 if (const auto *VR = dyn_cast(OrigR)) {
   if (VR->getDecl() == VD)
Index: clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -1193,7 +1193,7 @@
 
   // If we created a new MemRegion for the lambda, we should explicitly bind
   // the captures.
-  for (auto const [Idx, FieldForCapture, InitExpr] :
+  for (auto const &[Idx, FieldForCapture, InitExpr] :
llvm::zip(llvm::seq(0, -1), LE->getLambdaClass()->fields(),
  LE->capture_inits())) {
 SVal FieldLoc = State->getLValue(FieldForCapture, V);
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -211,7 +211,7 @@
 auto ReferencedVars = BDR->referenced_vars();
 auto CI = BD->capture_begin();
 auto CE = BD->capture_end();
-for (auto Var : ReferencedVars) {
+for (const auto  : ReferencedVars) {
   const VarRegion *capturedR = 

[clang] 043d03d - Revert "Reland "Fix __cfi_check not aligned to 4k on relocatable files with no executable code""

2023-08-04 Thread Florian Mayer via cfe-commits

Author: Florian Mayer
Date: 2023-08-04T14:24:26-07:00
New Revision: 043d03d25bd7eadef66685de298342b35fe6b466

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

LOG: Revert "Reland "Fix __cfi_check not aligned to 4k on relocatable files 
with no executable code""

Broke sanitizer build bots

This reverts commit b82c2b9ac2baae0f2a9dd65770cfb37fdc2a80a9.

Added: 


Modified: 
clang/lib/CodeGen/CGExpr.cpp
clang/test/CodeGen/cfi-check-fail.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index 07e204387804c8..0aadaeaba69f3d 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -3431,12 +3431,14 @@ void CodeGenFunction::EmitCfiCheckStub() {
   llvm::Function *F = llvm::Function::Create(
   llvm::FunctionType::get(VoidTy, {Int64Ty, Int8PtrTy, Int8PtrTy}, false),
   llvm::GlobalValue::WeakAnyLinkage, "__cfi_check", M);
-  F->setAlignment(llvm::Align(4096));
   CGM.setDSOLocal(F);
   llvm::BasicBlock *BB = llvm::BasicBlock::Create(Ctx, "entry", F);
-  // CrossDSOCFI pass is not executed if there is no executable code.
-  SmallVector Args{F->getArg(2), F->getArg(1)};
-  llvm::CallInst::Create(M->getFunction("__cfi_check_fail"), Args, "", BB);
+  // FIXME: consider emitting an intrinsic call like
+  // call void @llvm.cfi_check(i64 %0, i8* %1, i8* %2)
+  // which can be lowered in CrossDSOCFI pass to the actual contents of
+  // __cfi_check. This would allow inlining of __cfi_check calls.
+  llvm::CallInst::Create(
+  llvm::Intrinsic::getDeclaration(M, llvm::Intrinsic::trap), "", BB);
   llvm::ReturnInst::Create(Ctx, nullptr, BB);
 }
 
@@ -3530,6 +3532,9 @@ void CodeGenFunction::EmitCfiCheckFail() {
   }
 
   FinishFunction();
+  // The only reference to this function will be created during LTO link.
+  // Make sure it survives until then.
+  CGM.addUsedGlobal(F);
 }
 
 void CodeGenFunction::EmitUnreachable(SourceLocation Loc) {

diff  --git a/clang/test/CodeGen/cfi-check-fail.c 
b/clang/test/CodeGen/cfi-check-fail.c
index 2f12cee9dec602..a4d940641090e5 100644
--- a/clang/test/CodeGen/cfi-check-fail.c
+++ b/clang/test/CodeGen/cfi-check-fail.c
@@ -72,7 +72,7 @@ void caller(void (*f)(void)) {
 // CHECK: [[CONT5]]:
 // CHECK:   ret void
 
-// CHECK: define weak void @__cfi_check(i64 %[[TYPE:.*]], ptr %[[ADDR:.*]], 
ptr %[[DATA:.*]]) align 4096
+// CHECK: define weak void @__cfi_check(i64 %0, ptr %1, ptr %2)
 // CHECK-NOT: }
-// CHECK: call void @__cfi_check_fail(ptr %[[DATA]], ptr %[[ADDR]])
+// CHECK: call void @llvm.trap()
 // CHECK-NEXT: ret void



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


[PATCH] D156886: [CUDA][HIP] Reorganize options for documentation

2023-08-04 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
yaxunl marked 2 inline comments as done.
Closed by commit rGf037b895b7e9: [CUDA][HIP] Reorganize options for 
documentation (authored by yaxunl).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D156886?vs=546434=547349#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156886

Files:
  clang/include/clang/Driver/Options.td

Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -150,12 +150,22 @@
 Group, DocFlatten;
 def pedantic_Group : OptionGroup<"">, Group,
  DocFlatten;
+
+def offload_Group : OptionGroup<"">, Group,
+   DocName<"Common Offloading options">;
+
 def opencl_Group : OptionGroup<"">, Group,
DocName<"OpenCL options">;
 
 def sycl_Group : OptionGroup<"">, Group,
  DocName<"SYCL options">;
 
+def cuda_Group : OptionGroup<"">, Group,
+   DocName<"CUDA options">;
+
+def hip_Group : OptionGroup<"">, Group,
+   DocName<"HIP options">;
+
 def m_Group : OptionGroup<"">, Group,
   DocName<"Target-dependent compilation options">;
 
@@ -987,32 +997,108 @@
   NegFlag,
   PosFlag>;
 
+// Common offloading options
+let Group = offload_Group in {
+def offload_arch_EQ : Joined<["--"], "offload-arch=">, Flags<[NoXarchOption]>,
+  HelpText<"Specify an offloading device architecture for CUDA, HIP, or OpenMP. (e.g. sm_35). "
+   "If 'native' is used the compiler will detect locally installed architectures. "
+   "For HIP offloading, the device architecture can be followed by target ID features "
+   "delimited by a colon (e.g. gfx908:xnack+:sramecc-). May be specified more than once.">;
+def no_offload_arch_EQ : Joined<["--"], "no-offload-arch=">, Flags<[NoXarchOption]>,
+  HelpText<"Remove CUDA/HIP offloading device architecture (e.g. sm_35, gfx906) from the list of devices to compile for. "
+   "'all' resets the list to its default value.">;
+
+def offload_new_driver : Flag<["--"], "offload-new-driver">, Flags<[CC1Option]>, Group,
+  MarshallingInfoFlag>, HelpText<"Use the new driver for offloading compilation.">;
+def no_offload_new_driver : Flag<["--"], "no-offload-new-driver">, Flags<[CC1Option]>, Group,
+  HelpText<"Don't Use the new driver for offloading compilation.">;
+
+def offload_device_only : Flag<["--"], "offload-device-only">, Flags<[FlangOption]>,
+  HelpText<"Only compile for the offloading device.">;
+def offload_host_only : Flag<["--"], "offload-host-only">, Flags<[FlangOption]>,
+  HelpText<"Only compile for the offloading host.">;
+def offload_host_device : Flag<["--"], "offload-host-device">, Flags<[FlangOption]>,
+  HelpText<"Compile for both the offloading host and device (default).">;
+
 def gpu_use_aux_triple_only : Flag<["--"], "gpu-use-aux-triple-only">,
   InternalDriverOpt, HelpText<"Prepare '-aux-triple' only without populating "
   "'-aux-target-cpu' and '-aux-target-feature'.">;
+def amdgpu_arch_tool_EQ : Joined<["--"], "amdgpu-arch-tool=">,
+  HelpText<"Tool used for detecting AMD GPU arch in the system.">;
+def nvptx_arch_tool_EQ : Joined<["--"], "nvptx-arch-tool=">,
+  HelpText<"Tool used for detecting NVIDIA GPU arch in the system.">;
+
+defm gpu_rdc : BoolFOption<"gpu-rdc",
+  LangOpts<"GPURelocatableDeviceCode">, DefaultFalse,
+  PosFlag,
+  NegFlag>;
+
+def fgpu_default_stream_EQ : Joined<["-"], "fgpu-default-stream=">,
+  HelpText<"Specify default stream. The default value is 'legacy'. (CUDA/HIP only)">,
+  Flags<[CC1Option]>,
+  Values<"legacy,per-thread">,
+  NormalizedValuesScope<"LangOptions::GPUDefaultStreamKind">,
+  NormalizedValues<["Legacy", "PerThread"]>,
+  MarshallingInfoEnum, "Legacy">;
+
+def fgpu_flush_denormals_to_zero : Flag<["-"], "fgpu-flush-denormals-to-zero">,
+  HelpText<"Flush denormal floating point values to zero in CUDA/HIP device mode.">;
+def fno_gpu_flush_denormals_to_zero : Flag<["-"], "fno-gpu-flush-denormals-to-zero">;
+
+defm gpu_defer_diag : BoolFOption<"gpu-defer-diag",
+  LangOpts<"GPUDeferDiag">, DefaultFalse,
+  PosFlag, NegFlag,
+  BothFlags<[], " host/device related diagnostic messages for CUDA/HIP">>;
+
+defm gpu_exclude_wrong_side_overloads : BoolFOption<"gpu-exclude-wrong-side-overloads",
+  LangOpts<"GPUExcludeWrongSideOverloads">, DefaultFalse,
+  PosFlag,
+  NegFlag,
+  BothFlags<[HelpHidden], " in overloading resolution for CUDA/HIP">>;
+
+def cuid_EQ : Joined<["-"], "cuid=">, Flags<[CC1Option]>,
+  HelpText<"An ID for compilation unit, which should be the same for the same "
+   "compilation unit but different for different 

[clang] f037b89 - [CUDA][HIP] Reorganize options for documentation

2023-08-04 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2023-08-04T17:23:15-04:00
New Revision: f037b895b7e987d39c30c7edb82474d774540bc1

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

LOG: [CUDA][HIP] Reorganize options for documentation

Reorganize options and group them as "Common Offloading options",
"CUDA options" and "HIP options", so that they will be grouped
together like "OpenCL options" and "SYCL options" in
https://clang.llvm.org/docs/ClangCommandLineReference.html

Reviewed by: Joseph Huber, Fangrui Song

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index fb3534133b5213..0ad2fa0112328d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -150,12 +150,22 @@ def f_clang_Group : OptionGroup<"">,
 Group, DocFlatten;
 def pedantic_Group : OptionGroup<"">, Group,
  DocFlatten;
+
+def offload_Group : OptionGroup<"">, Group,
+   DocName<"Common Offloading options">;
+
 def opencl_Group : OptionGroup<"">, Group,
DocName<"OpenCL options">;
 
 def sycl_Group : OptionGroup<"">, Group,
  DocName<"SYCL options">;
 
+def cuda_Group : OptionGroup<"">, Group,
+   DocName<"CUDA options">;
+
+def hip_Group : OptionGroup<"">, Group,
+   DocName<"HIP options">;
+
 def m_Group : OptionGroup<"">, Group,
   DocName<"Target-dependent compilation options">;
 
@@ -987,32 +997,108 @@ defm convergent_functions : 
BoolFOption<"convergent-functions",
   NegFlag,
   PosFlag>;
 
+// Common offloading options
+let Group = offload_Group in {
+def offload_arch_EQ : Joined<["--"], "offload-arch=">, Flags<[NoXarchOption]>,
+  HelpText<"Specify an offloading device architecture for CUDA, HIP, or 
OpenMP. (e.g. sm_35). "
+   "If 'native' is used the compiler will detect locally installed 
architectures. "
+   "For HIP offloading, the device architecture can be followed by 
target ID features "
+   "delimited by a colon (e.g. gfx908:xnack+:sramecc-). May be 
specified more than once.">;
+def no_offload_arch_EQ : Joined<["--"], "no-offload-arch=">, 
Flags<[NoXarchOption]>,
+  HelpText<"Remove CUDA/HIP offloading device architecture (e.g. sm_35, 
gfx906) from the list of devices to compile for. "
+   "'all' resets the list to its default value.">;
+
+def offload_new_driver : Flag<["--"], "offload-new-driver">, 
Flags<[CC1Option]>, Group,
+  MarshallingInfoFlag>, HelpText<"Use the new 
driver for offloading compilation.">;
+def no_offload_new_driver : Flag<["--"], "no-offload-new-driver">, 
Flags<[CC1Option]>, Group,
+  HelpText<"Don't Use the new driver for offloading compilation.">;
+
+def offload_device_only : Flag<["--"], "offload-device-only">, 
Flags<[FlangOption]>,
+  HelpText<"Only compile for the offloading device.">;
+def offload_host_only : Flag<["--"], "offload-host-only">, 
Flags<[FlangOption]>,
+  HelpText<"Only compile for the offloading host.">;
+def offload_host_device : Flag<["--"], "offload-host-device">, 
Flags<[FlangOption]>,
+  HelpText<"Compile for both the offloading host and device (default).">;
+
 def gpu_use_aux_triple_only : Flag<["--"], "gpu-use-aux-triple-only">,
   InternalDriverOpt, HelpText<"Prepare '-aux-triple' only without populating "
   "'-aux-target-cpu' and '-aux-target-feature'.">;
+def amdgpu_arch_tool_EQ : Joined<["--"], "amdgpu-arch-tool=">,
+  HelpText<"Tool used for detecting AMD GPU arch in the system.">;
+def nvptx_arch_tool_EQ : Joined<["--"], "nvptx-arch-tool=">,
+  HelpText<"Tool used for detecting NVIDIA GPU arch in the system.">;
+
+defm gpu_rdc : BoolFOption<"gpu-rdc",
+  LangOpts<"GPURelocatableDeviceCode">, DefaultFalse,
+  PosFlag,
+  NegFlag>;
+
+def fgpu_default_stream_EQ : Joined<["-"], "fgpu-default-stream=">,
+  HelpText<"Specify default stream. The default value is 'legacy'. (CUDA/HIP 
only)">,
+  Flags<[CC1Option]>,
+  Values<"legacy,per-thread">,
+  NormalizedValuesScope<"LangOptions::GPUDefaultStreamKind">,
+  NormalizedValues<["Legacy", "PerThread"]>,
+  MarshallingInfoEnum, "Legacy">;
+
+def fgpu_flush_denormals_to_zero : Flag<["-"], "fgpu-flush-denormals-to-zero">,
+  HelpText<"Flush denormal floating point values to zero in CUDA/HIP device 
mode.">;
+def fno_gpu_flush_denormals_to_zero : Flag<["-"], 
"fno-gpu-flush-denormals-to-zero">;
+
+defm gpu_defer_diag : BoolFOption<"gpu-defer-diag",
+  LangOpts<"GPUDeferDiag">, DefaultFalse,
+  PosFlag, NegFlag,
+  BothFlags<[], " host/device related diagnostic messages for CUDA/HIP">>;
+
+defm 

[PATCH] D157140: [clang][Sema][OpenMP] Fix capture region for 'target teams loop'

2023-08-04 Thread David Pagan via Phabricator via cfe-commits
ddpagan created this revision.
ddpagan added a reviewer: ABataev.
ddpagan added projects: clang, OpenMP.
Herald added subscribers: guansong, yaxunl.
Herald added a project: All.
ddpagan requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, jplehr, sstefan1.

The capture region for 'target teams loop' should be the same as that for 
'target teams distribute parallel for' with an 'if(target:val)'. For this
specific case, there should be no capture region.

Updated test results for OpenMP/target_teams_generic_loop_if_codegen.cpp


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157140

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_teams_generic_loop_if_codegen.cpp

Index: clang/test/OpenMP/target_teams_generic_loop_if_codegen.cpp
===
--- clang/test/OpenMP/target_teams_generic_loop_if_codegen.cpp
+++ clang/test/OpenMP/target_teams_generic_loop_if_codegen.cpp
@@ -428,13 +428,8 @@
 // CHECK1-NEXT:[[RETVAL:%.*]] = alloca i32, align 4
 // CHECK1-NEXT:[[TMP:%.*]] = alloca i32, align 4
 // CHECK1-NEXT:[[KERNEL_ARGS:%.*]] = alloca [[STRUCT___TGT_KERNEL_ARGUMENTS:%.*]], align 8
-// CHECK1-NEXT:[[DOTCAPTURE_EXPR_:%.*]] = alloca i8, align 1
-// CHECK1-NEXT:[[DOTCAPTURE_EXPR__CASTED:%.*]] = alloca i64, align 8
-// CHECK1-NEXT:[[DOTOFFLOAD_BASEPTRS:%.*]] = alloca [1 x ptr], align 8
-// CHECK1-NEXT:[[DOTOFFLOAD_PTRS:%.*]] = alloca [1 x ptr], align 8
-// CHECK1-NEXT:[[DOTOFFLOAD_MAPPERS:%.*]] = alloca [1 x ptr], align 8
-// CHECK1-NEXT:[[_TMP5:%.*]] = alloca i32, align 4
-// CHECK1-NEXT:[[KERNEL_ARGS6:%.*]] = alloca [[STRUCT___TGT_KERNEL_ARGUMENTS]], align 8
+// CHECK1-NEXT:[[_TMP2:%.*]] = alloca i32, align 4
+// CHECK1-NEXT:[[KERNEL_ARGS3:%.*]] = alloca [[STRUCT___TGT_KERNEL_ARGUMENTS]], align 8
 // CHECK1-NEXT:store i32 0, ptr [[RETVAL]], align 4
 // CHECK1-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT___TGT_KERNEL_ARGUMENTS]], ptr [[KERNEL_ARGS]], i32 0, i32 0
 // CHECK1-NEXT:store i32 2, ptr [[TMP0]], align 4
@@ -472,69 +467,52 @@
 // CHECK1-NEXT:call void @{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}_main_l83() #[[ATTR2]]
 // CHECK1-NEXT:[[TMP15:%.*]] = load i32, ptr @Arg, align 4
 // CHECK1-NEXT:[[TOBOOL:%.*]] = icmp ne i32 [[TMP15]], 0
-// CHECK1-NEXT:[[FROMBOOL:%.*]] = zext i1 [[TOBOOL]] to i8
-// CHECK1-NEXT:store i8 [[FROMBOOL]], ptr [[DOTCAPTURE_EXPR_]], align 1
-// CHECK1-NEXT:[[TMP16:%.*]] = load i8, ptr [[DOTCAPTURE_EXPR_]], align 1
-// CHECK1-NEXT:[[TOBOOL1:%.*]] = trunc i8 [[TMP16]] to i1
-// CHECK1-NEXT:[[FROMBOOL2:%.*]] = zext i1 [[TOBOOL1]] to i8
-// CHECK1-NEXT:store i8 [[FROMBOOL2]], ptr [[DOTCAPTURE_EXPR__CASTED]], align 1
-// CHECK1-NEXT:[[TMP17:%.*]] = load i64, ptr [[DOTCAPTURE_EXPR__CASTED]], align 8
-// CHECK1-NEXT:[[TMP18:%.*]] = load i8, ptr [[DOTCAPTURE_EXPR_]], align 1
-// CHECK1-NEXT:[[TOBOOL3:%.*]] = trunc i8 [[TMP18]] to i1
-// CHECK1-NEXT:br i1 [[TOBOOL3]], label [[OMP_IF_THEN:%.*]], label [[OMP_IF_ELSE:%.*]]
+// CHECK1-NEXT:br i1 [[TOBOOL]], label [[OMP_IF_THEN:%.*]], label [[OMP_IF_ELSE:%.*]]
 // CHECK1:   omp_if.then:
-// CHECK1-NEXT:[[TMP19:%.*]] = getelementptr inbounds [1 x ptr], ptr [[DOTOFFLOAD_BASEPTRS]], i32 0, i32 0
-// CHECK1-NEXT:store i64 [[TMP17]], ptr [[TMP19]], align 8
-// CHECK1-NEXT:[[TMP20:%.*]] = getelementptr inbounds [1 x ptr], ptr [[DOTOFFLOAD_PTRS]], i32 0, i32 0
-// CHECK1-NEXT:store i64 [[TMP17]], ptr [[TMP20]], align 8
-// CHECK1-NEXT:[[TMP21:%.*]] = getelementptr inbounds [1 x ptr], ptr [[DOTOFFLOAD_MAPPERS]], i64 0, i64 0
+// CHECK1-NEXT:[[TMP16:%.*]] = load i32, ptr @Arg, align 4
+// CHECK1-NEXT:[[TOBOOL1:%.*]] = icmp ne i32 [[TMP16]], 0
+// CHECK1-NEXT:[[TMP17:%.*]] = select i1 [[TOBOOL1]], i32 0, i32 1
+// CHECK1-NEXT:[[TMP18:%.*]] = insertvalue [3 x i32] zeroinitializer, i32 [[TMP17]], 0
+// CHECK1-NEXT:[[TMP19:%.*]] = getelementptr inbounds [[STRUCT___TGT_KERNEL_ARGUMENTS]], ptr [[KERNEL_ARGS3]], i32 0, i32 0
+// CHECK1-NEXT:store i32 2, ptr [[TMP19]], align 4
+// CHECK1-NEXT:[[TMP20:%.*]] = getelementptr inbounds [[STRUCT___TGT_KERNEL_ARGUMENTS]], ptr [[KERNEL_ARGS3]], i32 0, i32 1
+// CHECK1-NEXT:store i32 0, ptr [[TMP20]], align 4
+// CHECK1-NEXT:[[TMP21:%.*]] = getelementptr inbounds [[STRUCT___TGT_KERNEL_ARGUMENTS]], ptr [[KERNEL_ARGS3]], i32 0, i32 2
 // CHECK1-NEXT:store ptr null, ptr [[TMP21]], align 8
-// CHECK1-NEXT:[[TMP22:%.*]] = getelementptr inbounds [1 x ptr], ptr [[DOTOFFLOAD_BASEPTRS]], i32 0, i32 0
-// CHECK1-NEXT:[[TMP23:%.*]] = getelementptr inbounds [1 x ptr], ptr [[DOTOFFLOAD_PTRS]], i32 0, i32 0
-// CHECK1-NEXT:[[TMP24:%.*]] = load i8, ptr [[DOTCAPTURE_EXPR_]], align 1
-// CHECK1-NEXT:[[TOBOOL4:%.*]] = trunc i8 [[TMP24]] to i1
-// CHECK1-NEXT:[[TMP25:%.*]] = select i1 

[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

2023-08-04 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

In D156928#4561849 , @arsenm wrote:

> In D156928#4561811 , 
> @JonChesterfield wrote:
>
>> What does code objects version= none mean?
>
> Handle any version

So... That should be the default, right? Emit IR that the back end specialises. 
Or, ideally, the only behaviour as far as the front end is concerned.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928

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


[PATCH] D156234: [clang][deps] add support for dependency scanning with cc1 command line

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6b4de7b1c71b: [clang][deps] add support for dependency 
scanning with cc1 command line (authored by cpsughrue, committed by 
jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156234

Files:
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/test/ClangScanDeps/modules-cc1.cpp

Index: clang/test/ClangScanDeps/modules-cc1.cpp
===
--- /dev/null
+++ clang/test/ClangScanDeps/modules-cc1.cpp
@@ -0,0 +1,29 @@
+// Check that clang-scan-deps works with cc1 command lines
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+
+//--- modules_cc1.cpp
+#include "header.h"
+
+//--- header.h
+
+//--- module.modulemap
+module header1 { header "header.h" }
+
+//--- cdb.json.template
+[{
+  "file": "DIR/modules_cc1.cpp",
+  "directory": "DIR",
+  "command": "clang -cc1 DIR/modules_cc1.cpp -fimplicit-module-maps -o modules_cc1.o"
+}]
+
+// RUN: sed "s|DIR|%/t|g" %t/cdb.json.template > %t/cdb.json
+// RUN: clang-scan-deps -compilation-database %t/cdb.json -j 1 -mode preprocess-dependency-directives > %t/result
+// RUN: cat %t/result | sed 's:\?:/:g' | FileCheck %s -DPREFIX=%/t
+
+// CHECK: modules_cc1.o:
+// CHECK-NEXT: [[PREFIX]]/modules_cc1.cpp
+// CHECK-NEXT: [[PREFIX]]/module.modulemap
+// CHECK-NEXT: [[PREFIX]]/header.h
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -385,6 +385,9 @@
   if (!Compilation)
 return false;
 
+  if (Compilation->containsError())
+return false;
+
   for (const driver::Command  : Compilation->getJobs()) {
 if (!Callback(Job))
   return false;
@@ -392,6 +395,26 @@
   return true;
 }
 
+static bool createAndRunToolInvocation(
+std::vector CommandLine, DependencyScanningAction ,
+FileManager ,
+std::shared_ptr ,
+DiagnosticsEngine , DependencyConsumer ) {
+
+  // Save executable path before providing CommandLine to ToolInvocation
+  std::string Executable = CommandLine[0];
+  ToolInvocation Invocation(std::move(CommandLine), , ,
+PCHContainerOps);
+  Invocation.setDiagnosticConsumer(Diags.getClient());
+  Invocation.setDiagnosticOptions(());
+  if (!Invocation.run())
+return false;
+
+  std::vector Args = Action.takeLastCC1Arguments();
+  Consumer.handleBuildCommand({std::move(Executable), std::move(Args)});
+  return true;
+}
+
 bool DependencyScanningWorker::computeDependencies(
 StringRef WorkingDirectory, const std::vector ,
 DependencyConsumer , DependencyActionController ,
@@ -454,37 +477,37 @@
   DependencyScanningAction Action(WorkingDirectory, Consumer, Controller, DepFS,
   Format, OptimizeArgs, EagerLoadModules,
   DisableFree, ModuleName);
-  bool Success = forEachDriverJob(
-  FinalCommandLine, *Diags, *FileMgr, [&](const driver::Command ) {
-if (StringRef(Cmd.getCreator().getName()) != "clang") {
-  // Non-clang command. Just pass through to the dependency
-  // consumer.
-  Consumer.handleBuildCommand(
-  {Cmd.getExecutable(),
-   {Cmd.getArguments().begin(), Cmd.getArguments().end()}});
-  return true;
-}
-
-std::vector Argv;
-Argv.push_back(Cmd.getExecutable());
-Argv.insert(Argv.end(), Cmd.getArguments().begin(),
-Cmd.getArguments().end());
-
-// Create an invocation that uses the underlying file
-// system to ensure that any file system requests that
-// are made by the driver do not go through the
-// dependency scanning filesystem.
-ToolInvocation Invocation(std::move(Argv), , &*FileMgr,
-  PCHContainerOps);
-Invocation.setDiagnosticConsumer(Diags->getClient());
-Invocation.setDiagnosticOptions(>getDiagnosticOptions());
-if (!Invocation.run())
-  return false;
-
-std::vector Args = Action.takeLastCC1Arguments();
-Consumer.handleBuildCommand({Cmd.getExecutable(), std::move(Args)});
-return true;
-  });
+
+  bool Success = false;
+  if (FinalCommandLine[1] == "-cc1") {
+Success = createAndRunToolInvocation(FinalCommandLine, Action, *FileMgr,
+ PCHContainerOps, *Diags, Consumer);
+  } else {
+Success = forEachDriverJob(
+FinalCommandLine, *Diags, *FileMgr, [&](const driver::Command ) {
+  if (StringRef(Cmd.getCreator().getName()) != "clang") {
+// Non-clang command. Just pass through to the dependency
+// 

[clang] 6b4de7b - [clang][deps] add support for dependency scanning with cc1 command line

2023-08-04 Thread Jan Svoboda via cfe-commits

Author: Connor Sughrue
Date: 2023-08-04T14:13:18-07:00
New Revision: 6b4de7b1c71b6b701e130c2a533d285dc93b8370

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

LOG: [clang][deps] add support for dependency scanning with cc1 command line

Allow users to run a dependency scan with a cc1 command line in addition to a 
driver command line. DependencyScanningAction was already being run with a cc1 
command line, but DependencyScanningWorker::computeDependencies assumed that it 
was always provided a driver command line. Now 
DependencyScanningWorker::computeDependencies can handle cc1 command lines too.

Reviewed By: jansvoboda11

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

Added: 
clang/test/ClangScanDeps/modules-cc1.cpp

Modified: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Removed: 




diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
index 28206dceadd972..29df0c3a0afdb5 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -385,6 +385,9 @@ static bool forEachDriverJob(
   if (!Compilation)
 return false;
 
+  if (Compilation->containsError())
+return false;
+
   for (const driver::Command  : Compilation->getJobs()) {
 if (!Callback(Job))
   return false;
@@ -392,6 +395,26 @@ static bool forEachDriverJob(
   return true;
 }
 
+static bool createAndRunToolInvocation(
+std::vector CommandLine, DependencyScanningAction ,
+FileManager ,
+std::shared_ptr ,
+DiagnosticsEngine , DependencyConsumer ) {
+
+  // Save executable path before providing CommandLine to ToolInvocation
+  std::string Executable = CommandLine[0];
+  ToolInvocation Invocation(std::move(CommandLine), , ,
+PCHContainerOps);
+  Invocation.setDiagnosticConsumer(Diags.getClient());
+  Invocation.setDiagnosticOptions(());
+  if (!Invocation.run())
+return false;
+
+  std::vector Args = Action.takeLastCC1Arguments();
+  Consumer.handleBuildCommand({std::move(Executable), std::move(Args)});
+  return true;
+}
+
 bool DependencyScanningWorker::computeDependencies(
 StringRef WorkingDirectory, const std::vector ,
 DependencyConsumer , DependencyActionController ,
@@ -454,37 +477,37 @@ bool DependencyScanningWorker::computeDependencies(
   DependencyScanningAction Action(WorkingDirectory, Consumer, Controller, 
DepFS,
   Format, OptimizeArgs, EagerLoadModules,
   DisableFree, ModuleName);
-  bool Success = forEachDriverJob(
-  FinalCommandLine, *Diags, *FileMgr, [&](const driver::Command ) {
-if (StringRef(Cmd.getCreator().getName()) != "clang") {
-  // Non-clang command. Just pass through to the dependency
-  // consumer.
-  Consumer.handleBuildCommand(
-  {Cmd.getExecutable(),
-   {Cmd.getArguments().begin(), Cmd.getArguments().end()}});
-  return true;
-}
-
-std::vector Argv;
-Argv.push_back(Cmd.getExecutable());
-Argv.insert(Argv.end(), Cmd.getArguments().begin(),
-Cmd.getArguments().end());
-
-// Create an invocation that uses the underlying file
-// system to ensure that any file system requests that
-// are made by the driver do not go through the
-// dependency scanning filesystem.
-ToolInvocation Invocation(std::move(Argv), , &*FileMgr,
-  PCHContainerOps);
-Invocation.setDiagnosticConsumer(Diags->getClient());
-Invocation.setDiagnosticOptions(>getDiagnosticOptions());
-if (!Invocation.run())
-  return false;
-
-std::vector Args = Action.takeLastCC1Arguments();
-Consumer.handleBuildCommand({Cmd.getExecutable(), std::move(Args)});
-return true;
-  });
+
+  bool Success = false;
+  if (FinalCommandLine[1] == "-cc1") {
+Success = createAndRunToolInvocation(FinalCommandLine, Action, *FileMgr,
+ PCHContainerOps, *Diags, Consumer);
+  } else {
+Success = forEachDriverJob(
+FinalCommandLine, *Diags, *FileMgr, [&](const driver::Command ) {
+  if (StringRef(Cmd.getCreator().getName()) != "clang") {
+// Non-clang command. Just pass through to the dependency
+// consumer.
+Consumer.handleBuildCommand(
+{Cmd.getExecutable(),
+ {Cmd.getArguments().begin(), Cmd.getArguments().end()}});
+return true;
+  }
+
+  // Insert -cc1 comand line options into Argv
+  

[PATCH] D153071: [clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

2023-08-04 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 547344.
ymandel added a comment.

rebase onto main.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153071

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
  clang/unittests/Analysis/CFGTest.cpp

Index: clang/unittests/Analysis/CFGTest.cpp
===
--- clang/unittests/Analysis/CFGTest.cpp
+++ clang/unittests/Analysis/CFGTest.cpp
@@ -6,13 +6,15 @@
 //
 //===--===//
 
+#include "clang/Analysis/CFG.h"
 #include "CFGBuildResult.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Analysis/Analyses/IntervalPartition.h"
 #include "clang/Analysis/AnalysisDeclContext.h"
-#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowWorklist.h"
 #include "clang/Tooling/Tooling.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 #include 
@@ -244,6 +246,8 @@
 TEST(CFG, Worklists) {
   const char *Code = "int f(bool cond) {\n"
  "  int a = 5;\n"
+ "  while (a < 6)\n"
+ "++a;\n"
  "  if (cond)\n"
  "a += 1;\n"
  "  return a;\n"
@@ -272,6 +276,30 @@
ForwardNodes.begin()));
   }
 
+  // RPO: 876321054
+  // WTO: 876534210
+  // So, we construct the WTO order accordingly from the reference order.
+  std::vector WTOOrder = {
+  ReferenceOrder[0], ReferenceOrder[1], ReferenceOrder[2],
+  ReferenceOrder[7], ReferenceOrder[3], ReferenceOrder[8],
+  ReferenceOrder[4], ReferenceOrder[5], ReferenceOrder[6]};
+
+  {
+using ::testing::ElementsAreArray;
+std::optional WTO = getIntervalWTO(*CFG);
+ASSERT_TRUE(WTO);
+WTOCompare WCmp(*WTO);
+WTODataflowWorklist WTOWorklist(*CFG, WCmp);
+for (const auto *B : *CFG)
+  WTOWorklist.enqueueBlock(B);
+
+std::vector WTONodes;
+while (const CFGBlock *B = WTOWorklist.dequeue())
+  WTONodes.push_back(B);
+
+EXPECT_THAT(WTONodes, ElementsAreArray(WTOOrder));
+  }
+
   std::reverse(ReferenceOrder.begin(), ReferenceOrder.end());
 
   {
Index: clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
@@ -12,6 +12,7 @@
 #ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWWORKLIST_H
 #define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWWORKLIST_H
 
+#include "clang/Analysis/Analyses/IntervalPartition.h"
 #include "clang/Analysis/Analyses/PostOrderCFGView.h"
 #include "clang/Analysis/CFG.h"
 #include "llvm/ADT/PriorityQueue.h"
@@ -21,16 +22,13 @@
 /// on the order defined by 'Comp'.
 template  class DataflowWorklistBase {
   llvm::BitVector EnqueuedBlocks;
-  PostOrderCFGView *POV;
   llvm::PriorityQueue, Comp>
   WorkList;
 
 public:
-  DataflowWorklistBase(const CFG , PostOrderCFGView *POV, Comp C)
-  : EnqueuedBlocks(Cfg.getNumBlockIDs()), POV(POV), WorkList(C) {}
-
-  const PostOrderCFGView *getCFGView() const { return POV; }
+  DataflowWorklistBase(const CFG , Comp C)
+  : EnqueuedBlocks(Cfg.getNumBlockIDs()), WorkList(C) {}
 
   void enqueueBlock(const CFGBlock *Block) {
 if (Block && !EnqueuedBlocks[Block->getBlockID()]) {
@@ -62,7 +60,7 @@
 struct ForwardDataflowWorklist
 : DataflowWorklistBase {
   ForwardDataflowWorklist(const CFG , PostOrderCFGView *POV)
-  : DataflowWorklistBase(Cfg, POV,
+  : DataflowWorklistBase(Cfg,
  ReversePostOrderCompare{POV->getComparator()}) {}
 
   ForwardDataflowWorklist(const CFG , AnalysisDeclContext )
@@ -74,6 +72,19 @@
   }
 };
 
+/// A worklist implementation for forward dataflow analysis based on a weak
+/// topological ordering of the nodes. The worklist cannot contain the same
+/// block multiple times at once.
+struct WTODataflowWorklist : DataflowWorklistBase {
+  WTODataflowWorklist(const CFG , const WTOCompare )
+  : DataflowWorklistBase(Cfg, Cmp) {}
+
+  void enqueueSuccessors(const CFGBlock *Block) {
+for (auto B : Block->succs())
+  enqueueBlock(B);
+  }
+};
+
 /// A worklist implementation for backward dataflow analysis. The enqueued
 /// block will be dequeued in post order. The worklist cannot contain the same
 /// block multiple times at once.
@@ -81,8 +92,7 @@
 : DataflowWorklistBase {
   BackwardDataflowWorklist(const CFG , AnalysisDeclContext )
   : DataflowWorklistBase(
-Cfg, Ctx.getAnalysis(),
-Ctx.getAnalysis()->getComparator()) {}
+Cfg, Ctx.getAnalysis()->getComparator()) {}
 
   void enqueuePredecessors(const CFGBlock *Block) {
 for (auto B : Block->preds())

[PATCH] D155852: [flang] Add -fppc-native-vector-element-order option to control the element order in PowerPC vector types

2023-08-04 Thread Kelvin Li via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG00769d69fbaa: [flang] Add -fppc-native-vector-element-order 
option to control the element… (authored by kkwli0).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155852

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Lower/CustomIntrinsicCall.h
  flang/include/flang/Lower/LoweringOptions.def
  flang/include/flang/Optimizer/Builder/IntrinsicCall.h
  flang/include/flang/Optimizer/Builder/PPCIntrinsicCall.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Lower/ConvertExpr.cpp
  flang/lib/Lower/CustomIntrinsicCall.cpp
  flang/lib/Optimizer/Builder/IntrinsicCall.cpp
  flang/lib/Optimizer/Builder/PPCIntrinsicCall.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/frontend-forwarding.f90
  flang/test/Lower/PowerPC/ppc-vec_cvf-elem-order.f90
  flang/tools/bbc/bbc.cpp

Index: flang/tools/bbc/bbc.cpp
===
--- flang/tools/bbc/bbc.cpp
+++ flang/tools/bbc/bbc.cpp
@@ -186,6 +186,11 @@
 llvm::cl::desc("enable polymorphic type lowering (experimental)"),
 llvm::cl::init(false));
 
+static llvm::cl::opt enableNoPPCNativeVecElemOrder(
+"fno-ppc-native-vector-element-order",
+llvm::cl::desc("no PowerPC native vector element order."),
+llvm::cl::init(false));
+
 static llvm::cl::opt useHLFIR("hlfir",
 llvm::cl::desc("Lower to high level FIR"),
 llvm::cl::init(false));
@@ -289,6 +294,7 @@
   // Use default lowering options for bbc.
   Fortran::lower::LoweringOptions loweringOptions{};
   loweringOptions.setPolymorphicTypeImpl(enablePolymorphic);
+  loweringOptions.setNoPPCNativeVecElemOrder(enableNoPPCNativeVecElemOrder);
   loweringOptions.setLowerToHighLevelFIR(useHLFIR || emitHLFIR);
   auto burnside = Fortran::lower::LoweringBridge::create(
   ctx, semanticsContext, defKinds, semanticsContext.intrinsics(),
Index: flang/test/Lower/PowerPC/ppc-vec_cvf-elem-order.f90
===
--- /dev/null
+++ flang/test/Lower/PowerPC/ppc-vec_cvf-elem-order.f90
@@ -0,0 +1,37 @@
+! RUN: bbc -emit-fir %s -fno-ppc-native-vector-element-order=true -o - | FileCheck --check-prefixes="FIR" %s
+! RUN: %flang_fc1 -emit-llvm %s -fno-ppc-native-vector-element-order -o - | FileCheck --check-prefixes="LLVMIR" %s
+! REQUIRES: target=powerpc{{.*}}
+
+! CHECK-LABEL: vec_cvf_test_r4r8
+subroutine vec_cvf_test_r4r8(arg1)
+  vector(real(8)), intent(in) :: arg1
+  vector(real(4)) :: r
+  r = vec_cvf(arg1)
+
+! FIR: %[[arg:.*]] = fir.load %{{.*}} : !fir.ref>
+! FIR: %[[carg:.*]] = fir.convert %[[arg]] : (!fir.vector<2:f64>) -> vector<2xf64>
+! FIR: %[[call:.*]] = fir.call @llvm.ppc.vsx.xvcvdpsp(%[[carg]]) fastmath : (vector<2xf64>) -> !fir.vector<4:f32>
+! FIR: %[[ccall:.*]] = fir.convert %[[call]] : (!fir.vector<4:f32>) -> vector<4xf32>
+! FIR: %[[r:.*]] = fir.convert %[[ccall]] : (vector<4xf32>) -> !fir.vector<4:f32>
+! FIR: fir.store %[[r]] to %{{.*}} : !fir.ref>
+
+! LLVMIR: %[[arg:.*]] = load <2 x double>, ptr %{{.*}}, align 16
+! LLVMIR: %[[call:.*]] = call contract <4 x float> @llvm.ppc.vsx.xvcvdpsp(<2 x double> %[[arg]])
+! LLVMIR: store <4 x float> %[[call]], ptr %{{.*}}, align 16
+end subroutine vec_cvf_test_r4r8
+
+! CHECK-LABEL: vec_cvf_test_r8r4
+subroutine vec_cvf_test_r8r4(arg1)
+  vector(real(4)), intent(in) :: arg1
+  vector(real(8)) :: r
+  r = vec_cvf(arg1)
+
+! FIR: %[[arg:.*]] = fir.load %{{.*}} : !fir.ref>
+! FIR: %[[carg:.*]] = fir.convert %[[arg]] : (!fir.vector<4:f32>) -> vector<4xf32>
+! FIR: %[[call:.*]] = fir.call @llvm.ppc.vsx.xvcvspdp(%[[carg]]) fastmath : (vector<4xf32>) -> !fir.vector<2:f64>
+! FIR: fir.store %[[call]] to %{{.*}} : !fir.ref>
+
+! LLVMIR: %[[arg:.*]] = load <4 x float>, ptr %{{.*}}, align 16
+! LLVMIR: %[[r:.*]] = call contract <2 x double> @llvm.ppc.vsx.xvcvspdp(<4 x float> %[[arg]])
+! LLVMIR: store <2 x double> %[[r]], ptr %{{.*}}, align 16
+end subroutine vec_cvf_test_r8r4
Index: flang/test/Driver/frontend-forwarding.f90
===
--- flang/test/Driver/frontend-forwarding.f90
+++ flang/test/Driver/frontend-forwarding.f90
@@ -18,6 +18,8 @@
 ! RUN: -fversion-loops-for-stride \
 ! RUN: -flang-experimental-polymorphism \
 ! RUN: -flang-experimental-hlfir \
+! RUN: -fno-ppc-native-vector-element-order \
+! RUN: -fppc-native-vector-element-order \
 ! RUN: -mllvm -print-before-all \
 ! RUN: -save-temps=obj \
 ! RUN: -P \
@@ -40,5 +42,7 @@
 ! CHECK: "-fversion-loops-for-stride"
 ! CHECK: "-flang-experimental-polymorphism"
 ! CHECK: 

[clang] 00769d6 - [flang] Add -fppc-native-vector-element-order option to control the element order in PowerPC vector types

2023-08-04 Thread Kelvin Li via cfe-commits

Author: Kelvin Li
Date: 2023-08-04T17:11:30-04:00
New Revision: 00769d69fbaa39ecdcbbaf826a35ad999bdc951e

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

LOG: [flang] Add -fppc-native-vector-element-order option to control the 
element order in PowerPC vector types

This patch also adds a LIT test for the vec_cvf intrinsic that
can be affected by the option.

Co-authored-by: Mark Danial 
Co-authored-by: Daniel Chen 

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

Added: 
flang/test/Lower/PowerPC/ppc-vec_cvf-elem-order.f90

Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Flang.cpp
flang/include/flang/Lower/CustomIntrinsicCall.h
flang/include/flang/Lower/LoweringOptions.def
flang/include/flang/Optimizer/Builder/IntrinsicCall.h
flang/include/flang/Optimizer/Builder/PPCIntrinsicCall.h
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/Lower/ConvertExpr.cpp
flang/lib/Lower/CustomIntrinsicCall.cpp
flang/lib/Optimizer/Builder/IntrinsicCall.cpp
flang/lib/Optimizer/Builder/PPCIntrinsicCall.cpp
flang/test/Driver/driver-help-hidden.f90
flang/test/Driver/driver-help.f90
flang/test/Driver/frontend-forwarding.f90
flang/tools/bbc/bbc.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 840cfa3f368504..fb3534133b5213 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5416,6 +5416,9 @@ defm xor_operator : OptInFC1FFlag<"xor-operator", "Enable 
.XOR. as a synonym of
 defm logical_abbreviations : OptInFC1FFlag<"logical-abbreviations", "Enable 
logical abbreviations">;
 defm implicit_none : OptInFC1FFlag<"implicit-none", "No implicit typing 
allowed unless overridden by IMPLICIT statements">;
 defm underscoring : OptInFC1FFlag<"underscoring", "Appends one trailing 
underscore to external names">;
+defm ppc_native_vec_elem_order: BoolOptionWithoutMarshalling<"f", 
"ppc-native-vector-element-order",
+  PosFlag,
+  NegFlag>;
 
 def fno_automatic : Flag<["-"], "fno-automatic">, Group,
   HelpText<"Implies the SAVE attribute for non-automatic local objects in 
subprograms unless RECURSIVE">;

diff  --git a/clang/lib/Driver/ToolChains/Flang.cpp 
b/clang/lib/Driver/ToolChains/Flang.cpp
index 0c86f5269cddd7..d0ab58bf4a8559 100644
--- a/clang/lib/Driver/ToolChains/Flang.cpp
+++ b/clang/lib/Driver/ToolChains/Flang.cpp
@@ -144,7 +144,9 @@ void Flang::addCodegenOptions(const ArgList ,
 CmdArgs.push_back("-fversion-loops-for-stride");
 
   Args.AddAllArgs(CmdArgs, {options::OPT_flang_experimental_hlfir,
-options::OPT_flang_experimental_polymorphism});
+options::OPT_flang_experimental_polymorphism,
+options::OPT_fno_ppc_native_vec_elem_order,
+options::OPT_fppc_native_vec_elem_order});
 }
 
 void Flang::addPicOptions(const ArgList , ArgStringList ) const {

diff  --git a/flang/include/flang/Lower/CustomIntrinsicCall.h 
b/flang/include/flang/Lower/CustomIntrinsicCall.h
index 253a53c2346f93..31d0d0e07899a2 100644
--- a/flang/include/flang/Lower/CustomIntrinsicCall.h
+++ b/flang/include/flang/Lower/CustomIntrinsicCall.h
@@ -103,11 +103,12 @@ lowerCustomIntrinsic(fir::FirOpBuilder , 
mlir::Location loc,
 /// Generate the FIR+MLIR operations for the generic intrinsic \p name
 /// with argument \p args and expected result type \p resultType.
 /// Returned fir::ExtendedValue is the returned Fortran intrinsic value.
-fir::ExtendedValue genIntrinsicCall(fir::FirOpBuilder ,
-mlir::Location loc, llvm::StringRef name,
-std::optional resultType,
-llvm::ArrayRef args,
-StatementContext );
+fir::ExtendedValue
+genIntrinsicCall(fir::FirOpBuilder , mlir::Location loc,
+ llvm::StringRef name, std::optional resultType,
+ llvm::ArrayRef args,
+ StatementContext ,
+ Fortran::lower::AbstractConverter *converter = nullptr);
 
 } // namespace lower
 } // namespace Fortran

diff  --git a/flang/include/flang/Lower/LoweringOptions.def 
b/flang/include/flang/Lower/LoweringOptions.def
index 2a89308467fd90..0ab7c5220d24c4 100644
--- a/flang/include/flang/Lower/LoweringOptions.def
+++ b/flang/include/flang/Lower/LoweringOptions.def
@@ -31,5 +31,8 @@ ENUM_LOWERINGOPT(PolymorphicTypeImpl, unsigned, 1, 0)
 /// Off by default until fully ready.
 ENUM_LOWERINGOPT(LowerToHighLevelFIR, unsigned, 1, 0)
 
+/// If true, reverse PowerPC native vector element order.
+ENUM_LOWERINGOPT(NoPPCNativeVecElemOrder, unsigned, 1, 0)
+
 

[PATCH] D156886: [CUDA][HIP] Reorganize options for documentation

2023-08-04 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 2 inline comments as done.
yaxunl added inline comments.



Comment at: clang/include/clang/Driver/Options.td:155
+def offload_Group : OptionGroup<"">, Group,
+   DocName<"Common Offloading flags">;
+

MaskRay wrote:
> The existing `flags` uses are misnomer (`Flag` does not accept values). 
> Perhaps use `options` for new option groups.
will do



Comment at: clang/include/clang/Driver/Options.td:1021
+def offload_host_device : Flag<["--"], "offload-host-device">, 
Flags<[FlangOption]>,
+  HelpText<"Only compile for the offloading host.">;
+

jhuber6 wrote:
> Can you fix this copy paste error while you're here?
It has been fixed in the trunk.


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

https://reviews.llvm.org/D156886

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


[PATCH] D157033: [clang][CFG] Fix 2 memory errors in interval computation.

2023-08-04 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe21b1dd9cc53: [clang][CFG] Fix 2 memory errors in interval 
computation. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157033

Files:
  clang/lib/Analysis/IntervalPartition.cpp
  clang/unittests/Analysis/IntervalPartitionTest.cpp

Index: clang/unittests/Analysis/IntervalPartitionTest.cpp
===
--- clang/unittests/Analysis/IntervalPartitionTest.cpp
+++ clang/unittests/Analysis/IntervalPartitionTest.cpp
@@ -360,5 +360,38 @@
   Optional(blockOrder(9, 8, 7, 6, 1, 0, 5, 4, 2, 3)));
 }
 
+TEST(GetIntervalWTO, UnreachablePred) {
+  const char *Code = R"(
+  void target(bool Foo) {
+bool Bar = false;
+if (Foo)
+  Bar = Foo;
+else
+  __builtin_unreachable();
+(void)0;
+  })";
+  BuildResult Result = BuildCFG(Code);
+  ASSERT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+  EXPECT_THAT(getIntervalWTO(*Result.getCFG()),
+  Optional(blockOrder(5, 4, 3, 2, 1, 0)));
+}
+
+TEST(WTOCompare, UnreachableBlock) {
+  const char *Code = R"(
+void target() {
+  while (true) {}
+  (void)0;
+  /*[[p]]*/
+})";
+  BuildResult Result = BuildCFG(Code);
+  ASSERT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+  std::optional WTO = getIntervalWTO(*Result.getCFG());
+  ASSERT_THAT(WTO, Optional(blockOrder(4, 3, 2)));
+  auto Cmp = WTOCompare(*WTO);
+  const CFGBlock  = Result.getCFG()->getEntry();
+  const CFGBlock  = Result.getCFG()->getExit();
+  EXPECT_TRUE(Cmp(, ));
+}
+
 } // namespace
 } // namespace clang
Index: clang/lib/Analysis/IntervalPartition.cpp
===
--- clang/lib/Analysis/IntervalPartition.cpp
+++ clang/lib/Analysis/IntervalPartition.cpp
@@ -16,7 +16,6 @@
 #include "llvm/ADT/STLExtras.h"
 #include 
 #include 
-#include 
 #include 
 
 namespace clang {
@@ -24,23 +23,25 @@
 // Intermediate data used in constructing a CFGIntervalNode.
 template  struct BuildResult {
   // Use a vector to maintain the insertion order. Given the expected small
-  // number of nodes, vector should be sufficiently efficient.
+  // number of nodes, vector should be sufficiently efficient. Elements must not
+  // be null.
   std::vector Nodes;
+  // Elements must not be null.
   llvm::SmallDenseSet Successors;
 };
 
 namespace internal {
-static unsigned getID(const CFGBlock *B) { return B->getBlockID(); }
-static unsigned getID(const CFGIntervalNode *I) { return I->ID; }
+static unsigned getID(const CFGBlock ) { return B.getBlockID(); }
+static unsigned getID(const CFGIntervalNode ) { return I.ID; }
 
 // `Node` must be one of `CFGBlock` or `CFGIntervalNode`.
 template 
 BuildResult buildInterval(llvm::BitVector ,
 const Node *Header) {
-  assert(Header);
+  assert(Header != nullptr);
   BuildResult Interval;
   Interval.Nodes.push_back(Header);
-  Partitioned.set(getID(Header));
+  Partitioned.set(getID(*Header));
 
   // FIXME: Compare performance against using RPO to consider nodes, rather than
   // following successors.
@@ -50,7 +51,7 @@
   llvm::BitVector Workset(Partitioned.size(), false);
   for (const Node *S : Header->succs())
 if (S != nullptr)
-  if (auto SID = getID(S); !Partitioned.test(SID)) {
+  if (auto SID = getID(*S); !Partitioned.test(SID)) {
 // Successors are unique, so we don't test against `Workset` before
 // adding to `Worklist`.
 Worklist.push(S);
@@ -63,12 +64,12 @@
   // yet. In the latter case, we'll revisit the block through some other path
   // from the interval. At the end of processing the worklist, we filter out any
   // that ended up in the interval to produce the output set of interval
-  // successors.
+  // successors. Elements are never null.
   std::vector MaybeSuccessors;
 
   while (!Worklist.empty()) {
 const auto *B = Worklist.front();
-auto ID = getID(B);
+auto ID = getID(*B);
 Worklist.pop();
 Workset.reset(ID);
 
@@ -82,7 +83,7 @@
   Partitioned.set(ID);
   for (const Node *S : B->succs())
 if (S != nullptr)
-  if (auto SID = getID(S);
+  if (auto SID = getID(*S);
   !Partitioned.test(SID) && !Workset.test(SID)) {
 Worklist.push(S);
 Workset.set(SID);
@@ -116,8 +117,9 @@
   // graph. In this case, the new interval has identifier `ID` so all of its
   // nodes (`Result.Nodes`) map to `ID`.
   for (const auto *N : Result.Nodes) {
-assert(getID(N) < Index.size());
-Index[getID(N)] = 
+assert(N != nullptr);
+assert(getID(*N) < Index.size());
+Index[getID(*N)] = 
   }
 
   if constexpr (std::is_same_v, CFGBlock>)
@@ -159,7 +161,8 @@
   while (!Successors.empty()) {
 const auto *B = Successors.front();
 Successors.pop();
-if 

[clang] e21b1dd - [clang][CFG] Fix 2 memory errors in interval computation.

2023-08-04 Thread Yitzhak Mandelbaum via cfe-commits

Author: Yitzhak Mandelbaum
Date: 2023-08-04T21:10:35Z
New Revision: e21b1dd9cc5316c00216ba54f899f67fe473ab33

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

LOG: [clang][CFG] Fix 2 memory errors in interval computation.

This fixes 2 bugs and adds corresponding tests. Both related to unreachable
blocks. One occured in the `WTOCompare` construction, which assumed the size of
the order was the same as the number of blocks in the CFG, which isn't true when
some blocks are unreachable.  The other assumed predecessor pointers were
non-null, which can be false for blocks with unreachable predecessors.

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

Added: 


Modified: 
clang/lib/Analysis/IntervalPartition.cpp
clang/unittests/Analysis/IntervalPartitionTest.cpp

Removed: 




diff  --git a/clang/lib/Analysis/IntervalPartition.cpp 
b/clang/lib/Analysis/IntervalPartition.cpp
index db54c9dc676989..5f06606ec132e9 100644
--- a/clang/lib/Analysis/IntervalPartition.cpp
+++ b/clang/lib/Analysis/IntervalPartition.cpp
@@ -16,7 +16,6 @@
 #include "llvm/ADT/STLExtras.h"
 #include 
 #include 
-#include 
 #include 
 
 namespace clang {
@@ -24,23 +23,25 @@ namespace clang {
 // Intermediate data used in constructing a CFGIntervalNode.
 template  struct BuildResult {
   // Use a vector to maintain the insertion order. Given the expected small
-  // number of nodes, vector should be sufficiently efficient.
+  // number of nodes, vector should be sufficiently efficient. Elements must 
not
+  // be null.
   std::vector Nodes;
+  // Elements must not be null.
   llvm::SmallDenseSet Successors;
 };
 
 namespace internal {
-static unsigned getID(const CFGBlock *B) { return B->getBlockID(); }
-static unsigned getID(const CFGIntervalNode *I) { return I->ID; }
+static unsigned getID(const CFGBlock ) { return B.getBlockID(); }
+static unsigned getID(const CFGIntervalNode ) { return I.ID; }
 
 // `Node` must be one of `CFGBlock` or `CFGIntervalNode`.
 template 
 BuildResult buildInterval(llvm::BitVector ,
 const Node *Header) {
-  assert(Header);
+  assert(Header != nullptr);
   BuildResult Interval;
   Interval.Nodes.push_back(Header);
-  Partitioned.set(getID(Header));
+  Partitioned.set(getID(*Header));
 
   // FIXME: Compare performance against using RPO to consider nodes, rather 
than
   // following successors.
@@ -50,7 +51,7 @@ BuildResult buildInterval(llvm::BitVector ,
   llvm::BitVector Workset(Partitioned.size(), false);
   for (const Node *S : Header->succs())
 if (S != nullptr)
-  if (auto SID = getID(S); !Partitioned.test(SID)) {
+  if (auto SID = getID(*S); !Partitioned.test(SID)) {
 // Successors are unique, so we don't test against `Workset` before
 // adding to `Worklist`.
 Worklist.push(S);
@@ -63,12 +64,12 @@ BuildResult buildInterval(llvm::BitVector 
,
   // yet. In the latter case, we'll revisit the block through some other path
   // from the interval. At the end of processing the worklist, we filter out 
any
   // that ended up in the interval to produce the output set of interval
-  // successors.
+  // successors. Elements are never null.
   std::vector MaybeSuccessors;
 
   while (!Worklist.empty()) {
 const auto *B = Worklist.front();
-auto ID = getID(B);
+auto ID = getID(*B);
 Worklist.pop();
 Workset.reset(ID);
 
@@ -82,7 +83,7 @@ BuildResult buildInterval(llvm::BitVector ,
   Partitioned.set(ID);
   for (const Node *S : B->succs())
 if (S != nullptr)
-  if (auto SID = getID(S);
+  if (auto SID = getID(*S);
   !Partitioned.test(SID) && !Workset.test(SID)) {
 Worklist.push(S);
 Workset.set(SID);
@@ -116,8 +117,9 @@ void fillIntervalNode(CFGIntervalGraph ,
   // graph. In this case, the new interval has identifier `ID` so all of its
   // nodes (`Result.Nodes`) map to `ID`.
   for (const auto *N : Result.Nodes) {
-assert(getID(N) < Index.size());
-Index[getID(N)] = 
+assert(N != nullptr);
+assert(getID(*N) < Index.size());
+Index[getID(*N)] = 
   }
 
   if constexpr (std::is_same_v, CFGBlock>)
@@ -159,7 +161,8 @@ CFGIntervalGraph partitionIntoIntervalsImpl(unsigned 
NumBlockIDs,
   while (!Successors.empty()) {
 const auto *B = Successors.front();
 Successors.pop();
-if (Partitioned.test(getID(B)))
+assert(B != nullptr);
+if (Partitioned.test(getID(*B)))
   continue;
 
 // B has not been partitioned, but it has a predecessor that has. Create a
@@ -173,8 +176,11 @@ CFGIntervalGraph partitionIntoIntervalsImpl(unsigned 
NumBlockIDs,
 // Map input-graph predecessors to output-graph nodes and mark those as
 // predecessors of `N`. Then, mark `N` as a successor of 

[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

2023-08-04 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D156928#4561811 , @JonChesterfield 
wrote:

> What does code objects version= none mean?

Handle any version


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928

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


[PATCH] D157029: [llvm] Construct option's prefixed name at compile-time

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 547339.
jansvoboda11 added a comment.

Rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157029

Files:
  clang-tools-extra/clangd/CompileCommands.cpp
  clang/lib/Driver/Driver.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Tooling/Tooling.cpp
  llvm/include/llvm/Option/OptTable.h
  llvm/include/llvm/Option/Option.h
  llvm/lib/Option/OptTable.cpp
  llvm/unittests/Option/OptionMarshallingTest.cpp
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -34,30 +34,14 @@
   return OS;
 }
 
-static std::string getOptionSpelling(const Record , size_t ) {
+static std::string getOptionPrefixedName(const Record ) {
   std::vector Prefixes = R.getValueAsListOfStrings("Prefixes");
   StringRef Name = R.getValueAsString("Name");
 
-  if (Prefixes.empty()) {
-PrefixLength = 0;
+  if (Prefixes.empty())
 return Name.str();
-  }
-
-  PrefixLength = Prefixes[0].size();
-  return (Twine(Prefixes[0]) + Twine(Name)).str();
-}
 
-static std::string getOptionSpelling(const Record ) {
-  size_t PrefixLength;
-  return getOptionSpelling(R, PrefixLength);
-}
-
-static void emitNameUsingSpelling(raw_ostream , const Record ) {
-  size_t PrefixLength;
-  OS << "llvm::StringLiteral(";
-  write_cstring(
-  OS, StringRef(getOptionSpelling(R, PrefixLength)).substr(PrefixLength));
-  OS << ")";
+  return (Prefixes[0] + Twine(Name)).str();
 }
 
 class MarshallingInfo {
@@ -105,8 +89,6 @@
   }
 
   void emit(raw_ostream ) const {
-write_cstring(OS, StringRef(getOptionSpelling(R)));
-OS << ", ";
 OS << ShouldParse;
 OS << ", ";
 OS << ShouldAlwaysEmit;
@@ -303,7 +285,7 @@
 // The option prefix;
 OS << "llvm::ArrayRef()";
 
-// The option string.
+// The option prefixed name.
 OS << ", \"" << R.getValueAsString("Name") << '"';
 
 // The option identifier name.
@@ -346,8 +328,10 @@
 std::vector RPrefixes = R.getValueAsListOfStrings("Prefixes");
 OS << Prefixes[PrefixKeyT(RPrefixes.begin(), RPrefixes.end())] << ", ";
 
-// The option string.
-emitNameUsingSpelling(OS, R);
+// The option prefixed name.
+OS << "llvm::StringLiteral(";
+write_cstring(OS, getOptionPrefixedName(R));
+OS << ")";
 
 // The option identifier name.
 OS << ", " << getOptionName(R);
Index: llvm/unittests/Option/OptionMarshallingTest.cpp
===
--- llvm/unittests/Option/OptionMarshallingTest.cpp
+++ llvm/unittests/Option/OptionMarshallingTest.cpp
@@ -10,7 +10,7 @@
 #include "gtest/gtest.h"
 
 struct OptionWithMarshallingInfo {
-  llvm::StringRef Name;
+  llvm::StringLiteral PrefixedName;
   const char *KeyPath;
   const char *ImpliedCheck;
   const char *ImpliedValue;
@@ -18,20 +18,20 @@
 
 static const OptionWithMarshallingInfo MarshallingTable[] = {
 #define OPTION_WITH_MARSHALLING(   \
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
-HELPTEXT, METAVAR, VALUES, SPELLING, SHOULD_PARSE, ALWAYS_EMIT, KEYPATH,   \
+PREFIX_TYPE, PREFIXED_NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS,  \
+PARAM, HELPTEXT, METAVAR, VALUES, SHOULD_PARSE, ALWAYS_EMIT, KEYPATH,  \
 DEFAULT_VALUE, IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, \
 MERGER, EXTRACTOR, TABLE_INDEX)\
-  {NAME, #KEYPATH, #IMPLIED_CHECK, #IMPLIED_VALUE},
+  {PREFIXED_NAME, #KEYPATH, #IMPLIED_CHECK, #IMPLIED_VALUE},
 #include "Opts.inc"
 #undef OPTION_WITH_MARSHALLING
 };
 
 TEST(OptionMarshalling, EmittedOrderSameAsDefinitionOrder) {
-  ASSERT_STREQ(MarshallingTable[0].Name.data(), "marshalled-flag-d");
-  ASSERT_STREQ(MarshallingTable[1].Name.data(), "marshalled-flag-c");
-  ASSERT_STREQ(MarshallingTable[2].Name.data(), "marshalled-flag-b");
-  ASSERT_STREQ(MarshallingTable[3].Name.data(), "marshalled-flag-a");
+  ASSERT_EQ(MarshallingTable[0].PrefixedName, "-marshalled-flag-d");
+  ASSERT_EQ(MarshallingTable[1].PrefixedName, "-marshalled-flag-c");
+  ASSERT_EQ(MarshallingTable[2].PrefixedName, "-marshalled-flag-b");
+  ASSERT_EQ(MarshallingTable[3].PrefixedName, "-marshalled-flag-a");
 }
 
 TEST(OptionMarshalling, EmittedSpecifiedKeyPath) {
Index: llvm/lib/Option/OptTable.cpp
===
--- llvm/lib/Option/OptTable.cpp
+++ llvm/lib/Option/OptTable.cpp
@@ -59,7 +59,7 @@
   if ( == )
 return false;
 
-  if (int N = StrCmpOptionName(A.Name, B.Name))
+  if (int N = StrCmpOptionName(A.getName(), B.getName()))
 return N < 0;
 
   for (size_t I = 0, K = std::min(A.Prefixes.size(), B.Prefixes.size()); I != K;

[PATCH] D157028: [llvm] Extract common `OptTable` bits into macros

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3f092f37b736: [llvm] Extract common `OptTable` bits into 
macros (authored by jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157028

Files:
  clang/include/clang/Driver/Options.h
  clang/lib/Driver/DriverOptions.cpp
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp
  lld/COFF/Driver.h
  lld/COFF/DriverUtils.cpp
  lld/ELF/Driver.h
  lld/ELF/DriverUtils.cpp
  lld/MachO/Driver.h
  lld/MinGW/Driver.cpp
  lld/wasm/Driver.cpp
  lldb/tools/driver/Driver.cpp
  lldb/tools/lldb-server/lldb-gdbserver.cpp
  lldb/tools/lldb-vscode/lldb-vscode.cpp
  llvm/include/llvm/Option/OptTable.h
  llvm/lib/ExecutionEngine/JITLink/COFFDirectiveParser.cpp
  llvm/lib/ExecutionEngine/JITLink/COFFDirectiveParser.h
  llvm/lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
  llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp
  llvm/tools/dsymutil/dsymutil.cpp
  llvm/tools/llvm-cvtres/llvm-cvtres.cpp
  llvm/tools/llvm-cxxfilt/llvm-cxxfilt.cpp
  llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp
  llvm/tools/llvm-dwarfutil/llvm-dwarfutil.cpp
  llvm/tools/llvm-dwp/llvm-dwp.cpp
  llvm/tools/llvm-gsymutil/llvm-gsymutil.cpp
  llvm/tools/llvm-ifs/llvm-ifs.cpp
  llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp
  llvm/tools/llvm-lipo/llvm-lipo.cpp
  llvm/tools/llvm-ml/llvm-ml.cpp
  llvm/tools/llvm-mt/llvm-mt.cpp
  llvm/tools/llvm-nm/llvm-nm.cpp
  llvm/tools/llvm-objcopy/ObjcopyOptions.cpp
  llvm/tools/llvm-objdump/ObjdumpOptID.h
  llvm/tools/llvm-objdump/llvm-objdump.cpp
  llvm/tools/llvm-rc/llvm-rc.cpp
  llvm/tools/llvm-readobj/llvm-readobj.cpp
  llvm/tools/llvm-size/llvm-size.cpp
  llvm/tools/llvm-strings/llvm-strings.cpp
  llvm/tools/llvm-symbolizer/llvm-symbolizer.cpp
  llvm/tools/llvm-tli-checker/llvm-tli-checker.cpp
  llvm/tools/sancov/sancov.cpp
  llvm/unittests/Option/OptionParsingTest.cpp

Index: llvm/unittests/Option/OptionParsingTest.cpp
===
--- llvm/unittests/Option/OptionParsingTest.cpp
+++ llvm/unittests/Option/OptionParsingTest.cpp
@@ -17,9 +17,7 @@
 
 enum ID {
   OPT_INVALID = 0, // This is not an option ID.
-#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
-   HELPTEXT, METAVAR, VALUES)  \
-  OPT_##ID,
+#define OPTION(...) LLVM_MAKE_OPT_ID(__VA_ARGS__),
 #include "Opts.inc"
   LastOption
 #undef OPTION
@@ -47,10 +45,7 @@
 };
 
 static constexpr OptTable::Info InfoTable[] = {
-#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
-   HELPTEXT, METAVAR, VALUES)  \
-  {PREFIX, NAME,  HELPTEXT,METAVAR, OPT_##ID,  Option::KIND##Class,\
-   PARAM,  FLAGS, OPT_##GROUP, OPT_##ALIAS, ALIASARGS, VALUES},
+#define OPTION(...) LLVM_CONSTRUCT_OPT_INFO(__VA_ARGS__),
 #include "Opts.inc"
 #undef OPTION
 };
Index: llvm/tools/sancov/sancov.cpp
===
--- llvm/tools/sancov/sancov.cpp
+++ llvm/tools/sancov/sancov.cpp
@@ -63,9 +63,7 @@
 using namespace llvm::opt;
 enum ID {
   OPT_INVALID = 0, // This is not an option ID.
-#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
-   HELPTEXT, METAVAR, VALUES)  \
-  OPT_##ID,
+#define OPTION(...) LLVM_MAKE_OPT_ID(__VA_ARGS__),
 #include "Opts.inc"
 #undef OPTION
 };
@@ -78,13 +76,7 @@
 #undef PREFIX
 
 static constexpr opt::OptTable::Info InfoTable[] = {
-#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
-   HELPTEXT, METAVAR, VALUES)  \
-  {\
-  PREFIX,  NAME,  HELPTEXT,\
-  METAVAR, OPT_##ID,  opt::Option::KIND##Class,\
-  PARAM,   FLAGS, OPT_##GROUP, \
-  OPT_##ALIAS, ALIASARGS, VALUES},
+#define OPTION(...) LLVM_CONSTRUCT_OPT_INFO(__VA_ARGS__),
 #include "Opts.inc"
 #undef OPTION
 };
Index: llvm/tools/llvm-tli-checker/llvm-tli-checker.cpp
===
--- llvm/tools/llvm-tli-checker/llvm-tli-checker.cpp
+++ llvm/tools/llvm-tli-checker/llvm-tli-checker.cpp
@@ -28,9 +28,7 @@
 namespace {
 enum ID {
   OPT_INVALID = 0, // This is not an option ID.
-#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
-   HELPTEXT, METAVAR, VALUES)  \
-  OPT_##ID,
+#define OPTION(...) LLVM_MAKE_OPT_ID(__VA_ARGS__),
 #include "Opts.inc"
 #undef OPTION
 };
@@ -43,13 +41,7 @@
 #undef PREFIX
 
 static constexpr 

[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

2023-08-04 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

What does code objects version= none mean?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928

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


[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

2023-08-04 Thread John McIver via Phabricator via cfe-commits
jmciver added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155773

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


[PATCH] D156749: [modules] Fix error about the same module being defined in different .pcm files when using VFS overlays.

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

In D156749#4552590 , @vsapsai wrote:

> In D156749#4551596 , @jansvoboda11 
> wrote:
>
>> Alternatively, we could keep VFS overlays out of the context hash but create 
>> `` from the on-disk real path of the defining module map and make the 
>> whole PCM VFS-agnostic. Then it'd be correct to import that PCM regardless 
>> of the specific VFS overlay setup, as long as all VFS queries of the 
>> importer resolve the same way they resolved within the instance that built 
>> the PCM. Maybe we can force the importer to recompile the PCM if that's not 
>> the case, similar to what we do for diagnostic options.
>
> I'm not sure I understand your proposal. Before this change we were 
> calculating hash from the on-disk real path of the defining module map. And 
> due to different VFS/no-VFS options defining module map is at different 
> locations on-disk.

My suggestion is to use the actual real on-disk path. Not 
`FileEntryRef::getName()`, but something that always behaves as if 
`use-external-name` was set to `true`. I believe this would handle your 
VFS/VFS-use-external-name-true/VFS-use-external-name-false problem. It would 
also handle another pitfall: two compilations with distinct VFS overlays that 
redirect two different as-requested module map paths into the same on-disk path.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156749

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


[PATCH] D145138: [clang-tidy] Implement FixIts for C arrays

2023-08-04 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added a comment.

Test are failing, and I do not think that converting c-strings into std::array 
is a good idea


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145138

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


[PATCH] D157057: [clang-tidy] Implement cppcoreguidelines CP.52

2023-08-04 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added a comment.

Consider ignoring template instances, to avoid generating lot of warnings for 
each instance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157057

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


[PATCH] D157057: [clang-tidy] Implement cppcoreguidelines CP.52

2023-08-04 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/NoSuspendWithLockCheck.cpp:24-26
+  hasType(recordDecl(hasAnyName(
+  "::std::unique_lock", "::std::lock_guard",
+  "::std::scoped_lock", 
"::std::shared_lock"

add configuration option for lock types, many big project got own types or 
wrappers.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/no-suspend-with-lock.rst:13
+Instead, locks should be released before suspending a coroutine.
+
+Examples:

add info to documentation that manual locking/unlocking is not supported.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/no-suspend-with-lock.cpp:189
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: coroutine suspended with lock 
'lock' held [cppcoreguidelines-no-suspend-with-lock]
+}

add test with lambda, something like:
```
std::unique_lock lock(mtx);

auto lambda = [] { co_yeld 0; }
```

And add test with class defined in function with co_yeld in class, and lock in 
function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157057

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


[PATCH] D155895: Anonymous unions should be transparent wrt `[[clang::trivial_abi]]`.

2023-08-04 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 accepted this revision.
gribozavr2 added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/SemaCXX/attr-trivial-abi.cpp:258
+  
static_assert(__is_trivially_relocatable(TrivialAbiAttributeAppliedToAnonymousUnion),
 "");
+#endif
+

Is it possible to restructure the ifdefs to only wrap the different parts?

That is, you can place only the `expected-warning` line and `static_assert` 
lines within ifdefs. You can use the `@`-syntax on `expected-warning` to tell 
clang to expect the warning on a different line, for example see 
`test/SemaCXX/deprecated.cpp`.


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

https://reviews.llvm.org/D155895

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


[PATCH] D157135: [OpenMP][Docs] Update OpenMP supported features table

2023-08-04 Thread David Pagan via Phabricator via cfe-commits
ddpagan created this revision.
ddpagan added a reviewer: ABataev.
Herald added subscribers: guansong, yaxunl.
Herald added a project: All.
ddpagan requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, jplehr, sstefan1.
Herald added a project: clang.

Updated status of alignment clause for allocate directive in OpenMP features 
table, section OpenMP 5.1 Implementation Details.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157135

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -309,7 +309,7 @@
 
+--+--+--+---+
 | loop | 'reproducible'/'unconstrained' modifiers in 
'order' clause   | :part:`partial`  | D127855   
|
 
+--+--+--+---+
-| memory management| alignment for allocate directive and clause   
   | :part:`worked on`| 
  |
+| memory management| alignment for allocate directive and clause   
   | :good:`done` | D115683 
  |
 
+--+--+--+---+
 | memory management| new memory management routines
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -309,7 +309,7 @@
 +--+--+--+---+
 | loop | 'reproducible'/'unconstrained' modifiers in 'order' clause   | :part:`partial`  | D127855   |
 +--+--+--+---+
-| memory management| alignment for allocate directive and clause  | :part:`worked on`|   |
+| memory management| alignment for allocate directive and clause  | :good:`done` | D115683   |
 +--+--+--+---+
 | memory management| new memory management routines   | :none:`unclaimed`|   |
 +--+--+--+---+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D156596: [Clang] Produce a warning instead of an error in unevaluated strings before C++26

2023-08-04 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added a comment.

In D156596#4558097 , @cor3ntin wrote:

> Note: we are waiting for feedback from @hubert.reinterpretcast's people 
> before progressing this.

The "full" build hit some (unrelated) snags, but the initial results look good. 
The patch is awaiting C test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156596

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


[PATCH] D140760: [clang-tidy] Support begin/end free functions in modernize-loop-convert

2023-08-04 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL accepted this revision.
PiotrZSL added a comment.
This revision is now accepted and ready to land.

LGTM, things that are missing:

- some crash protection (getName)
- test for rbegin/rend




Comment at: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp:333
 
+enum IteratorCallKind {
+  ICK_Member,

if we can, please use enum class



Comment at: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp:363
+  return ContainerCall{TheCall->getImplicitObjectArgument(),
+   Member->getMemberDecl()->getName(),
+   Member->isArrow(), CallKind};

would be nice to verify if we got "name" here, same in other places



Comment at: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp:940
+return false;
+} else
+  return Nodes.getNodeAs(EndCallName) != nullptr;

no need for else after return



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/modernize/loop-convert-basic.cpp:484
 }
 
 // Tests to verify the proper use of auto where the init variable type and the

Please add test with rbegin/rend


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140760

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


[PATCH] D157115: Revert "[clang][X86] Add __cpuidex function to cpuid.h"

2023-08-04 Thread Aiden Grossman via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf3baf63d9a1b: Revert [clang][X86] Add __cpuidex 
function to cpuid.h (authored by aidengrossman).

Changed prior to commit:
  https://reviews.llvm.org/D157115?vs=547247=547329#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157115

Files:
  clang/lib/Headers/cpuid.h
  clang/test/Headers/__cpuidex_conflict.c
  clang/test/Headers/cpuid.c


Index: clang/test/Headers/cpuid.c
===
--- clang/test/Headers/cpuid.c
+++ clang/test/Headers/cpuid.c
@@ -6,19 +6,14 @@
 
 // CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A 
cpuid\0A xchgq %rbx,${1:q}", 
"={ax},=r,={cx},={dx},0,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}})
 // CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A  
cpuid\0A  xchgq  %rbx,${1:q}", 
"={ax},=r,={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 
%{{[a-z0-9]+}})
-// CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A  
cpuid\0A  xchgq  %rbx,${1:q}", 
"={ax},=r,={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 
%{{[a-z0-9]+}})
 
 // CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", 
"={ax},={bx},={cx},={dx},0,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}})
 // CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", 
"={ax},={bx},={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, 
i32 %{{[a-z0-9]+}})
-// CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", 
"={ax},={bx},={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, 
i32 %{{[a-z0-9]+}})
 
 unsigned eax0, ebx0, ecx0, edx0;
 unsigned eax1, ebx1, ecx1, edx1;
 
-int cpuid_info[4];
-
 void test_cpuid(unsigned level, unsigned count) {
   __cpuid(level, eax1, ebx1, ecx1, edx1);
   __cpuid_count(level, count, eax0, ebx0, ecx0, edx0);
-  __cpuidex(cpuid_info, level, count);
 }
Index: clang/test/Headers/__cpuidex_conflict.c
===
--- clang/test/Headers/__cpuidex_conflict.c
+++ /dev/null
@@ -1,15 +0,0 @@
-// Make sure that __cpuidex in cpuid.h doesn't conflict with the MS
-// compatibility built in by ensuring compilation succeeds:
-// RUN: %clang_cc1 %s -ffreestanding -fms-extensions -fms-compatibility \
-// RUN:  -fms-compatibility-version=19.00 -triple x86_64-pc-windows-msvc 
-emit-llvm -o -
-
-typedef __SIZE_TYPE__ size_t;
-
-#include 
-#include 
-
-int cpuid_info[4];
-
-void test_cpuidex(unsigned level, unsigned count) {
-  __cpuidex(cpuid_info, level, count);
-}
Index: clang/lib/Headers/cpuid.h
===
--- clang/lib/Headers/cpuid.h
+++ clang/lib/Headers/cpuid.h
@@ -328,14 +328,4 @@
 return 1;
 }
 
-// If MS extensions are enabled, __cpuidex is defined as a builtin which will
-// conflict with the __cpuidex definition below.
-#ifndef _MSC_EXTENSIONS
-static __inline void __cpuidex (int __cpu_info[4], int __leaf, int __subleaf)
-{
-  __cpuid_count(__leaf, __subleaf, __cpu_info[0], __cpu_info[1], __cpu_info[2],
-__cpu_info[3]);
-}
-#endif
-
 #endif /* __CPUID_H */


Index: clang/test/Headers/cpuid.c
===
--- clang/test/Headers/cpuid.c
+++ clang/test/Headers/cpuid.c
@@ -6,19 +6,14 @@
 
 // CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A cpuid\0A xchgq %rbx,${1:q}", "={ax},=r,={cx},={dx},0,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}})
 // CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A  cpuid\0A  xchgq  %rbx,${1:q}", "={ax},=r,={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 %{{[a-z0-9]+}})
-// CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A  cpuid\0A  xchgq  %rbx,${1:q}", "={ax},=r,={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 %{{[a-z0-9]+}})
 
 // CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", "={ax},={bx},={cx},={dx},0,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}})
 // CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", "={ax},={bx},={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 %{{[a-z0-9]+}})
-// CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", "={ax},={bx},={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 %{{[a-z0-9]+}})
 
 unsigned eax0, ebx0, ecx0, edx0;
 unsigned eax1, ebx1, ecx1, edx1;
 
-int cpuid_info[4];
-
 void test_cpuid(unsigned level, unsigned count) {
   __cpuid(level, eax1, ebx1, ecx1, edx1);
   __cpuid_count(level, count, eax0, ebx0, ecx0, edx0);
-  __cpuidex(cpuid_info, level, count);
 }
Index: clang/test/Headers/__cpuidex_conflict.c

[clang] f3baf63 - Revert "[clang][X86] Add __cpuidex function to cpuid.h"

2023-08-04 Thread Aiden Grossman via cfe-commits

Author: Aiden Grossman
Date: 2023-08-04T13:28:53-07:00
New Revision: f3baf63d9a1ba91974f4df6abb8f2abd9a0df5b5

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

LOG: Revert "[clang][X86] Add __cpuidex function to cpuid.h"

This reverts commit 2df77ac20a1ed996706b164b0c4ed5ad140f635f.

This has been causing some issues with some windows builds as
_MSC_EXTENSIONS isn't defined when only -fms-extensions is set, but the
builtin that conflicts with __cpuidex is. This was also causing problems
as it exposed some latent issues with how auxiliary triples are handled
in clang.

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

Added: 


Modified: 
clang/lib/Headers/cpuid.h
clang/test/Headers/cpuid.c

Removed: 
clang/test/Headers/__cpuidex_conflict.c



diff  --git a/clang/lib/Headers/cpuid.h b/clang/lib/Headers/cpuid.h
index 454f74e92f85a0..1ad6853a97c9d2 100644
--- a/clang/lib/Headers/cpuid.h
+++ b/clang/lib/Headers/cpuid.h
@@ -328,14 +328,4 @@ static __inline int __get_cpuid_count (unsigned int __leaf,
 return 1;
 }
 
-// If MS extensions are enabled, __cpuidex is defined as a builtin which will
-// conflict with the __cpuidex definition below.
-#ifndef _MSC_EXTENSIONS
-static __inline void __cpuidex (int __cpu_info[4], int __leaf, int __subleaf)
-{
-  __cpuid_count(__leaf, __subleaf, __cpu_info[0], __cpu_info[1], __cpu_info[2],
-__cpu_info[3]);
-}
-#endif
-
 #endif /* __CPUID_H */

diff  --git a/clang/test/Headers/__cpuidex_conflict.c 
b/clang/test/Headers/__cpuidex_conflict.c
deleted file mode 100644
index 0eff1ff425f83e..00
--- a/clang/test/Headers/__cpuidex_conflict.c
+++ /dev/null
@@ -1,15 +0,0 @@
-// Make sure that __cpuidex in cpuid.h doesn't conflict with the MS
-// compatibility built in by ensuring compilation succeeds:
-// RUN: %clang_cc1 %s -ffreestanding -fms-extensions -fms-compatibility \
-// RUN:  -fms-compatibility-version=19.00 -triple x86_64-pc-windows-msvc 
-emit-llvm -o -
-
-typedef __SIZE_TYPE__ size_t;
-
-#include 
-#include 
-
-int cpuid_info[4];
-
-void test_cpuidex(unsigned level, unsigned count) {
-  __cpuidex(cpuid_info, level, count);
-}

diff  --git a/clang/test/Headers/cpuid.c b/clang/test/Headers/cpuid.c
index 6ed12eca7a61d4..7e485495c10665 100644
--- a/clang/test/Headers/cpuid.c
+++ b/clang/test/Headers/cpuid.c
@@ -6,19 +6,14 @@
 
 // CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A 
cpuid\0A xchgq %rbx,${1:q}", 
"={ax},=r,={cx},={dx},0,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}})
 // CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A  
cpuid\0A  xchgq  %rbx,${1:q}", 
"={ax},=r,={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 
%{{[a-z0-9]+}})
-// CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A  
cpuid\0A  xchgq  %rbx,${1:q}", 
"={ax},=r,={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 
%{{[a-z0-9]+}})
 
 // CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", 
"={ax},={bx},={cx},={dx},0,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}})
 // CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", 
"={ax},={bx},={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, 
i32 %{{[a-z0-9]+}})
-// CHECK-32: {{.*}} call { i32, i32, i32, i32 } asm "cpuid", 
"={ax},={bx},={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, 
i32 %{{[a-z0-9]+}})
 
 unsigned eax0, ebx0, ecx0, edx0;
 unsigned eax1, ebx1, ecx1, edx1;
 
-int cpuid_info[4];
-
 void test_cpuid(unsigned level, unsigned count) {
   __cpuid(level, eax1, ebx1, ecx1, edx1);
   __cpuid_count(level, count, eax0, ebx0, ecx0, edx0);
-  __cpuidex(cpuid_info, level, count);
 }



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


[PATCH] D157115: Revert "[clang][X86] Add __cpuidex function to cpuid.h"

2023-08-04 Thread Aiden Grossman via Phabricator via cfe-commits
aidengrossman added a comment.

Thanks for the quick response!

Sorry for all the churn with this patch. I'm fine leaving this out of LLVM 17, 
so I'll land this patch, backport the commit to the 17 release branch, and then 
once we have the aux triple and MS extensions flag fixes I'll reland in main 
and won't backport it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157115

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


[PATCH] D157115: Revert "[clang][X86] Add __cpuidex function to cpuid.h"

2023-08-04 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D157115#4561497 , @aaron.ballman 
wrote:

> Thank you for this! The revert LGTM, but please wait for @mstorsjo to confirm 
> this won't cause problems for MinGW folks.

I guess this is fine.

We should probably sync mingw-w64 and revert 
https://github.com/mingw-w64/mingw-w64/commit/2b6c9247613aa830374e3686e09d3b8d582a92a6
 after that. There's less rush in reverting it though (not many projects use 
`__cpuidex` so it's not so bad to not have it defined it at all - while having 
a double conflicting definition is fatal), but I guess I should update it at 
least once the 17.0.0 release gets closer and we see where we're settled (maybe 
bump the version threshold to 18 instead of 17, if we're somewhat sure we'll 
have it in main even if it's reverted in 17.x).

For mingw, I'd at least appreciate if we don't switch it back and forth further 
on the 17.x release branch after 17.0.0 is released.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157115

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


[PATCH] D156749: [modules] Fix error about the same module being defined in different .pcm files when using VFS overlays.

2023-08-04 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai added a comment.

Ping @jansvoboda11 , @benlangmuir  in case you still have thoughts on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156749

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


[PATCH] D157029: [llvm] Construct option's prefixed name at compile-time

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

In D157029#4561519 , @jansvoboda11 
wrote:

> In D157029#4561490 , @MaskRay wrote:
>
>> This increases the size of  `Info` (static data size and static 
>> relocations). In return, some dynamic relocations are saved. Is this a net 
>> win?
>
> If that's a concern, I can remove `Info::Name` and replace its usages with a 
> function call that drops the prefix from prefixed name.

Done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157029

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


[PATCH] D157029: [llvm] Construct option's prefixed name at compile-time

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 547316.
jansvoboda11 added a comment.

Remove `OptTable::Info::Name`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157029

Files:
  clang-tools-extra/clangd/CompileCommands.cpp
  clang/lib/Driver/Driver.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Tooling/Tooling.cpp
  llvm/include/llvm/Option/OptTable.h
  llvm/include/llvm/Option/Option.h
  llvm/lib/Option/OptTable.cpp
  llvm/unittests/Option/OptionMarshallingTest.cpp
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -34,30 +34,14 @@
   return OS;
 }
 
-static std::string getOptionSpelling(const Record , size_t ) {
+static std::string getOptionPrefixedName(const Record ) {
   std::vector Prefixes = R.getValueAsListOfStrings("Prefixes");
   StringRef Name = R.getValueAsString("Name");
 
-  if (Prefixes.empty()) {
-PrefixLength = 0;
+  if (Prefixes.empty())
 return Name.str();
-  }
-
-  PrefixLength = Prefixes[0].size();
-  return (Twine(Prefixes[0]) + Twine(Name)).str();
-}
 
-static std::string getOptionSpelling(const Record ) {
-  size_t PrefixLength;
-  return getOptionSpelling(R, PrefixLength);
-}
-
-static void emitNameUsingSpelling(raw_ostream , const Record ) {
-  size_t PrefixLength;
-  OS << "llvm::StringLiteral(";
-  write_cstring(
-  OS, StringRef(getOptionSpelling(R, PrefixLength)).substr(PrefixLength));
-  OS << ")";
+  return (Prefixes[0] + Twine(Name)).str();
 }
 
 class MarshallingInfo {
@@ -105,8 +89,6 @@
   }
 
   void emit(raw_ostream ) const {
-write_cstring(OS, StringRef(getOptionSpelling(R)));
-OS << ", ";
 OS << ShouldParse;
 OS << ", ";
 OS << ShouldAlwaysEmit;
@@ -303,7 +285,7 @@
 // The option prefix;
 OS << "llvm::ArrayRef()";
 
-// The option string.
+// The option prefixed name.
 OS << ", \"" << R.getValueAsString("Name") << '"';
 
 // The option identifier name.
@@ -346,8 +328,10 @@
 std::vector RPrefixes = R.getValueAsListOfStrings("Prefixes");
 OS << Prefixes[PrefixKeyT(RPrefixes.begin(), RPrefixes.end())] << ", ";
 
-// The option string.
-emitNameUsingSpelling(OS, R);
+// The option prefixed name.
+OS << "llvm::StringLiteral(";
+write_cstring(OS, getOptionPrefixedName(R));
+OS << ")";
 
 // The option identifier name.
 OS << ", " << getOptionName(R);
Index: llvm/unittests/Option/OptionMarshallingTest.cpp
===
--- llvm/unittests/Option/OptionMarshallingTest.cpp
+++ llvm/unittests/Option/OptionMarshallingTest.cpp
@@ -10,7 +10,7 @@
 #include "gtest/gtest.h"
 
 struct OptionWithMarshallingInfo {
-  llvm::StringRef Name;
+  llvm::StringLiteral PrefixedName;
   const char *KeyPath;
   const char *ImpliedCheck;
   const char *ImpliedValue;
@@ -18,20 +18,20 @@
 
 static const OptionWithMarshallingInfo MarshallingTable[] = {
 #define OPTION_WITH_MARSHALLING(   \
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
-HELPTEXT, METAVAR, VALUES, SPELLING, SHOULD_PARSE, ALWAYS_EMIT, KEYPATH,   \
+PREFIX_TYPE, PREFIXED_NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS,  \
+PARAM, HELPTEXT, METAVAR, VALUES, SHOULD_PARSE, ALWAYS_EMIT, KEYPATH,  \
 DEFAULT_VALUE, IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, \
 MERGER, EXTRACTOR, TABLE_INDEX)\
-  {NAME, #KEYPATH, #IMPLIED_CHECK, #IMPLIED_VALUE},
+  {PREFIXED_NAME, #KEYPATH, #IMPLIED_CHECK, #IMPLIED_VALUE},
 #include "Opts.inc"
 #undef OPTION_WITH_MARSHALLING
 };
 
 TEST(OptionMarshalling, EmittedOrderSameAsDefinitionOrder) {
-  ASSERT_STREQ(MarshallingTable[0].Name.data(), "marshalled-flag-d");
-  ASSERT_STREQ(MarshallingTable[1].Name.data(), "marshalled-flag-c");
-  ASSERT_STREQ(MarshallingTable[2].Name.data(), "marshalled-flag-b");
-  ASSERT_STREQ(MarshallingTable[3].Name.data(), "marshalled-flag-a");
+  ASSERT_EQ(MarshallingTable[0].PrefixedName, "-marshalled-flag-d");
+  ASSERT_EQ(MarshallingTable[1].PrefixedName, "-marshalled-flag-c");
+  ASSERT_EQ(MarshallingTable[2].PrefixedName, "-marshalled-flag-b");
+  ASSERT_EQ(MarshallingTable[3].PrefixedName, "-marshalled-flag-a");
 }
 
 TEST(OptionMarshalling, EmittedSpecifiedKeyPath) {
Index: llvm/lib/Option/OptTable.cpp
===
--- llvm/lib/Option/OptTable.cpp
+++ llvm/lib/Option/OptTable.cpp
@@ -59,7 +59,7 @@
   if ( == )
 return false;
 
-  if (int N = StrCmpOptionName(A.Name, B.Name))
+  if (int N = StrCmpOptionName(A.getName(), B.getName()))
 return N < 0;
 
   for (size_t I = 0, K = std::min(A.Prefixes.size(), 

[PATCH] D153071: [clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

2023-08-04 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 547315.
ymandel added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153071

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
  clang/unittests/Analysis/CFGTest.cpp

Index: clang/unittests/Analysis/CFGTest.cpp
===
--- clang/unittests/Analysis/CFGTest.cpp
+++ clang/unittests/Analysis/CFGTest.cpp
@@ -6,13 +6,15 @@
 //
 //===--===//
 
+#include "clang/Analysis/CFG.h"
 #include "CFGBuildResult.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Analysis/Analyses/IntervalPartition.h"
 #include "clang/Analysis/AnalysisDeclContext.h"
-#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowWorklist.h"
 #include "clang/Tooling/Tooling.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 #include 
@@ -244,6 +246,8 @@
 TEST(CFG, Worklists) {
   const char *Code = "int f(bool cond) {\n"
  "  int a = 5;\n"
+ "  while (a < 6)\n"
+ "++a;\n"
  "  if (cond)\n"
  "a += 1;\n"
  "  return a;\n"
@@ -272,6 +276,30 @@
ForwardNodes.begin()));
   }
 
+  // RPO: 876321054
+  // WTO: 876534210
+  // So, we construct the WTO order accordingly from the reference order.
+  std::vector WTOOrder = {
+  ReferenceOrder[0], ReferenceOrder[1], ReferenceOrder[2],
+  ReferenceOrder[7], ReferenceOrder[3], ReferenceOrder[8],
+  ReferenceOrder[4], ReferenceOrder[5], ReferenceOrder[6]};
+
+  {
+using ::testing::ElementsAreArray;
+std::optional WTO = getIntervalWTO(*CFG);
+ASSERT_TRUE(WTO);
+WTOCompare WCmp(*WTO);
+WTODataflowWorklist WTOWorklist(*CFG, WCmp);
+for (const auto *B : *CFG)
+  WTOWorklist.enqueueBlock(B);
+
+std::vector WTONodes;
+while (const CFGBlock *B = WTOWorklist.dequeue())
+  WTONodes.push_back(B);
+
+EXPECT_THAT(WTONodes, ElementsAreArray(WTOOrder));
+  }
+
   std::reverse(ReferenceOrder.begin(), ReferenceOrder.end());
 
   {
Index: clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowWorklist.h
@@ -12,6 +12,7 @@
 #ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWWORKLIST_H
 #define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWWORKLIST_H
 
+#include "clang/Analysis/Analyses/IntervalPartition.h"
 #include "clang/Analysis/Analyses/PostOrderCFGView.h"
 #include "clang/Analysis/CFG.h"
 #include "llvm/ADT/PriorityQueue.h"
@@ -21,16 +22,13 @@
 /// on the order defined by 'Comp'.
 template  class DataflowWorklistBase {
   llvm::BitVector EnqueuedBlocks;
-  PostOrderCFGView *POV;
   llvm::PriorityQueue, Comp>
   WorkList;
 
 public:
-  DataflowWorklistBase(const CFG , PostOrderCFGView *POV, Comp C)
-  : EnqueuedBlocks(Cfg.getNumBlockIDs()), POV(POV), WorkList(C) {}
-
-  const PostOrderCFGView *getCFGView() const { return POV; }
+  DataflowWorklistBase(const CFG , Comp C)
+  : EnqueuedBlocks(Cfg.getNumBlockIDs()), WorkList(C) {}
 
   void enqueueBlock(const CFGBlock *Block) {
 if (Block && !EnqueuedBlocks[Block->getBlockID()]) {
@@ -62,7 +60,7 @@
 struct ForwardDataflowWorklist
 : DataflowWorklistBase {
   ForwardDataflowWorklist(const CFG , PostOrderCFGView *POV)
-  : DataflowWorklistBase(Cfg, POV,
+  : DataflowWorklistBase(Cfg,
  ReversePostOrderCompare{POV->getComparator()}) {}
 
   ForwardDataflowWorklist(const CFG , AnalysisDeclContext )
@@ -74,6 +72,19 @@
   }
 };
 
+/// A worklist implementation for forward dataflow analysis based on a weak
+/// topological ordering of the nodes. The worklist cannot contain the same
+/// block multiple times at once.
+struct WTODataflowWorklist : DataflowWorklistBase {
+  WTODataflowWorklist(const CFG , const WTOCompare )
+  : DataflowWorklistBase(Cfg, Cmp) {}
+
+  void enqueueSuccessors(const CFGBlock *Block) {
+for (auto B : Block->succs())
+  enqueueBlock(B);
+  }
+};
+
 /// A worklist implementation for backward dataflow analysis. The enqueued
 /// block will be dequeued in post order. The worklist cannot contain the same
 /// block multiple times at once.
@@ -81,8 +92,7 @@
 : DataflowWorklistBase {
   BackwardDataflowWorklist(const CFG , AnalysisDeclContext )
   : DataflowWorklistBase(
-Cfg, Ctx.getAnalysis(),
-Ctx.getAnalysis()->getComparator()) {}
+Cfg, Ctx.getAnalysis()->getComparator()) {}
 
   void enqueuePredecessors(const CFGBlock *Block) {
 for (auto B : Block->preds())

[PATCH] D157076: [clang][ExtractAPI] Add support for C++ class templates and concepts

2023-08-04 Thread Erick Velez via Phabricator via cfe-commits
evelez7 updated this revision to Diff 547314.
evelez7 added a comment.

Add documentation to template argument name deduction, add missing method 
declarations to visitor base


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157076

Files:
  clang/include/clang/ExtractAPI/API.h
  clang/include/clang/ExtractAPI/DeclarationFragments.h
  clang/include/clang/ExtractAPI/ExtractAPIVisitor.h
  clang/include/clang/ExtractAPI/Serialization/SerializerBase.h
  clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h
  clang/lib/ExtractAPI/API.cpp
  clang/lib/ExtractAPI/DeclarationFragments.cpp
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
  clang/test/ExtractAPI/class_template.cpp
  clang/test/ExtractAPI/class_template_partial_spec.cpp
  clang/test/ExtractAPI/class_template_spec.cpp
  clang/test/ExtractAPI/concept.cpp

Index: clang/test/ExtractAPI/concept.cpp
===
--- /dev/null
+++ clang/test/ExtractAPI/concept.cpp
@@ -0,0 +1,133 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
+// RUN: %clang_cc1 -std=c++20 -extract-api -triple arm64-apple-macosx \
+// RUN:   -x c++-header %t/input.h -o %t/output.json -verify
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+//--- input.h
+template concept Foo = true;
+
+/// expected-no-diagnostics
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {
+  "major": 0,
+  "minor": 5,
+  "patch": 3
+},
+"generator": "?"
+  },
+  "module": {
+"name": "",
+"platform": {
+  "architecture": "arm64",
+  "operatingSystem": {
+"minimumVersion": {
+  "major": 11,
+  "minor": 0,
+  "patch": 0
+},
+"name": "macosx"
+  },
+  "vendor": "apple"
+}
+  },
+  "relationships": [],
+  "symbols": [
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "keyword",
+  "spelling": "template"
+},
+{
+  "kind": "text",
+  "spelling": "<"
+},
+{
+  "kind": "keyword",
+  "spelling": "typename"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "genericParameter",
+  "spelling": "T"
+},
+{
+  "kind": "text",
+  "spelling": "> "
+},
+{
+  "kind": "keyword",
+  "spelling": "concept"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "Foo"
+},
+{
+  "kind": "text",
+  "spelling": ";"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c++",
+"precise": "c:@CT@Foo"
+  },
+  "kind": {
+"displayName": "Concept",
+"identifier": "c++.concept"
+  },
+  "location": {
+"position": {
+  "character": 30,
+  "line": 1
+},
+"uri": "file://INPUT_DIR/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "Foo"
+  }
+],
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "Foo"
+  }
+],
+"title": "Foo"
+  },
+  "pathComponents": [
+"Foo"
+  ],
+  "swiftGenerics": {
+"parameters": [
+  {
+"depth": 0,
+"index": 0,
+"name": "T"
+  }
+]
+  }
+}
+  ]
+}
Index: clang/test/ExtractAPI/class_template_spec.cpp
===
--- /dev/null
+++ clang/test/ExtractAPI/class_template_spec.cpp
@@ -0,0 +1,205 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
+// RUN: %clang_cc1 -extract-api -triple arm64-apple-macosx \
+// RUN:   -x c++-header %t/input.h -o %t/output.json -verify
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+//--- input.h
+template class Foo {};
+
+template<> class Foo {};
+
+/// expected-no-diagnostics
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {

[PATCH] D139730: [OpenMP][DeviceRTL][AMDGPU] Support code object version 5

2023-08-04 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D139730#4561619 , @arsenm wrote:

> In D139730#4561575 , @jhuber6 wrote:
>
>> In D139730#4561573 , @arsenm wrote:
>>
>>> In D139730#4561540 , @jhuber6 
>>> wrote:
>>>
 Could you explain briefly what the approach here is? I'm confused as to 
 what's actually changed and how we're handling this difference. I thought 
 if this was just the definition of some builtin function we could just 
 rely on the backend to figure it out. Why do we need to know the code 
 object version inside the device RTL?
>>>
>>> The build is called in the device rtl, so the device RTL needs to contain 
>>> both implementations. The "backend figuring it out" is dead code elimination
>>
>> Okay, do we expect to re-use this interface anywhere? If it's just for 
>> OpenMP then we should probably copy the approach taken for 
>> `__omp_rtl_debug_kind`, which is a global created on the GPU by 
>> `CGOpenMPRuntimeGPU`'s constructor and does more or less the same thing.
>
> device libs replicates the same scheme using its own copy of an equivalent 
> variable. Trying to merge those two together

Although I guess that doesn't really need the builtin changes?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139730

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


[PATCH] D148997: [clang] Add a new annotation token: annot_repl_input_end

2023-08-04 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev added a comment.

In D148997#4561614 , @bnbarham wrote:

> In D148997#4561577 , @v.g.vassilev 
> wrote:
>
>>> My other concern here is that it seems our use cases are somewhat 
>>> different, eg. we wouldn't want any parsing differences and while I don't 
>>> know why this is yet, the removal of:
>>
>> I think I understand now. We basically want a mode which keeps some of the 
>> clang objects alive and ready to process more input. And on top, for 
>> clang-repl we want to enable some special parsing mode for the top-level 
>> statement declarations.
>
> Yeah, I'd say that sums it up pretty well.
>
>>>   // Skip over the EOF token, flagging end of previous input for incremental
>>>   // processing
>>>   if (PP.isIncrementalProcessingEnabled() && Tok.is(tok::eof))
>>> ConsumeToken();
>>>
>>> is causing issues for us as well.
>>
>> Yes, that now seems to be moved on the user side as we thought it would be 
>> dead code. We can bring that one back if that's the only issue you see with 
>> that approach.
>
> I think it would make sense to bring it back under the mode you spoke about 
> above, yeah 

So, in that case we should bring back the boolean flag for incremental 
processing and keep the `IncrementalExtensions` LanguageOption separate. In 
that case `IncrementalExtensions` would mean that we must turn on incremental 
processing for managing lifetime and only use the language option when 
extending the parsing logic. However, I think the problem would be what to do 
with the `tok::eof` and `tok::annot_repl_input_end`? I'd probably need 
@aaron.ballman or @rsmith here...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148997

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


[PATCH] D139730: [OpenMP][DeviceRTL][AMDGPU] Support code object version 5

2023-08-04 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D139730#4561575 , @jhuber6 wrote:

> In D139730#4561573 , @arsenm wrote:
>
>> In D139730#4561540 , @jhuber6 
>> wrote:
>>
>>> Could you explain briefly what the approach here is? I'm confused as to 
>>> what's actually changed and how we're handling this difference. I thought 
>>> if this was just the definition of some builtin function we could just rely 
>>> on the backend to figure it out. Why do we need to know the code object 
>>> version inside the device RTL?
>>
>> The build is called in the device rtl, so the device RTL needs to contain 
>> both implementations. The "backend figuring it out" is dead code elimination
>
> Okay, do we expect to re-use this interface anywhere? If it's just for OpenMP 
> then we should probably copy the approach taken for `__omp_rtl_debug_kind`, 
> which is a global created on the GPU by `CGOpenMPRuntimeGPU`'s constructor 
> and does more or less the same thing.

device libs replicates the same scheme using its own copy of an equivalent 
variable. Trying to merge those two together


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139730

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


[PATCH] D148997: [clang] Add a new annotation token: annot_repl_input_end

2023-08-04 Thread Ben Barham via Phabricator via cfe-commits
bnbarham added a comment.

In D148997#4561577 , @v.g.vassilev 
wrote:

>> My other concern here is that it seems our use cases are somewhat different, 
>> eg. we wouldn't want any parsing differences and while I don't know why this 
>> is yet, the removal of:
>
> I think I understand now. We basically want a mode which keeps some of the 
> clang objects alive and ready to process more input. And on top, for 
> clang-repl we want to enable some special parsing mode for the top-level 
> statement declarations.

Yeah, I'd say that sums it up pretty well.

>>   // Skip over the EOF token, flagging end of previous input for incremental
>>   // processing
>>   if (PP.isIncrementalProcessingEnabled() && Tok.is(tok::eof))
>> ConsumeToken();
>>
>> is causing issues for us as well.
>
> Yes, that now seems to be moved on the user side as we thought it would be 
> dead code. We can bring that one back if that's the only issue you see with 
> that approach.

I think it would make sense to bring it back under the mode you spoke about 
above, yeah 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148997

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


[PATCH] D89001: [clang] Don't look into for C++ headers if they are found alongside the toolchain

2023-08-04 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

I don't have access to rdar these days to look into the current state or to 
refresh my memory.

My memory is that the high-level goal was to move the libc++ headers from the 
toolchain to the SDK. For the transition, this was staged in such a way that 
they were in both locations for some period of time (internally, the transition 
may be ongoing, for all I know).

Apple clang needed to prefer the SDK, since that was the "new" place. I don't 
remember the reasoning for inverting this behaviour for LLVM clang.

- Maybe, because this way an LLVM toolchain could still override the C++ 
headers, like it could previously?
- Maybe, there was a plan to eventually switch the default in LLVM clang, but 
that got dropped/forgotten?
- Maybe, there was a plan to eventually switch the default in Apple clang, but 
that was dropped/forgotten, or the internal transition is ongoing? (This rings 
a bell. "Change LLVM clang to the desired end state, and we'll flip the 
direction temporarily in Apple clang for the duration of the transition...")

Anyway, I'm not sure the best way forward here. Perhaps clang should have a 
flag to decide which is preferred. Or perhaps LLVM clang should just change to 
match Apple clang for now.

@ldionne, thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89001

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


[PATCH] D156054: [Clang][Sema] DR722 (nullptr and varargs) and missing -Wvarargs diagnostics

2023-08-04 Thread Mital Ashok via Phabricator via cfe-commits
MitalAshok updated this revision to Diff 547311.
MitalAshok added a comment.

No longer warn on printf("%p", nullptr)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156054

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/AST/FormatString.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CXX/drs/dr7xx.cpp
  clang/test/CodeGen/xcore-abi.c
  clang/test/Sema/format-strings-pedantic.c
  clang/test/SemaCXX/varargs.cpp
  clang/www/cxx_dr_status.html

Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -4373,7 +4373,7 @@
 https://cplusplus.github.io/CWG/issues/722.html;>722
 CD2
 Can nullptr be passed to an ellipsis?
-Unknown
+Clang 18
   
   
 https://cplusplus.github.io/CWG/issues/726.html;>726
Index: clang/test/SemaCXX/varargs.cpp
===
--- clang/test/SemaCXX/varargs.cpp
+++ clang/test/SemaCXX/varargs.cpp
@@ -55,6 +55,16 @@
   (void)__builtin_va_arg(ap, unsigned int);
 
   (void)__builtin_va_arg(ap, bool); // expected-warning {{second argument to 'va_arg' is of promotable type 'bool'; this va_arg has undefined behavior because arguments will be promoted to 'int'}}
+
+  (void)__builtin_va_arg(ap, float); // expected-warning {{second argument to 'va_arg' is of promotable type 'float'; this va_arg has undefined behavior because arguments will be promoted to 'double'}}
+  (void)__builtin_va_arg(ap, __fp16); // expected-warning {{second argument to 'va_arg' is of promotable type '__fp16'; this va_arg has undefined behavior because arguments will be promoted to 'double'}}
+
+#if __cplusplus >= 201103L
+  (void)__builtin_va_arg(ap, decltype(nullptr)); // expected-warning {{second argument to 'va_arg' is of promotable type 'decltype(nullptr)' (aka 'std::nullptr_t'); this va_arg has undefined behavior because arguments will be promoted to 'void *'}}
+#endif
+
+  (void)__builtin_va_arg(ap, int[3]); // expected-warning {{second argument to 'va_arg' is of promotable type 'int[3]'; this va_arg has undefined behavior because arguments will be promoted to 'int *'}}
+  (void)__builtin_va_arg(ap, const int[3]); // expected-warning {{second argument to 'va_arg' is of promotable type 'const int[3]'; this va_arg has undefined behavior because arguments will be promoted to 'const int *'}}
 }
 
 #if __cplusplus >= 201103L
Index: clang/test/Sema/format-strings-pedantic.c
===
--- clang/test/Sema/format-strings-pedantic.c
+++ clang/test/Sema/format-strings-pedantic.c
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -Wno-format -Wformat-pedantic %s
 // RUN: %clang_cc1 -xobjective-c -fblocks -fsyntax-only -verify -Wno-format -Wformat-pedantic %s
 // RUN: %clang_cc1 -xc++ -fsyntax-only -verify -Wno-format -Wformat-pedantic %s
+// RUN: %clang_cc1 -std=c2x -fsyntax-only -verify -Wno-format -Wformat-pedantic %s
 
 __attribute__((format(printf, 1, 2)))
 int printf(const char *restrict, ...);
@@ -14,7 +15,7 @@
   printf("%p", (id)0); // expected-warning {{format specifies type 'void *' but the argument has type 'id'}}
 #endif
 
-#ifdef __cplusplus
-  printf("%p", nullptr); // expected-warning {{format specifies type 'void *' but the argument has type 'std::nullptr_t'}}
+#if !__is_identifier(nullptr)
+  printf("%p", nullptr);
 #endif
 }
Index: clang/test/CodeGen/xcore-abi.c
===
--- clang/test/CodeGen/xcore-abi.c
+++ clang/test/CodeGen/xcore-abi.c
@@ -76,7 +76,8 @@
   // CHECK: call void @llvm.memcpy.p0.p0.i32(ptr align 4 [[V5]], ptr align 4 [[P]], i32 20, i1 false)
   // CHECK: call void @f(ptr noundef [[V5]])
 
-  int* v6 = va_arg (ap, int[4]);  // an unusual aggregate type
+  // an unusual aggregate type
+  int* v6 = va_arg (ap, int[4]);  // expected-warning{{second argument to 'va_arg' is of promotable type 'int[4]'}}
   f(v6);
   // CHECK: [[I:%[a-z0-9]+]] = load ptr, ptr [[AP]]
   // CHECK: [[P:%[a-z0-9]+]] = load ptr, ptr [[I]]
Index: clang/test/CXX/drs/dr7xx.cpp
===
--- clang/test/CXX/drs/dr7xx.cpp
+++ clang/test/CXX/drs/dr7xx.cpp
@@ -53,6 +53,15 @@
 #endif
 }
 
+namespace dr722 { // dr722: 18
+#if __cplusplus >= 201103L
+  int x = __builtin_printf("%p", nullptr);
+  void f(__builtin_va_list args) {
+__builtin_va_arg(args, decltype(nullptr)); // expected-warning {{second argument to 'va_arg' is of promotable type 'decltype(nullptr)' (aka 'std::nullptr_t'); this va_arg has undefined behavior because arguments will be promoted to 'void *'}}
+  }
+#endif
+}
+
 namespace dr727 { // dr727: partial
   struct A {
 template struct C; // expected-note 6{{here}}
Index: clang/lib/Sema/SemaExpr.cpp

[PATCH] D157129: [NFC] Fix unnecessary copy with auto.

2023-08-04 Thread Balázs Benics via Phabricator via cfe-commits
steakhal requested changes to this revision.
steakhal added a comment.
This revision now requires changes to proceed.

I can only vouch for the SttaticAnalyzer portion.
Those parts makes sense to me.
However, I've seen cases where it doesn't resonate.
As a rule of thumb, if we are "copying" only at most 3 pointers, I'd rather 
still just make a copy instead of by reference.
Please check if your recommended changes reflect this.

If you decide to take it by reference, prefer taking it also by const.

Let me know if you oppose.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157129

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


[PATCH] D157130: [RISCV] Check type size for lax conversions between RVV builtin types and VectorType::RVVFixedLengthDataVector.

2023-08-04 Thread Craig Topper via Phabricator via cfe-commits
craig.topper created this revision.
craig.topper added reviewers: aaron.ballman, c-rhodes.
Herald added subscribers: jobnoorman, luke, VincentWu, ctetreau, vkmr, 
frasercrmck, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, 
psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, 
edward-jones, zzheng, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, 
simoncook, johnrusso, rbar, asb, arichardson.
Herald added a project: All.
craig.topper requested review of this revision.
Herald added subscribers: wangpc, eopXD.
Herald added a project: clang.

This code was copied from SVE and modified for RVV. For SVE, there
is only one size for builtin types so they didn't need to check
the size. For RVV, due to LMUL there are 7 different sizes of builtin
types so we do need to check the size.

I'm not sure we should have lax vector conversions at all for RVV.
That appears to be contributing to 
https://github.com/llvm/llvm-project/issues/64404

This patch at least fixes the obvious correctness issue.
This should be backported to LLVM 17.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157130

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/Sema/riscv-rvv-lax-vector-conversions.c


Index: clang/test/Sema/riscv-rvv-lax-vector-conversions.c
===
--- clang/test/Sema/riscv-rvv-lax-vector-conversions.c
+++ clang/test/Sema/riscv-rvv-lax-vector-conversions.c
@@ -2,8 +2,6 @@
 // RUN: %clang_cc1 -triple riscv64-none-linux-gnu -target-feature +f 
-target-feature +d -target-feature +zve64d -mvscale-min=8 -mvscale-max=8 
-flax-vector-conversions=integer -ffreestanding -fsyntax-only 
-verify=lax-vector-integer %s
 // RUN: %clang_cc1 -triple riscv64-none-linux-gnu -target-feature +f 
-target-feature +d -target-feature +zve64d -mvscale-min=8 -mvscale-max=8 
-flax-vector-conversions=all -ffreestanding -fsyntax-only 
-verify=lax-vector-all %s
 
-// lax-vector-all-no-diagnostics
-
 // REQUIRES: riscv-registered-target
 
 #define RVV_FIXED_ATTR 
__attribute__((riscv_rvv_vector_bits(__riscv_v_fixed_vlen)))
@@ -20,6 +18,8 @@
 typedef __rvv_float32m1_t vfloat32m1_t;
 typedef __rvv_float64m1_t vfloat64m1_t;
 
+typedef __rvv_int64m2_t vint64m2_t;
+
 typedef vfloat32m1_t rvv_fixed_float32m1_t RVV_FIXED_ATTR;
 typedef vint32m1_t rvv_fixed_int32m1_t RVV_FIXED_ATTR;
 typedef float gnu_fixed_float32m1_t GNU_FIXED_ATTR;
@@ -76,3 +76,17 @@
   // lax-vector-none-error@-1 {{assigning to 'vfloat64m1_t' (aka 
'__rvv_float64m1_t') from incompatible type}}
   // lax-vector-integer-error@-2 {{assigning to 'vfloat64m1_t' (aka 
'__rvv_float64m1_t') from incompatible type}}
 }
+
+void not_allowed() {
+  rvv_fixed_int32m1_t fi32m1;
+  vint64m2_t si64m2;
+
+  fi32m1 = si64m2;
+  // lax-vector-none-error@-1 {{assigning to 'rvv_fixed_int32m1_t' (vector of 
16 'int' values) from incompatible type}}
+  // lax-vector-integer-error@-2 {{assigning to 'rvv_fixed_int32m1_t' (vector 
of 16 'int' values) from incompatible type}}
+  // lax-vector-all-error@-3 {{assigning to 'rvv_fixed_int32m1_t' (vector of 
16 'int' values) from incompatible type}}
+  si64m2 = fi32m1;
+  // lax-vector-none-error@-1 {{assigning to 'vint64m2_t' (aka 
'__rvv_int64m2_t') from incompatible type}}
+  // lax-vector-integer-error@-2 {{assigning to 'vint64m2_t' (aka 
'__rvv_int64m2_t') from incompatible type}}
+  // lax-vector-all-error@-3 {{assigning to 'vint64m2_t' (aka 
'__rvv_int64m2_t') from incompatible type}}
+}
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -9612,9 +9612,8 @@
   const LangOptions::LaxVectorConversionKind LVCKind =
   getLangOpts().getLaxVectorConversions();
 
-  // If __riscv_v_fixed_vlen != N do not allow GNU vector lax conversion.
-  if (VecTy->getVectorKind() == VectorType::GenericVector &&
-  getTypeSize(SecondType) != getRVVTypeSize(*this, BT))
+  // If __riscv_v_fixed_vlen != N do not allow vector lax conversion.
+  if (getTypeSize(SecondType) != getRVVTypeSize(*this, BT))
 return false;
 
   // If -flax-vector-conversions=all is specified, the types are


Index: clang/test/Sema/riscv-rvv-lax-vector-conversions.c
===
--- clang/test/Sema/riscv-rvv-lax-vector-conversions.c
+++ clang/test/Sema/riscv-rvv-lax-vector-conversions.c
@@ -2,8 +2,6 @@
 // RUN: %clang_cc1 -triple riscv64-none-linux-gnu -target-feature +f -target-feature +d -target-feature +zve64d -mvscale-min=8 -mvscale-max=8 -flax-vector-conversions=integer -ffreestanding -fsyntax-only -verify=lax-vector-integer %s
 // RUN: %clang_cc1 -triple riscv64-none-linux-gnu -target-feature +f -target-feature +d -target-feature +zve64d -mvscale-min=8 -mvscale-max=8 -flax-vector-conversions=all -ffreestanding -fsyntax-only -verify=lax-vector-all %s
 
-// lax-vector-all-no-diagnostics

[PATCH] D148997: [clang] Add a new annotation token: annot_repl_input_end

2023-08-04 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev added a comment.

In D148997#4561516 , @bnbarham wrote:

> In D148997#4561211 , @v.g.vassilev 
> wrote:
>
> https://github.com/llvm/llvm-project/blob/df6b35e329ebecad6dc3bfb83183e482eb7a0020/clang/lib/Parse/ParseExprCXX.cpp#L4070

 That looks a bit obscure to me. Looks like we are trying to reach some 
 error recovery anchor but do you happen to have some use case at hand? In 
 principle we could do the same as for the other 3.
>>>
>>> This was just one I picked at random from my grep over the parser. It's 
>>> unclear how often this would be hit, but I have to assume it (and the other 
>>> references) can, even if they're obscure/unlikely. My main point is that 
>>> `!eof` is being used somewhat frequently to end loops, but with this change 
>>> they will now all never end.
>>
>> Since `eof` there were several `eof`-like tokens that were added: 
>> `annot_module_begin`, `annot_module_end`, `tok::annot_module_include` which 
>> are commonly handled in `isEofOrEom`. We could update these uses with 
>> `isEofOrEom` but I am pretty sure that @rsmith will point out cases where 
>> that's not a good very good idea :) We could either experiment with using 
>> `isEofOrEom` or have a similar utility function only for the two tokens (say 
>> `isEoI` -- end of input whatever that means).
>
> My other concern here is that it seems our use cases are somewhat different, 
> eg. we wouldn't want any parsing differences and while I don't know why this 
> is yet, the removal of:

I think I understand now. We basically want a mode which keeps some of the 
clang objects alive and ready to process more input. And on top, for clang-repl 
we want to enable some special parsing mode for the top-level statement 
declarations.

>   // Skip over the EOF token, flagging end of previous input for incremental
>   // processing
>   if (PP.isIncrementalProcessingEnabled() && Tok.is(tok::eof))
> ConsumeToken();
>
> is causing issues for us as well.

Yes, that now seems to be moved on the user side as we thought it would be dead 
code. We can bring that one back if that's the only issue you see with that 
approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148997

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


[PATCH] D139730: [OpenMP][DeviceRTL][AMDGPU] Support code object version 5

2023-08-04 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

In D139730#4561573 , @arsenm wrote:

> In D139730#4561540 , @jhuber6 wrote:
>
>> Could you explain briefly what the approach here is? I'm confused as to 
>> what's actually changed and how we're handling this difference. I thought if 
>> this was just the definition of some builtin function we could just rely on 
>> the backend to figure it out. Why do we need to know the code object version 
>> inside the device RTL?
>
> The build is called in the device rtl, so the device RTL needs to contain 
> both implementations. The "backend figuring it out" is dead code elimination

Okay, do we expect to re-use this interface anywhere? If it's just for OpenMP 
then we should probably copy the approach taken for `__omp_rtl_debug_kind`, 
which is a global created on the GPU by `CGOpenMPRuntimeGPU`'s constructor and 
does more or less the same thing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139730

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


[PATCH] D139730: [OpenMP][DeviceRTL][AMDGPU] Support code object version 5

2023-08-04 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D139730#4561540 , @jhuber6 wrote:

> Could you explain briefly what the approach here is? I'm confused as to 
> what's actually changed and how we're handling this difference. I thought if 
> this was just the definition of some builtin function we could just rely on 
> the backend to figure it out. Why do we need to know the code object version 
> inside the device RTL?

The build is called in the device rtl, so the device RTL needs to contain both 
implementations. The "backend figuring it out" is dead code elimination


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139730

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


[PATCH] D139730: [OpenMP][DeviceRTL][AMDGPU] Support code object version 5

2023-08-04 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added inline comments.



Comment at: openmp/libomptarget/plugins-nextgen/amdgpu/utils/UtilitiesRTL.h:36
 
-// The implicit arguments of AMDGPU kernels.
-struct AMDGPUImplicitArgsTy {
-  uint64_t OffsetX;
-  uint64_t OffsetY;
-  uint64_t OffsetZ;
-  uint64_t HostcallPtr;
-  uint64_t Unused0;
-  uint64_t Unused1;
-  uint64_t Unused2;
+enum IMPLICITARGS : uint32_t {
+  COV4_SIZE = 56,

arsenm wrote:
> This is getting duplicated a few places, should it move to a support header?
> 
> I don't love the existing APIs for this, I think a struct definition makes 
> more sense
The other user here is my custom loader, @JonChesterfield has talked about 
wanting a common HSA helper header for awhile now.

I agree that the struct definition is much better. Being able to simply 
allocate this size and then zero fill it is much cleaner.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139730

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


[PATCH] D157074: [clang][ExprConst] Add RHS source range to div by zero diags

2023-08-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:2811-2813
+static bool handleIntIntBinOp(EvalInfo , const BinaryOperator *E,
+  const APSInt , BinaryOperatorKind Opcode,
+  APSInt RHS, APSInt ) {

I think we should remove that parameter because it'd be pretty weird to pass in 
a binary operator and a different binary operator kind than the one used by the 
binary operator, right?


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

https://reviews.llvm.org/D157074

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


[PATCH] D157129: [NFC] Fix unnecessary copy with auto.

2023-08-04 Thread Srividya Sundaram via Phabricator via cfe-commits
srividya-sundaram created this revision.
Herald added subscribers: luke, steakhal, frasercrmck, martong, luismarques, 
apazos, sameer.abuasal, s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, 
MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, niosHD, sabuasal, 
simoncook, johnrusso, rbar, asb.
Herald added a reviewer: NoQ.
Herald added a project: All.
srividya-sundaram requested review of this revision.
Herald added subscribers: cfe-commits, wangpc, MaskRay.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157129

Files:
  clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
  clang/lib/AST/Interp/ByteCodeEmitter.cpp
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/lib/Analysis/FlowSensitive/RecordOps.cpp
  clang/lib/Sema/SemaRISCVVectorLookup.cpp
  clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/ObjCSelfInitChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/ObjCUnusedIVarsChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/SimpleStreamChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/UndefCapturedBlockVarChecker.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  clang/lib/StaticAnalyzer/Core/MemRegion.cpp
  clang/lib/StaticAnalyzer/Core/ProgramState.cpp
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp

Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1089,7 +1089,7 @@
   // BlockDataRegion?  If so, invalidate captured variables that are passed
   // by reference.
   if (const BlockDataRegion *BR = dyn_cast(baseR)) {
-for (auto Var : BR->referenced_vars()) {
+for (auto  : BR->referenced_vars()) {
   const VarRegion *VR = Var.getCapturedRegion();
   const VarDecl *VD = VR->getDecl();
   if (VD->hasAttr() || !VD->hasLocalStorage()) {
@@ -2844,7 +2844,7 @@
 
 // All regions captured by a block are also live.
 if (const BlockDataRegion *BR = dyn_cast(R)) {
-  for (auto Var : BR->referenced_vars())
+  for (auto  : BR->referenced_vars())
 AddToWorkList(Var.getCapturedRegion());
 }
   }
Index: clang/lib/StaticAnalyzer/Core/ProgramState.cpp
===
--- clang/lib/StaticAnalyzer/Core/ProgramState.cpp
+++ clang/lib/StaticAnalyzer/Core/ProgramState.cpp
@@ -627,7 +627,7 @@
 
   // Regions captured by a block are also implicitly reachable.
   if (const BlockDataRegion *BDR = dyn_cast(R)) {
-for (auto Var : BDR->referenced_vars()) {
+for (auto  : BDR->referenced_vars()) {
   if (!scan(Var.getCapturedRegion()))
 return false;
 }
Index: clang/lib/StaticAnalyzer/Core/MemRegion.cpp
===
--- clang/lib/StaticAnalyzer/Core/MemRegion.cpp
+++ clang/lib/StaticAnalyzer/Core/MemRegion.cpp
@@ -492,7 +492,7 @@
 void BlockDataRegion::dumpToStream(raw_ostream ) const {
   os << "block_data{" << BC;
   os << "; ";
-  for (auto Var : referenced_vars())
+  for (auto  : referenced_vars())
 os << "(" << Var.getCapturedRegion() << "<-" << Var.getOriginalRegion()
<< ") ";
   os << '}';
@@ -966,7 +966,7 @@
 if (const auto *BC = dyn_cast(LC)) {
   const auto *BR = static_cast(BC->getData());
   // FIXME: This can be made more efficient.
-  for (auto Var : BR->referenced_vars()) {
+  for (auto  : BR->referenced_vars()) {
 const TypedValueRegion *OrigR = Var.getOriginalRegion();
 if (const auto *VR = dyn_cast(OrigR)) {
   if (VR->getDecl() == VD)
Index: clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -1193,7 +1193,7 @@
 
   // If we created a new MemRegion for the lambda, we should explicitly bind
   // the captures.
-  for (auto const [Idx, FieldForCapture, InitExpr] :
+  for (auto const &[Idx, FieldForCapture, InitExpr] :
llvm::zip(llvm::seq(0, -1), LE->getLambdaClass()->fields(),
  LE->capture_inits())) {
 SVal FieldLoc = State->getLValue(FieldForCapture, V);
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ 

[PATCH] D144634: [Clang][OpenMP] Support for Code Generation of loop bind clause

2023-08-04 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


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

https://reviews.llvm.org/D144634

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


[PATCH] D139730: [OpenMP][DeviceRTL][AMDGPU] Support code object version 5

2023-08-04 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

Could you explain briefly what the approach here is? I'm confused as to what's 
actually changed and how we're handling this difference. I thought if this was 
just the definition of some builtin function we could just rely on the backend 
to figure it out. Why do we need to know the code object version inside the 
device RTL?




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:17140
+
+  if (Cov == clang::TargetOptions::COV_None) {
+auto *ABIVersionC = CGF.CGM.GetOrCreateLLVMGlobal(

Could you explain the function of this in a comment? Are we emitting generic 
code if unspecified?



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:17187-17188
+Address(Result, CGF.Int16Ty, CharUnits::fromQuantity(2)));
+  } else {
+if (Cov == clang::TargetOptions::COV_5) {
+  // Indexing the implicit kernarg segment.

nit.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:17194
+  // CGBuiltin.cpp ~ line 17052 ~ Value*EmitAMDGPUWorkGroupSize ~ COV:
+  // " << Cov ; llvm::errs().resetColor();
+} else {

Leftover debugging?



Comment at: clang/lib/Driver/ToolChain.cpp:1360
+if (A->getOption().matches(options::OPT_mcode_object_version_EQ))
+  DAL->append(A);
+

Shouldn't we be able to put this under the `OPT_m_group` below?



Comment at: openmp/libomptarget/plugins-nextgen/amdgpu/src/rtl.cpp:1752
+// if (auto Err = preAllocateDeviceMemoryPool())
+//   return Err;
+

Leftoever?



Comment at: openmp/libomptarget/plugins-nextgen/amdgpu/src/rtl.cpp:2542
+  /// Get the address of pointer to the preallocated device memory pool.
+  void **getPreAllocatedDeviceMemoryPool() {
+return 

Why do we need this? The current method shouldn't need to change if all we're 
doing is allocating memory of greater size.



Comment at: openmp/libomptarget/plugins-nextgen/amdgpu/src/rtl.cpp:3036
 
+  if (getImplicitArgsSize() < utils::COV5_SIZE) {
+DP("Setting fields of ImplicitArgs for COV4\n");

So we're required to emit some new arguments? I don't have any idea 
what'schanged between this COV4 and COV5 stuff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139730

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


[PATCH] D139730: [OpenMP][DeviceRTL][AMDGPU] Support code object version 5

2023-08-04 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:17146
+Value *ABIVersion;
+if (ABIVersionC) {
+  ABIVersion = CGF.Builder.CreateAlignedLoad(CGF.Int32Ty, ABIVersionC,

this must always pass



Comment at: openmp/libomptarget/plugins-nextgen/amdgpu/src/rtl.cpp:3037
+  if (getImplicitArgsSize() < utils::COV5_SIZE) {
+DP("Setting fields of ImplicitArgs for COV4\n");
+  } else {

This isn't doing anything?



Comment at: openmp/libomptarget/plugins-nextgen/amdgpu/utils/UtilitiesRTL.h:36
 
-// The implicit arguments of AMDGPU kernels.
-struct AMDGPUImplicitArgsTy {
-  uint64_t OffsetX;
-  uint64_t OffsetY;
-  uint64_t OffsetZ;
-  uint64_t HostcallPtr;
-  uint64_t Unused0;
-  uint64_t Unused1;
-  uint64_t Unused2;
+enum IMPLICITARGS : uint32_t {
+  COV4_SIZE = 56,

This is getting duplicated a few places, should it move to a support header?

I don't love the existing APIs for this, I think a struct definition makes more 
sense


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139730

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


[PATCH] D144634: [Clang][OpenMP] Support for Code Generation of loop bind clause

2023-08-04 Thread Sunil K via Phabricator via cfe-commits
koops updated this revision to Diff 547304.
koops added a comment.

1. Support for PCH Serilization/deserilization for the PrevMapLoopConstruct 
variable in OMPExecutableDirective.
2. Modification of clang/test/PCH/pragma-loop.cpp to include "#pragma omp loop 
bind" with different parameters for bind clause.


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

https://reviews.llvm.org/D144634

Files:
  clang/include/clang/AST/StmtOpenMP.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/StmtOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/OpenMP/generic_loop_ast_print.cpp
  clang/test/OpenMP/generic_loop_codegen.cpp
  clang/test/OpenMP/loop_bind_codegen.cpp
  clang/test/OpenMP/loop_bind_enclosed.cpp
  clang/test/OpenMP/loop_bind_messages.cpp
  clang/test/OpenMP/nested_loop_codegen.cpp
  clang/test/PCH/pragma-loop.cpp

Index: clang/test/PCH/pragma-loop.cpp
===
--- clang/test/PCH/pragma-loop.cpp
+++ clang/test/PCH/pragma-loop.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -emit-pch -o %t.a %s
-// RUN: %clang_cc1 -include-pch %t.a %s -ast-print -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -emit-pch -o %t.a %s
+// RUN: %clang_cc1 -fopenmp -include-pch %t.a %s -ast-print -o - | FileCheck %s
 
 // CHECK: #pragma clang loop vectorize_width(4)
 // CHECK: #pragma clang loop interleave_count(8)
@@ -18,6 +18,9 @@
 // CHECK: #pragma nounroll{{$}}
 // CHECK: #pragma clang loop vectorize_width(V)
 // CHECK: #pragma clang loop interleave_count(I)
+// CHECK: #pragma omp simd
+// CHECK: #pragma omp for
+// CHECK: #pragma omp distribute
 
 #ifndef HEADER
 #define HEADER
@@ -94,9 +97,33 @@
   List[i] = i;
 }
   }
+
+  inline void run8(int *List, int Length) {
+int i = 0;
+#pragma omp loop bind(thread)
+for (int i = 0; i < Length; i++) {
+  List[i] = i;
+}
+  }
+
+  inline void run9(int *List, int Length) {
+int i = 0;
+#pragma omp loop bind(parallel)
+for (int i = 0; i < Length; i++) {
+  List[i] = i;
+}
+  }
+
+  inline void run10(int *List, int Length) {
+int i = 0;
+#pragma omp loop bind(teams)
+for (int i = 0; i < Length; i++) {
+  List[i] = i;
+}
+  }
+
 };
 #else
-
 void test() {
   int List[100];
 
@@ -109,6 +136,9 @@
   pt.run5(List, 100);
   pt.run6(List, 100);
   pt.run7<2, 4>(List, 100);
+  pt.run8(List, 100);
+  pt.run9(List, 100);
+  pt.run10(List, 100);
 }
 
 #endif
Index: clang/test/OpenMP/nested_loop_codegen.cpp
===
--- clang/test/OpenMP/nested_loop_codegen.cpp
+++ clang/test/OpenMP/nested_loop_codegen.cpp
@@ -58,6 +58,12 @@
 // CHECK1-NEXT:[[DOTGLOBAL_TID__ADDR:%.*]] = alloca ptr, align 8
 // CHECK1-NEXT:[[DOTBOUND_TID__ADDR:%.*]] = alloca ptr, align 8
 // CHECK1-NEXT:[[I_ADDR:%.*]] = alloca ptr, align 8
+// CHECK1-NEXT:[[TMP:%.*]] = alloca i32, align 4
+// CHECK1-NEXT:[[DOTOMP_IV:%.*]] = alloca i32, align 4
+// CHECK1-NEXT:[[DOTOMP_LB:%.*]] = alloca i32, align 4
+// CHECK1-NEXT:[[DOTOMP_UB:%.*]] = alloca i32, align 4
+// CHECK1-NEXT:[[DOTOMP_STRIDE:%.*]] = alloca i32, align 4
+// CHECK1-NEXT:[[DOTOMP_IS_LAST:%.*]] = alloca i32, align 4
 // CHECK1-NEXT:[[K:%.*]] = alloca i32, align 4
 // CHECK1-NEXT:store ptr [[DOTGLOBAL_TID_]], ptr [[DOTGLOBAL_TID__ADDR]], align 8
 // CHECK1-NEXT:store ptr [[DOTBOUND_TID_]], ptr [[DOTBOUND_TID__ADDR]], align 8
@@ -66,35 +72,27 @@
 // CHECK1-NEXT:store i32 0, ptr [[TMP0]], align 4
 // CHECK1-NEXT:br label [[FOR_COND:%.*]]
 // CHECK1:   for.cond:
-// CHECK1-NEXT:[[TMP1:%.*]] = load i32, ptr [[TMP0]], align 4
-// CHECK1-NEXT:[[CMP:%.*]] = icmp slt i32 [[TMP1]], 10
-// CHECK1-NEXT:br i1 [[CMP]], label [[FOR_BODY:%.*]], label [[FOR_END7:%.*]]
 // CHECK1:   for.body:
-// CHECK1-NEXT:store i32 0, ptr [[K]], align 4
-// CHECK1-NEXT:br label [[FOR_COND1:%.*]]
-// CHECK1:   for.cond1:
-// CHECK1-NEXT:[[TMP2:%.*]] = load i32, ptr [[K]], align 4
-// CHECK1-NEXT:[[CMP2:%.*]] = icmp slt i32 [[TMP2]], 5
-// CHECK1-NEXT:br i1 [[CMP2]], label [[FOR_BODY3:%.*]], label [[FOR_END:%.*]]
-// CHECK1:   for.body3:
-// CHECK1-NEXT:[[TMP3:%.*]] = load i32, ptr [[K]], align 4
-// CHECK1-NEXT:[[INC:%.*]] = add nsw i32 [[TMP3]], 1
-// CHECK1-NEXT:store i32 [[INC]], ptr [[K]], align 4
-// CHECK1-NEXT:br label [[FOR_INC:%.*]]
-// CHECK1:   for.inc:
-// CHECK1-NEXT:[[TMP4:%.*]] = load i32, ptr [[K]], align 4
-// CHECK1-NEXT:[[INC4:%.*]] = add nsw i32 [[TMP4]], 1
-// CHECK1-NEXT:store i32 [[INC4]], ptr [[K]], align 4
-// CHECK1-NEXT:br label [[FOR_COND1]], !llvm.loop [[LOOP3:![0-9]+]]
-// CHECK1:   for.end:
-// CHECK1-NEXT:br label [[FOR_INC5:%.*]]
-// CHECK1:   for.inc5:
-// 

[PATCH] D157029: [llvm] Construct option's prefixed name at compile-time

2023-08-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

In D157029#4561490 , @MaskRay wrote:

> This increases the size of  `Info` (static data size and static relocations). 
> In return, some dynamic relocations are saved. Is this a net win?

If that's a concern, I can remove `Info::Name` and replace its usages with a 
function call that drops the prefix from prefixed name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157029

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


[PATCH] D157033: [clang][CFG] Fix 2 memory errors in interval computation.

2023-08-04 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 547305.
ymandel added a comment.

rebase onto main


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157033

Files:
  clang/lib/Analysis/IntervalPartition.cpp
  clang/unittests/Analysis/IntervalPartitionTest.cpp

Index: clang/unittests/Analysis/IntervalPartitionTest.cpp
===
--- clang/unittests/Analysis/IntervalPartitionTest.cpp
+++ clang/unittests/Analysis/IntervalPartitionTest.cpp
@@ -360,5 +360,38 @@
   Optional(blockOrder(9, 8, 7, 6, 1, 0, 5, 4, 2, 3)));
 }
 
+TEST(GetIntervalWTO, UnreachablePred) {
+  const char *Code = R"(
+  void target(bool Foo) {
+bool Bar = false;
+if (Foo)
+  Bar = Foo;
+else
+  __builtin_unreachable();
+(void)0;
+  })";
+  BuildResult Result = BuildCFG(Code);
+  ASSERT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+  EXPECT_THAT(getIntervalWTO(*Result.getCFG()),
+  Optional(blockOrder(5, 4, 3, 2, 1, 0)));
+}
+
+TEST(WTOCompare, UnreachableBlock) {
+  const char *Code = R"(
+void target() {
+  while (true) {}
+  (void)0;
+  /*[[p]]*/
+})";
+  BuildResult Result = BuildCFG(Code);
+  ASSERT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+  std::optional WTO = getIntervalWTO(*Result.getCFG());
+  ASSERT_THAT(WTO, Optional(blockOrder(4, 3, 2)));
+  auto Cmp = WTOCompare(*WTO);
+  const CFGBlock  = Result.getCFG()->getEntry();
+  const CFGBlock  = Result.getCFG()->getExit();
+  EXPECT_TRUE(Cmp(, ));
+}
+
 } // namespace
 } // namespace clang
Index: clang/lib/Analysis/IntervalPartition.cpp
===
--- clang/lib/Analysis/IntervalPartition.cpp
+++ clang/lib/Analysis/IntervalPartition.cpp
@@ -16,7 +16,6 @@
 #include "llvm/ADT/STLExtras.h"
 #include 
 #include 
-#include 
 #include 
 
 namespace clang {
@@ -24,23 +23,25 @@
 // Intermediate data used in constructing a CFGIntervalNode.
 template  struct BuildResult {
   // Use a vector to maintain the insertion order. Given the expected small
-  // number of nodes, vector should be sufficiently efficient.
+  // number of nodes, vector should be sufficiently efficient. Elements must not
+  // be null.
   std::vector Nodes;
+  // Elements must not be null.
   llvm::SmallDenseSet Successors;
 };
 
 namespace internal {
-static unsigned getID(const CFGBlock *B) { return B->getBlockID(); }
-static unsigned getID(const CFGIntervalNode *I) { return I->ID; }
+static unsigned getID(const CFGBlock ) { return B.getBlockID(); }
+static unsigned getID(const CFGIntervalNode ) { return I.ID; }
 
 // `Node` must be one of `CFGBlock` or `CFGIntervalNode`.
 template 
 BuildResult buildInterval(llvm::BitVector ,
 const Node *Header) {
-  assert(Header);
+  assert(Header != nullptr);
   BuildResult Interval;
   Interval.Nodes.push_back(Header);
-  Partitioned.set(getID(Header));
+  Partitioned.set(getID(*Header));
 
   // FIXME: Compare performance against using RPO to consider nodes, rather than
   // following successors.
@@ -50,7 +51,7 @@
   llvm::BitVector Workset(Partitioned.size(), false);
   for (const Node *S : Header->succs())
 if (S != nullptr)
-  if (auto SID = getID(S); !Partitioned.test(SID)) {
+  if (auto SID = getID(*S); !Partitioned.test(SID)) {
 // Successors are unique, so we don't test against `Workset` before
 // adding to `Worklist`.
 Worklist.push(S);
@@ -63,12 +64,12 @@
   // yet. In the latter case, we'll revisit the block through some other path
   // from the interval. At the end of processing the worklist, we filter out any
   // that ended up in the interval to produce the output set of interval
-  // successors.
+  // successors. Elements are never null.
   std::vector MaybeSuccessors;
 
   while (!Worklist.empty()) {
 const auto *B = Worklist.front();
-auto ID = getID(B);
+auto ID = getID(*B);
 Worklist.pop();
 Workset.reset(ID);
 
@@ -82,7 +83,7 @@
   Partitioned.set(ID);
   for (const Node *S : B->succs())
 if (S != nullptr)
-  if (auto SID = getID(S);
+  if (auto SID = getID(*S);
   !Partitioned.test(SID) && !Workset.test(SID)) {
 Worklist.push(S);
 Workset.set(SID);
@@ -116,8 +117,9 @@
   // graph. In this case, the new interval has identifier `ID` so all of its
   // nodes (`Result.Nodes`) map to `ID`.
   for (const auto *N : Result.Nodes) {
-assert(getID(N) < Index.size());
-Index[getID(N)] = 
+assert(N != nullptr);
+assert(getID(*N) < Index.size());
+Index[getID(*N)] = 
   }
 
   if constexpr (std::is_same_v, CFGBlock>)
@@ -159,7 +161,8 @@
   while (!Successors.empty()) {
 const auto *B = Successors.front();
 Successors.pop();
-if (Partitioned.test(getID(B)))
+assert(B != nullptr);
+if (Partitioned.test(getID(*B)))
   

[PATCH] D148997: [clang] Add a new annotation token: annot_repl_input_end

2023-08-04 Thread Ben Barham via Phabricator via cfe-commits
bnbarham added a comment.

In D148997#4561211 , @v.g.vassilev 
wrote:

 https://github.com/llvm/llvm-project/blob/df6b35e329ebecad6dc3bfb83183e482eb7a0020/clang/lib/Parse/ParseExprCXX.cpp#L4070
>>>
>>> That looks a bit obscure to me. Looks like we are trying to reach some 
>>> error recovery anchor but do you happen to have some use case at hand? In 
>>> principle we could do the same as for the other 3.
>>
>> This was just one I picked at random from my grep over the parser. It's 
>> unclear how often this would be hit, but I have to assume it (and the other 
>> references) can, even if they're obscure/unlikely. My main point is that 
>> `!eof` is being used somewhat frequently to end loops, but with this change 
>> they will now all never end.
>
> Since `eof` there were several `eof`-like tokens that were added: 
> `annot_module_begin`, `annot_module_end`, `tok::annot_module_include` which 
> are commonly handled in `isEofOrEom`. We could update these uses with 
> `isEofOrEom` but I am pretty sure that @rsmith will point out cases where 
> that's not a good very good idea :) We could either experiment with using 
> `isEofOrEom` or have a similar utility function only for the two tokens (say 
> `isEoI` -- end of input whatever that means).

My other concern here is that it seems our use cases are somewhat different, 
eg. we wouldn't want any parsing differences and while I don't know why this is 
yet, the removal of:

  // Skip over the EOF token, flagging end of previous input for incremental
  // processing
  if (PP.isIncrementalProcessingEnabled() && Tok.is(tok::eof))
ConsumeToken();

is causing issues for us as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148997

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


[PATCH] D157115: Revert "[clang][X86] Add __cpuidex function to cpuid.h"

2023-08-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Thank you for this! The revert LGTM, but please wait for @mstorsjo to confirm 
this won't cause problems for MinGW folks.

In terms of solving the underlying issue with aux triple so that we can re-land 
this, I went digging to see if there's an existing issue tracking this and I 
could not find one. However, related to the functionality in this patch, I did 
see: https://github.com/llvm/llvm-project/issues/60383. I filed 
https://github.com/llvm/llvm-project/issues/64436 to track the aux-triple 
issue; hopefully we can find someone with the bandwidth to look into that issue 
(I'll see if I can get someone at Intel to look into it, but if someone else 
wanted to tackle it first, that would be great).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157115

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


  1   2   >