date:20210823

[PATCH] D67429: Improve code generation for thread_local variables:

2021-08-23 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

@rsmith, can you fix or revert?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67429

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

[PATCH] D108609: [clang] NFC: remove superfluous braces

2021-08-23 Thread John McCall via Phabricator via cfe-commits

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108609

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

[PATCH] D108268: [Modules] Change result of reading AST block to llvm::Error instead

2021-08-23 Thread Volodymyr Sapsai via Phabricator via cfe-commits

vsapsai added a comment.

In D108268#2961547 , @bnbarham wrote:

> Unless we also change `DiagnosticEngine` it doesn't look like this is a 
> viable solution. The `PartialDiagnostic` can't be emitted straight to 
> `Diags`, since there may already be a diagnostic in flight (see 
> `Error(unsigned DiagID, ...)`). The args in `PartialDiagnostic` are currently 
> protected and it seems weird to change that, but even if they weren't it sort 
> of defeats the purpose of using `DiagnosticError` in the first place.
>
> Any other ideas?

This might be a stupid idea and a bridge too far but what if delayed diagnostic 
was storing `PartialDiagnostic` and not three strings? This looks like a better 
API but I haven't tried it myself and  concerned we might not have diag 
allocator in all required places.

Another idea is to replace DiagnosedError with something like ThreeStringError 
(please don't use this name). I can be wrong but I find it easier to understand 
an error representing diagnostics compared to a marker that diagnostic was 
emitted-or-scheduled earlier.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108268

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

[PATCH] D108609: [clang] NFC: remove superfluous braces

2021-08-23 Thread zhouyizhou via Phabricator via cfe-commits

zhouyizhou created this revision.
zhouyizhou added reviewers: pengfei, rsmith, rjmccall, doug.gregor, sepavloff, 
craig.topper, klimek.
zhouyizhou requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

In commit 9bb33f572f7609d469d3a505c9987b83eac5b78c, a pair of superfluous 
braces are introduced to the function Sema::BuildDeclarationNameExpr.
This patch tries to remove the superfluous braces. Also use clang-format to 
further beautify the above function.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108609

Files:
  clang/lib/Sema/SemaExpr.cpp

Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -3250,8 +3250,7 @@
 
   // Make sure that we're referring to a value.
   if (!isa(D)) {
-Diag(Loc, diag::err_ref_non_value)
-  << D << SS.getRange();
+Diag(Loc, diag::err_ref_non_value) << D << SS.getRange();
 Diag(D->getLocation(), diag::note_declared_at);
 return ExprError();
   }
@@ -3277,210 +3276,204 @@
   return BuildAnonymousStructUnionMemberReference(SS, NameInfo.getLoc(),
   indirectField);
 
-  {
-QualType type = VD->getType();
-if (type.isNull())
-  return ExprError();
-ExprValueKind valueKind = VK_PRValue;
+  QualType type = VD->getType();
+  if (type.isNull())
+return ExprError();
+  ExprValueKind valueKind = VK_PRValue;
 
-// In 'T ...V;', the type of the declaration 'V' is 'T...', but the type of
-// a reference to 'V' is simply (unexpanded) 'T'. The type, like the value,
-// is expanded by some outer '...' in the context of the use.
-type = type.getNonPackExpansionType();
+  // In 'T ...V;', the type of the declaration 'V' is 'T...', but the type of
+  // a reference to 'V' is simply (unexpanded) 'T'. The type, like the value,
+  // is expanded by some outer '...' in the context of the use.
+  type = type.getNonPackExpansionType();
 
-switch (D->getKind()) {
+  switch (D->getKind()) {
 // Ignore all the non-ValueDecl kinds.
 #define ABSTRACT_DECL(kind)
 #define VALUE(type, base)
-#define DECL(type, base) \
-case Decl::type:
+#define DECL(type, base) case Decl::type:
 #include "clang/AST/DeclNodes.inc"
-  llvm_unreachable("invalid value decl kind");
-
-// These shouldn't make it here.
-case Decl::ObjCAtDefsField:
-  llvm_unreachable("forming non-member reference to ivar?");
-
-// Enum constants are always r-values and never references.
-// Unresolved using declarations are dependent.
-case Decl::EnumConstant:
-case Decl::UnresolvedUsingValue:
-case Decl::OMPDeclareReduction:
-case Decl::OMPDeclareMapper:
-  valueKind = VK_PRValue;
+llvm_unreachable("invalid value decl kind");
+
+  // These shouldn't make it here.
+  case Decl::ObjCAtDefsField:
+llvm_unreachable("forming non-member reference to ivar?");
+
+  // Enum constants are always r-values and never references.
+  // Unresolved using declarations are dependent.
+  case Decl::EnumConstant:
+  case Decl::UnresolvedUsingValue:
+  case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
+valueKind = VK_PRValue;
+break;
+
+  // Fields and indirect fields that got here must be for
+  // pointer-to-member expressions; we just call them l-values for
+  // internal consistency, because this subexpression doesn't really
+  // exist in the high-level semantics.
+  case Decl::Field:
+  case Decl::IndirectField:
+  case Decl::ObjCIvar:
+assert(getLangOpts().CPlusPlus && "building reference to field in C?");
+
+// These can't have reference type in well-formed programs, but
+// for internal consistency we do this anyway.
+type = type.getNonReferenceType();
+valueKind = VK_LValue;
+break;
+
+  // Non-type template parameters are either l-values or r-values
+  // depending on the type.
+  case Decl::NonTypeTemplateParm: {
+if (const ReferenceType *reftype = type->getAs()) {
+  type = reftype->getPointeeType();
+  valueKind = VK_LValue; // even if the parameter is an r-value reference
   break;
+}
 
-// Fields and indirect fields that got here must be for
-// pointer-to-member expressions; we just call them l-values for
-// internal consistency, because this subexpression doesn't really
-// exist in the high-level semantics.
-case Decl::Field:
-case Decl::IndirectField:
-case Decl::ObjCIvar:
-  assert(getLangOpts().CPlusPlus &&
- "building reference to field in C?");
-
-  // These can't have reference type in well-formed programs, but
-  // for internal consistency we do this anyway.
-  type = type.getNonReferenceType();
+// [expr.prim.id.unqual]p2:
+//   If the entity is a template parameter object for a template
+//   parameter o

[PATCH] D105671: [Intrinsics][ObjC] Mark objc_retain and friends as thisreturn.

2021-08-23 Thread John McCall via Phabricator via cfe-commits

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

Okay, thanks, seems like a good approach.




Comment at: clang/test/CodeGenObjC/convert-messages-to-runtime-calls.m:34
+  // CALLS-NOT: {{call.*@llvm.objc.release}}
+  // CALLS-NOT: {{tail call.*@llvm.objc.autorelease}}
   // CALLS: {{call.*@objc_alloc}}

This only actually tests for the absence of these lines between the CHECK-LABEL 
and the first CALLS line below, so I don't think it does much.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105671

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

[PATCH] D105972: Fix attribute((annotate("")) with non-zero globals AS

2021-08-23 Thread John McCall via Phabricator via cfe-commits

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

Sorry for the delay; LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105972

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

[PATCH] D107547: [CodeGen] Align calling convention bit-width to bitcode

2021-08-23 Thread John McCall via Phabricator via cfe-commits

rjmccall added inline comments.



Comment at: clang/include/clang/CodeGen/CGFunctionInfo.h:562
   /// The clang::CallingConv that this was originally created with.
-  unsigned ASTCallingConvention : 6;
+  unsigned ASTCallingConvention : 10;
 

At some point, these bit-fields fit into a single 32-bit unit.  There's 
currently 33 bits, so that hasn't been true for a while, and we might as well 
make all three of these fields 16 bits.

It doesn't look like there's a good opportunity to pack the struct because 
we're at an odd number of 32-bit chunks overall, so that'll do for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107547

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

[PATCH] D108421: Mark openmp internal global dso_local

2021-08-23 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:2194
+  getOrCreateInternalVariable(KmpCriticalNameTy, Name));
+  if (!GV->isDSOLocal())
+GV->setDSOLocal(true);

MaskRay wrote:
> Can be variable be preemptible on ELF? (i.e. default visibility non-local 
> linkage) If yes, it cannot be marked dso_local in that case.
> in that case

=> When -fpic is used.

`-fpic -shared` may give a linker error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108421

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

[PATCH] D108421: Mark openmp internal global dso_local

2021-08-23 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:2194
+  getOrCreateInternalVariable(KmpCriticalNameTy, Name));
+  if (!GV->isDSOLocal())
+GV->setDSOLocal(true);

Can be variable be preemptible on ELF? (i.e. default visibility non-local 
linkage) If yes, it cannot be marked dso_local in that case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108421

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

[PATCH] D108421: Mark openmp internal global dso_local

2021-08-23 Thread kamlesh kumar via Phabricator via cfe-commits

kamleshbhalui updated this revision to Diff 368261.
kamleshbhalui added a comment.

updated test and make changes local to auto generated global vars for lock.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108421

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/critical_codegen.cpp
  clang/test/OpenMP/critical_codegen_attr.cpp
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp


Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -2487,7 +2487,12 @@
 Value *OpenMPIRBuilder::getOMPCriticalRegionLock(StringRef CriticalName) {
   std::string Prefix = Twine("gomp_critical_user_", CriticalName).str();
   std::string Name = getNameWithSeparators({Prefix, "var"}, ".", ".");
-  return getOrCreateOMPInternalVariable(KmpCriticalNameTy, Name);
+  llvm::GlobalVariable *GV = cast(
+  getOrCreateOMPInternalVariable(KmpCriticalNameTy, Name));
+  if (!GV->isDSOLocal())
+GV->setDSOLocal(true);
+
+  return cast(GV);
 }
 
 GlobalVariable *
Index: clang/test/OpenMP/critical_codegen_attr.cpp
===
--- clang/test/OpenMP/critical_codegen_attr.cpp
+++ clang/test/OpenMP/critical_codegen_attr.cpp
@@ -16,9 +16,9 @@
 #define HEADER
 
 // ALL:   [[IDENT_T_TY:%.+]] = type { i32, i32, i32, i32, i8* }
-// ALL:   [[UNNAMED_LOCK:@.+]] = common global [8 x i32] zeroinitializer
-// ALL:   [[THE_NAME_LOCK:@.+]] = common global [8 x i32] zeroinitializer
-// ALL:   [[THE_NAME_LOCK1:@.+]] = common global [8 x i32] zeroinitializer
+// ALL:   [[UNNAMED_LOCK:@.+]] = common dso_local global [8 x i32] 
zeroinitializer
+// ALL:   [[THE_NAME_LOCK:@.+]] = common dso_local global [8 x i32] 
zeroinitializer
+// ALL:   [[THE_NAME_LOCK1:@.+]] = common dso_local global [8 x i32] 
zeroinitializer
 
 // ALL:   define {{.*}}void [[FOO:@.+]]()
 
Index: clang/test/OpenMP/critical_codegen.cpp
===
--- clang/test/OpenMP/critical_codegen.cpp
+++ clang/test/OpenMP/critical_codegen.cpp
@@ -16,9 +16,9 @@
 #define HEADER
 
 // ALL:   [[IDENT_T_TY:%.+]] = type { i32, i32, i32, i32, i8* }
-// ALL:   [[UNNAMED_LOCK:@.+]] = common global [8 x i32] zeroinitializer
-// ALL:   [[THE_NAME_LOCK:@.+]] = common global [8 x i32] zeroinitializer
-// ALL:   [[THE_NAME_LOCK1:@.+]] = common global [8 x i32] zeroinitializer
+// ALL:   [[UNNAMED_LOCK:@.+]] = common dso_local global [8 x i32] 
zeroinitializer
+// ALL:   [[THE_NAME_LOCK:@.+]] = common dso_local global [8 x i32] 
zeroinitializer
+// ALL:   [[THE_NAME_LOCK1:@.+]] = common dso_local global [8 x i32] 
zeroinitializer
 
 // ALL:   define {{.*}}void [[FOO:@.+]]()
 
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -2189,7 +2189,12 @@
 llvm::Value *CGOpenMPRuntime::getCriticalRegionLock(StringRef CriticalName) {
   std::string Prefix = Twine("gomp_critical_user_", CriticalName).str();
   std::string Name = getName({Prefix, "var"});
-  return getOrCreateInternalVariable(KmpCriticalNameTy, Name);
+  llvm::GlobalVariable *GV = cast(
+  getOrCreateInternalVariable(KmpCriticalNameTy, Name));
+  if (!GV->isDSOLocal())
+GV->setDSOLocal(true);
+
+  return cast(GV);
 }
 
 namespace {


Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -2487,7 +2487,12 @@
 Value *OpenMPIRBuilder::getOMPCriticalRegionLock(StringRef CriticalName) {
   std::string Prefix = Twine("gomp_critical_user_", CriticalName).str();
   std::string Name = getNameWithSeparators({Prefix, "var"}, ".", ".");
-  return getOrCreateOMPInternalVariable(KmpCriticalNameTy, Name);
+  llvm::GlobalVariable *GV = cast(
+  getOrCreateOMPInternalVariable(KmpCriticalNameTy, Name));
+  if (!GV->isDSOLocal())
+GV->setDSOLocal(true);
+
+  return cast(GV);
 }
 
 GlobalVariable *
Index: clang/test/OpenMP/critical_codegen_attr.cpp
===
--- clang/test/OpenMP/critical_codegen_attr.cpp
+++ clang/test/OpenMP/critical_codegen_attr.cpp
@@ -16,9 +16,9 @@
 #define HEADER
 
 // ALL:   [[IDENT_T_TY:%.+]] = type { i32, i32, i32, i32, i8* }
-// ALL:   [[UNNAMED_LOCK:@.+]] = common global [8 x i32] zeroinitializer
-// ALL:   [[THE_NAME_LOCK:@.+]] = common global [8 x i32] zeroinitializer
-// ALL:   [[THE_NAME_LOCK1:@.+]] = common global [8 x i32] zeroinitializer
+// ALL:   [[UNNAMED_LOCK:@.+]] = common dso_local global [8 x i32] zeroinitializer
+// ALL:

[PATCH] D108464: [clang][CodeGen] Refactor CreateTempAlloca function nest. NFC.

2021-08-23 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

In D108464#2960791 , @tlively wrote:

> In D108464#2960623 , @rjmccall 
> wrote:
>
>> + JF, who knows something about Web Assembly, or can at least drag in the 
>> right people
>>
>> In D108464#2959591 , @wingo wrote:
>>
>>> In D108464#2957276 , @wingo wrote:
>>>
 So... besides the refactor, this is getting closer to where I'm going 
 in https://lists.llvm.org/pipermail/cfe-dev/2021-July/068559.html, though 
 still NFC.  I think you can see where I would replace 
 `getASTAllocaAddressSpace` with `getAllocaAddressSpace(QualType Ty)`, and 
 possibly (depending on the source language) avoid casting the resulting 
 alloca to `LangAS::Default`.  WDYT, is this sort of thing OK?
>>>
>>> Taking this patch as perhaps a better generic discussion point, @rjmccall 
>>> graciously gave some general feedback on this approach (thank you!!!):
>>>
>>> In D108360#2957844 , @rjmccall 
>>> wrote:
>>>
 I'm not sure that I agree with your overall plan, though:

 - The WebAssembly operand stack is not a good match for an address space 
 at the language level because it's not addressable at all.  If you can't 
 meaningfully have a pointer into the address space, then you don't really 
 need this in the type system; it's more like a declaration modifier at 
 best.
 - Allocating local variables on the operand stack ought to be a very 
 straightforward analysis in the backend.  There's not much optimization 
 value in trying to do it in the frontend, and it's going to be problematic 
 for things like coroutine lowering.
 - The security argument seems pretty weak, not because security isn't 
 important but because this is not really an adequate basis for getting the 
 tamper-proof guarantee you want.  For example, LLVM passes can and do 
 introduce its own allocas and store scalars into them sometimes.  Really 
 you need some sort of "tamper-proof" *type* which the compiler can make an 
 end-to-end guarantee of non-tamper-ability for the values of, and while 
 optimally this would be implemented by just keeping values on the operand 
 stack, in the general case you will need to have some sort of strategy for 
 keeping things in memory.
>>>
>>> Thanks for thinking about this!  Indeed I started out with the goal of not 
>>> going deep into clang and if it's possible to avoid going too deeply, that 
>>> would be better for everyone involved.  I am starting to think however that 
>>> it may be unavoidable for me at least.
>>>
>>> So, I am focusing on WebAssembly global and local variables; the 
>>> WebAssembly operand stack is an artifact of the IR-to-MC lowering and 
>>> AFAICS doesn't have any bearing on what clang does -- though perhaps I am 
>>> misunderstanding what you are getting at here.  The issue is not to 
>>> allocate locals on the operand stack, but rather to allocate them as part 
>>> of the "locals" of a WebAssembly function 
>>> .  
>>> Cc @tlively on the WebAssembly side.
>>
>> By "operand stack" I mean the innate, unaddressable stack that the 
>> WebAssembly VM maintains in order to make functions reentrant.  I don't know 
>> what term the VM spec uses for it, but I believe "operand stack" is widely 
>> accepted terminology for the unaddressable stack when you've got this kind 
>> of dual-stack setup.  And yes, VM "locals" would go there.
>
> @wingo, are there cases where it is useful to declare variables as living in 
> WebAssembly locals and not in the VM stack? I'm having trouble coming up with 
> a case where leaving that up to the backend is not enough. We clearly need a 
> way to prevent values from being written to main memory (AS 0), but it's not 
> clear to me that we need a way to specifically allocate locals for them.

Right, I think this is one of the key questions here.  Right now this seems to 
be entirely type-directed: it's a special property of a couple of builtin types 
that you can't take the address of their objects and those objects can only 
live in specific places.  Having it be type-directed, but only to the point of 
saying that certain types *must* use certain address spaces, and then imposing 
all the other restrictions on those types as novel restrictions on those 
address spaces, feels like it's adding complexity to the language concept of 
address spaces without much benefit.

>>> The main motivator is the ability to have "reference type" 
>>>  
>>> (`externref`/`funcref`) locals and globals 
>>>  at 
>>> all.  Reference-typed values can't b

[PATCH] D107394: [AIX] "aligned" attribute does not decrease alignment

2021-08-23 Thread John McCall via Phabricator via cfe-commits

rjmccall added inline comments.



Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:1975
+  bool AlignAttrCanDecreaseAlignment =
+  AlignIsRequired && (Ty->getAs() != nullptr || FieldPacked);
+

stevewan wrote:
> rjmccall wrote:
> > Okay, so first off, the comment and variable names here make this sound 
> > very general when in fact this computation is only relevant to the AIX 
> > alignment upgrade logic.  Also, please do not introduce new variables with 
> > broad scope named things like `Ty` that are actually referring to a very 
> > specific type and not, say, the unadulterated type of the field.
> > 
> > It seems to me that the right way to think about this is that, while the 
> > AIX power alignment upgrade considers whether field type alignment is 
> > "required", it uses a different condition than the standard rule when 
> > making that decision.  It's important to understand what that rule is 
> > exactly, and we can't see that from the current test cases.  In particular, 
> > attributes on fields that define structs inline actually end up applying to 
> > both the field and the struct, which confounds unrelated issues.  Consider:
> > 
> > ```
> > struct __attribute__((packed, aligned(2))) SS {
> >   double d;
> > };
> > 
> > struct S {
> >   // Neither the field nor the struct are packed, but the field type is.
> >   // Do we apply the alignment upgrade to S or not?
> >   struct SS s;
> > };
> > ```
> > 
> > Regardless, I don't think this check for a typedef works; it's bypassing 
> > quite a bit of recursive logic for computing whether type alignment is 
> > required.  For example, you could have an explicitly aligned typedef of an 
> > array type, and you'll lose that typedef here.
> Thanks for the review. 
> 
> > the comment and variable names here make this sound very general when in 
> > fact this computation is only relevant to the AIX alignment upgrade logic.
> Moved the variable declarations back to the AIX alignment upgrade logic. 
> >  It's important to understand what that rule is exactly, and we can't see 
> > that from the current test cases.
> Updated the test cases accordingly.
> > For example, you could have an explicitly aligned typedef of an array type, 
> > and you'll lose that typedef here.
> Updated the check to examine the immediate type rather than the base element 
> type, this should take care of the array-type considerations. 
> 
No, I'm not sure that's quite correct, either, because you might have an array 
of an explicitly aligned typedef.  You might need to do a recursive examination 
of the type the same way that getTypeInfo would, except I guess not recursing 
into records.

I assume you verified that the behavior in your new test cases matches the 
behavior of some existing AIX compiler?  For our general edification, what 
compiler(s) are you testing against?

I've found that extracting very complex conditions into a function (perhaps a 
lambda if it's inconvenient to have it separately-declared) can be useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107394

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

[PATCH] D106343: [OpenCL] Support cl_ext_float_atomics

2021-08-23 Thread Yang Haonan via Phabricator via cfe-commits

haonanya updated this revision to Diff 368256.
haonanya added a comment.

Fix formatting issues


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

https://reviews.llvm.org/D106343

Files:
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h
  clang/lib/Sema/OpenCLBuiltins.td
  clang/test/Headers/opencl-c-header.cl
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl

Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -122,6 +122,27 @@
 }
 #endif
 
+#if !defined(NO_HEADER) && !defined(NO_FP64) && __OPENCL_C_VERSION__ >= 200
+// Check added atomic_fetch_ functions by cl_ext_float_atomics
+// extension can be called
+void test_atomic_fetch_with_address_space(volatile __generic atomic_float *a_float,
+		  volatile __generic atomic_double *a_double,
+  volatile __local atomic_float *a_float_local,
+  volatile __local atomic_double *a_double_local,
+  volatile __global atomic_float *a_float_global,
+  volatile __global atomic_double *a_double_global) {
+  float f1, resf1;
+  double d1, resd1;
+  resf1 = atomic_fetch_min(a_float, f1);
+  resf1 = atomic_fetch_max_explicit(a_float_local, f1, memory_order_seq_cst);
+  resf1 = atomic_fetch_add_explicit(a_float_global, f1, memory_order_seq_cst, memory_scope_work_group);
+
+  resd1 = atomic_fetch_min(a_double, d1);
+  resd1 = atomic_fetch_max_explicit(a_double_local, d1, memory_order_seq_cst);
+  resd1 = atomic_fetch_add_explicit(a_double_global, d1, memory_order_seq_cst, memory_scope_work_group);
+}
+#endif // !defined(NO_HEADER) && __OPENCL_C_VERSION__ >= 200
+
 // Test old atomic overloaded with generic address space in C++ for OpenCL.
 #if __OPENCL_C_VERSION__ >= 200
 void test_legacy_atomics_cpp(__generic volatile unsigned int *a) {
Index: clang/test/Headers/opencl-c-header.cl
===
--- clang/test/Headers/opencl-c-header.cl
+++ clang/test/Headers/opencl-c-header.cl
@@ -135,6 +135,51 @@
 #if __opencl_c_integer_dot_product_input_4x8bit_packed != 1
 #error "Incorrectly defined __opencl_c_integer_dot_product_input_4x8bit_packed"
 #endif
+#if cl_ext_float_atomics != 1
+#error "Incorrectly defined cl_ext_float_atomics"
+#endif
+#if __opencl_c_ext_fp16_global_atomic_load_store != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_global_atomic_load_store"
+#endif
+#if __opencl_c_ext_fp16_local_atomic_load_store != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_local_atomic_load_store"
+#endif
+#if __opencl_c_ext_fp16_global_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_global_atomic_add"
+#endif
+#if __opencl_c_ext_fp32_global_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp32_global_atomic_add"
+#endif
+#if __opencl_c_ext_fp64_global_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp64_global_atomic_add"
+#endif
+#if __opencl_c_ext_fp16_local_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_local_atomic_add"
+#endif
+#if __opencl_c_ext_fp32_local_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp32_local_atomic_add"
+#endif
+#if __opencl_c_ext_fp64_local_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp64_local_atomic_add"
+#endif
+#if __opencl_c_ext_fp16_global_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_global_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp32_global_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp32_global_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp64_global_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp64_global_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp16_local_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_local_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp32_local_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp32_local_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp64_local_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp64_local_atomic_min_max"
+#endif
 
 #else
 
@@ -171,6 +216,51 @@
 #ifdef __opencl_c_integer_dot_product_input_4x8bit_packed
 #error "Incorrect __opencl_c_integer_dot_product_input_4x8bit_packed define"
 #endif
+#ifdef cl_ext_float_atomics
+#error "Incorrect cl_ext_float_atomics define"
+#endif
+#ifdef __opencl_c_ext_fp16_global_atomic_load_store
+#error "Incorrectly __opencl_c_ext_fp16_global_atomic_load_store defined"
+#endif
+#ifdef __opencl_c_ext_fp16_local_atomic_load_store
+#error "Incorrectly __opencl_c_ext_fp16_local_atomic_load_store defined"
+#endif
+#ifdef __opencl_c_ext_fp16_global_atomic_add
+#error "Incorrectly __opencl_c_ext_fp16_global_atomic_add defined"
+#endif
+

[PATCH] D105268: [X86] AVX512FP16 instructions enabling 5/6

2021-08-23 Thread Pengfei Wang 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 rGc728bd5bbaab: [X86] AVX512FP16 instructions enabling 5/6 
(authored by pengfei).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105268

Files:
  clang/include/clang/Basic/BuiltinsX86.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/avx512fp16intrin.h
  clang/lib/Headers/avx512vlfp16intrin.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/X86/avx512fp16-builtins.c
  clang/test/CodeGen/X86/avx512vlfp16-builtins.c
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86InstrAVX512.td
  llvm/lib/Target/X86/X86InstrFMA3Info.cpp
  llvm/lib/Target/X86/X86InstrFoldTables.cpp
  llvm/lib/Target/X86/X86InstrFormats.td
  llvm/lib/Target/X86/X86InstrInfo.cpp
  llvm/lib/Target/X86/X86IntrinsicsInfo.h
  llvm/test/CodeGen/X86/avx512fp16-fma-commute.ll
  llvm/test/CodeGen/X86/avx512fp16-fma-intrinsics.ll
  llvm/test/CodeGen/X86/avx512fp16vl-fma-intrinsics.ll
  llvm/test/CodeGen/X86/fp-strict-scalar-fp16.ll
  llvm/test/CodeGen/X86/stack-folding-fp-avx512fp16-fma.ll
  llvm/test/CodeGen/X86/stack-folding-fp-avx512fp16vl-fma.ll
  llvm/test/CodeGen/X86/vec-strict-128-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-256-fp16.ll
  llvm/test/CodeGen/X86/vec-strict-512-fp16.ll
  llvm/test/MC/Disassembler/X86/avx512fp16.txt
  llvm/test/MC/Disassembler/X86/avx512fp16vl.txt
  llvm/test/MC/X86/avx512fp16.s
  llvm/test/MC/X86/avx512fp16vl.s
  llvm/test/MC/X86/intel-syntax-avx512fp16.s
  llvm/test/MC/X86/intel-syntax-avx512fp16vl.s

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

[PATCH] D108268: [Modules] Change result of reading AST block to llvm::Error instead

2021-08-23 Thread Ben Barham via Phabricator via cfe-commits

bnbarham added a comment.

In D108268#2958568 , @vsapsai wrote:

> `DiagnosticError` looks like a good fit for the task at hand, so it is worth 
> to try it. Though I don't know if it would end up in the end convoluted or OK.

Unless we also change `DiagnosticEngine` it doesn't look like this is a viable 
solution. The `PartialDiagnostic` can't be emitted straight to `Diags`, since 
there may already be a diagnostic in flight (see `Error(unsigned DiagID, 
...)`). The args in `PartialDiagnostic` are currently protected and it seems 
weird to change that, but even if they weren't it sort of defeats the purpose 
of using `DiagnosticError` in the first place.

Any other ideas?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108268

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

[PATCH] D108603: [clang][codegen] Set CurLinkModule in CodeGenAction::ExecuteAction

2021-08-23 Thread Bob Haarman via Phabricator via cfe-commits

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

CodeGenAction::ExecuteAction creates a BackendConsumer for the
purpose of handling diagnostics. The BackendConsumer's
DiagnosticHandlerImpl method expects CurLinkModule to be set,
but this did not happen on the code path that goes through
ExecuteAction. This change makes it so that the BackendConsumer
constructor used by ExecuteAction requires the Module to be
specified and passes the appropriate module in ExecuteAction.

The change also adds a test that fails without this change
and passes with it. To make the test work, the FIXME in the
handling of DK_Linker diagnostics was addressed so that warnings
and notes are no longer silently discarded. Since this introduces
a new warning diagnostic, a flag to control it (-Wlinker-warnings)
has also been added.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108603

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/CodeGen/Inputs/linker-diagnostic1.ll
  clang/test/CodeGen/linker-diagnostic.ll
  clang/test/Misc/serialized-diags-driver.c

Index: clang/test/Misc/serialized-diags-driver.c
===
--- clang/test/Misc/serialized-diags-driver.c
+++ clang/test/Misc/serialized-diags-driver.c
@@ -8,7 +8,8 @@
 // RUN: %clang -Wx-typoed-warning -Wall -fsyntax-only --serialize-diagnostics %t.diag %s
 // RUN: c-index-test -read-diagnostics %t.diag 2>&1 | FileCheck %s
 
-// CHECK: warning: unknown warning option '-Wx-typoed-warning' [-Wunknown-warning-option] []
+// CHECK: warning: unknown warning option '-Wx-typoed-warning'
+// CHECK-SAME: [-Wunknown-warning-option] []
 
 // CHECK: warning: variable 'voodoo' is uninitialized when used here [-Wuninitialized]
 // CHECK: note: initialize the variable 'voodoo' to silence this warning []
Index: clang/test/CodeGen/linker-diagnostic.ll
===
--- /dev/null
+++ clang/test/CodeGen/linker-diagnostic.ll
@@ -0,0 +1,17 @@
+; RUN: mkdir -p %t
+; RUN: opt -module-summary -o %t/foo.o %s
+; RUN: opt -module-summary -o %t/bar.o %S/Inputs/linker-diagnostic1.ll
+; RUN: llvm-lto2 run --thinlto-distributed-indexes -r %t/foo.o,foo,plx -r %t/bar.o,bar,plx \
+; RUN:   -r %t/bar.o,foo, -o %t/foobar.so %t/foo.o %t/bar.o
+; RUN: %clang -c -o %t/lto.bar.o --target=armv4-none-unknown-eabi -O2 \
+; RUN:   -fthinlto-index=%t/bar.o.thinlto.bc %t/bar.o -Wno-override-module 2>&1 | FileCheck %s
+
+; CHECK: linking module '{{.*}}/bar.o': Linking two modules of different target triples: '{{.*}}/foo.o' is 'thumbv6-unknown-linux-gnueabihf' whereas '{{.*}}/bar.o' is 'armv4-none-unknown-eabi'
+
+target triple = "thumbv6-unknown-linux-gnueabihf"
+target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
+
+define i32 @foo(i32 %x) {
+  %1 = add i32 %x, 1
+  ret i32 %1
+}
Index: clang/test/CodeGen/Inputs/linker-diagnostic1.ll
===
--- /dev/null
+++ clang/test/CodeGen/Inputs/linker-diagnostic1.ll
@@ -0,0 +1,9 @@
+target triple = "armv4-none-unknown-eabi"
+target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
+
+declare i32 @foo(i32)
+
+define i32 @bar(i32 %x) {
+  %1 = tail call i32 @foo(i32 %x)
+  ret i32 %1
+}
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -160,7 +160,7 @@
 const PreprocessorOptions &PPOpts,
 const CodeGenOptions &CodeGenOpts,
 const TargetOptions &TargetOpts,
-const LangOptions &LangOpts,
+const LangOptions &LangOpts, llvm::Module *Module,
 SmallVector LinkModules, LLVMContext &C,
 CoverageSourceInfo *CoverageInfo = nullptr)
 : Diags(Diags), Action(Action), HeaderSearchOpts(HeaderSearchOpts),
@@ -170,7 +170,7 @@
   LLVMIRGenerationRefCount(0),
   Gen(CreateLLVMCodeGen(Diags, "", HeaderSearchOpts, PPOpts,
 CodeGenOpts, C, CoverageInfo)),
-  LinkModules(std::move(LinkModules)) {
+  LinkModules(std::move(LinkModules)), CurLinkModule(Module) {
   TimerIsEnabled = CodeGenOpts.TimePasses;
   llvm::TimePassesIsEnabled = CodeGenOpts.TimePasses;
   llvm::TimePassesPerRun = CodeGenOpts.TimePassesPerRun;
@@ -779,11 +779,7 @@
 ComputeDiagID(Severity, backend_frame_larger_than, DiagID);
 break;
   case DK_Linker:
-assert(CurLinkModule);
-// FIXME: stop eating the warnings and notes.
-if (Severity != DS_Error)
-  return;
-DiagID = diag::err_fe_cannot_link_module;
+ComputeDiagID(Sev

[PATCH] D107850: [asan] Implemented intrinsic for the custom calling convention similar used by HWASan for X86.

2021-08-23 Thread Vitaly Buka via Phabricator via cfe-commits

vitalybuka added inline comments.



Comment at: llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h:166
+  ASanAccessInfo(bool IsWrite, bool CompileKernel, uint8_t AccessSizeIndex);
+};
+

.cpp file is missing



Comment at: llvm/lib/Target/X86/X86MCInstLower.cpp:1426
+  OutStreamer->emitInstruction(MCInstBuilder(X86::AND32ri8)
+   .addReg(X86::ECX)
+   .addReg(X86::ECX)

kstoimenov wrote:
> vitalybuka wrote:
> > what is in ECX register here?
> Should be NoRegister. Done.
Why NoRegister update is not reflected in tests?



Comment at: llvm/test/CodeGen/X86/asan-check-memaccess-or.ll:94
+; CHECK-NEXT: movq[[REG]], %rcx
+; CHECK-NEXT: andl$7, %ecx
+; CHECK-NEXT: addl$1, %ecx

What is ECX here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107850

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

[PATCH] D107685: [WebAssembly] Tidy up EH/SjLj options

2021-08-23 Thread Heejin Ahn via Phabricator via cfe-commits

aheejin added inline comments.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp:449
+  // done in WasmEHPrepare pass after these IR passes, but Wasm SjLj requires
+  // Emscripten libraries and processed together in LowerEmscriptenEHSjLJ pass.
+  if (WasmEnableEmEH || WasmEnableEmSjLj || WasmEnableSjLj)

dschuff wrote:
> it's not clear what "and processed" is intended to mean here.
Yeah the sentence is unclear and even grammatically incorrect... Rewrote it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107685

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

[PATCH] D107685: [WebAssembly] Tidy up EH/SjLj options

2021-08-23 Thread Heejin Ahn via Phabricator via cfe-commits

aheejin updated this revision to Diff 368237.
aheejin marked 3 inline comments as done.
aheejin added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107685

Files:
  clang/test/CodeGenCXX/wasm-eh.cpp
  lld/test/wasm/tag-section.ll
  llvm/lib/Target/WebAssembly/WebAssembly.h
  llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyMCInstLower.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.ll
  llvm/test/CodeGen/WebAssembly/eh-lsda.ll
  llvm/test/CodeGen/WebAssembly/exception.ll
  llvm/test/CodeGen/WebAssembly/lower-em-ehsjlj.ll
  llvm/test/CodeGen/WebAssembly/lower-em-exceptions-allowed.ll
  llvm/test/CodeGen/WebAssembly/lower-em-exceptions-resume-only.ll
  llvm/test/CodeGen/WebAssembly/lower-em-exceptions.ll
  llvm/test/CodeGen/WebAssembly/lower-em-sjlj-alias.ll
  llvm/test/CodeGen/WebAssembly/lower-em-sjlj-debuginfo.ll
  llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll
  llvm/test/CodeGen/WebAssembly/null-streamer.ll
  llvm/test/CodeGen/WebAssembly/wasm-eh-em-sjlj-error.ll
  llvm/test/MC/WebAssembly/tag-section-decoding.ll
  llvm/test/MC/WebAssembly/tag-section.ll

Index: llvm/test/MC/WebAssembly/tag-section.ll
===
--- llvm/test/MC/WebAssembly/tag-section.ll
+++ llvm/test/MC/WebAssembly/tag-section.ll
@@ -1,5 +1,5 @@
-; RUN: llc -filetype=obj -exception-model=wasm -mattr=+exception-handling %s -o - | obj2yaml | FileCheck %s
-; RUN: llc -filetype=obj -exception-model=wasm -mattr=+exception-handling %s -o - | llvm-readobj -S - | FileCheck -check-prefix=SEC %s
+; RUN: llc -filetype=obj -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling %s -o - | obj2yaml | FileCheck %s
+; RUN: llc -filetype=obj -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling %s -o - | llvm-readobj -S - | FileCheck -check-prefix=SEC %s
 
 target triple = "wasm32-unknown-unknown"
 
Index: llvm/test/MC/WebAssembly/tag-section-decoding.ll
===
--- llvm/test/MC/WebAssembly/tag-section-decoding.ll
+++ llvm/test/MC/WebAssembly/tag-section-decoding.ll
@@ -1,4 +1,4 @@
-; RUN: llc -filetype=obj -exception-model=wasm -mattr=+exception-handling %s -o - | obj2yaml | FileCheck %s
+; RUN: llc -filetype=obj -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling %s -o - | obj2yaml | FileCheck %s
 
 ; This is a regression test for a decoding bug that happens when a tag's
 ; sigindex is greater than 63, so we put 63 dummy functions with different
Index: llvm/test/CodeGen/WebAssembly/wasm-eh-em-sjlj-error.ll
===
--- llvm/test/CodeGen/WebAssembly/wasm-eh-em-sjlj-error.ll
+++ llvm/test/CodeGen/WebAssembly/wasm-eh-em-sjlj-error.ll
@@ -1,4 +1,4 @@
-; RUN: not --crash llc < %s -enable-emscripten-sjlj -exception-model=wasm 2>&1 | FileCheck %s
+; RUN: not --crash llc < %s -wasm-enable-eh -enable-emscripten-sjlj -exception-model=wasm 2>&1 | FileCheck %s
 
 target triple = "wasm32-unknown-unknown"
 
Index: llvm/test/CodeGen/WebAssembly/null-streamer.ll
===
--- llvm/test/CodeGen/WebAssembly/null-streamer.ll
+++ llvm/test/CodeGen/WebAssembly/null-streamer.ll
@@ -1,5 +1,5 @@
-; RUN: llc < %s -O0 -filetype=null -exception-model=wasm -mattr=+exception-handling
-; RUN: llc < %s -O0 -filetype=asm -asm-verbose=false -exception-model=wasm -mattr=+exception-handling | FileCheck %s
+; RUN: llc < %s -O0 -filetype=null -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling
+; RUN: llc < %s -O0 -filetype=asm -asm-verbose=false -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling | FileCheck %s
 
 target triple = "wasm32-unknown-unknown"
 
Index: llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll
===
--- llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll
+++ llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll
@@ -1,6 +1,6 @@
-; RUN: opt < %s -wasm-lower-em-ehsjlj -S | FileCheck %s --check-prefixes=CHECK,NO-TLS -DPTR=i32
-; RUN: opt < %s -wasm-lower-em-ehsjlj -S --mattr=+atomics,+bulk-memory | FileCheck %s --check-prefixes=CHECK,TLS -DPTR=i32
-; RUN: opt < %s -wasm-lower-em-ehsjlj --mtriple=wasm64-unknown-unknown -data-layout="e-m:e-p:64:64-i64:64-n32:64-S128" -S | FileCheck %s --check-prefixes=CHECK -DPTR=i64
+; RUN: opt < %s -wasm-lower-em-ehsjlj -enable-emscripten-sjlj -S | FileCheck %s --check-prefixes=CHECK,NO-TLS -DPTR=i32
+; RUN: opt < %s -wasm-lower-em-ehsjlj -enable-emscripten-sjlj -S --mattr=+atomics,+bulk-memory | FileCheck %s --check-prefixes=CHECK,TLS -DPTR=i32
+; RUN: opt < %s -wasm-lower-em-ehsjlj -enable-emscripten-sjlj --mtripl

[PATCH] D107850: [asan] Implemented intrinsic for the custom calling convention similar used by HWASan for X86.

2021-08-23 Thread Kirill Stoimenov via Phabricator via cfe-commits

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

Fixed code generation bug.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107850

Files:
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
  llvm/lib/Target/X86/X86AsmPrinter.cpp
  llvm/lib/Target/X86/X86AsmPrinter.h
  llvm/lib/Target/X86/X86InstrCompiler.td
  llvm/lib/Target/X86/X86MCInstLower.cpp
  llvm/lib/Target/X86/X86RegisterInfo.td
  llvm/test/CodeGen/X86/asan-check-memaccess-add.ll
  llvm/test/CodeGen/X86/asan-check-memaccess-or.ll
  llvm/tools/llvm-exegesis/CMakeLists.txt

Index: llvm/tools/llvm-exegesis/CMakeLists.txt
===
--- llvm/tools/llvm-exegesis/CMakeLists.txt
+++ llvm/tools/llvm-exegesis/CMakeLists.txt
@@ -1,4 +1,5 @@
 set(LLVM_LINK_COMPONENTS
+  Instrumentation
   MC
   MCParser
   Support
Index: llvm/test/CodeGen/X86/asan-check-memaccess-or.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/asan-check-memaccess-or.ll
@@ -0,0 +1,253 @@
+; RUN: llc < %s | FileCheck %s
+
+target triple = "x86_64-pc-win"
+
+define void @load1(i8* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load1_rn[[RN1:.*]]
+; CHECK:  callq   __asan_check_store1_rn[[RN1]]
+; CHECK-NEXT: retq
+  call void @llvm.asan.check.memaccess(i8* %x, i32 0)
+  call void @llvm.asan.check.memaccess(i8* %x, i32 32)
+  ret void
+}
+
+define void @load2(i16* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load2_rn[[RN2:.*]]
+; CHECK:  callq   __asan_check_store2_rn[[RN2]]
+; CHECK-NEXT: retq
+  %1 = ptrtoint i16* %x to i64
+  %2 = bitcast i16* %x to i8*
+  call void @llvm.asan.check.memaccess(i8* %2, i32 2)
+  call void @llvm.asan.check.memaccess(i8* %2, i32 34)
+  ret void
+}
+
+define void @load4(i32* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load4_rn[[RN4:.*]]
+; CHECK:  callq   __asan_check_store4_rn[[RN4]]
+; CHECK-NEXT: retq
+  %1 = ptrtoint i32* %x to i64
+  %2 = bitcast i32* %x to i8*
+  call void @llvm.asan.check.memaccess(i8* %2, i32 4)
+  call void @llvm.asan.check.memaccess(i8* %2, i32 36)
+  ret void
+}
+define void @load8(i64* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load8_rn[[RN8:.*]]
+; CHECK:  callq   __asan_check_store8_rn[[RN8]]
+; CHECK-NEXT: retq
+  %1 = ptrtoint i64* %x to i64
+  %2 = bitcast i64* %x to i8*
+  call void @llvm.asan.check.memaccess(i8* %2, i32 6)
+  call void @llvm.asan.check.memaccess(i8* %2, i32 38)
+  ret void
+}
+
+define void @load16(i128* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load16_rn[[RN16:.*]]
+; CHECK:  callq   __asan_check_store16_rn[[RN16]]
+; CHECK-NEXT: retq
+  %1 = ptrtoint i128* %x to i64
+  %2 = bitcast i128* %x to i8*
+  call void @llvm.asan.check.memaccess(i8* %2, i32 8)
+  call void @llvm.asan.check.memaccess(i8* %2, i32 40)
+  ret void
+}
+
+; CHECK:  .type   __asan_check_load1_rn[[RN1]],@function
+; CHECK-NEXT: .weak   __asan_check_load1_rn[[RN1]]
+; CHECK-NEXT: .hidden __asan_check_load1_rn[[RN1]]
+; CHECK-NEXT: __asan_check_load1_rn[[RN1]]:
+; CHECK-NEXT: movq[[REG:.*]], %r8
+; CHECK-NEXT: shrq$3, %r8
+; CHECK-NEXT: orq $17592186044416, %r8{{.*}}
+; CHECK-NEXT: movb(%r8), %r8b
+; CHECK-NEXT: testb   %r8b, %r8b
+; CHECK-NEXT: jne [[EXTRA:.*]]
+; CHECK-NEXT: [[RET:.*]]:
+; CHECK-NEXT: retq
+; CHECK-NEXT: [[EXTRA]]:
+; CHECK-NEXT: pushq   %rcx
+; CHECK-NEXT: movq[[REG]], %rcx
+; CHECK-NEXT: andl$7, %ecx
+; CHECK-NEXT: cmpl%r8d, %ecx
+; CHECK-NEXT: popq%rcx
+; CHECK-NEXT: jl  [[RET]]
+; CHECK-NEXT: movq[[REG:.*]], %rdi
+; CHECK-NEXT: jmp __asan_report_load1
+
+; CHECK:  .type   __asan_check_load2_rn[[RN2]],@function
+; CHECK-NEXT: .weak   __asan_check_load2_rn[[RN2]]
+; CHECK-NEXT: .hidden __asan_check_load2_rn[[RN2]]
+; CHECK-NEXT: __asan_check_load2_rn[[RN2]]:
+; CHECK-NEXT: movq[[REG:.*]], %r8
+; CHECK-NEXT: shrq$3, %r8
+; CHECK-NEXT: orq $17592186044416, %r8{{.*}}
+; CHECK-NEXT: movb(%r8), %r8b
+; CHECK-NEXT: testb   %r8b, %r8b
+; CHECK-NEXT: jne [[EXTRA:.*]]
+; CHECK-NEXT: [[RET:.*]]:
+; CHECK-NEXT: retq
+; CHECK-NEXT: [[EXTRA]]:
+; CHECK-NEXT: pushq   %rcx
+; CHECK-NEXT: movq[[REG]], %rcx
+; CHECK-NEXT: andl$7, %ecx
+; CHECK-NEXT: addl$1, %ecx
+; CHECK-NEXT: cmpl%r8d, %ecx
+; CHECK-NEXT: popq%rcx
+; CHECK-NEXT: jl  [[RET]]
+; CHECK-NEXT:

[PATCH] D108021: [dllexport] Instantiate default ctor default args

2021-08-23 Thread Reid Kleckner 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 rGe42ce422a978: [dllexport] Instantiate default ctor default 
args (authored by rnk).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108021

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp


Index: clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -triple i686-windows-msvc -emit-llvm -std=c++14 \
+// RUN:-fno-threadsafe-statics -fms-extensions -O1 -mconstructor-aliases \
+// RUN:-disable-llvm-passes -o - %s -w -fms-compatibility-version=19.00 | \
+// RUN:FileCheck %s
+
+struct HasDtor {
+  ~HasDtor();
+  int o;
+};
+struct HasImplicitDtor1 {
+  HasDtor o;
+};
+struct __declspec(dllexport) CtorClosureOuter {
+  struct __declspec(dllexport) CtorClosureInner {
+CtorClosureInner(const HasImplicitDtor1 &v = {}) {}
+  };
+};
+
+// CHECK-LABEL: $"??1HasImplicitDtor1@@QAE@XZ" = comdat any
+// CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void 
@"??_FCtorClosureInner@CtorClosureOuter@@QAEXXZ"({{.*}}) {{#[0-9]+}} comdat
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -6005,6 +6005,15 @@
   if (TSK == TSK_ImplicitInstantiation && !ClassAttr->isInherited())
 continue;
 
+  // If this is an MS ABI dllexport default constructor, instantiate any
+  // default arguments.
+  if (S.Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+auto *CD = dyn_cast(MD);
+if (CD && CD->isDefaultConstructor() && TSK == TSK_Undeclared) {
+  S.InstantiateDefaultCtorDefaultArgs(CD);
+}
+  }
+
   S.MarkFunctionReferenced(Class->getLocation(), MD);
 
   // The function will be passed to the consumer when its definition is


Index: clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -triple i686-windows-msvc -emit-llvm -std=c++14 \
+// RUN:-fno-threadsafe-statics -fms-extensions -O1 -mconstructor-aliases \
+// RUN:-disable-llvm-passes -o - %s -w -fms-compatibility-version=19.00 | \
+// RUN:FileCheck %s
+
+struct HasDtor {
+  ~HasDtor();
+  int o;
+};
+struct HasImplicitDtor1 {
+  HasDtor o;
+};
+struct __declspec(dllexport) CtorClosureOuter {
+  struct __declspec(dllexport) CtorClosureInner {
+CtorClosureInner(const HasImplicitDtor1 &v = {}) {}
+  };
+};
+
+// CHECK-LABEL: $"??1HasImplicitDtor1@@QAE@XZ" = comdat any
+// CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void @"??_FCtorClosureInner@CtorClosureOuter@@QAEXXZ"({{.*}}) {{#[0-9]+}} comdat
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -6005,6 +6005,15 @@
   if (TSK == TSK_ImplicitInstantiation && !ClassAttr->isInherited())
 continue;
 
+  // If this is an MS ABI dllexport default constructor, instantiate any
+  // default arguments.
+  if (S.Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+auto *CD = dyn_cast(MD);
+if (CD && CD->isDefaultConstructor() && TSK == TSK_Undeclared) {
+  S.InstantiateDefaultCtorDefaultArgs(CD);
+}
+  }
+
   S.MarkFunctionReferenced(Class->getLocation(), MD);
 
   // The function will be passed to the consumer when its definition is
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e42ce42 - [dllexport] Instantiate default ctor default args

2021-08-23 Thread Reid Kleckner via cfe-commits


Author: Reid Kleckner
Date: 2021-08-23T15:56:29-07:00
New Revision: e42ce422a97876e5ecd1c845b12ec65f96f8a293

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

LOG: [dllexport] Instantiate default ctor default args

Fixes https://bugs.llvm.org/show_bug.cgi?id=51414.

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

Added: 
clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp

Modified: 
clang/lib/Sema/SemaDeclCXX.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 4827f6b3bb345..d980869a3b067 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -6005,6 +6005,15 @@ static void ReferenceDllExportedMembers(Sema &S, 
CXXRecordDecl *Class) {
   if (TSK == TSK_ImplicitInstantiation && !ClassAttr->isInherited())
 continue;
 
+  // If this is an MS ABI dllexport default constructor, instantiate any
+  // default arguments.
+  if (S.Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+auto *CD = dyn_cast(MD);
+if (CD && CD->isDefaultConstructor() && TSK == TSK_Undeclared) {
+  S.InstantiateDefaultCtorDefaultArgs(CD);
+}
+  }
+
   S.MarkFunctionReferenced(Class->getLocation(), MD);
 
   // The function will be passed to the consumer when its definition is

diff  --git a/clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp 
b/clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp
new file mode 100644
index 0..36dab8600e21b
--- /dev/null
+++ b/clang/test/CodeGenCXX/dllexport-ctor-closure-nested.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -triple i686-windows-msvc -emit-llvm -std=c++14 \
+// RUN:-fno-threadsafe-statics -fms-extensions -O1 -mconstructor-aliases \
+// RUN:-disable-llvm-passes -o - %s -w -fms-compatibility-version=19.00 | \
+// RUN:FileCheck %s
+
+struct HasDtor {
+  ~HasDtor();
+  int o;
+};
+struct HasImplicitDtor1 {
+  HasDtor o;
+};
+struct __declspec(dllexport) CtorClosureOuter {
+  struct __declspec(dllexport) CtorClosureInner {
+CtorClosureInner(const HasImplicitDtor1 &v = {}) {}
+  };
+};
+
+// CHECK-LABEL: $"??1HasImplicitDtor1@@QAE@XZ" = comdat any
+// CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void 
@"??_FCtorClosureInner@CtorClosureOuter@@QAEXXZ"({{.*}}) {{#[0-9]+}} comdat



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

[PATCH] D107685: [WebAssembly] Tidy up EH/SjLj options

2021-08-23 Thread Derek Schuff via Phabricator via cfe-commits

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



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp:278
+// Two SjLj modes cannot be turned on at the same time
+assert(!(EnableEmSjLj && EnableWasmSjLj));
+// Wasm SjLj should be only used with Wasm EH

You could put the comment text directly in the assert, i.e. `assert(condition 
&& "text")`



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp:48
 
+// Wasm exception handling using wasm EH instructions
+cl::opt WasmEnableEH("wasm-enable-eh",

this description seems a bit redundant. I guess "C++ exception handling using 
wasm EH instructions" might be a bit too specific since it could be anything 
that generates WinEH-style IR. Maybe just leave out the first "wasm"?



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp:449
+  // done in WasmEHPrepare pass after these IR passes, but Wasm SjLj requires
+  // Emscripten libraries and processed together in LowerEmscriptenEHSjLJ pass.
+  if (WasmEnableEmEH || WasmEnableEmSjLj || WasmEnableSjLj)

it's not clear what "and processed" is intended to mean here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107685

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

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

2021-08-23 Thread Leonard Chan via Phabricator via cfe-commits

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

Some extra comments/open questions:

- This patch supports using `N.0.0` as a version number. Do we want to just 
only accept `N` and disallow any number for minor/subminor, or will zeros be 
allowed?
- This currently will only work if the major number is provided via the target 
triple (`x86_64-unknown-fuchsia16`). Do we have a concept of a default version 
number for fuchsia we can fall back to if this is not provided?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108592

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

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

2021-08-23 Thread Leonard Chan via Phabricator via cfe-commits

leonardchan created this revision.
leonardchan added reviewers: phosek, mcgrathr.
leonardchan added a project: clang.
Herald added a reviewer: aaron.ballman.
leonardchan requested review of this revision.

This also adds a warning that triggers when a non-zero minor/subminor are used.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-availability-fuchsia.c


Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia16" -fsyntax-only -verify 
%s
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
+void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 
11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); 
// expected-note{{explicitly marked unavailable}}
+void f5(int) __attribute__((availability(ios, introduced = 3.2), 
availability(fuchsia, unavailable)));   
// expected-note{{'f5' has been explicitly marked unavailable here}}
+void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));
+void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // 
expected-warning {{Fuchsia versions only support 'major', not 
'.minor[.subminor]}}
+
+void test() {
+  f0(0);
+  f1(0);
+  f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 
16}}
+  f3(0);
+  f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
+  f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2488,6 +2488,15 @@
 }
   }
 
+  if (II->isStr("fuchsia")) {
+Optional Min, Sub;
+if (((Min = Introduced.Version.getMinor()) && Min.getValue()) ||
+((Sub = Introduced.Version.getSubminor()) && Sub.getValue())) {
+  S.Diag(AL.getLoc(), diag::warn_availability_fuchsia_unavailable_minor);
+  return;
+}
+  }
+
   int PriorityModifier = AL.isPragmaClangAttribute()
  ? Sema::AP_PragmaClangAttribute
  : Sema::AP_Explicit;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -885,6 +885,11 @@
 // Required by the libc++ locale support.
 if (Opts.CPlusPlus)
   Builder.defineMacro("_GNU_SOURCE");
+
+unsigned Maj, Min, Rev;
+Triple.getOSVersion(Maj, Min, Rev);
+this->PlatformName = "fuchsia";
+this->PlatformMinVersion = VersionTuple(Maj, Min, Rev);
   }
 
 public:
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3543,6 +3543,9 @@
   InGroup;
 def note_protocol_method : Note<
   "protocol method is here">;
+def warn_availability_fuchsia_unavailable_minor : Warning<
+  "Fuchsia versions only support 'major', not '.minor[.subminor]'">,
+  InGroup;
 
 def warn_unguarded_availability :
   Warning<"%0 is only available on %1 %2 or newer">,
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -848,6 +848,7 @@
 [{static llvm::StringRef getPrettyPlatformName(llvm::StringRef Platform) {
 return llvm::StringSwitch(Platform)
  .Case("android", "Android")
+ .Case("fuchsia", "Fuchsia")
  .Case("ios", "iOS")
  .Case("macos", "macOS")
  .Case("tvos", "tvOS")


Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia16" -fsyntax-only -verify %s
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, dep

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added a comment.

There are 3 problems here (ignoring our test setup which should be discussed 
separately):

1. make sure clang finds libomp.so
2. make sure libomp.so (or clang?) finds libomptarget.so
3. make sure libomptartget.so finds the plugins

All of which have to work nicely with LD_LIBRARY_PATH.

I think for 3 you can look at the current dir. That was discussed and, as long 
as it does work with LD_LIBRARY_PATH, that seems a win.

For 2, why don't we install them in the same place? If so, we reduce it to 
problem 1) [after applying solution to 3)] no?

For 1, doing something always backwards compatible that may or may not work on 
some platforms and configurations seems best. You had a proposal here already. 
If that works, let's do it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D105191: [Clang][OpenMP] Add support for Static Device Libraries

2021-08-23 Thread Ye Luo via Phabricator via cfe-commits

ye-luo added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.h:62
+ bool postClangLink);
+void AddStaticDeviceLibs(Compilation *C, const Tool *T, const JobAction *JA,
+ const InputInfoList *Inputs, const Driver &D,

Differentiate the names of all the three AddStaticDeviceLibs functions and add 
documentation. Be sure to do document every function added in this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105191

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

[PATCH] D108291: [clang-nvlink-wrapper] Wrapper around nvlink for archive files

2021-08-23 Thread Ye Luo via Phabricator via cfe-commits

ye-luo added inline comments.



Comment at: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp:19
+/// Such an archive is then passed to this tool to extract cubin files before
+/// passing to nvlink.
+///

Right now clang-offload-bundler is only used to create an object file for the 
host and a cubin file for the device.
Then cubin files are passed to the nvlink.
This is different from what you described
```
clang-offload-bundler creates a device specific archive of cubin files.
Such an archive is then passed to this tool to extract cubin files before 
passing to nvlink.
```
Is this caused by changes in https://reviews.llvm.org/D105191?
Do you have any reading materials which documents the whole linking flow of 
D105191?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108291

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

[PATCH] D54943: [clang-tidy] implement const-transformation for cppcoreguidelines-const-correctness

2021-08-23 Thread Tiago Macarios via Phabricator via cfe-commits

tiagoma added a comment.

In D54943#2959546 , @JonasToth wrote:

> thanks for your testing! i will look at the `__unaligned` issue, not sure if 
> clang supports it, its an MSVC extension, is it?

Yes it is. The clang frontend supports it. I am not sure about the backend.

> Did the transformations produce issues and approximately how much code did 
> you check? I would like to get a better feeling for its quality before 
> enabling it by default.

I run it in all of Microsoft Word. It seems pretty solid to me. The places 
where it breaks it is due to the code being ill-formed in some way (which is a 
welcome break). I already have to tell tidy to apply the fixits, so I am not 
sure what having the extra flag adds. I would suggest have them on by default 
and letting people disable it if they need.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D54943

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

[PATCH] D108584: [clangd] Use the active file's language for hover code blocks

2021-08-23 Thread David Goldman via Phabricator via cfe-commits

dgoldman added a comment.

LMK if you can think of a better approach to decide which language to use here. 
Likely will send a follow up diff to include more context in the Objective-C 
decl printing so they highlight properly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108584

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

[PATCH] D108584: [clangd] Use the active file's language for hover code blocks

2021-08-23 Thread David Goldman via Phabricator via cfe-commits

dgoldman created this revision.
dgoldman added reviewers: kadircet, sammccall.
Herald added subscribers: usaxena95, arphaman.
dgoldman requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

This helps improve the syntax highlighting for Objective-C code,
although it currently doesn't work well in VS Code with
methods/properties/ivars since we don't currently include the proper
decl context (e.g. class).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108584

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -939,6 +939,42 @@
   }
 }
 
+TEST(Hover, DefinitionLanuage) {
+  struct {
+const char *const Code;
+const std::string ClangLanguageFlag;
+const char *const ExpectedDefinitionLanguage;
+  } Cases[] = {{R"cpp(
+  void [[some^Global]]() {}
+  )cpp",
+"", "cpp"},
+   {R"cpp(
+  void [[some^Global]]() {}
+  )cpp",
+"-xobjective-c++", "objective-cpp"},
+   {R"cpp(
+  void [[some^Global]]() {}
+  )cpp",
+"-xobjective-c", "objective-c"}};
+  for (const auto &Case : Cases) {
+SCOPED_TRACE(Case.Code);
+
+Annotations T(Case.Code);
+TestTU TU = TestTU::withCode(T.code());
+if (!Case.ClangLanguageFlag.empty())
+  TU.ExtraArgs.push_back(Case.ClangLanguageFlag);
+// Types might be different depending on the target triplet, we chose a
+// fixed one to make sure tests passes on different platform.
+TU.ExtraArgs.push_back("--target=x86_64-pc-linux-gnu");
+auto AST = TU.build();
+
+auto H = getHover(AST, T.point(), format::getLLVMStyle(), nullptr);
+ASSERT_TRUE(H);
+
+EXPECT_STREQ(H->DefinitionLanguage, Case.ExpectedDefinitionLanguage);
+  }
+}
+
 TEST(Hover, CallPassType) {
   const llvm::StringRef CodePrefix = R"cpp(
 class Base {};
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -131,6 +131,13 @@
   return Definition;
 }
 
+const char *getMarkdownLanguage(const ASTContext &Ctx) {
+  const auto &LangOpts = Ctx.getLangOpts();
+  if (LangOpts.ObjC && LangOpts.CPlusPlus)
+return "objective-cpp";
+  return LangOpts.ObjC ? "objective-c" : "cpp";
+}
+
 std::string printType(QualType QT, const PrintingPolicy &PP) {
   // TypePrinter doesn't resolve decltypes, so resolve them here.
   // FIXME: This doesn't handle composite types that contain a decltype in them.
@@ -593,6 +600,7 @@
   }
 
   HI.Definition = printDefinition(D, PP);
+  HI.DefinitionLanguage = getMarkdownLanguage(Ctx);
   return HI;
 }
 
@@ -622,10 +630,12 @@
 if (!Invalid) {
   unsigned StartOffset = SM.getFileOffset(StartLoc);
   unsigned EndOffset = SM.getFileOffset(EndLoc);
-  if (EndOffset <= Buffer.size() && StartOffset < EndOffset)
+  if (EndOffset <= Buffer.size() && StartOffset < EndOffset) {
 HI.Definition =
 ("#define " + Buffer.substr(StartOffset, EndOffset - StartOffset))
 .str();
+HI.DefinitionLanguage = getMarkdownLanguage(AST.getASTContext());
+  }
 }
   }
   return HI;
@@ -646,6 +656,7 @@
   HoverInfo HI;
   HI.Name = "this";
   HI.Definition = printType(PrettyThisType, PP);
+  HI.DefinitionLanguage = getMarkdownLanguage(ASTCtx);
   return HI;
 }
 
@@ -670,6 +681,7 @@
   enhanceFromIndex(HI, *CommentD, Index);
 }
   }
+  HI.DefinitionLanguage = getMarkdownLanguage(ASTCtx);
 
   return HI;
 }
@@ -731,6 +743,7 @@
 llvm::raw_string_ostream OS(HI.Definition);
 A->printPretty(OS, AST.getASTContext().getPrintingPolicy());
   }
+  HI.DefinitionLanguage = getMarkdownLanguage(AST.getASTContext());
   HI.Documentation = Attr::getDocumentation(A->getKind()).str();
   return HI;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 4c40c03 - Fixed doc build.

2021-08-23 Thread Artem Belevich via cfe-commits


Author: Artem Belevich
Date: 2021-08-23T13:45:36-07:00
New Revision: 4c40c03b3933ce32a2b5f532810dc30f6f329fd4

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

LOG: Fixed doc build.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index aaa471e9b9d4..8b62f026765e 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -118,7 +118,7 @@ C++2b Feature Support
 ...
 
 CUDA Language Changes in Clang

+--
 
 - Clang now supports CUDA versions up to 11.4.
 - Default GPU architecture has been changed from sm_20 to sm_35.



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

[PATCH] D108582: [WebAssembly] Add Wasm SjLj option support for clang

2021-08-23 Thread Heejin Ahn via Phabricator via cfe-commits

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

Oh sorry I clicked the wrong button


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108582

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

[PATCH] D108582: [WebAssembly] Add Wasm SjLj option support for clang

2021-08-23 Thread Heejin Ahn via Phabricator via cfe-commits

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

Oh, I fortot I made this currently set `+multivalue` feature... Maybe we have 
to rethink that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108582

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

[PATCH] D105191: [Clang][OpenMP] Add support for Static Device Libraries

2021-08-23 Thread Artem Belevich via Phabricator via cfe-commits

tra added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:1599-1618
+// For bitcode SDL, search for these 12 relative SDL filenames
+SDLs.push_back(
+Twine("/libdevice/libbc-" + Lib + "-" + Arch + "-" + Target + ".a")
+.str());
+SDLs.push_back(
+Twine("/libbc-" + Lib + "-" + Arch + "-" + Target + ".a").str());
+SDLs.push_back(Twine("/libdevice/libbc-" + Lib + "-" + Arch + ".a").str());

This could probably be collapsed into a couple of nested loops:

```
for (auto base: {"/libbc-", "/lib"}) {
  std::string ext = base == "/lib" ? ".bc" : ".a";
  for( auto suffix : {Lib + "-" + Arch + "-" + Target, Lib + "-" + Arch, Lib } 
}) {
SDLs.append({"/libdevice" + base + suffix + ext,  base + suffix + ext })
  }
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105191

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

[PATCH] D108582: [WebAssembly] Add Wasm SjLj option support for clang

2021-08-23 Thread Heejin Ahn via Phabricator via cfe-commits

aheejin created this revision.
aheejin added reviewers: dschuff, tlively.
Herald added subscribers: wingo, ecnelises, sunfish, jgravelle-google, sbc100.
aheejin requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This adds support for Wasm SjLj in clang. Also this sets the new
`-mllvm -wasm-enable-eh` option for Wasm EH.

Note there is a little unfortunate inconsistency there: Wasm EH is
enabled by a clang option `-fwasm-exceptions`, which sets
`-mllvm -wasm-enable-eh` in the backend options. It also sets
`-exception-model=wasm` but this is done in the common code.

Wasm SjLj doesn't have a clang-level option like `-fwasm-exceptions`.
`-fwasm-exceptions` was added because each exception model has its
corresponding `-f***-exceptions`, but I'm not sure if adding a new
option like `-fwasm-sjlj` or something is a good idea.

So the current plan is Emscripten sets `-mllvm -wasm-enable-sjlj` if
Wasm SJLj is enabled in its settings.js, as it does for Emscripten
EH/SjLj (it sets `-mllvm -enable-emscripten-cxx-exceptions` for
Emscripten EH and `-mllvm -enable-emscripten-sjlj` for Emscripten SjLj).
And setting this enables the exception handling feature, and also sets
`-exception-model=wasm`, but this time this is not done in the common
code so we do it ourselves. It also sets the multivalue feature, because
for `longjmp` we throw two values and catch two values: the setjmp
buffer and the return value. So `catch` instruction will produce two
values.

Also note that other exception models have 1-to-1 correspondance with
their `-f***-exceptions` flag and their `-exception-model=***` flag, but
because we use `-exception-model=wasm` also for Wasm SjLj while
`-fwasm-exceptions` still means Wasm EH, there is also a little
inconsistency there, but I think it is manageable.

Also this adds various error checking and tests.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108582

Files:
  clang/lib/Driver/ToolChains/WebAssembly.cpp
  clang/test/Driver/wasm-toolchain.c

Index: clang/test/Driver/wasm-toolchain.c
===
--- clang/test/Driver/wasm-toolchain.c
+++ clang/test/Driver/wasm-toolchain.c
@@ -94,11 +94,11 @@
 // RUN:   | FileCheck -check-prefix=EMSCRIPTEN_EH_ALLOWED_WO_ENABLE %s
 // EMSCRIPTEN_EH_ALLOWED_WO_ENABLE: invalid argument '-mllvm -emscripten-cxx-exceptions-allowed' only allowed with '-mllvm -enable-emscripten-cxx-exceptions'
 
-// '-fwasm-exceptions' sets +exception-handling
+// '-fwasm-exceptions' sets +exception-handling and '-mllvm -wasm-enable-eh'
 // RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown \
 // RUN:--sysroot=/foo %s -fwasm-exceptions 2>&1 \
 // RUN:  | FileCheck -check-prefix=WASM_EXCEPTIONS %s
-// WASM_EXCEPTIONS: clang{{.*}}" "-cc1" {{.*}} "-target-feature" "+exception-handling"
+// WASM_EXCEPTIONS: clang{{.*}}" "-cc1" {{.*}} "-target-feature" "+exception-handling" "-mllvm" "-wasm-enable-eh"
 
 // '-fwasm-exceptions' not allowed with '-mno-exception-handling'
 // RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown \
@@ -106,13 +106,48 @@
 // RUN:   | FileCheck -check-prefix=WASM_EXCEPTIONS_NO_EH %s
 // WASM_EXCEPTIONS_NO_EH: invalid argument '-fwasm-exceptions' not allowed with '-mno-exception-handling'
 
-// '-fwasm-exceptions' not allowed with
-// '-mllvm -enable-emscripten-cxx-exceptions'
+// '-fwasm-exceptions' not allowed with '-mllvm -enable-emscripten-cxx-exceptions'
 // RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown \
-// RUN: --sysroot=/foo %s -fwasm-exceptions -mllvm -enable-emscripten-cxx-exceptions 2>&1 \
+// RUN: --sysroot=/foo %s -fwasm-exceptions \
+// RUN: -mllvm -enable-emscripten-cxx-exceptions 2>&1 \
 // RUN:   | FileCheck -check-prefix=WASM_EXCEPTIONS_EMSCRIPTEN_EH %s
 // WASM_EXCEPTIONS_EMSCRIPTEN_EH: invalid argument '-fwasm-exceptions' not allowed with '-mllvm -enable-emscripten-cxx-exceptions'
 
+// '-mllvm -wasm-enable-sjlj' sets +exception-handling, +multivalue and
+// '-exception-model=wasm'
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown \
+// RUN:--sysroot=/foo %s -mllvm -wasm-enable-sjlj 2>&1 \
+// RUN:  | FileCheck -check-prefix=WASM_SJLJ %s
+// WASM_SJLJ: clang{{.*}}" "-cc1" {{.*}} "-target-feature" "+exception-handling" "-target-feature" "+multivalue" "-exception-model=wasm"
+
+// '-mllvm -wasm-enable-sjlj' not allowed with '-mno-exception-handling'
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown \
+// RUN: --sysroot=/foo %s -mllvm -wasm-enable-sjlj -mno-exception-handling \
+// RUN: 2>&1 \
+// RUN:   | FileCheck -check-prefix=WASM_SJLJ_NO_EH %s
+// WASM_SJLJ_NO_EH: invalid argument '-mllvm -wasm-enable-sjlj' not allowed with '-mno-exception-handling'
+
+// '-mllvm -wasm-enable-sjlj' not allowed with '-mno-multivalue'
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-u

[PATCH] D102449: [WIP][Clang][OpenMP] Add the support for compare clause in atomic directive

2021-08-23 Thread Shilei Tian via Phabricator via cfe-commits

tianshilei1992 added a comment.

In D102449#2960209 , @jdoerfert wrote:

> Is this still WIP or should it be reviewed? Needs a proper commit message.

Not yet.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102449

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

[PATCH] D107685: [WebAssembly] Tidy up EH/SjLj options

2021-08-23 Thread Heejin Ahn via Phabricator via cfe-commits

aheejin updated this revision to Diff 368203.
aheejin added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Add `-wasm-enable-eh`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107685

Files:
  clang/test/CodeGenCXX/wasm-eh.cpp
  lld/test/wasm/tag-section.ll
  llvm/lib/Target/WebAssembly/WebAssembly.h
  llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyMCInstLower.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.ll
  llvm/test/CodeGen/WebAssembly/eh-lsda.ll
  llvm/test/CodeGen/WebAssembly/exception.ll
  llvm/test/CodeGen/WebAssembly/lower-em-ehsjlj.ll
  llvm/test/CodeGen/WebAssembly/lower-em-exceptions-allowed.ll
  llvm/test/CodeGen/WebAssembly/lower-em-exceptions-resume-only.ll
  llvm/test/CodeGen/WebAssembly/lower-em-exceptions.ll
  llvm/test/CodeGen/WebAssembly/lower-em-sjlj-alias.ll
  llvm/test/CodeGen/WebAssembly/lower-em-sjlj-debuginfo.ll
  llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll
  llvm/test/CodeGen/WebAssembly/null-streamer.ll
  llvm/test/CodeGen/WebAssembly/wasm-eh-em-sjlj-error.ll
  llvm/test/MC/WebAssembly/tag-section-decoding.ll
  llvm/test/MC/WebAssembly/tag-section.ll

Index: llvm/test/MC/WebAssembly/tag-section.ll
===
--- llvm/test/MC/WebAssembly/tag-section.ll
+++ llvm/test/MC/WebAssembly/tag-section.ll
@@ -1,5 +1,5 @@
-; RUN: llc -filetype=obj -exception-model=wasm -mattr=+exception-handling %s -o - | obj2yaml | FileCheck %s
-; RUN: llc -filetype=obj -exception-model=wasm -mattr=+exception-handling %s -o - | llvm-readobj -S - | FileCheck -check-prefix=SEC %s
+; RUN: llc -filetype=obj -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling %s -o - | obj2yaml | FileCheck %s
+; RUN: llc -filetype=obj -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling %s -o - | llvm-readobj -S - | FileCheck -check-prefix=SEC %s
 
 target triple = "wasm32-unknown-unknown"
 
Index: llvm/test/MC/WebAssembly/tag-section-decoding.ll
===
--- llvm/test/MC/WebAssembly/tag-section-decoding.ll
+++ llvm/test/MC/WebAssembly/tag-section-decoding.ll
@@ -1,4 +1,4 @@
-; RUN: llc -filetype=obj -exception-model=wasm -mattr=+exception-handling %s -o - | obj2yaml | FileCheck %s
+; RUN: llc -filetype=obj -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling %s -o - | obj2yaml | FileCheck %s
 
 ; This is a regression test for a decoding bug that happens when a tag's
 ; sigindex is greater than 63, so we put 63 dummy functions with different
Index: llvm/test/CodeGen/WebAssembly/wasm-eh-em-sjlj-error.ll
===
--- llvm/test/CodeGen/WebAssembly/wasm-eh-em-sjlj-error.ll
+++ llvm/test/CodeGen/WebAssembly/wasm-eh-em-sjlj-error.ll
@@ -1,4 +1,4 @@
-; RUN: not --crash llc < %s -enable-emscripten-sjlj -exception-model=wasm 2>&1 | FileCheck %s
+; RUN: not --crash llc < %s -wasm-enable-eh -enable-emscripten-sjlj -exception-model=wasm 2>&1 | FileCheck %s
 
 target triple = "wasm32-unknown-unknown"
 
Index: llvm/test/CodeGen/WebAssembly/null-streamer.ll
===
--- llvm/test/CodeGen/WebAssembly/null-streamer.ll
+++ llvm/test/CodeGen/WebAssembly/null-streamer.ll
@@ -1,5 +1,5 @@
-; RUN: llc < %s -O0 -filetype=null -exception-model=wasm -mattr=+exception-handling
-; RUN: llc < %s -O0 -filetype=asm -asm-verbose=false -exception-model=wasm -mattr=+exception-handling | FileCheck %s
+; RUN: llc < %s -O0 -filetype=null -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling
+; RUN: llc < %s -O0 -filetype=asm -asm-verbose=false -wasm-enable-eh -exception-model=wasm -mattr=+exception-handling | FileCheck %s
 
 target triple = "wasm32-unknown-unknown"
 
Index: llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll
===
--- llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll
+++ llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll
@@ -1,6 +1,6 @@
-; RUN: opt < %s -wasm-lower-em-ehsjlj -S | FileCheck %s --check-prefixes=CHECK,NO-TLS -DPTR=i32
-; RUN: opt < %s -wasm-lower-em-ehsjlj -S --mattr=+atomics,+bulk-memory | FileCheck %s --check-prefixes=CHECK,TLS -DPTR=i32
-; RUN: opt < %s -wasm-lower-em-ehsjlj --mtriple=wasm64-unknown-unknown -data-layout="e-m:e-p:64:64-i64:64-n32:64-S128" -S | FileCheck %s --check-prefixes=CHECK -DPTR=i64
+; RUN: opt < %s -wasm-lower-em-ehsjlj -enable-emscripten-sjlj -S | FileCheck %s --check-prefixes=CHECK,NO-TLS -DPTR=i32
+; RUN: opt < %s -wasm-lower-em-ehsjlj -enable-emscripten-sjlj -S --mattr=+atomics,+bulk-memory | FileCheck %s --check-prefixes=CHECK,TLS -DPTR=i32
+; RUN: opt < %s -wasm-lower-em-ehsjl

[PATCH] D108291: [clang-nvlink-wrapper] Wrapper around nvlink for archive files

2021-08-23 Thread Saiyedul Islam via Phabricator via cfe-commits

saiislam updated this revision to Diff 368202.
saiislam marked 7 inline comments as done.
saiislam added a comment.
Herald added a subscriber: sstefan1.

1. Added documentation.
2. Improved error handling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108291

Files:
  clang/tools/CMakeLists.txt
  clang/tools/clang-nvlink-wrapper/CMakeLists.txt
  clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp

Index: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
===
--- /dev/null
+++ clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
@@ -0,0 +1,164 @@
+//===-- clang-nvlink-wrapper/ClangNvlinkWrapper.cpp - wrapper over nvlink-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===-===//
+///
+/// \file
+/// This tool works as a wrapper over nvlink program. It transparently passes
+/// every input option and objects to nvlink except archive files. It reads
+/// each input archive file to extract archived cubin files as temporary files.
+/// These temp (*.cubin) files are passed to nvlink, because nvlink does not
+/// support linking of archive files implicitly.
+///
+/// During linking of heteregenous device archive libraries, the
+/// clang-offload-bundler creates a device specific archive of cubin files.
+/// Such an archive is then passed to this tool to extract cubin files before
+/// passing to nvlink.
+///
+/// Example:
+/// clang-nvlink-wrapper -o a.out-openmp-nvptx64 /tmp/libTest-nvptx-sm_50.a
+///
+/// 1. Extract (libTest-nvptx-sm_50.a) => /tmp/a.cubin /tmp/b.cubin
+/// 2. nvlink -o a.out-openmp-nvptx64 /tmp/a.cubin /tmp/b.cubin
+//===-===//
+
+#include "llvm/Object/Archive.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/Errc.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/Signals.h"
+#include "llvm/Support/StringSaver.h"
+#include "llvm/Support/WithColor.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
+
+static Error runNVLink(std::string NVLinkPath,
+   SmallVectorImpl &Args) {
+  std::vector NVLArgs;
+  NVLArgs.push_back(NVLinkPath);
+  for (auto &Arg : Args) {
+NVLArgs.push_back(Arg);
+  }
+
+  if (sys::ExecuteAndWait(NVLinkPath.c_str(), NVLArgs))
+return createStringError(inconvertibleErrorCode(), "'nvlink' failed");
+  return Error::success();
+}
+
+static Error extractArchiveFiles(StringRef Filename,
+ SmallVectorImpl &Args,
+ SmallVectorImpl &TmpFiles) {
+  std::vector> ArchiveBuffers;
+
+  ErrorOr> BufOrErr =
+  MemoryBuffer::getFileOrSTDIN(Filename, -1, false);
+  if (std::error_code EC = BufOrErr.getError())
+return createFileError(Filename, EC);
+
+  ArchiveBuffers.push_back(std::move(*BufOrErr));
+  Expected> LibOrErr =
+  object::Archive::create(ArchiveBuffers.back()->getMemBufferRef());
+  if (!LibOrErr)
+return LibOrErr.takeError();
+
+  auto Archive = std::move(*LibOrErr);
+
+  Error Err = Error::success();
+  auto ChildEnd = Archive->child_end();
+  for (auto ChildIter = Archive->child_begin(Err); ChildIter != ChildEnd;
+   ++ChildIter) {
+if (Err)
+  return Err;
+auto ChildNameOrErr = (*ChildIter).getName();
+if (!ChildNameOrErr)
+  return ChildNameOrErr.takeError();
+
+StringRef ChildName = sys::path::filename(ChildNameOrErr.get());
+
+auto ChildBufferRefOrErr = (*ChildIter).getMemoryBufferRef();
+if (!ChildBufferRefOrErr)
+  return ChildBufferRefOrErr.takeError();
+
+auto ChildBuffer =
+MemoryBuffer::getMemBuffer(ChildBufferRefOrErr.get(), false);
+auto ChildNameSplit = ChildName.split('.');
+
+SmallString<16> Path;
+int FileDesc;
+if (std::error_code EC = sys::fs::createTemporaryFile(
+(ChildNameSplit.first), (ChildNameSplit.second), FileDesc, Path))
+  return createFileError(ChildName, EC);
+
+std::string TmpFileName(Path.str());
+Args.push_back(TmpFileName);
+TmpFiles.push_back(TmpFileName);
+std::error_code EC;
+raw_fd_ostream OS(Path.c_str(), EC, sys::fs::OF_None);
+if (EC)
+  return createFileError(TmpFileName, errc::io_error);
+OS << ChildBuffer->getBuffer();
+OS.close();
+  }
+  return Err;
+}
+
+static Error cleanupTmpFiles(SmallVectorImpl &TmpFiles) {
+  for (auto &TmpFile : TmpFiles) {
+if (std::error_code EC = sys::fs::remove(TmpFile))
+  return createFil

[PATCH] D108248: [CUDA] Bump the latest supported CUDA version to 11.4.

2021-08-23 Thread Artem Belevich via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGce4545db1d31: [CUDA] Bump  the latest supported CUDA version 
to 11.4. (authored by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108248

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Cuda.h


Index: clang/include/clang/Basic/Cuda.h
===
--- clang/include/clang/Basic/Cuda.h
+++ clang/include/clang/Basic/Cuda.h
@@ -33,7 +33,7 @@
   CUDA_112,
   CUDA_113,
   CUDA_114,
-  FULLY_SUPPORTED = CUDA_101,
+  FULLY_SUPPORTED = CUDA_114,
   PARTIALLY_SUPPORTED =
   CUDA_114, // Partially supported. Proceed with a warning.
   NEW = 1,  // Too new. Issue a warning, but allow using it.
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -117,6 +117,12 @@
 ^
 ...
 
+CUDA Language Changes in Clang
+---
+
+- Clang now supports CUDA versions up to 11.4.
+- Default GPU architecture has been changed from sm_20 to sm_35.
+
 Objective-C Language Changes in Clang
 -
 


Index: clang/include/clang/Basic/Cuda.h
===
--- clang/include/clang/Basic/Cuda.h
+++ clang/include/clang/Basic/Cuda.h
@@ -33,7 +33,7 @@
   CUDA_112,
   CUDA_113,
   CUDA_114,
-  FULLY_SUPPORTED = CUDA_101,
+  FULLY_SUPPORTED = CUDA_114,
   PARTIALLY_SUPPORTED =
   CUDA_114, // Partially supported. Proceed with a warning.
   NEW = 1,  // Too new. Issue a warning, but allow using it.
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -117,6 +117,12 @@
 ^
 ...
 
+CUDA Language Changes in Clang
+---
+
+- Clang now supports CUDA versions up to 11.4.
+- Default GPU architecture has been changed from sm_20 to sm_35.
+
 Objective-C Language Changes in Clang
 -
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108247: [CUDA] Improve CUDA version detection and diagnostics.

2021-08-23 Thread Artem Belevich via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3db8e486e560: [CUDA] Improve CUDA version detection and 
diagnostics. (authored by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108247

Files:
  clang/include/clang/Basic/Cuda.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Basic/Cuda.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/lib/Driver/ToolChains/Cuda.h
  clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/bin/.keep
  clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/include/.keep
  clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/include/cuda.h
  clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/lib/.keep
  clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/lib64/.keep
  
clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/nvvm/libdevice/libdevice.10.bc
  clang/test/Driver/Inputs/CUDA-unknown/usr/local/cuda/version.txt
  clang/test/Driver/Inputs/CUDA_80/usr/local/cuda/include/cuda.h
  clang/test/Driver/Inputs/CUDA_80/usr/local/cuda/version.txt
  clang/test/Driver/Inputs/CUDA_90/usr/local/cuda/include/cuda.h
  clang/test/Driver/cuda-version-check.cu

Index: clang/test/Driver/cuda-version-check.cu
===
--- clang/test/Driver/cuda-version-check.cu
+++ clang/test/Driver/cuda-version-check.cu
@@ -8,15 +8,12 @@
 // RUN:FileCheck %s --check-prefix=OK
 // RUN: %clang --target=x86_64-linux -v -### --cuda-gpu-arch=sm_60 --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda 2>&1 %s | \
 // RUN:FileCheck %s --check-prefix=OK
-// Test version guess when no version.txt or cuda.h are found
+// Test version guess when cuda.h has not been found
 // RUN: %clang --target=x86_64-linux -v -### --cuda-gpu-arch=sm_60 --cuda-path=%S/Inputs/CUDA-unknown/usr/local/cuda 2>&1 %s | \
 // RUN:FileCheck %s --check-prefix=UNKNOWN_VERSION
-// Unknown version with version.txt present
-// RUN: %clang --target=x86_64-linux -v -### --cuda-gpu-arch=sm_60 --cuda-path=%S/Inputs/CUDA_102/usr/local/cuda 2>&1 %s | \
-// RUN:FileCheck %s --check-prefix=UNKNOWN_VERSION_V
-// Unknown version with no version.txt but with version info present in cuda.h
-// RUN: %clang --target=x86_64-linux -v -### --cuda-gpu-arch=sm_60 --cuda-path=%S/Inputs/CUDA_111/usr/local/cuda 2>&1 %s | \
-// RUN:FileCheck %s --check-prefix=UNKNOWN_VERSION_H
+// Unknown version info present in cuda.h
+// RUN: %clang --target=x86_64-linux -v -### --cuda-gpu-arch=sm_60 --cuda-path=%S/Inputs/CUDA-new/usr/local/cuda 2>&1 %s | \
+// RUN:FileCheck %s --check-prefix=UNKNOWN_VERSION
 // Make sure that we don't warn about CUDA version during C++ compilation.
 // RUN: %clang --target=x86_64-linux -v -### -x c++ --cuda-gpu-arch=sm_60 \
 // RUN:--cuda-path=%S/Inputs/CUDA-unknown/usr/local/cuda 2>&1 %s | \
@@ -66,13 +63,14 @@
 // OK_SM35-NOT: error: GPU arch sm_35
 
 // We should only get one error per architecture.
+// ERR_SM20: error: GPU arch sm_20 {{.*}}
+// ERR_SM20-NOT: error: GPU arch sm_20
+
 // ERR_SM60: error: GPU arch sm_60 {{.*}}
 // ERR_SM60-NOT: error: GPU arch sm_60
 
 // ERR_SM61: error: GPU arch sm_61 {{.*}}
 // ERR_SM61-NOT: error: GPU arch sm_61
 
-// UNKNOWN_VERSION_V: unknown CUDA version: version.txt:{{.*}}; assuming the latest supported version
-// UNKNOWN_VERSION_H: unknown CUDA version: cuda.h: CUDA_VERSION={{.*}}; assuming the latest supported version
-// UNKNOWN_VERSION: unknown CUDA version: no version found in version.txt or cuda.h; assuming the latest supported version
+// UNKNOWN_VERSION: CUDA version is newer than the latest{{.*}} supported version
 // UNKNOWN_VERSION_CXX-NOT: unknown CUDA version
Index: clang/test/Driver/Inputs/CUDA_90/usr/local/cuda/include/cuda.h
===
--- /dev/null
+++ clang/test/Driver/Inputs/CUDA_90/usr/local/cuda/include/cuda.h
@@ -0,0 +1,7 @@
+//
+// Placeholder file for testing CUDA version detection
+//
+
+#define CUDA_VERSION 9000
+
+//
Index: clang/test/Driver/Inputs/CUDA_80/usr/local/cuda/version.txt
===
--- clang/test/Driver/Inputs/CUDA_80/usr/local/cuda/version.txt
+++ /dev/null
@@ -1 +0,0 @@
-CUDA Version 8.0.42
Index: clang/test/Driver/Inputs/CUDA_80/usr/local/cuda/include/cuda.h
===
--- /dev/null
+++ clang/test/Driver/Inputs/CUDA_80/usr/local/cuda/include/cuda.h
@@ -0,0 +1,7 @@
+//
+// Placeholder file for testing CUDA version detection
+//
+
+#define CUDA_VERSION 8000
+
+//
Index: clang/test/Driver/Inputs/CUDA-unknown/usr/local/cuda/version.txt
===
--- clang/test/Driver/Inputs/CUDA-unknown/usr/local/cuda/version.txt
+++ /dev/null
@@ -1 +0,0 @@
-CUDA Version 999.999.999
Index: clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/include/cuda.h

[PATCH] D108239: [CUDA] Add support for CUDA-11.4.

2021-08-23 Thread Artem Belevich via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG49d982d8cbbb: [CUDA] Add support for CUDA-11.4 (authored by 
tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108239

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  llvm/lib/Target/NVPTX/NVPTX.td

Index: llvm/lib/Target/NVPTX/NVPTX.td
===
--- llvm/lib/Target/NVPTX/NVPTX.td
+++ llvm/lib/Target/NVPTX/NVPTX.td
@@ -89,6 +89,10 @@
  "Use PTX version 7.1">;
 def PTX72 : SubtargetFeature<"ptx72", "PTXVersion", "72",
  "Use PTX version 7.2">;
+def PTX73 : SubtargetFeature<"ptx73", "PTXVersion", "73",
+ "Use PTX version 7.3">;
+def PTX74 : SubtargetFeature<"ptx74", "PTXVersion", "74",
+ "Use PTX version 7.4">;
 
 //===--===//
 // NVPTX supported processors.
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -77,6 +77,12 @@
 return CudaVersion::CUDA_110;
   if (raw_version < 11020)
 return CudaVersion::CUDA_111;
+  if (raw_version < 11030)
+return CudaVersion::CUDA_112;
+  if (raw_version < 11040)
+return CudaVersion::CUDA_113;
+  if (raw_version < 11050)
+return CudaVersion::CUDA_114;
   return CudaVersion::LATEST;
 }
 
@@ -720,6 +726,8 @@
   case CudaVersion::CUDA_##CUDA_VER:   \
 PtxFeature = "+ptx" #PTX_VER;  \
 break;
+CASE_CUDA_VERSION(114, 74);
+CASE_CUDA_VERSION(113, 73);
 CASE_CUDA_VERSION(112, 72);
 CASE_CUDA_VERSION(111, 71);
 CASE_CUDA_VERSION(110, 70);
Index: clang/lib/Basic/Targets/NVPTX.cpp
===
--- clang/lib/Basic/Targets/NVPTX.cpp
+++ clang/lib/Basic/Targets/NVPTX.cpp
@@ -44,6 +44,8 @@
 if (!Feature.startswith("+ptx"))
   continue;
 PTXVersion = llvm::StringSwitch(Feature)
+ .Case("+ptx74", 74)
+ .Case("+ptx73", 73)
  .Case("+ptx72", 72)
  .Case("+ptx71", 71)
  .Case("+ptx70", 70)
Index: clang/lib/Basic/Cuda.cpp
===
--- clang/lib/Basic/Cuda.cpp
+++ clang/lib/Basic/Cuda.cpp
@@ -36,6 +36,10 @@
 return "11.1";
   case CudaVersion::CUDA_112:
 return "11.2";
+  case CudaVersion::CUDA_113:
+return "11.3";
+  case CudaVersion::CUDA_114:
+return "11.4";
   }
   llvm_unreachable("invalid enum");
 }
@@ -54,6 +58,8 @@
   .Case("11.0", CudaVersion::CUDA_110)
   .Case("11.1", CudaVersion::CUDA_111)
   .Case("11.2", CudaVersion::CUDA_112)
+  .Case("11.3", CudaVersion::CUDA_113)
+  .Case("11.4", CudaVersion::CUDA_114)
   .Default(CudaVersion::UNKNOWN);
 }
 
@@ -194,6 +200,8 @@
   case CudaArch::SM_20:
   case CudaArch::SM_21:
 return CudaVersion::CUDA_80;
+  case CudaArch::SM_30:
+return CudaVersion::CUDA_110;
   default:
 return CudaVersion::LATEST;
   }
@@ -227,6 +235,10 @@
 return CudaVersion::CUDA_111;
   case 112:
 return CudaVersion::CUDA_112;
+  case 113:
+return CudaVersion::CUDA_113;
+  case 114:
+return CudaVersion::CUDA_114;
   default:
 return CudaVersion::UNKNOWN;
   }
Index: clang/include/clang/Basic/Cuda.h
===
--- clang/include/clang/Basic/Cuda.h
+++ clang/include/clang/Basic/Cuda.h
@@ -31,7 +31,9 @@
   CUDA_110,
   CUDA_111,
   CUDA_112,
-  LATEST = CUDA_112,
+  CUDA_113,
+  CUDA_114,
+  LATEST = CUDA_114,
   LATEST_SUPPORTED = CUDA_101,
 };
 const char *CudaVersionToString(CudaVersion V);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ce4545d - [CUDA] Bump the latest supported CUDA version to 11.4.

2021-08-23 Thread Artem Belevich via cfe-commits


Author: Artem Belevich
Date: 2021-08-23T13:24:49-07:00
New Revision: ce4545db1d31f447bb42987099d691d5658da4bf

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

LOG: [CUDA] Bump  the latest supported CUDA version to 11.4.

This should reduce the amount of noise issued by clang for the recent-ish CUDA
versions.

Clang still does not support all the features offered by NVCC, but is expected
to handle CUDA headers and produce binaries for all GPUs supported by NVCC.

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Cuda.h

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f728f5b4fcfc..aaa471e9b9d4 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -117,6 +117,12 @@ C++2b Feature Support
 ^
 ...
 
+CUDA Language Changes in Clang
+---
+
+- Clang now supports CUDA versions up to 11.4.
+- Default GPU architecture has been changed from sm_20 to sm_35.
+
 Objective-C Language Changes in Clang
 -
 

diff  --git a/clang/include/clang/Basic/Cuda.h 
b/clang/include/clang/Basic/Cuda.h
index 1aa24d8060cf..ef2023cabf7f 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -33,7 +33,7 @@ enum class CudaVersion {
   CUDA_112,
   CUDA_113,
   CUDA_114,
-  FULLY_SUPPORTED = CUDA_101,
+  FULLY_SUPPORTED = CUDA_114,
   PARTIALLY_SUPPORTED =
   CUDA_114, // Partially supported. Proceed with a warning.
   NEW = 1,  // Too new. Issue a warning, but allow using it.



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

[PATCH] D108235: [CUDA] Bump default GPU architecture to sm_35.

2021-08-23 Thread Artem Belevich via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0060fffc8222: [CUDA] Bump default GPU architecture to sm_35. 
(authored by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108235

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/cuda-external-tools.cu
  clang/test/Driver/cuda-march.cu
  clang/test/Driver/cuda-options-freebsd.cu
  clang/test/Driver/cuda-options.cu
  clang/test/Driver/cuda-ptxas-path.cu
  clang/test/Driver/lto.cu
  clang/test/Driver/openmp-offload.c
  clang/test/Driver/opt-record.c
  clang/test/Driver/thinlto.cu

Index: clang/test/Driver/thinlto.cu
===
--- clang/test/Driver/thinlto.cu
+++ clang/test/Driver/thinlto.cu
@@ -16,13 +16,13 @@
 // CHECK-COMPILELINK-ACTIONS: 0: input, "{{.*}}thinlto.cu", cuda, (host-cuda)
 // CHECK-COMPILELINK-ACTIONS: 1: preprocessor, {0}, cuda-cpp-output
 // CHECK-COMPILELINK-ACTIONS: 2: compiler, {1}, ir, (host-cuda)
-// CHECK-COMPILELINK-ACTIONS: 3: input, "{{.*}}thinlto.cu", cuda, (device-cuda, sm_20)
-// CHECK-COMPILELINK-ACTIONS: 4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_20)
-// CHECK-COMPILELINK-ACTIONS: 5: compiler, {4}, ir, (device-cuda, sm_20)
-// CHECK-COMPILELINK-ACTIONS: 6: backend, {5}, assembler, (device-cuda, sm_20)
-// CHECK-COMPILELINK-ACTIONS: 7: assembler, {6}, object, (device-cuda, sm_20)
-// CHECK-COMPILELINK-ACTIONS: 8: offload, "device-cuda (nvptx{{.*}}-nvidia-cuda:sm_20)" {7}, object
-// CHECK-COMPILELINK-ACTIONS: 9: offload, "device-cuda (nvptx{{.*}}-nvidia-cuda:sm_20)" {6}, assembler
+// CHECK-COMPILELINK-ACTIONS: 3: input, "{{.*}}thinlto.cu", cuda, (device-cuda, sm_{{.*}})
+// CHECK-COMPILELINK-ACTIONS: 4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_{{.*}})
+// CHECK-COMPILELINK-ACTIONS: 5: compiler, {4}, ir, (device-cuda, sm_{{.*}})
+// CHECK-COMPILELINK-ACTIONS: 6: backend, {5}, assembler, (device-cuda, sm_{{.*}})
+// CHECK-COMPILELINK-ACTIONS: 7: assembler, {6}, object, (device-cuda, sm_{{.*}})
+// CHECK-COMPILELINK-ACTIONS: 8: offload, "device-cuda (nvptx{{.*}}-nvidia-cuda:sm_{{.*}})" {7}, object
+// CHECK-COMPILELINK-ACTIONS: 9: offload, "device-cuda (nvptx{{.*}}-nvidia-cuda:sm_{{.*}})" {6}, assembler
 // CHECK-COMPILELINK-ACTIONS: 10: linker, {8, 9}, cuda-fatbin, (device-cuda)
 // CHECK-COMPILELINK-ACTIONS: 11: offload, "host-cuda {{.*}}" {2}, "device-cuda{{.*}}" {10}, ir
 // CHECK-COMPILELINK-ACTIONS: 12: backend, {11}, lto-bc, (host-cuda)
Index: clang/test/Driver/opt-record.c
===
--- clang/test/Driver/opt-record.c
+++ clang/test/Driver/opt-record.c
@@ -24,7 +24,7 @@
 
 // CHECK-NO-O: "-cc1"
 // CHECK-NO-O-DAG: "-opt-record-file" "opt-record.opt.yaml"
-// CHECK-CUDA-DEV-DAG: "-opt-record-file" "opt-record-cuda-{{nvptx64|nvptx}}-nvidia-cuda-sm_20.opt.yaml"
+// CHECK-CUDA-DEV-DAG: "-opt-record-file" "opt-record-cuda-{{nvptx64|nvptx}}-nvidia-cuda-sm_{{.*}}.opt.yaml"
 
 // CHECK-EQ: "-cc1"
 // CHECK-EQ: "-opt-record-file" "BAR.txt"
Index: clang/test/Driver/openmp-offload.c
===
--- clang/test/Driver/openmp-offload.c
+++ clang/test/Driver/openmp-offload.c
@@ -215,13 +215,13 @@
 // CHK-PHASES-WITH-CUDA: 0: input, "[[INPUT:.+\.c]]", cuda, (host-cuda-openmp)
 // CHK-PHASES-WITH-CUDA: 1: preprocessor, {0}, cuda-cpp-output, (host-cuda-openmp)
 // CHK-PHASES-WITH-CUDA: 2: compiler, {1}, ir, (host-cuda-openmp)
-// CHK-PHASES-WITH-CUDA: 3: input, "[[INPUT]]", cuda, (device-cuda, sm_20)
-// CHK-PHASES-WITH-CUDA: 4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_20)
-// CHK-PHASES-WITH-CUDA: 5: compiler, {4}, ir, (device-cuda, sm_20)
-// CHK-PHASES-WITH-CUDA: 6: backend, {5}, assembler, (device-cuda, sm_20)
-// CHK-PHASES-WITH-CUDA: 7: assembler, {6}, object, (device-cuda, sm_20)
-// CHK-PHASES-WITH-CUDA: 8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_20)" {7}, object
-// CHK-PHASES-WITH-CUDA: 9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_20)" {6}, assembler
+// CHK-PHASES-WITH-CUDA: 3: input, "[[INPUT]]", cuda, (device-cuda, sm_{{.*}})
+// CHK-PHASES-WITH-CUDA: 4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_{{.*}})
+// CHK-PHASES-WITH-CUDA: 5: compiler, {4}, ir, (device-cuda, sm_{{.*}})
+// CHK-PHASES-WITH-CUDA: 6: backend, {5}, assembler, (device-cuda, sm_{{.*}})
+// CHK-PHASES-WITH-CUDA: 7: assembler, {6}, object, (device-cuda, sm_{{.*}})
+// CHK-PHASES-WITH-CUDA: 8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_{{.*}})" {7}, object
+// CHK-PHASES-WITH-CUDA: 9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_{{.*}})" {6}, assembler
 // CHK-PHASES-WITH-CUDA: 10: linker, {8, 9}, cuda-fatbin, (device-cuda)
 // CHK-PHASES-WITH-CUDA: 11: offload, "host-cuda-openmp (powerpc64le-ibm-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {10}, ir
 // CHK-PHASES-WITH-CUDA: 12: backend,

[clang] 3db8e48 - [CUDA] Improve CUDA version detection and diagnostics.

2021-08-23 Thread Artem Belevich via cfe-commits


Author: Artem Belevich
Date: 2021-08-23T13:24:48-07:00
New Revision: 3db8e486e560183f064e31a228aada52fdeac5d6

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

LOG: [CUDA] Improve CUDA version detection and diagnostics.

Always use cuda.h to detect CUDA version. It's a more universal approach
compared to version.txt which is no longer present in recent CUDA versions.

Split the 'unknown CUDA version' warning in two:

* when detected CUDA version is partially supported by clang. It's expected to
work in general, at the feature parity with the latest supported CUDA
version. and may be missing support for the new features/instructions/GPU
variants. Clang will issue a warning.

* when detected version is new. Recent CUDA versions have been working with
clang reasonably well, and will likely to work similarly to the partially
supported ones above. Or it may not work at all. Clang will issue a warning and
proceed as if the latest known CUDA version was detected.

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

Added: 
clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/bin/.keep
clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/include/.keep
clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/include/cuda.h
clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/lib/.keep
clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/lib64/.keep

clang/test/Driver/Inputs/CUDA-new/usr/local/cuda/nvvm/libdevice/libdevice.10.bc
clang/test/Driver/Inputs/CUDA_80/usr/local/cuda/include/cuda.h
clang/test/Driver/Inputs/CUDA_90/usr/local/cuda/include/cuda.h

Modified: 
clang/include/clang/Basic/Cuda.h
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/lib/Basic/Cuda.cpp
clang/lib/Driver/ToolChains/Cuda.cpp
clang/lib/Driver/ToolChains/Cuda.h
clang/test/Driver/cuda-version-check.cu

Removed: 
clang/test/Driver/Inputs/CUDA-unknown/usr/local/cuda/version.txt
clang/test/Driver/Inputs/CUDA_80/usr/local/cuda/version.txt



diff  --git a/clang/include/clang/Basic/Cuda.h 
b/clang/include/clang/Basic/Cuda.h
index 1bdb0077b8ef..1aa24d8060cf 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -33,8 +33,10 @@ enum class CudaVersion {
   CUDA_112,
   CUDA_113,
   CUDA_114,
-  LATEST = CUDA_114,
-  LATEST_SUPPORTED = CUDA_101,
+  FULLY_SUPPORTED = CUDA_101,
+  PARTIALLY_SUPPORTED =
+  CUDA_114, // Partially supported. Proceed with a warning.
+  NEW = 1,  // Too new. Issue a warning, but allow using it.
 };
 const char *CudaVersionToString(CudaVersion V);
 // Input is "Major.Minor"

diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 660f7e418b9e..57e91bf52ef1 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -77,8 +77,11 @@ def err_drv_cuda_version_unsupported : Error<
   "but installation at %3 is %4; use '--cuda-path' to specify a 
diff erent CUDA "
   "install, pass a 
diff erent GPU arch with '--cuda-gpu-arch', or pass "
   "'--no-cuda-version-check'">;
-def warn_drv_unknown_cuda_version: Warning<
-  "unknown CUDA version: %0; assuming the latest supported version %1">,
+def warn_drv_new_cuda_version: Warning<
+  "CUDA version%0 is newer than the latest%select{| partially}1 supported 
version %2">,
+  InGroup;
+def warn_drv_partially_supported_cuda_version: Warning<
+  "CUDA version %0 is only partially supported">,
   InGroup;
 def err_drv_cuda_host_arch : Error<
   "unsupported architecture '%0' for host compilation">;

diff  --git a/clang/lib/Basic/Cuda.cpp b/clang/lib/Basic/Cuda.cpp
index 2e34da7fa867..f5ee1fb4c228 100644
--- a/clang/lib/Basic/Cuda.cpp
+++ b/clang/lib/Basic/Cuda.cpp
@@ -40,6 +40,8 @@ const char *CudaVersionToString(CudaVersion V) {
 return "11.3";
   case CudaVersion::CUDA_114:
 return "11.4";
+  case CudaVersion::NEW:
+return "";
   }
   llvm_unreachable("invalid enum");
 }
@@ -192,7 +194,7 @@ CudaVersion MinVersionForCudaArch(CudaArch A) {
 CudaVersion MaxVersionForCudaArch(CudaArch A) {
   // AMD GPUs do not depend on CUDA versions.
   if (IsAMDGpuArch(A))
-return CudaVersion::LATEST;
+return CudaVersion::NEW;
 
   switch (A) {
   case CudaArch::UNKNOWN:
@@ -203,7 +205,7 @@ CudaVersion MaxVersionForCudaArch(CudaArch A) {
   case CudaArch::SM_30:
 return CudaVersion::CUDA_110;
   default:
-return CudaVersion::LATEST;
+return CudaVersion::NEW;
   }
 }
 

diff  --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 0d94ad0e66d7..47c1228b030f 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -17,6 +17,7 @@
 #include "clang/Driver/InputInfo.h"
 #i

[clang] 49d982d - [CUDA] Add support for CUDA-11.4

2021-08-23 Thread Artem Belevich via cfe-commits


Author: Artem Belevich
Date: 2021-08-23T13:24:46-07:00
New Revision: 49d982d8c6e01b6f8e4f173ed6325beab08b

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

LOG: [CUDA] Add support for CUDA-11.4

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

Added: 


Modified: 
clang/include/clang/Basic/Cuda.h
clang/lib/Basic/Cuda.cpp
clang/lib/Basic/Targets/NVPTX.cpp
clang/lib/Driver/ToolChains/Cuda.cpp
llvm/lib/Target/NVPTX/NVPTX.td

Removed: 




diff  --git a/clang/include/clang/Basic/Cuda.h 
b/clang/include/clang/Basic/Cuda.h
index aa12724cbf0c..1bdb0077b8ef 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -31,7 +31,9 @@ enum class CudaVersion {
   CUDA_110,
   CUDA_111,
   CUDA_112,
-  LATEST = CUDA_112,
+  CUDA_113,
+  CUDA_114,
+  LATEST = CUDA_114,
   LATEST_SUPPORTED = CUDA_101,
 };
 const char *CudaVersionToString(CudaVersion V);

diff  --git a/clang/lib/Basic/Cuda.cpp b/clang/lib/Basic/Cuda.cpp
index 766135bcb376..2e34da7fa867 100644
--- a/clang/lib/Basic/Cuda.cpp
+++ b/clang/lib/Basic/Cuda.cpp
@@ -36,6 +36,10 @@ const char *CudaVersionToString(CudaVersion V) {
 return "11.1";
   case CudaVersion::CUDA_112:
 return "11.2";
+  case CudaVersion::CUDA_113:
+return "11.3";
+  case CudaVersion::CUDA_114:
+return "11.4";
   }
   llvm_unreachable("invalid enum");
 }
@@ -54,6 +58,8 @@ CudaVersion CudaStringToVersion(const llvm::Twine &S) {
   .Case("11.0", CudaVersion::CUDA_110)
   .Case("11.1", CudaVersion::CUDA_111)
   .Case("11.2", CudaVersion::CUDA_112)
+  .Case("11.3", CudaVersion::CUDA_113)
+  .Case("11.4", CudaVersion::CUDA_114)
   .Default(CudaVersion::UNKNOWN);
 }
 
@@ -194,6 +200,8 @@ CudaVersion MaxVersionForCudaArch(CudaArch A) {
   case CudaArch::SM_20:
   case CudaArch::SM_21:
 return CudaVersion::CUDA_80;
+  case CudaArch::SM_30:
+return CudaVersion::CUDA_110;
   default:
 return CudaVersion::LATEST;
   }
@@ -227,6 +235,10 @@ CudaVersion ToCudaVersion(llvm::VersionTuple Version) {
 return CudaVersion::CUDA_111;
   case 112:
 return CudaVersion::CUDA_112;
+  case 113:
+return CudaVersion::CUDA_113;
+  case 114:
+return CudaVersion::CUDA_114;
   default:
 return CudaVersion::UNKNOWN;
   }

diff  --git a/clang/lib/Basic/Targets/NVPTX.cpp 
b/clang/lib/Basic/Targets/NVPTX.cpp
index c245753c93f4..0461a91d0add 100644
--- a/clang/lib/Basic/Targets/NVPTX.cpp
+++ b/clang/lib/Basic/Targets/NVPTX.cpp
@@ -44,6 +44,8 @@ NVPTXTargetInfo::NVPTXTargetInfo(const llvm::Triple &Triple,
 if (!Feature.startswith("+ptx"))
   continue;
 PTXVersion = llvm::StringSwitch(Feature)
+ .Case("+ptx74", 74)
+ .Case("+ptx73", 73)
  .Case("+ptx72", 72)
  .Case("+ptx71", 71)
  .Case("+ptx70", 70)

diff  --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 37a4da80c03c..0d94ad0e66d7 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -77,6 +77,12 @@ CudaVersion getCudaVersion(uint32_t raw_version) {
 return CudaVersion::CUDA_110;
   if (raw_version < 11020)
 return CudaVersion::CUDA_111;
+  if (raw_version < 11030)
+return CudaVersion::CUDA_112;
+  if (raw_version < 11040)
+return CudaVersion::CUDA_113;
+  if (raw_version < 11050)
+return CudaVersion::CUDA_114;
   return CudaVersion::LATEST;
 }
 
@@ -720,6 +726,8 @@ void CudaToolChain::addClangTargetOptions(
   case CudaVersion::CUDA_##CUDA_VER:   
\
 PtxFeature = "+ptx" #PTX_VER;  
\
 break;
+CASE_CUDA_VERSION(114, 74);
+CASE_CUDA_VERSION(113, 73);
 CASE_CUDA_VERSION(112, 72);
 CASE_CUDA_VERSION(111, 71);
 CASE_CUDA_VERSION(110, 70);

diff  --git a/llvm/lib/Target/NVPTX/NVPTX.td b/llvm/lib/Target/NVPTX/NVPTX.td
index 2b0972b8531e..ecbf1e0aa4b4 100644
--- a/llvm/lib/Target/NVPTX/NVPTX.td
+++ b/llvm/lib/Target/NVPTX/NVPTX.td
@@ -89,6 +89,10 @@ def PTX71 : SubtargetFeature<"ptx71", "PTXVersion", "71",
  "Use PTX version 7.1">;
 def PTX72 : SubtargetFeature<"ptx72", "PTXVersion", "72",
  "Use PTX version 7.2">;
+def PTX73 : SubtargetFeature<"ptx73", "PTXVersion", "73",
+ "Use PTX version 7.3">;
+def PTX74 : SubtargetFeature<"ptx74", "PTXVersion", "74",
+ "Use PTX version 7.4">;
 
 
//===--===//
 // NVPTX supported processors.



___
cfe-commits mailing list
cfe-commits@lists.llv

[clang] 0060fff - [CUDA] Bump default GPU architecture to sm_35.

2021-08-23 Thread Artem Belevich via cfe-commits


Author: Artem Belevich
Date: 2021-08-23T13:24:45-07:00
New Revision: 0060fffc822261ff7350e34371c4456f363f866d

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

LOG: [CUDA] Bump default GPU architecture to sm_35.

It's the oldest GPU architecture currently supported by all CUDA versions clang
can use.

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/cuda-external-tools.cu
clang/test/Driver/cuda-march.cu
clang/test/Driver/cuda-options.cu
clang/test/Driver/cuda-ptxas-path.cu
clang/test/Driver/lto.cu
clang/test/Driver/openmp-offload.c
clang/test/Driver/opt-record.c
clang/test/Driver/thinlto.cu

Removed: 
clang/test/Driver/cuda-options-freebsd.cu



diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 5c323cb6ea23..cdd8ee4ca378 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2765,7 +2765,7 @@ class OffloadingActionBuilder final {
 CudaActionBuilder(Compilation &C, DerivedArgList &Args,
   const Driver::InputList &Inputs)
 : CudaActionBuilderBase(C, Args, Inputs, Action::OFK_Cuda) {
-  DefaultCudaArch = CudaArch::SM_20;
+  DefaultCudaArch = CudaArch::SM_35;
 }
 
 StringRef getCanonicalOffloadArch(StringRef ArchStr) override {

diff  --git a/clang/test/Driver/cuda-external-tools.cu 
b/clang/test/Driver/cuda-external-tools.cu
index f73363508efe..4af5a3ce6016 100644
--- a/clang/test/Driver/cuda-external-tools.cu
+++ b/clang/test/Driver/cuda-external-tools.cu
@@ -7,96 +7,120 @@
 
 // Regular compiles with -O{0,1,2,3,4,fast}.  -O4 and -Ofast map to ptxas O3.
 // RUN: %clang -### -target x86_64-linux-gnu -O0 -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,OPT0 %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,OPT0 %s
 // RUN: %clang -### -target x86_64-linux-gnu -O1 -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,OPT1 %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,OPT1 %s
 // RUN: %clang -### -target x86_64-linux-gnu -O2 -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,OPT2 %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,OPT2 %s
 // RUN: %clang -### -target x86_64-linux-gnu -O3 -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,OPT3 %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,OPT3 %s
 // RUN: %clang -### -target x86_64-linux-gnu -O4 -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,OPT3 %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,OPT3 %s
 // RUN: %clang -### -target x86_64-linux-gnu -Ofast -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,OPT3 %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,OPT3 %s
 // Generating relocatable device code
 // RUN: %clang -### -target x86_64-linux-gnu -fgpu-rdc -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,RDC %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,RDC %s
 
 // With debugging enabled, ptxas should be run with with no ptxas 
optimizations.
 // RUN: %clang -### -target x86_64-linux-gnu --cuda-noopt-device-debug -O2 -g 
-c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,DBG %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,DBG %s
 
 // --no-cuda-noopt-device-debug overrides --cuda-noopt-device-debug.
 // RUN: %clang -### -target x86_64-linux-gnu --cuda-noopt-device-debug \
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
 // RUN:   --no-cuda-noopt-device-debug -O2 -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,OPT2 %s
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,OPT2 %s
 
 // Regular compile without -O.  This should result in us passing -O0 to ptxas.
 // RUN: %clang -### -target x86_64-linux-gnu -c %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM20,OPT0 %s
+// RUN:   --offload-arch=sm_35 --cuda-path=%S/Inputs/CUDA/usr/local/cuda \
+// RUN: | FileCheck -check-prefixes=CHECK,ARCH64,SM35,OPT0 %s
 
 // Regular compiles with -Os and -Oz.  For lack of a

[PATCH] D108525: Fix documentation and snippets for the handle attributes.

2021-08-23 Thread Paul Herman via Phabricator via cfe-commits

paulherman added a comment.

In D108525#2960877 , @aaron.ballman 
wrote:

> In D108525#2960765 , @paulherman 
> wrote:
>
>> Thanks for the very prompt review! I'm afraid I no longer have permissions 
>> to submit --my last commit was in 2015 and I recall that I had SVN access, 
>> but many things have changed. Would it be possible to submit this on my 
>> behalf?
>
> I'm happy to commit on your behalf -- what name and email address would you 
> like me to use for patch attribution?

Thanks a lot! You can use "Paul Herman" as name and paulher...@google.com as 
email.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108525

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

[PATCH] D108571: [clang] allow -fstack-clash-protection on FreeBSD

2021-08-23 Thread serge via Phabricator via cfe-commits

serge-sans-paille accepted this revision.
serge-sans-paille added a comment.
This revision is now accepted and ready to land.

You know your platform better than I do, and you already ran the patch without 
any issue, so LGTM


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

https://reviews.llvm.org/D108571

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

[PATCH] D108481: Avoid nullptr dereferencing of 'Constraint'

2021-08-23 Thread Sindhu Chittireddy via Phabricator via cfe-commits

schittir marked an inline comment as done.
schittir added a comment.

In D108481#2960875 , @aaron.ballman 
wrote:

> LGTM, thanks for the cleanup! Do you need someone to commit on your behalf? 
> If so, what name and email address would you like me to use for patch 
> attribution?

Thank you, Aaron. 
Yes, please! Sindhu Chittireddy; sindhu.chittire...@intel.com


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

https://reviews.llvm.org/D108481

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

[PATCH] D54880: Ignore gcc's stack-clash-protection flag

2021-08-23 Thread Vassil Vassilev via Phabricator via cfe-commits

v.g.vassilev abandoned this revision.
v.g.vassilev added a comment.

Thanks for the information!


Repository:
  rC Clang

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

https://reviews.llvm.org/D54880

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

[PATCH] D108525: Fix documentation and snippets for the handle attributes.

2021-08-23 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D108525#2960765 , @paulherman 
wrote:

> Thanks for the very prompt review! I'm afraid I no longer have permissions to 
> submit --my last commit was in 2015 and I recall that I had SVN access, but 
> many things have changed. Would it be possible to submit this on my behalf?

I'm happy to commit on your behalf -- what name and email address would you 
like me to use for patch attribution?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108525

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

[PATCH] D108481: Avoid nullptr dereferencing of 'Constraint'

2021-08-23 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM, thanks for the cleanup! Do you need someone to commit on your behalf? If 
so, what name and email address would you like me to use for patch attribution?


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

https://reviews.llvm.org/D108481

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

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

In D101960#2960846 , @protze.joachim 
wrote:

> The lit config has platform-specific rules to build the environmental 
> variables (including the use of the proper separators). I suggest to used 
> these values to create the printed env expressions.

Yep. That seems an unconditional win, however the rpath/runpath stuff works out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D108481: Avoid nullptr dereferencing of 'Constraint'

2021-08-23 Thread Sindhu Chittireddy via Phabricator via cfe-commits

schittir updated this revision to Diff 368183.
schittir added a comment.

1. Removed the useless assert on TC.
2. Retained the change from `cast_or_null` to `cast`


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

https://reviews.llvm.org/D108481

Files:
  clang/lib/Sema/SemaConcept.cpp


Index: clang/lib/Sema/SemaConcept.cpp
===
--- clang/lib/Sema/SemaConcept.cpp
+++ clang/lib/Sema/SemaConcept.cpp
@@ -1062,11 +1062,8 @@
   assert(TPL->size() == 1);
   const TypeConstraint *TC =
   cast(TPL->getParam(0))->getTypeConstraint();
-  assert(TC &&
- "TPL must have a template type parameter with a type constraint");
   auto *Constraint =
-  cast_or_null(
-  TC->getImmediatelyDeclaredConstraint());
+  cast(TC->getImmediatelyDeclaredConstraint());
   bool Dependent =
   Constraint->getTemplateArgsAsWritten() &&
   TemplateSpecializationType::anyInstantiationDependentTemplateArguments(


Index: clang/lib/Sema/SemaConcept.cpp
===
--- clang/lib/Sema/SemaConcept.cpp
+++ clang/lib/Sema/SemaConcept.cpp
@@ -1062,11 +1062,8 @@
   assert(TPL->size() == 1);
   const TypeConstraint *TC =
   cast(TPL->getParam(0))->getTypeConstraint();
-  assert(TC &&
- "TPL must have a template type parameter with a type constraint");
   auto *Constraint =
-  cast_or_null(
-  TC->getImmediatelyDeclaredConstraint());
+  cast(TC->getImmediatelyDeclaredConstraint());
   bool Dependent =
   Constraint->getTemplateArgsAsWritten() &&
   TemplateSpecializationType::anyInstantiationDependentTemplateArguments(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Joachim Protze via Phabricator via cfe-commits

protze.joachim added a comment.

In D101960#2960641 , @JonChesterfield 
wrote:

> Pasting `env LD_LIBRARY_PATH=` and `env LIBRARY_PATH` into the printed 
> commandline, as opposed to through magic, would solve most of my day to day 
> frustration here. libomp.so and libomptarget.so are in two different 
> directories, LD_LIBRARY_PATH turns out to be colon delimited. LIBRARY_PATH is 
> presently used to find the deviceRTL though I'd like to change that.

The lit config has platform-specific rules to build the environmental variables 
(including the use of the proper separators). I suggest to used these values to 
create the printed env expressions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D108320: Add semantic token modifier for non-const reference parameter

2021-08-23 Thread Tom Praschan via Phabricator via cfe-commits

tom-anders added a comment.

@sammccall @nridge Thanks for the positive feedback, let me know if I missed 
any of your suggestions!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108320

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

[PATCH] D108320: Add semantic token modifier for non-const reference parameter

2021-08-23 Thread Tom Praschan via Phabricator via cfe-commits

tom-anders updated this revision to Diff 368181.
tom-anders added a comment.

- clang-format once again


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108320

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/semantic-tokens.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -729,6 +729,63 @@
   }
 };
   )cpp",
+  // Modifier for variables passed as non-const references
+  R"cpp(
+void $Function_decl[[fun]](int, const int,
+   int*, const int*,
+   int&, const int&,
+   int*&, const int*&, const int* const &,
+   int**, int**&, int** const &,
+   int = 123) {
+  int $LocalVariable_decl[[val]];
+  int* $LocalVariable_decl[[ptr]];
+  const int* $LocalVariable_decl_readonly[[constPtr]];
+  int** $LocalVariable_decl[[array]];
+  $Function[[fun]]($LocalVariable[[val]], $LocalVariable[[val]], 
+   $LocalVariable[[ptr]], $LocalVariable_readonly[[constPtr]], 
+   $LocalVariable_usedAsMutableReference[[val]], $LocalVariable[[val]], 
+
+   $LocalVariable_usedAsMutableReference[[ptr]],
+   $LocalVariable_readonly_usedAsMutableReference[[constPtr]],
+   $LocalVariable_readonly[[constPtr]],
+
+   $LocalVariable[[array]], $LocalVariable_usedAsMutableReference[[array]], 
+   $LocalVariable[[array]]
+   );
+}
+struct $Class_decl[[S]] {
+  $Class_decl[[S]](int&) {
+$Class[[S]] $LocalVariable_decl[[s1]]($Field_usedAsMutableReference[[field]]);
+$Class[[S]] $LocalVariable_decl[[s2]]($LocalVariable[[s1]].$Field_usedAsMutableReference[[field]]);
+
+$Class[[S]] $LocalVariable_decl[[s3]]($StaticField_static_usedAsMutableReference[[staticField]]);
+$Class[[S]] $LocalVariable_decl[[s4]]($Class[[S]]::$StaticField_static_usedAsMutableReference[[staticField]]);
+  }
+  int $Field_decl[[field]];
+  static int $StaticField_decl_static[[staticField]];
+};
+template 
+void $Function_decl[[foo]]($TemplateParameter[[X]]& $Parameter_decl[[x]]) {
+  // We do not support dependent types, so this one should *not* get the modifier.
+  $Function[[foo]]($Parameter[[x]]); 
+}
+  )cpp",
+/*struct $Class_decl[[S]] {
+  $Class_decl[[S]](int $Parameter_decl[[value]], const int& $Parameter_decl_readonly[[constRef]], 
+int& $Parameter_decl[[ref]], int* $Parameter_decl[[ptr]], 
+int $Parameter_decl[[defaultParameter]] = 3);
+  int $Field_decl[[field]];
+};
+void $Function_decl[[bar]]() {
+  int $LocalVariable_decl[[foo]];
+  $Function[[fun]]($LocalVariable[[foo]], $LocalVariable[[foo]], 
+   $LocalVariable_usedAsMutableReference[[foo]], &$LocalVariable[[foo]]);
+
+  $Class[[S]] $LocalVariable_decl[[s]]($LocalVariable[[foo]], $LocalVariable[[foo]], 
+   $LocalVariable_usedAsMutableReference[[foo]], &$LocalVariable[[foo]]);
+  $Function[[fun]]($LocalVariable[[s]].$Field[[field]], $LocalVariable[[s]].$Field[[field]], 
+   $LocalVariable[[s]].$Field_usedAsMutableReference[[field]], &$LocalVariable[[s]].$Field[[field]]);
+}*/
   };
   for (const auto &TestCase : TestCases)
 // Mask off scope modifiers to keep the tests manageable.
Index: clang-tools-extra/clangd/test/semantic-tokens.test
===
--- clang-tools-extra/clangd/test/semantic-tokens.test
+++ clang-tools-extra/clangd/test/semantic-tokens.test
@@ -23,7 +23,7 @@
 # CHECK-NEXT:  4,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  0,
-# CHECK-NEXT:  4097
+# CHECK-NEXT:  8193
 # CHECK-NEXT:],
 # CHECK-NEXT:"resultId": "1"
 # CHECK-NEXT:  }
@@ -49,7 +49,7 @@
 # CHECK-NEXT:  4,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  0,
-# CHECK-NEXT:  4097
+# CHECK-NEXT:  8193
 # CHECK-NEXT:],
 #Inserted at position 1
 # CHECK-NEXT:"dele

[PATCH] D108320: Add semantic token modifier for non-const reference parameter

2021-08-23 Thread Tom Praschan via Phabricator via cfe-commits

tom-anders updated this revision to Diff 368179.
tom-anders added a comment.

- Remove accidentally added empty line


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108320

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/semantic-tokens.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -729,6 +729,63 @@
   }
 };
   )cpp",
+  // Modifier for variables passed as non-const references
+  R"cpp(
+void $Function_decl[[fun]](int, const int,
+   int*, const int*,
+   int&, const int&,
+   int*&, const int*&, const int* const &,
+   int**, int**&, int** const &,
+   int = 123) {
+  int $LocalVariable_decl[[val]];
+  int* $LocalVariable_decl[[ptr]];
+  const int* $LocalVariable_decl_readonly[[constPtr]];
+  int** $LocalVariable_decl[[array]];
+  $Function[[fun]]($LocalVariable[[val]], $LocalVariable[[val]], 
+   $LocalVariable[[ptr]], $LocalVariable_readonly[[constPtr]], 
+   $LocalVariable_usedAsMutableReference[[val]], $LocalVariable[[val]], 
+
+   $LocalVariable_usedAsMutableReference[[ptr]],
+   $LocalVariable_readonly_usedAsMutableReference[[constPtr]],
+   $LocalVariable_readonly[[constPtr]],
+
+   $LocalVariable[[array]], $LocalVariable_usedAsMutableReference[[array]], 
+   $LocalVariable[[array]]
+   );
+}
+struct $Class_decl[[S]] {
+  $Class_decl[[S]](int&) {
+$Class[[S]] $LocalVariable_decl[[s1]]($Field_usedAsMutableReference[[field]]);
+$Class[[S]] $LocalVariable_decl[[s2]]($LocalVariable[[s1]].$Field_usedAsMutableReference[[field]]);
+
+$Class[[S]] $LocalVariable_decl[[s3]]($StaticField_static_usedAsMutableReference[[staticField]]);
+$Class[[S]] $LocalVariable_decl[[s4]]($Class[[S]]::$StaticField_static_usedAsMutableReference[[staticField]]);
+  }
+  int $Field_decl[[field]];
+  static int $StaticField_decl_static[[staticField]];
+};
+template 
+void $Function_decl[[foo]]($TemplateParameter[[X]]& $Parameter_decl[[x]]) {
+  // We do not support dependent types, so this one should *not* get the modifier.
+  $Function[[foo]]($Parameter[[x]]); 
+}
+  )cpp",
+/*struct $Class_decl[[S]] {
+  $Class_decl[[S]](int $Parameter_decl[[value]], const int& $Parameter_decl_readonly[[constRef]], 
+int& $Parameter_decl[[ref]], int* $Parameter_decl[[ptr]], 
+int $Parameter_decl[[defaultParameter]] = 3);
+  int $Field_decl[[field]];
+};
+void $Function_decl[[bar]]() {
+  int $LocalVariable_decl[[foo]];
+  $Function[[fun]]($LocalVariable[[foo]], $LocalVariable[[foo]], 
+   $LocalVariable_usedAsMutableReference[[foo]], &$LocalVariable[[foo]]);
+
+  $Class[[S]] $LocalVariable_decl[[s]]($LocalVariable[[foo]], $LocalVariable[[foo]], 
+   $LocalVariable_usedAsMutableReference[[foo]], &$LocalVariable[[foo]]);
+  $Function[[fun]]($LocalVariable[[s]].$Field[[field]], $LocalVariable[[s]].$Field[[field]], 
+   $LocalVariable[[s]].$Field_usedAsMutableReference[[field]], &$LocalVariable[[s]].$Field[[field]]);
+}*/
   };
   for (const auto &TestCase : TestCases)
 // Mask off scope modifiers to keep the tests manageable.
Index: clang-tools-extra/clangd/test/semantic-tokens.test
===
--- clang-tools-extra/clangd/test/semantic-tokens.test
+++ clang-tools-extra/clangd/test/semantic-tokens.test
@@ -23,7 +23,7 @@
 # CHECK-NEXT:  4,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  0,
-# CHECK-NEXT:  4097
+# CHECK-NEXT:  8193
 # CHECK-NEXT:],
 # CHECK-NEXT:"resultId": "1"
 # CHECK-NEXT:  }
@@ -49,7 +49,7 @@
 # CHECK-NEXT:  4,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  0,
-# CHECK-NEXT:  4097
+# CHECK-NEXT:  8193
 # CHECK-NEXT:],
 #Inserted at position 1
 # CHECK-NEXT:

[PATCH] D36850: [ThinLTO] Add norecurse function attribute propagation

2021-08-23 Thread Di Mo via Phabricator via cfe-commits

modimo updated this revision to Diff 368178.
modimo added a comment.

Remove llvm/test/ThinLTO/X86/weak_externals.ll from diffs


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D36850

Files:
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGen/thinlto-distributed-cfi.ll
  clang/test/CodeGen/thinlto-funcattr-prop.ll
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/GlobalValue.h
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/Transforms/IPO/FunctionAttrs.h
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/ModuleSummaryIndex.cpp
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/FunctionAttrs.cpp
  llvm/test/Assembler/thinlto-summary.ll
  llvm/test/ThinLTO/X86/deadstrip.ll
  llvm/test/ThinLTO/X86/dot-dumper.ll
  llvm/test/ThinLTO/X86/dot-dumper2.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-exported-internal.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-indirect.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-undefined.ll
  llvm/test/ThinLTO/X86/funcattrs-prop.ll
  llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
  llvm/test/ThinLTO/X86/function_entry_count.ll
  llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll

Index: llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
===
--- llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
+++ llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
@@ -3,15 +3,17 @@
 ; verification error.
 ; RUN: opt -module-summary %s -o %t1.bc
 ; RUN: opt -module-summary %p/Inputs/linkonce_resolution_comdat.ll -o %t2.bc
-; RUN: llvm-lto -thinlto-action=run %t1.bc %t2.bc -exported-symbol=f -exported-symbol=g -thinlto-save-temps=%t3.
+; RUN: llvm-lto -thinlto-action=run -disable-thinlto-funcattrs=0 %t1.bc %t2.bc -exported-symbol=f -exported-symbol=g -thinlto-save-temps=%t3.
 
 ; RUN: llvm-dis %t3.0.3.imported.bc -o - | FileCheck %s --check-prefix=IMPORT1
 ; RUN: llvm-dis %t3.1.3.imported.bc -o - | FileCheck %s --check-prefix=IMPORT2
 ; Copy from first module is prevailing and converted to weak_odr, copy
 ; from second module is preempted and converted to available_externally and
 ; removed from comdat.
-; IMPORT1: define weak_odr i32 @f(i8* %0) unnamed_addr comdat($c1) {
-; IMPORT2: define available_externally i32 @f(i8* %0) unnamed_addr {
+; IMPORT1: define weak_odr i32 @f(i8* %0) unnamed_addr [[ATTR:#[0-9]+]] comdat($c1) {
+; IMPORT2: define available_externally i32 @f(i8* %0) unnamed_addr [[ATTR:#[0-9]+]] {
+
+; CHECK-DAG: attributes [[ATTR]] = { norecurse nounwind }
 
 ; RUN: llvm-nm -o - < %t1.bc.thinlto.o | FileCheck %s --check-prefix=NM1
 ; NM1: W f
Index: llvm/test/ThinLTO/X86/function_entry_count.ll
===
--- llvm/test/ThinLTO/X86/function_entry_count.ll
+++ llvm/test/ThinLTO/X86/function_entry_count.ll
@@ -2,7 +2,7 @@
 ; RUN: opt -thinlto-bc %p/Inputs/function_entry_count.ll -write-relbf-to-summary -thin-link-bitcode-file=%t2.thinlink.bc -o %t2.bc
 
 ; First perform the thin link on the normal bitcode file.
-; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps -thinlto-synthesize-entry-counts \
+; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps -disable-thinlto-funcattrs=0 -thinlto-synthesize-entry-counts \
 ; RUN: -r=%t1.bc,g, \
 ; RUN: -r=%t1.bc,f,px \
 ; RUN: -r=%t1.bc,h,px \
@@ -10,15 +10,16 @@
 ; RUN: -r=%t2.bc,g,px
 ; RUN: llvm-dis -o - %t.o.1.3.import.bc | FileCheck %s
 
-; RUN: llvm-lto -thinlto-action=run -thinlto-synthesize-entry-counts -exported-symbol=f \
+; RUN: llvm-lto -thinlto-action=run -disable-thinlto-funcattrs=0 -thinlto-synthesize-entry-counts -exported-symbol=f \
 ; RUN: -exported-symbol=g -exported-symbol=h -thinlto-save-temps=%t3. %t1.bc %t2.bc
 ; RUN: llvm-dis %t3.0.3.imported.bc -o - | FileCheck %s
 
-; CHECK: define void @h() !prof ![[PROF2:[0-9]+]]
-; CHECK: define void @f(i32{{.*}}) !prof ![[PROF1:[0-9]+]]
+; CHECK: define void @h() [[ATTR:#[0-9]+]] !prof ![[PROF2:[0-9]+]]
+; CHECK: define void @f(i32{{.*}}) [[ATTR:#[0-9]+]] !prof ![[PROF1:[0-9]+]]
 ; CHECK: define available_externally void @g() !prof ![[PROF2]]
 ; CHECK-DAG: ![[PROF1]] = !{!"synthetic_function_entry_count", i64 10}
 ; CHECK-DAG: ![[PROF2]] = !{!"synthetic_function_entry_count", i64 198}
+; CHECK-DAG: attributes [[ATTR]] = { norecurse nounwind }
 
 target triple = "x86_64-unknown-linux-gnu"
 target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
Index: llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
===
--- llvm/test/ThinLTO/X

[PATCH] D108464: [clang][CodeGen] Refactor CreateTempAlloca function nest. NFC.

2021-08-23 Thread Thomas Lively via Phabricator via cfe-commits

tlively added a comment.

In D108464#2960623 , @rjmccall wrote:

> + JF, who knows something about Web Assembly, or can at least drag in the 
> right people
>
> In D108464#2959591 , @wingo wrote:
>
>> In D108464#2957276 , @wingo wrote:
>>
>>> So... besides the refactor, this is getting closer to where I'm going 
>>> in https://lists.llvm.org/pipermail/cfe-dev/2021-July/068559.html, though 
>>> still NFC.  I think you can see where I would replace 
>>> `getASTAllocaAddressSpace` with `getAllocaAddressSpace(QualType Ty)`, and 
>>> possibly (depending on the source language) avoid casting the resulting 
>>> alloca to `LangAS::Default`.  WDYT, is this sort of thing OK?
>>
>> Taking this patch as perhaps a better generic discussion point, @rjmccall 
>> graciously gave some general feedback on this approach (thank you!!!):
>>
>> In D108360#2957844 , @rjmccall 
>> wrote:
>>
>>> I'm not sure that I agree with your overall plan, though:
>>>
>>> - The WebAssembly operand stack is not a good match for an address space at 
>>> the language level because it's not addressable at all.  If you can't 
>>> meaningfully have a pointer into the address space, then you don't really 
>>> need this in the type system; it's more like a declaration modifier at best.
>>> - Allocating local variables on the operand stack ought to be a very 
>>> straightforward analysis in the backend.  There's not much optimization 
>>> value in trying to do it in the frontend, and it's going to be problematic 
>>> for things like coroutine lowering.
>>> - The security argument seems pretty weak, not because security isn't 
>>> important but because this is not really an adequate basis for getting the 
>>> tamper-proof guarantee you want.  For example, LLVM passes can and do 
>>> introduce its own allocas and store scalars into them sometimes.  Really 
>>> you need some sort of "tamper-proof" *type* which the compiler can make an 
>>> end-to-end guarantee of non-tamper-ability for the values of, and while 
>>> optimally this would be implemented by just keeping values on the operand 
>>> stack, in the general case you will need to have some sort of strategy for 
>>> keeping things in memory.
>>
>> Thanks for thinking about this!  Indeed I started out with the goal of not 
>> going deep into clang and if it's possible to avoid going too deeply, that 
>> would be better for everyone involved.  I am starting to think however that 
>> it may be unavoidable for me at least.
>>
>> So, I am focusing on WebAssembly global and local variables; the WebAssembly 
>> operand stack is an artifact of the IR-to-MC lowering and AFAICS doesn't 
>> have any bearing on what clang does -- though perhaps I am misunderstanding 
>> what you are getting at here.  The issue is not to allocate locals on the 
>> operand stack, but rather to allocate them as part of the "locals" of a 
>> WebAssembly function 
>> .  Cc 
>> @tlively on the WebAssembly side.
>
> By "operand stack" I mean the innate, unaddressable stack that the 
> WebAssembly VM maintains in order to make functions reentrant.  I don't know 
> what term the VM spec uses for it, but I believe "operand stack" is widely 
> accepted terminology for the unaddressable stack when you've got this kind of 
> dual-stack setup.  And yes, VM "locals" would go there.

@wingo, are there cases where it is useful to declare variables as living in 
WebAssembly locals and not in the VM stack? I'm having trouble coming up with a 
case where leaving that up to the backend is not enough. We clearly need a way 
to prevent values from being written to main memory (AS 0), but it's not clear 
to me that we need a way to specifically allocate locals for them.

>> The main motivator is the ability to have "reference type" 
>>  
>> (`externref`/`funcref`) locals and globals 
>>  at 
>> all.  Reference-typed values can't be stored to linear memory.  They have no 
>> size and no byte representation -- they are opaque values from the host.  
>> However, WebAssembly locals and globals can define storage locations of type 
>> `externref` or `funcref`.
>
> I see.  I think you need to think carefully about the best way to represent 
> values of these types in LLVM IR, because it probably cannot just be "treat 
> them as a normal value, emit code a certain way that we know how to lower, 
> and hope nothing goes wrong".  It seems to me that you probably need a new IR 
> type for it, since normal types aren't restricted from memory and tokens 
> can't be used as parameters or return values.
>
> Hopefully, someone had a plan for this when they introduced that WebAssembly 
>

[PATCH] D108320: Add semantic token modifier for non-const reference parameter

2021-08-23 Thread Tom Praschan via Phabricator via cfe-commits

tom-anders updated this revision to Diff 368177.
tom-anders marked 3 inline comments as done.
tom-anders added a comment.

- Apply suggested renaming and fix nits
- Use a map for extra modifiers instead of abusing conflict resolution
- Use ArrayRef instead of callback
- Add FIXME for handling CXXOperatorCallExpr
- Use getLocation() instead of getBeginLoc()
- Add FIXME for unwrapping operators
- Iterate over FunctionProtoType instead of FunctionDecl
- Adjust highlighting condition and revise test cases


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108320

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/semantic-tokens.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -729,6 +729,63 @@
   }
 };
   )cpp",
+  // Modifier for variables passed as non-const references
+  R"cpp(
+void $Function_decl[[fun]](int, const int,
+   int*, const int*,
+   int&, const int&,
+   int*&, const int*&, const int* const &,
+   int**, int**&, int** const &,
+   int = 123) {
+  int $LocalVariable_decl[[val]];
+  int* $LocalVariable_decl[[ptr]];
+  const int* $LocalVariable_decl_readonly[[constPtr]];
+  int** $LocalVariable_decl[[array]];
+  $Function[[fun]]($LocalVariable[[val]], $LocalVariable[[val]], 
+   $LocalVariable[[ptr]], $LocalVariable_readonly[[constPtr]], 
+   $LocalVariable_usedAsMutableReference[[val]], $LocalVariable[[val]], 
+
+   $LocalVariable_usedAsMutableReference[[ptr]],
+   $LocalVariable_readonly_usedAsMutableReference[[constPtr]],
+   $LocalVariable_readonly[[constPtr]],
+
+   $LocalVariable[[array]], $LocalVariable_usedAsMutableReference[[array]], 
+   $LocalVariable[[array]]
+   );
+}
+struct $Class_decl[[S]] {
+  $Class_decl[[S]](int&) {
+$Class[[S]] $LocalVariable_decl[[s1]]($Field_usedAsMutableReference[[field]]);
+$Class[[S]] $LocalVariable_decl[[s2]]($LocalVariable[[s1]].$Field_usedAsMutableReference[[field]]);
+
+$Class[[S]] $LocalVariable_decl[[s3]]($StaticField_static_usedAsMutableReference[[staticField]]);
+$Class[[S]] $LocalVariable_decl[[s4]]($Class[[S]]::$StaticField_static_usedAsMutableReference[[staticField]]);
+  }
+  int $Field_decl[[field]];
+  static int $StaticField_decl_static[[staticField]];
+};
+template 
+void $Function_decl[[foo]]($TemplateParameter[[X]]& $Parameter_decl[[x]]) {
+  // We do not support dependent types, so this one should *not* get the modifier.
+  $Function[[foo]]($Parameter[[x]]); 
+}
+  )cpp",
+/*struct $Class_decl[[S]] {
+  $Class_decl[[S]](int $Parameter_decl[[value]], const int& $Parameter_decl_readonly[[constRef]], 
+int& $Parameter_decl[[ref]], int* $Parameter_decl[[ptr]], 
+int $Parameter_decl[[defaultParameter]] = 3);
+  int $Field_decl[[field]];
+};
+void $Function_decl[[bar]]() {
+  int $LocalVariable_decl[[foo]];
+  $Function[[fun]]($LocalVariable[[foo]], $LocalVariable[[foo]], 
+   $LocalVariable_usedAsMutableReference[[foo]], &$LocalVariable[[foo]]);
+
+  $Class[[S]] $LocalVariable_decl[[s]]($LocalVariable[[foo]], $LocalVariable[[foo]], 
+   $LocalVariable_usedAsMutableReference[[foo]], &$LocalVariable[[foo]]);
+  $Function[[fun]]($LocalVariable[[s]].$Field[[field]], $LocalVariable[[s]].$Field[[field]], 
+   $LocalVariable[[s]].$Field_usedAsMutableReference[[field]], &$LocalVariable[[s]].$Field[[field]]);
+}*/
   };
   for (const auto &TestCase : TestCases)
 // Mask off scope modifiers to keep the tests manageable.
Index: clang-tools-extra/clangd/test/semantic-tokens.test
===
--- clang-tools-extra/clangd/test/semantic-tokens.test
+++ clang-tools-extra/clangd/test/semantic-tokens.test
@@ -23,7 +23,7 @@
 # CHECK-NEXT:  4,
 # CHECK-NEXT:

[PATCH] D107647: [PowerPC] MMA - Add __builtin_vsx_build_pair and __builtin_mma_build_acc builtins

2021-08-23 Thread Ahsan Saghir via Phabricator via cfe-commits

saghir updated this revision to Diff 368176.
saghir added a comment.

Added comments, and re-organized tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107647

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-pair-mma.c
  clang/test/Sema/ppc-pair-mma-types.c
  clang/test/SemaCXX/ppc-pair-mma-types.cpp
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
  llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll

Index: llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll
===
--- llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll
+++ llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll
@@ -51,6 +51,81 @@
   ret void
 }
 
+; build_pair
+declare <256 x i1> @llvm.ppc.vsx.build.pair(<16 x i8>, <16 x i8>)
+define void @build_pair1(<256 x i1>* %ptr, <16 x i8> %vc) {
+; CHECK-LABEL: build_pair1:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vmr v3, v2
+; CHECK-NEXT:stxv v2, 16(r3)
+; CHECK-NEXT:stxv v3, 0(r3)
+; CHECK-NEXT:blr
+;
+; CHECK-NOMMA-LABEL: build_pair1:
+; CHECK-NOMMA:   # %bb.0: # %entry
+; CHECK-NOMMA-NEXT:vmr v3, v2
+; CHECK-NOMMA-NEXT:stxv v2, 16(r3)
+; CHECK-NOMMA-NEXT:stxv v3, 0(r3)
+; CHECK-NOMMA-NEXT:blr
+;
+; CHECK-BE-LABEL: build_pair1:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:vmr v3, v2
+; CHECK-BE-NEXT:stxv v2, 16(r3)
+; CHECK-BE-NEXT:stxv v2, 0(r3)
+; CHECK-BE-NEXT:blr
+;
+; CHECK-BE-NOMMA-LABEL: build_pair1:
+; CHECK-BE-NOMMA:   # %bb.0: # %entry
+; CHECK-BE-NOMMA-NEXT:vmr v3, v2
+; CHECK-BE-NOMMA-NEXT:stxv v2, 16(r3)
+; CHECK-BE-NOMMA-NEXT:stxv v2, 0(r3)
+; CHECK-BE-NOMMA-NEXT:blr
+entry:
+  %0 = tail call <256 x i1> @llvm.ppc.vsx.build.pair(<16 x i8> %vc, <16 x i8> %vc)
+  store <256 x i1> %0, <256 x i1>* %ptr, align 32
+  ret void
+}
+
+; build_pair
+define void @build_pair2(<256 x i1>* %ptr, <16 x i8> %in1, <16 x i8> %in2) {
+; CHECK-LABEL: build_pair2:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vmr v4, v3
+; CHECK-NEXT:vmr v5, v2
+; CHECK-NEXT:stxv v4, 16(r3)
+; CHECK-NEXT:stxv v5, 0(r3)
+; CHECK-NEXT:blr
+;
+; CHECK-NOMMA-LABEL: build_pair2:
+; CHECK-NOMMA:   # %bb.0: # %entry
+; CHECK-NOMMA-NEXT:vmr v4, v3
+; CHECK-NOMMA-NEXT:vmr v5, v2
+; CHECK-NOMMA-NEXT:stxv v4, 16(r3)
+; CHECK-NOMMA-NEXT:stxv v5, 0(r3)
+; CHECK-NOMMA-NEXT:blr
+;
+; CHECK-BE-LABEL: build_pair2:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:vmr v4, v3
+; CHECK-BE-NEXT:vmr v5, v2
+; CHECK-BE-NEXT:stxv v2, 16(r3)
+; CHECK-BE-NEXT:stxv v4, 0(r3)
+; CHECK-BE-NEXT:blr
+;
+; CHECK-BE-NOMMA-LABEL: build_pair2:
+; CHECK-BE-NOMMA:   # %bb.0: # %entry
+; CHECK-BE-NOMMA-NEXT:vmr v4, v3
+; CHECK-BE-NOMMA-NEXT:vmr v5, v2
+; CHECK-BE-NOMMA-NEXT:stxv v2, 16(r3)
+; CHECK-BE-NOMMA-NEXT:stxv v4, 0(r3)
+; CHECK-BE-NOMMA-NEXT:blr
+entry:
+%0 = tail call <256 x i1> @llvm.ppc.vsx.build.pair(<16 x i8> %in2, <16 x i8> %in1)
+store <256 x i1> %0, <256 x i1>* %ptr, align 64
+ret void
+}
+
 ; disassemble_pair
 declare { <16 x i8>, <16 x i8> } @llvm.ppc.vsx.disassemble.pair(<256 x i1>)
 define void @disass_pair(<256 x i1>* %ptr1, <16 x i8>* %ptr2, <16 x i8>* %ptr3) {
Index: llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
===
--- llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
+++ llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
@@ -40,6 +40,77 @@
   ret void
 }
 
+; build_acc
+declare <512 x i1> @llvm.ppc.mma.build.acc(<16 x i8>, <16 x i8>, <16 x i8>, <16 x i8>)
+define void @build_acc1(<512 x i1>* %ptr, <16 x i8> %vc) {
+; CHECK-LABEL: build_acc1:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vmr v3, v2
+; CHECK-NEXT:xxlor vs0, v2, v2
+; CHECK-NEXT:xxlor vs1, v3, v3
+; CHECK-NEXT:xxlor vs2, v2, v2
+; CHECK-NEXT:xxlor vs3, v3, v3
+; CHECK-NEXT:stxv vs0, 48(r3)
+; CHECK-NEXT:stxv vs1, 32(r3)
+; CHECK-NEXT:stxv vs2, 16(r3)
+; CHECK-NEXT:stxv vs3, 0(r3)
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: build_acc1:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:vmr v3, v2
+; CHECK-BE-NEXT:xxlor vs0, v2, v2
+; CHECK-BE-NEXT:xxlor vs1, v3, v3
+; CHECK-BE-NEXT:xxlor vs2, v2, v2
+; CHECK-BE-NEXT:xxlor vs3, v3, v3
+; CHECK-BE-NEXT:stxv vs1, 16(r3)
+; CHECK-BE-NEXT:stxv vs0, 0(r3)
+; CHECK-BE-NEXT:stxv vs3, 48(r3)
+; CHECK-BE-NEXT:stxv vs2, 32(r3)
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = tail call <512 x i1> @llvm.ppc.mma.build.acc(<16 x i8> %vc, <16 x i8> %vc, <16 x i8> %vc, <16 x i8> %vc)
+  store <512 x i1> %0, <512 x i1>* %ptr, align 64
+  ret void
+}
+
+; build_acc
+define void @build_acc2(<512 x i1>* %ptr, <16 x i8> %in1, <16 x i8> %i

[PATCH] D108320: Add semantic token modifier for non-const reference parameter

2021-08-23 Thread Tom Praschan via Phabricator via cfe-commits

tom-anders marked 12 inline comments as done.
tom-anders added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:314
 //   (these tend to be vague, like Type or Unknown)
+// - Resolved tokens (i.e. without the "dependent-name" modifier) with kind
+//   "Unknown" are less reliable than resolved tokens with other kinds

nridge wrote:
> sammccall wrote:
> > nridge wrote:
> > > We should consider the case where a dependent name is passed by non-const 
> > > reference, for example:
> > > 
> > > ```
> > > void increment_counter(int&);
> > > 
> > > template 
> > > void bar() {
> > >increment_counter(T::static_counter);
> > > }
> > > ```
> > > 
> > > This case does not work yet with the current patch (the dependent name is 
> > > a `DependentScopeDeclRefExpr` rather than a `DeclRefExpr`), but we'll 
> > > want to make it work in the future.
> > > 
> > > With the conflict resolution logic in this patch, the `Unknown` token 
> > > kind from `highlightPassedByNonConstReference()` will be chosen over the 
> > > dependent token kind.
> > > 
> > > As it happens, the dependent token kind for expressions is also `Unknown` 
> > > so it doesn't matter, but perhaps we shouldn't be relying on this. 
> > > Perhaps the following would make more sense:
> > > 
> > > 1. a token with `Unknown` as the kind has the lowest priority
> > > 2. then a token with the `DependentName` modifier (next lowest)
> > > 3. then everything else?
> > The conflict-resolution idea is subtle (and IME hard to debug). I'm wary of 
> > overloading it by deliberately introducing "conflicts" that should actually 
> > be merged. Did you consider the idea of tracking extra modifiers separately 
> > and merging them in at the end?
> > 
> > ---
> > 
> > BTW: we're stretching the meaning of `Unknown` here. There are two subtly 
> > different concepts:
> >  - clangd happens not to have determined the kind of this token, e.g. 
> > because we missed a case (uses in this patch)
> >  - clangd has determined that per C++ rules the kind of token is ambiguous 
> > (uses prior to this patch)
> > Call me weird, but I have "Unknown" highlighted in bright orange in my 
> > editor, because I want to know about the second case :-)
> I don't have a strong opinion on the options here, just wanted to chime in 
> and say I also highlight `Unknown` prominently for similar reasons :)
I switched to @sammccall's idea of having a map, I agree that 
it feels more natural than the previous version



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:514
+  bool VisitCallExpr(CallExpr *E) {
+// Highlighting parameters passed by non-const reference does not really
+// make sence for these

sammccall wrote:
> CXXOperatorCallExpr seems to make sense to me for the most part:
>  - functor calls are CXXOperatorCallExpr
>  - if `x + y` mutates y, I want to know that
> 
> There are some exceptions though:
>   - the functor object itself is more like the function callee, and to be 
> consistent we shouldn't highlight it
>   - highlighting `x` in `x += y` is weird
>   - `a << b` is a weird ambiguous case ("stream" vs "shift" want different 
> behavior)
> 
> I think these can be handled by choosing a minimum argument index to 
> highlight based on the operator type.
> 
> I think it makes sense to leave operators out of scope for this patch, but 
> IMO should be a "FIXME" rather than a "let's never do this" :-)
Agreed, added a FIXME



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:542
+// Is this parameter passed by non-const reference?
+if (T->isLValueReferenceType() && !isConst(T)) {
+  if (auto *Arg = GetArgExprAtIndex(I)) {

sammccall wrote:
> nridge wrote:
> > I think there are some edge cases where `isConst()` doesn't do what we want.
> > 
> > For example, I think for a parameter of type `const int*&`, it will return 
> > `true` (and thus we will **not** highlight the corresponding argument), 
> > even thus this is actually a non-const reference.
> > 
> > So, we may want to use a dedicated function that specifically handles 
> > reference-related logic only.
> > 
> > (This probably also makes a good test case.)
> Yeah this is the core of this modifier, worth being precise and explicit 
> here. I think we want to match only reference types where the inner type is 
> not top-level const.
> 
> I think we should also conservatively forbid the inner type from being 
> *dependent*. Consider the following function:
> 
> ```
> template 
> void foo(X& x) {
>   foo(x); // this call
> }
> ```
> 
> Locally, the recursive call looks like "mutable reference to dependent type". 
> But when instantiated, X may be `const int` and is in fact very likely to be 
> deduced that way in practice.
I adjusted the condition accordingly and added a few more test cases (including 
stuff like `const int*&`). 



Commen

[PATCH] D36850: [ThinLTO] Add norecurse function attribute propagation

2021-08-23 Thread Di Mo via Phabricator via cfe-commits

modimo updated this revision to Diff 368174.
modimo added a comment.

Minor test fixups


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D36850

Files:
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGen/thinlto-distributed-cfi.ll
  clang/test/CodeGen/thinlto-funcattr-prop.ll
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/GlobalValue.h
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/Transforms/IPO/FunctionAttrs.h
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/ModuleSummaryIndex.cpp
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/FunctionAttrs.cpp
  llvm/test/Assembler/thinlto-summary.ll
  llvm/test/ThinLTO/X86/deadstrip.ll
  llvm/test/ThinLTO/X86/dot-dumper.ll
  llvm/test/ThinLTO/X86/dot-dumper2.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-exported-internal.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-indirect.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-undefined.ll
  llvm/test/ThinLTO/X86/funcattrs-prop.ll
  llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
  llvm/test/ThinLTO/X86/function_entry_count.ll
  llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
  llvm/test/ThinLTO/X86/weak_externals.ll

Index: llvm/test/ThinLTO/X86/weak_externals.ll
===
--- llvm/test/ThinLTO/X86/weak_externals.ll
+++ llvm/test/ThinLTO/X86/weak_externals.ll
@@ -40,4 +40,3 @@
 define linkonce_odr dso_local dereferenceable(16) %struct.S* @_ZN9SingletonI1SE11getInstanceEv() #0 comdat align 2 {
   ret %struct.S* @_ZZN9SingletonI1SE11getInstanceEvE8instance
 }
-
Index: llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
===
--- llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
+++ llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
@@ -3,15 +3,17 @@
 ; verification error.
 ; RUN: opt -module-summary %s -o %t1.bc
 ; RUN: opt -module-summary %p/Inputs/linkonce_resolution_comdat.ll -o %t2.bc
-; RUN: llvm-lto -thinlto-action=run %t1.bc %t2.bc -exported-symbol=f -exported-symbol=g -thinlto-save-temps=%t3.
+; RUN: llvm-lto -thinlto-action=run -disable-thinlto-funcattrs=0 %t1.bc %t2.bc -exported-symbol=f -exported-symbol=g -thinlto-save-temps=%t3.
 
 ; RUN: llvm-dis %t3.0.3.imported.bc -o - | FileCheck %s --check-prefix=IMPORT1
 ; RUN: llvm-dis %t3.1.3.imported.bc -o - | FileCheck %s --check-prefix=IMPORT2
 ; Copy from first module is prevailing and converted to weak_odr, copy
 ; from second module is preempted and converted to available_externally and
 ; removed from comdat.
-; IMPORT1: define weak_odr i32 @f(i8* %0) unnamed_addr comdat($c1) {
-; IMPORT2: define available_externally i32 @f(i8* %0) unnamed_addr {
+; IMPORT1: define weak_odr i32 @f(i8* %0) unnamed_addr [[ATTR:#[0-9]+]] comdat($c1) {
+; IMPORT2: define available_externally i32 @f(i8* %0) unnamed_addr [[ATTR:#[0-9]+]] {
+
+; CHECK-DAG: attributes [[ATTR]] = { norecurse nounwind }
 
 ; RUN: llvm-nm -o - < %t1.bc.thinlto.o | FileCheck %s --check-prefix=NM1
 ; NM1: W f
Index: llvm/test/ThinLTO/X86/function_entry_count.ll
===
--- llvm/test/ThinLTO/X86/function_entry_count.ll
+++ llvm/test/ThinLTO/X86/function_entry_count.ll
@@ -2,7 +2,7 @@
 ; RUN: opt -thinlto-bc %p/Inputs/function_entry_count.ll -write-relbf-to-summary -thin-link-bitcode-file=%t2.thinlink.bc -o %t2.bc
 
 ; First perform the thin link on the normal bitcode file.
-; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps -thinlto-synthesize-entry-counts \
+; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps -disable-thinlto-funcattrs=0 -thinlto-synthesize-entry-counts \
 ; RUN: -r=%t1.bc,g, \
 ; RUN: -r=%t1.bc,f,px \
 ; RUN: -r=%t1.bc,h,px \
@@ -10,15 +10,16 @@
 ; RUN: -r=%t2.bc,g,px
 ; RUN: llvm-dis -o - %t.o.1.3.import.bc | FileCheck %s
 
-; RUN: llvm-lto -thinlto-action=run -thinlto-synthesize-entry-counts -exported-symbol=f \
+; RUN: llvm-lto -thinlto-action=run -disable-thinlto-funcattrs=0 -thinlto-synthesize-entry-counts -exported-symbol=f \
 ; RUN: -exported-symbol=g -exported-symbol=h -thinlto-save-temps=%t3. %t1.bc %t2.bc
 ; RUN: llvm-dis %t3.0.3.imported.bc -o - | FileCheck %s
 
-; CHECK: define void @h() !prof ![[PROF2:[0-9]+]]
-; CHECK: define void @f(i32{{.*}}) !prof ![[PROF1:[0-9]+]]
+; CHECK: define void @h() [[ATTR:#[0-9]+]] !prof ![[PROF2:[0-9]+]]
+; CHECK: define void @f(i32{{.*}}) [[ATTR:#[0-9]+]] !prof ![[PROF1:[0-9]+]]
 ; CHECK: define available_externally void @g() !prof ![[PROF2]]
 ; CHECK-DAG: ![[PROF1]] = !{!"synthetic_function_entry_count", i64 10}
 ; CHECK-D

[PATCH] D108525: Fix documentation and snippets for the handle attributes.

2021-08-23 Thread Paul Herman via Phabricator via cfe-commits

paulherman added a comment.

Thanks for the very prompt review! I'm afraid I no longer have permissions to 
submit --my last commit was in 2015 and I recall that I had SVN access, but 
many things have changed. Would it be possible to submit this on my behalf?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108525

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

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

2021-08-23 Thread Andrei Elovikov 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 rGf5c288948844: [NFC][clang] Use X86 Features declaration from 
X86TargetParser (authored by a.elovikov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

Files:
  clang/include/clang/Basic/X86Target.def
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/Support/X86TargetParser.def

Index: llvm/include/llvm/Support/X86TargetParser.def
===
--- llvm/include/llvm/Support/X86TargetParser.def
+++ llvm/include/llvm/Support/X86TargetParser.def
@@ -91,54 +91,59 @@
 X86_CPU_SUBTYPE(INTEL_COREI7_ROCKETLAKE, "rocketlake")
 #undef X86_CPU_SUBTYPE
 
-
-// This macro is used for cpu types present in compiler-rt/libgcc.
+// This macro is used for cpu types present in compiler-rt/libgcc. The third
+// parameter PRIORITY is as required by the attribute 'target' checking. Note
+// that not all are supported/prioritized by GCC, so synchronization with GCC's
+// implementation may require changing some existing values.
+//
+// We cannot just re-sort the list though because its order is dictated by the
+// order of bits in CodeGenFunction::GetX86CpuSupportsMask.
 #ifndef X86_FEATURE_COMPAT
-#define X86_FEATURE_COMPAT(ENUM, STR) X86_FEATURE(ENUM, STR)
+#define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY) X86_FEATURE(ENUM, STR)
 #endif
 
 #ifndef X86_FEATURE
 #define X86_FEATURE(ENUM, STR)
 #endif
 
-X86_FEATURE_COMPAT(CMOV,"cmov")
-X86_FEATURE_COMPAT(MMX, "mmx")
-X86_FEATURE_COMPAT(POPCNT,  "popcnt")
-X86_FEATURE_COMPAT(SSE, "sse")
-X86_FEATURE_COMPAT(SSE2,"sse2")
-X86_FEATURE_COMPAT(SSE3,"sse3")
-X86_FEATURE_COMPAT(SSSE3,   "ssse3")
-X86_FEATURE_COMPAT(SSE4_1,  "sse4.1")
-X86_FEATURE_COMPAT(SSE4_2,  "sse4.2")
-X86_FEATURE_COMPAT(AVX, "avx")
-X86_FEATURE_COMPAT(AVX2,"avx2")
-X86_FEATURE_COMPAT(SSE4_A,  "sse4a")
-X86_FEATURE_COMPAT(FMA4,"fma4")
-X86_FEATURE_COMPAT(XOP, "xop")
-X86_FEATURE_COMPAT(FMA, "fma")
-X86_FEATURE_COMPAT(AVX512F, "avx512f")
-X86_FEATURE_COMPAT(BMI, "bmi")
-X86_FEATURE_COMPAT(BMI2,"bmi2")
-X86_FEATURE_COMPAT(AES, "aes")
-X86_FEATURE_COMPAT(PCLMUL,  "pclmul")
-X86_FEATURE_COMPAT(AVX512VL,"avx512vl")
-X86_FEATURE_COMPAT(AVX512BW,"avx512bw")
-X86_FEATURE_COMPAT(AVX512DQ,"avx512dq")
-X86_FEATURE_COMPAT(AVX512CD,"avx512cd")
-X86_FEATURE_COMPAT(AVX512ER,"avx512er")
-X86_FEATURE_COMPAT(AVX512PF,"avx512pf")
-X86_FEATURE_COMPAT(AVX512VBMI,  "avx512vbmi")
-X86_FEATURE_COMPAT(AVX512IFMA,  "avx512ifma")
-X86_FEATURE_COMPAT(AVX5124VNNIW,"avx5124vnniw")
-X86_FEATURE_COMPAT(AVX5124FMAPS,"avx5124fmaps")
-X86_FEATURE_COMPAT(AVX512VPOPCNTDQ, "avx512vpopcntdq")
-X86_FEATURE_COMPAT(AVX512VBMI2, "avx512vbmi2")
-X86_FEATURE_COMPAT(GFNI,"gfni")
-X86_FEATURE_COMPAT(VPCLMULQDQ,  "vpclmulqdq")
-X86_FEATURE_COMPAT(AVX512VNNI,  "avx512vnni")
-X86_FEATURE_COMPAT(AVX512BITALG,"avx512bitalg")
-X86_FEATURE_COMPAT(AVX512BF16,  "avx512bf16")
-X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect")
+X86_FEATURE_COMPAT(CMOV,"cmov",  0)
+X86_FEATURE_COMPAT(MMX, "mmx",   1)
+X86_FEATURE_COMPAT(POPCNT,  "popcnt",9)
+X86_FEATURE_COMPAT(SSE, "sse",   2)
+X86_FEATURE_COMPAT(SSE2,"sse2",  3)
+X86_FEATURE_COMPAT(SSE3,"sse3",  4)
+X86_FEATURE_COMPAT(SSSE3,   "ssse3", 5)
+X86_FEATURE_COMPAT(SSE4_1,  "sse4.1",7)
+X86_FEATURE_COMPAT(SSE4_2,  "sse4.2",8)
+X86_FEATURE_COMPAT(AVX, "avx",   12)
+X86_FEATURE_COMPAT(AVX2,"avx2",  18)
+X86_FEATURE_COMPAT(SSE4_A,  "sse4a", 6)
+X86_FEATURE_COMPAT(FMA4,"fma4",  14)
+X86_FEATURE_COMPAT(XOP, "xop",   15)
+X86_FEATURE_COMPAT(FMA, "fma",   16)
+X86_FEATURE_COMPAT(AVX512F, "avx512f",   19)
+X86_FEATURE_COMPAT(BMI, "bmi",   13)
+X86_FEATURE_COMPAT(BMI2,"bmi2",  17)
+X86_FEATURE_COMPAT(AES, "aes",   10)
+X86_FEATURE_COMPAT(PCLMUL,  "pclmul",11)
+X86_FEATURE_COMPAT(AVX512VL,"avx512vl",  20)
+X86_FEATURE_COMPAT(AVX512BW,"avx512bw",  21)
+X86_FEATURE_COMPAT(AVX512DQ,"avx512dq",  22)
+X86_FEATURE_COMPAT(AVX51

[clang] f5c2889 - [NFC][clang] Use X86 Features declaration from X86TargetParser

2021-08-23 Thread Andrei Elovikov via cfe-commits


Author: Andrei Elovikov
Date: 2021-08-23T12:30:28-07:00
New Revision: f5c28894884488d236d66b766fe5da557cd1ac88

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

LOG: [NFC][clang] Use X86 Features declaration from X86TargetParser

...instead of redeclaring them in clang's own X86Target.def. They were already
required to be in sync (IIUC), so no reason to maintain two identical lists.

Reviewed By: erichkeane, craig.topper

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

Added: 


Modified: 
clang/include/clang/Basic/X86Target.def
clang/lib/Basic/Targets/X86.cpp
clang/lib/CodeGen/CGBuiltin.cpp
llvm/include/llvm/Support/X86TargetParser.def

Removed: 




diff  --git a/clang/include/clang/Basic/X86Target.def 
b/clang/include/clang/Basic/X86Target.def
index 70f3879f33a14..3a5d5b2183f2d 100644
--- a/clang/include/clang/Basic/X86Target.def
+++ b/clang/include/clang/Basic/X86Target.def
@@ -11,10 +11,6 @@
 //
 
//===--===//
 
-#ifndef FEATURE
-#define FEATURE(ENUM)
-#endif
-
 #ifndef CPU_SPECIFIC
 #define CPU_SPECIFIC(NAME, MANGLING, FEATURES)
 #endif
@@ -23,50 +19,6 @@
 #define CPU_SPECIFIC_ALIAS(NEW_NAME, NAME)
 #endif
 
-// List of CPU Supports features in order.  These need to remain in the order
-// required by attribute 'target' checking.  Note that not all are supported/
-// prioritized by GCC, so synchronization with GCC's implementation may require
-// changing some existing values.
-FEATURE(FEATURE_CMOV)
-FEATURE(FEATURE_MMX)
-FEATURE(FEATURE_SSE)
-FEATURE(FEATURE_SSE2)
-FEATURE(FEATURE_SSE3)
-FEATURE(FEATURE_SSSE3)
-FEATURE(FEATURE_SSE4_A)
-FEATURE(FEATURE_SSE4_1)
-FEATURE(FEATURE_SSE4_2)
-FEATURE(FEATURE_POPCNT)
-FEATURE(FEATURE_AES)
-FEATURE(FEATURE_PCLMUL)
-FEATURE(FEATURE_AVX)
-FEATURE(FEATURE_BMI)
-FEATURE(FEATURE_FMA4)
-FEATURE(FEATURE_XOP)
-FEATURE(FEATURE_FMA)
-FEATURE(FEATURE_BMI2)
-FEATURE(FEATURE_AVX2)
-FEATURE(FEATURE_AVX512F)
-FEATURE(FEATURE_AVX512VL)
-FEATURE(FEATURE_AVX512BW)
-FEATURE(FEATURE_AVX512DQ)
-FEATURE(FEATURE_AVX512CD)
-FEATURE(FEATURE_AVX512ER)
-FEATURE(FEATURE_AVX512PF)
-FEATURE(FEATURE_AVX512VBMI)
-FEATURE(FEATURE_AVX512IFMA)
-FEATURE(FEATURE_AVX5124VNNIW)
-FEATURE(FEATURE_AVX5124FMAPS)
-FEATURE(FEATURE_AVX512VPOPCNTDQ)
-FEATURE(FEATURE_AVX512VBMI2)
-FEATURE(FEATURE_GFNI)
-FEATURE(FEATURE_VPCLMULQDQ)
-FEATURE(FEATURE_AVX512VNNI)
-FEATURE(FEATURE_AVX512BITALG)
-FEATURE(FEATURE_AVX512BF16)
-FEATURE(FEATURE_AVX512VP2INTERSECT)
-
-
 // FIXME: When commented out features are supported in LLVM, enable them here.
 CPU_SPECIFIC("generic", 'A', "")
 CPU_SPECIFIC("pentium", 'B', "")
@@ -105,6 +57,3 @@ CPU_SPECIFIC("knm", 'j', 
"+cmov,+mmx,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,+mo
 
 #undef CPU_SPECIFIC_ALIAS
 #undef CPU_SPECIFIC
-#undef PROC_64_BIT
-#undef PROC_32_BIT
-#undef FEATURE

diff  --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index 84bb7882621ec..c00e74a40 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -18,6 +18,7 @@
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/X86TargetParser.h"
+#include 
 
 namespace clang {
 namespace targets {
@@ -1041,14 +1042,16 @@ bool X86TargetInfo::hasFeature(StringRef Feature) const 
{
 // X86TargetInfo::hasFeature for a somewhat comprehensive list).
 bool X86TargetInfo::validateCpuSupports(StringRef FeatureStr) const {
   return llvm::StringSwitch(FeatureStr)
-#define X86_FEATURE_COMPAT(ENUM, STR) .Case(STR, true)
+#define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY) .Case(STR, true)
 #include "llvm/Support/X86TargetParser.def"
   .Default(false);
 }
 
 static llvm::X86::ProcessorFeatures getFeature(StringRef Name) {
   return llvm::StringSwitch(Name)
-#define X86_FEATURE_COMPAT(ENUM, STR) .Case(STR, llvm::X86::FEATURE_##ENUM)
+#define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY)
\
+  .Case(STR, llvm::X86::FEATURE_##ENUM)
+
 #include "llvm/Support/X86TargetParser.def"
   ;
   // Note, this function should only be used after ensuring the value is
@@ -1056,15 +1059,28 @@ static llvm::X86::ProcessorFeatures 
getFeature(StringRef Name) {
 }
 
 static unsigned getFeaturePriority(llvm::X86::ProcessorFeatures Feat) {
-  enum class FeatPriority {
-#define FEATURE(FEAT) FEAT,
-#include "clang/Basic/X86Target.def"
+#ifndef NDEBUG
+  // Check that priorities are set properly in the .def file. We expect that
+  // "compat" features are assigned non-duplicate consecutive priorities
+  // starting from zero (0, 1, ..., num_features - 1).
+#define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY) PRIORITY,
+  unsigned Priorities[] = {
+#include "llvm/Support/X86TargetParser.def"
+  std::numeric_limits::m

[PATCH] D54880: Ignore gcc's stack-clash-protection flag

2021-08-23 Thread Ed Maste via Phabricator via cfe-commits

emaste added a comment.

Superseded by e67cbac81211d40332a79d98c9d5953624cc1202 
 (D68720 
)


Repository:
  rC Clang

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

https://reviews.llvm.org/D54880

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

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

In D101960#2960657 , @jdoerfert wrote:

> Do I understand correctly that adding runpath to libomp.so will help it find 
> libomptarget.so *and* still allows users to use LD_LIBRARY_PATH to make sure 
> a different libomptarget.so is found?
>
> If the above is the case, can't we do the same for clang?
>
> Asked differently, how does clang find things like compiler-rt?

If we set runpath on libomp.so it'll be able to find libomptarget.so without 
environment variables. If the user sets LD_LIBRARY_PATH, a libomptarget.so on 
that path will be used instead.

Clang can definitely set rpath or runpath on the user binary, that's what 
addOpenMPRuntimeSpecificRPath does. That way no environment variables are 
needed. The set of options are then:

- User has otherwise set nothing on the binary, either rpath or runpath works 
great
- User has set runpath and we set runpath, linker should put both in. Not sure 
which will go first. Probably fine
- User has set rpath and we set runpath. Linker will ignore the user rpath, so 
we've probably broken the binary
- User has set runpath and we set rpath. Harmless, but we'll be ignored

compiler-rt is different because it's statically linked into every binary and 
every shared library, and is carefully written so that it doesn't matter if the 
final running system has loads of copies of it as a result. If we statically 
linked our libraries none of the above would be an issue but developers (and I 
suppose users) would no longer be able to pick and choose at runtime.

There might be a linker flag (which might even exist on all the linkers users 
might use) to control the behaviour where any runpath means ignore all rpath. 
What we'd really like is to set r(un)path on the user binary unless something 
else is already doing so, but I don't think we can have that information.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D108571: [clang] allow -fstack-clash-protection on FreeBSD

2021-08-23 Thread Ed Maste via Phabricator via cfe-commits

emaste added a comment.

We make this change in FreeBSD's in-tree Clang about 9 months ago 
(https://reviews.freebsd.org/D27366)


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

https://reviews.llvm.org/D108571

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

[PATCH] D108571: [clang] allow -fstack-clash-protection on FreeBSD

2021-08-23 Thread Ed Maste via Phabricator via cfe-commits

emaste created this revision.
emaste added reviewers: serge-sans-paille, craig.topper, dim.
Herald added subscribers: krytarowski, arichardson.
emaste requested review of this revision.

`-fstack-clash-protection` was added in Clang commit e67cbac81211 
 but was 
enabled only on Linux.  Allow it on FreeBSD as well, as it works fine.


https://reviews.llvm.org/D108571

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/stack-clash-protection.c


Index: clang/test/Driver/stack-clash-protection.c
===
--- clang/test/Driver/stack-clash-protection.c
+++ clang/test/Driver/stack-clash-protection.c
@@ -5,6 +5,7 @@
 // SCP-i386-NO-NOT: "-fstack-clash-protection"
 
 // RUN: %clang -target x86_64-scei-linux -fstack-clash-protection -### %s 2>&1 
| FileCheck %s -check-prefix=SCP-x86
+// RUN: %clang -target x86_64-unknown-freebsd -fstack-clash-protection -### %s 
2>&1 | FileCheck %s -check-prefix=SCP-x86
 // SCP-x86: "-fstack-clash-protection"
 
 // RUN: %clang -target armv7k-apple-linux -fstack-clash-protection -### %s 
2>&1 | FileCheck %s -check-prefix=SCP-armv7
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3198,7 +3198,7 @@
  ArgStringList &CmdArgs) {
   const llvm::Triple &EffectiveTriple = TC.getEffectiveTriple();
 
-  if (!EffectiveTriple.isOSLinux())
+  if (!EffectiveTriple.isOSFreeBSD() && !EffectiveTriple.isOSLinux())
 return;
 
   if (!EffectiveTriple.isX86() && !EffectiveTriple.isSystemZ() &&


Index: clang/test/Driver/stack-clash-protection.c
===
--- clang/test/Driver/stack-clash-protection.c
+++ clang/test/Driver/stack-clash-protection.c
@@ -5,6 +5,7 @@
 // SCP-i386-NO-NOT: "-fstack-clash-protection"
 
 // RUN: %clang -target x86_64-scei-linux -fstack-clash-protection -### %s 2>&1 | FileCheck %s -check-prefix=SCP-x86
+// RUN: %clang -target x86_64-unknown-freebsd -fstack-clash-protection -### %s 2>&1 | FileCheck %s -check-prefix=SCP-x86
 // SCP-x86: "-fstack-clash-protection"
 
 // RUN: %clang -target armv7k-apple-linux -fstack-clash-protection -### %s 2>&1 | FileCheck %s -check-prefix=SCP-armv7
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3198,7 +3198,7 @@
  ArgStringList &CmdArgs) {
   const llvm::Triple &EffectiveTriple = TC.getEffectiveTriple();
 
-  if (!EffectiveTriple.isOSLinux())
+  if (!EffectiveTriple.isOSFreeBSD() && !EffectiveTriple.isOSLinux())
 return;
 
   if (!EffectiveTriple.isX86() && !EffectiveTriple.isSystemZ() &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107850: [asan] Implemented intrinsic for the custom calling convention similar used by HWASan for X86.

2021-08-23 Thread Kirill Stoimenov via Phabricator via cfe-commits

kstoimenov added inline comments.



Comment at: llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h:150
 
+namespace AsanAccessInfo {
+

vitalybuka wrote:
> kstoimenov wrote:
> > vitalybuka wrote:
> > > It's not how enums described here 
> > > https://llvm.org/docs/CodingStandards.html#id43
> > > Also it's common to use enum class nowerdays.
> > > 
> > > 
> > > However this one does not need to be enum and just "constexpr size_t"
> > I wanted to be as close as possible to the HWASan style. Please let me know 
> > if you want me to change it. 
> They are quite unrelated, no need to violate coding style to match them.
> 
> Also packing and unpacking implementation unnecessary separated.
> Maybe something like this and keep bit arithmetic in a single cpp file:
> ```
> struct AsanAccessInfo {
>   uint8_t AccessSize;
>   bool CompileKernel;
>   bool IsWrite;
> ...
> 
>   explicit AsanAccessInfo(int64_t packed);
>   int64_t Pack() const;
> }
> ```
> 
> Also math a little bit simpler if 4bit field is the last
I like the idea. Keeps things well encapsulated in the implementation file. 
Done. 



Comment at: llvm/lib/Target/X86/X86MCInstLower.cpp:1426
+  OutStreamer->emitInstruction(MCInstBuilder(X86::AND32ri8)
+   .addReg(X86::ECX)
+   .addReg(X86::ECX)

vitalybuka wrote:
> what is in ECX register here?
Should be NoRegister. Done.



Comment at: llvm/lib/Target/X86/X86MCInstLower.cpp:1561-1564
+bool CompileKernel = (AccessInfo >> ASanAccessInfo::CompileKernelShift) & 
1;
+int32_t AccessSizeIndex =
+(AccessInfo >> ASanAccessInfo::AccessSizeShift) & 0xf;
+bool IsWrite = (AccessInfo >> ASanAccessInfo::IsWriteShift) & 1;

vitalybuka wrote:
> as-is shifts are in the header, and masks are here, which is not nice.
Encapsulated in the implementation file as you have recommended. 



Comment at: llvm/test/CodeGen/X86/asan-check-memaccess-add.ll:6
+define void @load1(i8* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load1_rn[[RN1:.*]]
+; CHECK:  callq   __asan_check_store1_rn[[RN1]]

vitalybuka wrote:
> should we also check how we load registers before callq?
The issue is that there is no load instruction, because the registers are 
implied.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107850

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

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

2021-08-23 Thread Andrei Elovikov via Phabricator via cfe-commits

a.elovikov updated this revision to Diff 368164.
a.elovikov added a comment.

Address Erich's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

Files:
  clang/include/clang/Basic/X86Target.def
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/Support/X86TargetParser.def

Index: llvm/include/llvm/Support/X86TargetParser.def
===
--- llvm/include/llvm/Support/X86TargetParser.def
+++ llvm/include/llvm/Support/X86TargetParser.def
@@ -91,54 +91,59 @@
 X86_CPU_SUBTYPE(INTEL_COREI7_ROCKETLAKE, "rocketlake")
 #undef X86_CPU_SUBTYPE
 
-
-// This macro is used for cpu types present in compiler-rt/libgcc.
+// This macro is used for cpu types present in compiler-rt/libgcc. The third
+// parameter PRIORITY is as required by the attribute 'target' checking. Note
+// that not all are supported/prioritized by GCC, so synchronization with GCC's
+// implementation may require changing some existing values.
+//
+// We cannot just re-sort the list though because its order is dictated by the
+// order of bits in CodeGenFunction::GetX86CpuSupportsMask.
 #ifndef X86_FEATURE_COMPAT
-#define X86_FEATURE_COMPAT(ENUM, STR) X86_FEATURE(ENUM, STR)
+#define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY) X86_FEATURE(ENUM, STR)
 #endif
 
 #ifndef X86_FEATURE
 #define X86_FEATURE(ENUM, STR)
 #endif
 
-X86_FEATURE_COMPAT(CMOV,"cmov")
-X86_FEATURE_COMPAT(MMX, "mmx")
-X86_FEATURE_COMPAT(POPCNT,  "popcnt")
-X86_FEATURE_COMPAT(SSE, "sse")
-X86_FEATURE_COMPAT(SSE2,"sse2")
-X86_FEATURE_COMPAT(SSE3,"sse3")
-X86_FEATURE_COMPAT(SSSE3,   "ssse3")
-X86_FEATURE_COMPAT(SSE4_1,  "sse4.1")
-X86_FEATURE_COMPAT(SSE4_2,  "sse4.2")
-X86_FEATURE_COMPAT(AVX, "avx")
-X86_FEATURE_COMPAT(AVX2,"avx2")
-X86_FEATURE_COMPAT(SSE4_A,  "sse4a")
-X86_FEATURE_COMPAT(FMA4,"fma4")
-X86_FEATURE_COMPAT(XOP, "xop")
-X86_FEATURE_COMPAT(FMA, "fma")
-X86_FEATURE_COMPAT(AVX512F, "avx512f")
-X86_FEATURE_COMPAT(BMI, "bmi")
-X86_FEATURE_COMPAT(BMI2,"bmi2")
-X86_FEATURE_COMPAT(AES, "aes")
-X86_FEATURE_COMPAT(PCLMUL,  "pclmul")
-X86_FEATURE_COMPAT(AVX512VL,"avx512vl")
-X86_FEATURE_COMPAT(AVX512BW,"avx512bw")
-X86_FEATURE_COMPAT(AVX512DQ,"avx512dq")
-X86_FEATURE_COMPAT(AVX512CD,"avx512cd")
-X86_FEATURE_COMPAT(AVX512ER,"avx512er")
-X86_FEATURE_COMPAT(AVX512PF,"avx512pf")
-X86_FEATURE_COMPAT(AVX512VBMI,  "avx512vbmi")
-X86_FEATURE_COMPAT(AVX512IFMA,  "avx512ifma")
-X86_FEATURE_COMPAT(AVX5124VNNIW,"avx5124vnniw")
-X86_FEATURE_COMPAT(AVX5124FMAPS,"avx5124fmaps")
-X86_FEATURE_COMPAT(AVX512VPOPCNTDQ, "avx512vpopcntdq")
-X86_FEATURE_COMPAT(AVX512VBMI2, "avx512vbmi2")
-X86_FEATURE_COMPAT(GFNI,"gfni")
-X86_FEATURE_COMPAT(VPCLMULQDQ,  "vpclmulqdq")
-X86_FEATURE_COMPAT(AVX512VNNI,  "avx512vnni")
-X86_FEATURE_COMPAT(AVX512BITALG,"avx512bitalg")
-X86_FEATURE_COMPAT(AVX512BF16,  "avx512bf16")
-X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect")
+X86_FEATURE_COMPAT(CMOV,"cmov",  0)
+X86_FEATURE_COMPAT(MMX, "mmx",   1)
+X86_FEATURE_COMPAT(POPCNT,  "popcnt",9)
+X86_FEATURE_COMPAT(SSE, "sse",   2)
+X86_FEATURE_COMPAT(SSE2,"sse2",  3)
+X86_FEATURE_COMPAT(SSE3,"sse3",  4)
+X86_FEATURE_COMPAT(SSSE3,   "ssse3", 5)
+X86_FEATURE_COMPAT(SSE4_1,  "sse4.1",7)
+X86_FEATURE_COMPAT(SSE4_2,  "sse4.2",8)
+X86_FEATURE_COMPAT(AVX, "avx",   12)
+X86_FEATURE_COMPAT(AVX2,"avx2",  18)
+X86_FEATURE_COMPAT(SSE4_A,  "sse4a", 6)
+X86_FEATURE_COMPAT(FMA4,"fma4",  14)
+X86_FEATURE_COMPAT(XOP, "xop",   15)
+X86_FEATURE_COMPAT(FMA, "fma",   16)
+X86_FEATURE_COMPAT(AVX512F, "avx512f",   19)
+X86_FEATURE_COMPAT(BMI, "bmi",   13)
+X86_FEATURE_COMPAT(BMI2,"bmi2",  17)
+X86_FEATURE_COMPAT(AES, "aes",   10)
+X86_FEATURE_COMPAT(PCLMUL,  "pclmul",11)
+X86_FEATURE_COMPAT(AVX512VL,"avx512vl",  20)
+X86_FEATURE_COMPAT(AVX512BW,"avx512bw",  21)
+X86_FEATURE_COMPAT(AVX512DQ,"avx512dq",  22)
+X86_FEATURE_COMPAT(AVX512CD,"avx512cd",  23)
+X86_FEATURE_COMPAT(AVX512ER,"avx512er",  24)
+X86_FEATURE_COMPAT(AVX512PF,"avx5

[PATCH] D107850: [asan] Implemented intrinsic for the custom calling convention similar used by HWASan for X86.

2021-08-23 Thread Kirill Stoimenov via Phabricator via cfe-commits

kstoimenov updated this revision to Diff 368162.
kstoimenov marked 4 inline comments as done.
kstoimenov added a comment.

Addressed the comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107850

Files:
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
  llvm/lib/Target/X86/X86AsmPrinter.cpp
  llvm/lib/Target/X86/X86AsmPrinter.h
  llvm/lib/Target/X86/X86InstrCompiler.td
  llvm/lib/Target/X86/X86MCInstLower.cpp
  llvm/lib/Target/X86/X86RegisterInfo.td
  llvm/test/CodeGen/X86/asan-check-memaccess-add.ll
  llvm/test/CodeGen/X86/asan-check-memaccess-or.ll
  llvm/tools/llvm-exegesis/CMakeLists.txt

Index: llvm/tools/llvm-exegesis/CMakeLists.txt
===
--- llvm/tools/llvm-exegesis/CMakeLists.txt
+++ llvm/tools/llvm-exegesis/CMakeLists.txt
@@ -1,4 +1,5 @@
 set(LLVM_LINK_COMPONENTS
+  Instrumentation
   MC
   MCParser
   Support
Index: llvm/test/CodeGen/X86/asan-check-memaccess-or.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/asan-check-memaccess-or.ll
@@ -0,0 +1,253 @@
+; RUN: llc < %s | FileCheck %s
+
+target triple = "x86_64-pc-win"
+
+define void @load1(i8* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load1_rn[[RN1:.*]]
+; CHECK:  callq   __asan_check_store1_rn[[RN1]]
+; CHECK-NEXT: retq
+  call void @llvm.asan.check.memaccess(i8* %x, i32 0)
+  call void @llvm.asan.check.memaccess(i8* %x, i32 32)
+  ret void
+}
+
+define void @load2(i16* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load2_rn[[RN2:.*]]
+; CHECK:  callq   __asan_check_store2_rn[[RN2]]
+; CHECK-NEXT: retq
+  %1 = ptrtoint i16* %x to i64
+  %2 = bitcast i16* %x to i8*
+  call void @llvm.asan.check.memaccess(i8* %2, i32 2)
+  call void @llvm.asan.check.memaccess(i8* %2, i32 34)
+  ret void
+}
+
+define void @load4(i32* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load4_rn[[RN4:.*]]
+; CHECK:  callq   __asan_check_store4_rn[[RN4]]
+; CHECK-NEXT: retq
+  %1 = ptrtoint i32* %x to i64
+  %2 = bitcast i32* %x to i8*
+  call void @llvm.asan.check.memaccess(i8* %2, i32 4)
+  call void @llvm.asan.check.memaccess(i8* %2, i32 36)
+  ret void
+}
+define void @load8(i64* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load8_rn[[RN8:.*]]
+; CHECK:  callq   __asan_check_store8_rn[[RN8]]
+; CHECK-NEXT: retq
+  %1 = ptrtoint i64* %x to i64
+  %2 = bitcast i64* %x to i8*
+  call void @llvm.asan.check.memaccess(i8* %2, i32 6)
+  call void @llvm.asan.check.memaccess(i8* %2, i32 38)
+  ret void
+}
+
+define void @load16(i128* nocapture readonly %x) {
+; CHECK:  callq   __asan_check_load16_rn[[RN16:.*]]
+; CHECK:  callq   __asan_check_store16_rn[[RN16]]
+; CHECK-NEXT: retq
+  %1 = ptrtoint i128* %x to i64
+  %2 = bitcast i128* %x to i8*
+  call void @llvm.asan.check.memaccess(i8* %2, i32 8)
+  call void @llvm.asan.check.memaccess(i8* %2, i32 40)
+  ret void
+}
+
+; CHECK:  .type   __asan_check_load1_rn[[RN1]],@function
+; CHECK-NEXT: .weak   __asan_check_load1_rn[[RN1]]
+; CHECK-NEXT: .hidden __asan_check_load1_rn[[RN1]]
+; CHECK-NEXT: __asan_check_load1_rn[[RN1]]:
+; CHECK-NEXT: movq[[REG:.*]], %r8
+; CHECK-NEXT: shrq$3, %r8
+; CHECK-NEXT: orq $17592186044416, %r8{{.*}}
+; CHECK-NEXT: movb(%r8), %r8b
+; CHECK-NEXT: testb   %r8b, %r8b
+; CHECK-NEXT: jne [[EXTRA:.*]]
+; CHECK-NEXT: [[RET:.*]]:
+; CHECK-NEXT: retq
+; CHECK-NEXT: [[EXTRA]]:
+; CHECK-NEXT: pushq   %rcx
+; CHECK-NEXT: movq[[REG]], %rcx
+; CHECK-NEXT: andl$7, %ecx
+; CHECK-NEXT: cmpl%r8d, %ecx
+; CHECK-NEXT: popq%rcx
+; CHECK-NEXT: jl  [[RET]]
+; CHECK-NEXT: movq[[REG:.*]], %rdi
+; CHECK-NEXT: jmp __asan_report_load1
+
+; CHECK:  .type   __asan_check_load2_rn[[RN2]],@function
+; CHECK-NEXT: .weak   __asan_check_load2_rn[[RN2]]
+; CHECK-NEXT: .hidden __asan_check_load2_rn[[RN2]]
+; CHECK-NEXT: __asan_check_load2_rn[[RN2]]:
+; CHECK-NEXT: movq[[REG:.*]], %r8
+; CHECK-NEXT: shrq$3, %r8
+; CHECK-NEXT: orq $17592186044416, %r8{{.*}}
+; CHECK-NEXT: movb(%r8), %r8b
+; CHECK-NEXT: testb   %r8b, %r8b
+; CHECK-NEXT: jne [[EXTRA:.*]]
+; CHECK-NEXT: [[RET:.*]]:
+; CHECK-NEXT: retq
+; CHECK-NEXT: [[EXTRA]]:
+; CHECK-NEXT: pushq   %rcx
+; CHECK-NEXT: movq[[REG]], %rcx
+; CHECK-NEXT: andl$7, %ecx
+; CHECK-NEXT: addl$1, %ecx
+; CHECK-NEXT: cmpl%r8d, %ecx
+; CHECK-NEXT: popq%rcx
+; CHECK-NEXT:

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added a comment.

Do I understand correctly that adding runpath to libomp.so will help it find 
libomptarget.so *and* still allows users to use LD_LIBRARY_PATH to make sure a 
different libomptarget.so is found?

If the above is the case, can't we do the same for clang?

Asked differently, how does clang find things like compiler-rt?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:648
 
+void tools::addOpenMPRuntimeSpecificRPath(const ToolChain &TC,
+  const ArgList &Args,

JonChesterfield wrote:
> protze.joachim wrote:
> > JonChesterfield wrote:
> > > lebedev.ri wrote:
> > > > JonChesterfield wrote:
> > > > > Similar to other functions in this file, derived from aomp (by 
> > > > > deleting some stuff for finding a debug version of the library)
> > > > > 
> > > > > I can make my peace with runpath instead if people are keen to 
> > > > > override this with LD_LIBRARY_PATH. The rest of clang's toolchains 
> > > > > wire things up with rpath but that doesn't mean we have to make the 
> > > > > same choice here.
> > > > I think it would be a shame if this would be the only thing
> > > > that *doesn't* support being overriden with `LD_LIBRARY_PATH`.
> > > > I'm not sure about `libomptarget`, but it i think it would be good to 
> > > > keep such possibility for `libomp`.
> > > The search order is 'rpath' then 'LD_LIBRARY_PATH' then 'runpath'. 
> > > Presently we set no default at all and require the user to set 
> > > LD_LIBRARY_PATH or manually link the right library. So using runpath here 
> > > is backwards compatible, in that all the scripts out there that use 
> > > LD_LIBRARY_PATH will continue to work. That may force our hand here.
> > Especially for debugging, I like the ability to exchange the OpenMP 
> > runtimes by adding the debugging build of the runtimes to LD_LIBRARY_PATH 
> > without needing to relink the application, so I'd also prefer runpath.
> > 
> > 
> > In the manpage of ld I found: 
> > > For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of 
> > > a shared library are searched for shared libraries needed by it. The 
> > > "DT_RPATH" entries are ignored if "DT_RUNPATH" entries exist.
> > 
> > Does this mean, that adding a runpath here will lead to ignoring the other 
> > rpath entries? Or does this only affect linking shared libraries and not 
> > linking an application?
> > 
> The internet also claims rpath is now deprecated, which I suppose is 
> consistent with ignoring rpath when both are present. So it seems likely that 
> setting runpath here will clobber any (possibly deprecated) rpath that is 
> added elsewhere.
> 
> I'm not sure what the right path is from there. People might set rpath on 
> openmp executables, and we shouldn't clobber that if they do. There may be a 
> linker flag along the lines of 'set runpath unless there is already an rpath 
> requested'.
> 
> I think it's a bug in the linker to ignore one when the other is present but 
> backwards compatibility will render that a feature.
> 
> There is a halfway step where we set rpath (or runpath) on libomp.so so that 
> it can find libomptarget, as we own the libomp.so that is being built at the 
> time, but that doesn't really solve the problem.
> 
> I'd note that compiler-rt is always statically linked, which seems a good 
> idea for a compiler runtime, but would totally thwart the desire to replace 
> it with some other runtime without relinking.
> 
> We could embed rpath, which gets definitely working out of the box behaviour, 
> with a compiler flag to leave that off for development builds that want 
> dynamic control over the pieces. Where I see that rpath is 'deprecated', but 
> also that the runpath behaviour of clobbering an unrelated rpath makes it 
> unusable in this context.
Mutating the binary to let it find libomp.so (like this, or with runpath) is 
convenient for users who want that and very inconvenient for those who are 
using rpath for some other purpose. What we could do is change the build script 
for libomp.so to add a relative runpath to let it find libomptarget.so. That 
makes the test infra slightly simpler.

It also means a user only has to arrange for their binary to find libomp.so on 
their own without worrying about the other pieces, so doesn't necessarily have 
to use LD_LIBRARY_PATH to do it.



Comment at: openmp/libomptarget/test/lit.cfg:182
+
+if config.cuda_path and config.cuda_path != 'CUDA_TOOLKIT_ROOT_DIR-NOTFOUND':
   config.substitutions.append(("%cuda_flags", "--cuda-path=" + 
config.cuda_path))

JonChesterfield wrote:
> protze.joachim wrote:
> > This would completely avoid the --cuda-path flag for non-nvptx tests
> Yes. That seems like a good thing. Is there a reason we want to pass 
> `--cuda-path=CUDA_TOOLKIT_ROOT_DIR-NOTFOUND` to all the non-nvptx tests?
This should disappear under a rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D108525: Fix documentation and snippets for the handle attributes.

2021-08-23 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108525

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

[PATCH] D101935: [clang] Search runtimes build tree for openmp runtime

2021-08-23 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

At present libomptarget_amdgcn_bc_path and nvptx need to be a path to a file. 
If we relax that to accept a path to a directory in which the corresponding 
file is found, then we can use that argument in place of LIBRARY_PATH from the 
test scripts. That will let the tests run, gives developers absolute control 
over which deviceRTL library is linked in, stops clang from picking up the 
wrong file from an unrelated toolchain on LIBRARY_PATH. I consider that 
strictly better than the above patch. Thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101935

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

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

Pasting `env LD_LIBRARY_PATH=` and `env LIBRARY_PATH` into the printed 
commandline, as opposed to through magic, would solve most of my day to day 
frustration here. libomp.so and libomptarget.so are in two different 
directories, LD_LIBRARY_PATH turns out to be colon delimited. LIBRARY_PATH is 
presently used to find the deviceRTL though I'd like to change that.

That doesn't solve any of the experience for our users but does help with 
debugging the tests. I'm currently trying to work out why the set of tests that 
fail under lit are different to the set that fail outside of lit and decreasing 
magic there might help me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added a comment.

In D101960#2960622 , @jdoerfert wrote:

> To summarize the conversation, can we do LD_LIBRARY_PATH overwrites after 
> this patch or not? If so, I feel everyone is in favor, if not, we need a 
> different solution.

+1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D108464: [clang][CodeGen] Refactor CreateTempAlloca function nest. NFC.

2021-08-23 Thread John McCall via Phabricator via cfe-commits

rjmccall added a reviewer: jfb.
rjmccall added a comment.

+ JF, who knows something about Web Assembly, or can at least drag in the right 
people

In D108464#2959591 , @wingo wrote:

> In D108464#2957276 , @wingo wrote:
>
>> So... besides the refactor, this is getting closer to where I'm going in 
>> https://lists.llvm.org/pipermail/cfe-dev/2021-July/068559.html, though still 
>> NFC.  I think you can see where I would replace `getASTAllocaAddressSpace` 
>> with `getAllocaAddressSpace(QualType Ty)`, and possibly (depending on the 
>> source language) avoid casting the resulting alloca to `LangAS::Default`.  
>> WDYT, is this sort of thing OK?
>
> Taking this patch as perhaps a better generic discussion point, @rjmccall 
> graciously gave some general feedback on this approach (thank you!!!):
>
> In D108360#2957844 , @rjmccall 
> wrote:
>
>> I'm not sure that I agree with your overall plan, though:
>>
>> - The WebAssembly operand stack is not a good match for an address space at 
>> the language level because it's not addressable at all.  If you can't 
>> meaningfully have a pointer into the address space, then you don't really 
>> need this in the type system; it's more like a declaration modifier at best.
>> - Allocating local variables on the operand stack ought to be a very 
>> straightforward analysis in the backend.  There's not much optimization 
>> value in trying to do it in the frontend, and it's going to be problematic 
>> for things like coroutine lowering.
>> - The security argument seems pretty weak, not because security isn't 
>> important but because this is not really an adequate basis for getting the 
>> tamper-proof guarantee you want.  For example, LLVM passes can and do 
>> introduce its own allocas and store scalars into them sometimes.  Really you 
>> need some sort of "tamper-proof" *type* which the compiler can make an 
>> end-to-end guarantee of non-tamper-ability for the values of, and while 
>> optimally this would be implemented by just keeping values on the operand 
>> stack, in the general case you will need to have some sort of strategy for 
>> keeping things in memory.
>
> Thanks for thinking about this!  Indeed I started out with the goal of not 
> going deep into clang and if it's possible to avoid going too deeply, that 
> would be better for everyone involved.  I am starting to think however that 
> it may be unavoidable for me at least.
>
> So, I am focusing on WebAssembly global and local variables; the WebAssembly 
> operand stack is an artifact of the IR-to-MC lowering and AFAICS doesn't have 
> any bearing on what clang does -- though perhaps I am misunderstanding what 
> you are getting at here.  The issue is not to allocate locals on the operand 
> stack, but rather to allocate them as part of the "locals" of a WebAssembly 
> function 
> .  Cc 
> @tlively on the WebAssembly side.

By "operand stack" I mean the innate, unaddressable stack that the WebAssembly 
VM maintains in order to make functions reentrant.  I don't know what term the 
VM spec uses for it, but I believe "operand stack" is widely accepted 
terminology for the unaddressable stack when you've got this kind of dual-stack 
setup.  And yes, VM "locals" would go there.

> The main motivator is the ability to have "reference type" 
>  
> (`externref`/`funcref`) locals and globals 
>  at all. 
>  Reference-typed values can't be stored to linear memory.  They have no size 
> and no byte representation -- they are opaque values from the host.  However, 
> WebAssembly locals and globals can define storage locations of type 
> `externref` or `funcref`.

I see.  I think you need to think carefully about the best way to represent 
values of these types in LLVM IR, because it probably cannot just be "treat 
them as a normal value, emit code a certain way that we know how to lower, and 
hope nothing goes wrong".  It seems to me that you probably need a new IR type 
for it, since normal types aren't restricted from memory and tokens can't be 
used as parameters or return values.

Hopefully, someone had a plan for this when they introduced that WebAssembly 
extension.

> But, if we add a generic OpenCL-like address space attribute, that would 
> allow the user to declare some variables to be in alternate address spaces.  
> Then we can apply the ACLE SVE semantic restrictions to these values also, 
> and add on an additional restriction preventing address-of.  That way users 
> get to make off-heap definitions, and if they misuse them, they get 
> comprehensible errors.  LLVM IR and WebAssembly lowering is ready for these 
> alternate-address-space allocations.

Again, I'm n

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-23 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added a comment.

To summarize the conversation, can we do LD_LIBRARY_PATH overwrites after this 
patch or not? If so, I feel everyone is in favor, if not, we need a different 
solution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D108567: Implement #pragma clang final extension

2021-08-23 Thread Chris Bieneman via Phabricator via cfe-commits

beanz created this revision.
beanz added reviewers: aaron.ballman, rsmith, lgerbarg, pete, lebedev.ri, 
dexonsmith.
beanz requested review of this revision.
Herald added a project: clang.

This patch adds a new preprocessor extension ``#pragma clang final``
which enables warning on undefinition and re-definition of macros.

The intent of this warning is to extend beyond ``-Wmacro-redefined`` to
warn against any and all alterations to macros that are marked `final`.

This warning is part of the ``-Wpedantic-macros`` diagnostics group.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108567

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/Pragma.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/Lexer/Inputs/final-macro.h
  clang/test/Lexer/final-macro.c
  clang/test/Lexer/pedantic-macro-interplay.c

Index: clang/test/Lexer/pedantic-macro-interplay.c
===
--- clang/test/Lexer/pedantic-macro-interplay.c
+++ clang/test/Lexer/pedantic-macro-interplay.c
@@ -11,4 +11,17 @@
 // not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as deprecated: Don't use this!}}
 #pragma clang restrict_expansion(UNSAFE_MACRO_2, "Don't use this!")
 
-// expected-no-diagnostics
+
+#define Foo 1
+#pragma clang final(Foo)
+// expected-note@+2{{macro marked 'deprecated' here}}
+// expected-note@+1{{macro marked 'deprecated' here}}
+#pragma clang deprecated(Foo)
+// expected-note@+1{{macro marked 'restrict_expansion' here}}
+#pragma clang restrict_expansion(Foo)
+
+// Test that unsafe_header and deprecated markings stick around after the undef
+#include "Inputs/final-macro.h"
+
+// expected-warning@+1{{macro 'Foo' has been marked as deprecated}}
+const int X = Foo;
Index: clang/test/Lexer/final-macro.c
===
--- /dev/null
+++ clang/test/Lexer/final-macro.c
@@ -0,0 +1,40 @@
+// RUN: %clang_cc1 -Wfinal-macro %s -fsyntax-only -verify
+
+// Test warning production
+// expected-note@+1{{previous definition is here}}
+#define Foo 1
+// expected-note@+2{{macro marked 'final' here}}
+// expected-note@+1{{macro marked 'final' here}}
+#pragma clang final(Foo)
+#pragma clang deprecated(Foo)
+#pragma clang header_unsafe(Foo)
+
+// expected-warning@+1{{'Foo' macro redefined}}
+#define Foo 2
+
+// expected-warning@+1{{redefining builtin macro}}
+#define __TIME__ 1
+
+// expected-warning@+1{{undefining builtin macro}}
+#undef __TIMESTAMP__
+
+// expected-warning@+1{{macro 'Foo' has been marked as final and should not be undefined}}
+#undef Foo
+// expected-warning@+1{{macro 'Foo' has been marked as final and should not be redefined}}
+#define Foo 3
+
+// Test parse errors
+// expected-error@+1{{expected (}}
+#pragma clang final
+
+// expected-error@+1{{expected )}}
+#pragma clang final(Foo
+
+// expected-error@+1{{no macro named Baz}}
+#pragma clang final(Baz)
+
+// expected-error@+1{{expected identifier}}
+#pragma clang final(4)
+
+// expected-error@+1{{expected (}}
+#pragma clang final Baz
Index: clang/test/Lexer/Inputs/final-macro.h
===
--- /dev/null
+++ clang/test/Lexer/Inputs/final-macro.h
@@ -0,0 +1,4 @@
+// expected-warning@+2{{macro 'Foo' has been marked as deprecated}}
+// expected-warning@+1{{macro 'Foo' has been marked as unsafe for use in headers}}
+#if Foo
+#endif
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -1413,26 +1413,46 @@
   return true;
 }
 
-void Preprocessor::emitMacroDeprecationWarning(const Token &Identifier) {
-  auto DepMsg = getMacroDeprecationMsg(Identifier.getIdentifierInfo());
-  if (DepMsg.first.empty())
+void Preprocessor::emitMacroDeprecationWarning(const Token &Identifier) const {
+  const MacroAnnotations &A =
+  getMacroAnnotations(Identifier.getIdentifierInfo());
+  assert(A.DeprecationInfo &&
+ "Macro deprecation warning without recorded annotation!");
+  const MacroAnnotationInfo &Info = *A.DeprecationInfo;
+  if (Info.Message.empty())
 Diag(Identifier, diag::warn_pragma_deprecated_macro_use)
 << Identifier.getIdentifierInfo() << 0;
   else
 Diag(Identifier, diag::warn_pragma_deprecated_macro_use)
-<< Identifier.getIdentifierInfo() << 1 << DepMsg.first;
-  Diag(DepMsg.second, diag::note_pp_macro_annotation) << 0;
+<< Identifier.getIdentifierInfo() << 1 << Info.Message;
+  Diag(Info.Location, diag::note_pp_macro_annotation) << 0;
 }
 
-void Preprocessor::emitMacroUnsafeHeaderWarning(const Token &Identifier) {
-  auto DepMsg = getRestrictExpansionMsg(Identifier.getIdentifierInfo());
-  if (DepMsg.first

Re: [llvm-dev] Phabricator Creator Pulling the Plug

2021-08-23 Thread James Y Knight via cfe-commits

If phabricator/phorge do turn out to be non-viable in the future, I think
we may want to reopen the option of moving to Gerrit for the primary
code-review platform.

I'll note that the Golang folks are using Gerrit as their review platform,
and they have a GitHub bot setup to translate GH pull-requests into a
gerrit review, so as to be friendly to first-time or drive-by contributors.
See e.g. https://github.com/golang/go/pull/47766 for an example.

On Mon, Aug 23, 2021 at 1:38 PM Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On Wed, 18 Aug 2021 at 18:17, MyDeveloper Day via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> But unless I missed this, was there any discussion regarding the recent
>> "Winding Down" announcement of Phabricator? and what it might mean for us
>> in LLVM
>>
>
> I think we have our own self-hosted version and enough local people that
> has hacked on it to "maintain" it, but we'd stop getting the updated from
> upstream, which have been substantial over the years.
>
> I don't think this should be a rush to replace with an alternative, as
> there is no imminent peril, but it is an additional important point for the
> ongoing discussion of potential transition.
>
> Personally I'm excited by the concept of a community driven replacement (
>> https://we.phorge.it/) .
>> epriestley did a truly amazing job, it wasn't open to public
>> contributions. Perhaps more open development could lead to closing some of
>> the github gaps that were of concern.
>>
>
> IMO, it would have to be seriously active upstream, understand our
> existing database "as is" and import without problems, and interface with
> Github more closely to be worth the hassle of migration.
>
> Github pull requests don't seem to be improving a lot, so "phorge" may be
> the right answer sooner than they catch up...
>
> cheers,
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [llvm-dev] Phabricator Creator Pulling the Plug

2021-08-23 Thread Renato Golin via cfe-commits

On Wed, 18 Aug 2021 at 18:17, MyDeveloper Day via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> But unless I missed this, was there any discussion regarding the recent
> "Winding Down" announcement of Phabricator? and what it might mean for us
> in LLVM
>

I think we have our own self-hosted version and enough local people that
has hacked on it to "maintain" it, but we'd stop getting the updated from
upstream, which have been substantial over the years.

I don't think this should be a rush to replace with an alternative, as
there is no imminent peril, but it is an additional important point for the
ongoing discussion of potential transition.

Personally I'm excited by the concept of a community driven replacement (
> https://we.phorge.it/) .
> epriestley did a truly amazing job, it wasn't open to public
> contributions. Perhaps more open development could lead to closing some of
> the github gaps that were of concern.
>

IMO, it would have to be seriously active upstream, understand our existing
database "as is" and import without problems, and interface with Github
more closely to be worth the hassle of migration.

Github pull requests don't seem to be improving a lot, so "phorge" may be
the right answer sooner than they catch up...

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

[PATCH] D108456: [CUDA] Fix static device variables with -fgpu-rdc

2021-08-23 Thread Artem Belevich via Phabricator via cfe-commits

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

LGTM.

Please wait for @yaxunl . I believe he mentioned in D85223 
 that he'll check whether it works on AMD's 
end.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6450
 llvm::raw_ostream &OS) const {
-  OS << ".static." << getContext().getCUIDHash();
+  OS << "__static__" << getContext().getCUIDHash();
 }

Hahnfeld wrote:
> tra wrote:
> > I would expect  NVPTXAssignValidGlobalNames.cpp to deal with this ptx 
> > quirk. 
> > I'm fine with the underscores, but it would be good we're not just covering 
> > up an issue somewhere else.
> > 
> `NVPTXAssignValidGlobalNames` checks `hasLocalLinkage`, which the `static` 
> variables here are not (see discussion in D85223). I think the reason is that 
> we don't want variable and function names to differ between host and device, 
> and this might even be important here for maintaining proper connection for 
> `cudaMemcpy`s and so on.
Right. We do need to have the same names on both sides.

I wish there was a way to avoid breaking demangling, but looks like we don't 
have any good options here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108456

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

[PATCH] D107769: [OpenCL] Make generic addrspace optional for -fdeclare-opencl-builtins

2021-08-23 Thread Sven van Haastregt via Phabricator via cfe-commits

svenvh updated this revision to Diff 368136.
svenvh edited the summary of this revision.
svenvh added a comment.

I have done an alternative spin of this patch: instead of introducing 
`RequireDisabledExtension`, simply always make the `private`, `global`, and 
`local` overloads available.  This makes tablegen diverge from `opencl-c.h` 
though.  Perhaps we should also always add make the `private`, `global`, and 
`local` overloads available in `opencl-c.h`?


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

https://reviews.llvm.org/D107769

Files:
  clang/lib/Sema/OpenCLBuiltins.td
  clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -63,6 +63,7 @@
 
 // Enable extensions that are enabled in opencl-c-base.h.
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
+#define __opencl_c_generic_address_space 1
 #define cl_khr_subgroup_extended_types 1
 #define cl_khr_subgroup_ballot 1
 #define cl_khr_subgroup_non_uniform_arithmetic 1
Index: clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
@@ -1,5 +1,11 @@
-// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL1.2 -finclude-default-header %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header %s | FileCheck 
%s
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL1.2 -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL3.0 -fdeclare-opencl-builtins -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-GAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL3.0 -fdeclare-opencl-builtins -finclude-default-header 
-cl-ext=-__opencl_c_generic_address_space,-__opencl_c_pipes %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
 
 // Test that mix is correctly defined.
 // CHECK-LABEL: @test_float
@@ -32,6 +38,15 @@
   size_t lid = get_local_id(0);
 }
 
+// Test that the correct builtin is called depending on the generic address
+// space feature availability.
+// CHECK-LABEL: @test_generic_optionality
+// CHECK-GAS: call spir_func float @_Z5fractfPU3AS4f
+// CHECK-NOGAS: call spir_func float @_Z5fractfPf
+void test_generic_optionality(float a, float *b) {
+  float res = fract(a, b);
+}
+
 // CHECK: attributes [[ATTR_CONST]] =
 // CHECK-SAME: readnone
 // CHECK: attributes [[ATTR_PURE]] =
Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -83,6 +83,7 @@
 def FuncExtKhrMipmapImageWrites  : 
FunctionExtension<"cl_khr_mipmap_image_writes">;
 def FuncExtKhrGlMsaaSharing  : 
FunctionExtension<"cl_khr_gl_msaa_sharing">;
 
+def FuncExtOpenCLCGenericAddressSpace: 
FunctionExtension<"__opencl_c_generic_address_space">;
 def FuncExtOpenCLCPipes  : 
FunctionExtension<"__opencl_c_pipes">;
 def FuncExtOpenCLCWGCollectiveFunctions  : 
FunctionExtension<"__opencl_c_work_group_collective_functions">;
 
@@ -566,10 +567,8 @@
   }
 }
 
-let MaxVersion = CL20 in {
-  defm : MathWithPointer<[GlobalAS, LocalAS, PrivateAS]>;
-}
-let MinVersion = CL20 in {
+defm : MathWithPointer<[GlobalAS, LocalAS, PrivateAS]>;
+let Extension = FuncExtOpenCLCGenericAddressSpace in {
   defm : MathWithPointer<[GenericAS]>;
 }
 
@@ -824,10 +823,8 @@
   }
 }
 
-let MaxVersion = CL20 in {
-  defm : VloadVstore<[GlobalAS, LocalAS, PrivateAS], 1>;
-}
-let MinVersion = CL20 in {
+defm : VloadVstore<[GlobalAS, LocalAS, PrivateAS], 1>;
+let Extension = FuncExtOpenCLCGenericAddressSpace in {
   defm : VloadVstore<[GenericAS], 1>;
 }
 // vload with constant address space is available regardless of version.
@@ -859,10 +856,8 @@
   }
 }
 
-let MaxVersion = CL20 in {
-  defm : VloadVstoreHalf<[GlobalAS, LocalAS, PrivateAS], 1>;
-}
-let MinVersion = CL20 in {
+defm : VloadVstoreHalf<[GlobalAS, LocalAS, PrivateAS], 1>;
+let Extension = FuncExtOpenCLCGenericAddressSpace in {
   defm : VloadVstoreHalf<[GenericAS], 1>;
 }
 // vload with constant address space is available regardless of version.


Index: clang/test/SemaOpenCL/fdecla

[PATCH] D106343: [OpenCL] Support cl_ext_float_atomics

2021-08-23 Thread Sven van Haastregt via Phabricator via cfe-commits

svenvh added a comment.

Thanks for the update!  I have a comment about indentation, other than that 
this is looking good to me.




Comment at: clang/lib/Sema/OpenCLBuiltins.td:1129
+let Extension = FuncExtFloatAtomicsFp64GlobalAdd in {
+def : Builtin<"atomic_fetch_" # ModOp,
+[Double, PointerType, GlobalAS>, Double]>;

Please indent the content inside all `let` blocks.


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

https://reviews.llvm.org/D106343

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

[PATCH] D108544: [clang][deps] Avoid generating arguments for missing module map files

2021-08-23 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

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

In D108544#2960279 , @dexonsmith 
wrote:

> Is there a way to test this?

Marking "request changes" for clarity.

Since this drops `-fmodule-map-file=` arguments, I imagine you can add a test 
that demonstrates it. But if that's currently awkward to observe because you 
need another piece to land in a follow-up, I'm fine to delay testing until then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108544

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

[PATCH] D108366: [clang][deps] Deduce resource directory from the compiler path

2021-08-23 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

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

In D108366#2959736 , @jansvoboda11 
wrote:

> For `clang-scan-deps`, this is //almost// NFC. This code kicks in iff 
> `ResourceDirectoryCache` doesn't provide any result:
>
> - the execution of `CommandLine[0] -print-resource-dir` command returns a 
> non-zero exit code (exercised in the test) or doesn't print anything,
> - the `CommandLine` is empty,
> - the compiler executable (`CommandLine[0]`) is not an absolute path.
>
> That's why I want to check with people if we can agree on removing 
> `ResourceDirectoryCache`. I'd be keen on updating this patch to include the 
> change and make the test more obviously correct.

Got it.

I wonder if it'd be better to split "changing default behaviour of 
clang-scan-deps the tool" from "avoid inject-resource-dir logic when it's 
incorrect". I.e., commit something in this patch to fix the immediate problem 
and remove/optimize ResourceDirectoryCache in a follow-up.

For this patch, you could add an inject-resource-dir flag to the scanning 
service, which controls the new Clang::Tooling flag (and can be controlled by 
libclang), and a command-line flag in clang-scan-deps to allow testing both 
sides of it. Would be worth documenting the testcase with a good comment to 
explain the corner case. Maybe the command-line flag would also disable 
ResourceDirectoryCache.

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

I don't love this hardcoded path to clang which //could// exist on some machine.

Could you use `/dev/null` for the path to clang?
Or `/dev/null/bin/clang`?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108366

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

[PATCH] D107095: Implement #pragma clang restrict_expansion

2021-08-23 Thread Chris Bieneman via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG43de869d77f7: Implement #pragma clang restrict_expansion 
(authored by beanz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107095

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/Pragma.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/Lexer/Inputs/pedantic-macro-interplay.h
  clang/test/Lexer/Inputs/unsafe-macro-2.h
  clang/test/Lexer/Inputs/unsafe-macro.h
  clang/test/Lexer/pedantic-macro-interplay.c
  clang/test/Lexer/unsafe-macro.c

Index: clang/test/Lexer/unsafe-macro.c
===
--- /dev/null
+++ clang/test/Lexer/unsafe-macro.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -Wrestrict-expansion %s -fsyntax-only -verify
+#include "Inputs/unsafe-macro.h"
+#include "Inputs/unsafe-macro-2.h"
+
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#if UNSAFE_MACRO
+#endif
Index: clang/test/Lexer/pedantic-macro-interplay.c
===
--- /dev/null
+++ clang/test/Lexer/pedantic-macro-interplay.c
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -Wpedantic-macros %s -fsyntax-only -verify
+
+// This test verifies that the -Wpedantic-macros warnings don't fire in the
+// annotation pragmas themselves. This ensures you can annotate macros with
+// more than one of the pragmas without spewing warnings all over the code.
+
+#include "Inputs/pedantic-macro-interplay.h"
+
+#define UNSAFE_MACRO_2 1
+#pragma clang deprecated(UNSAFE_MACRO_2, "Don't use this!")
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as deprecated: Don't use this!}}
+#pragma clang restrict_expansion(UNSAFE_MACRO_2, "Don't use this!")
+
+// expected-no-diagnostics
Index: clang/test/Lexer/Inputs/unsafe-macro.h
===
--- /dev/null
+++ clang/test/Lexer/Inputs/unsafe-macro.h
@@ -0,0 +1,27 @@
+// expected-error@+1{{expected (}}
+#pragma clang restrict_expansion
+
+// expected-error@+1{{expected identifier}}
+#pragma clang restrict_expansion(4
+
+// expected-error@+1{{no macro named foo}}
+#pragma clang restrict_expansion(foo)
+
+
+#define UNSAFE_MACRO 1
+// expected-note@+8{{macro marked 'restrict_expansion' here}}
+// expected-note@+7{{macro marked 'restrict_expansion' here}}
+// expected-note@+6{{macro marked 'restrict_expansion' here}}
+// expected-note@+5{{macro marked 'restrict_expansion' here}}
+// expected-note@+4{{macro marked 'restrict_expansion' here}}
+// expected-note@+3{{macro marked 'restrict_expansion' here}}
+// expected-note@+2{{macro marked 'restrict_expansion' here}}
+// expected-note@+1{{macro marked 'restrict_expansion' here}} 
+#pragma clang restrict_expansion(UNSAFE_MACRO, "Don't use this!")
+
+#define UNSAFE_MACRO_2 2
+// expected-note@+1{{macro marked 'restrict_expansion' here}}
+#pragma clang restrict_expansion(UNSAFE_MACRO_2)
+
+// expected-error@+1{{expected )}}
+#pragma clang deprecated(UNSAFE_MACRO
Index: clang/test/Lexer/Inputs/unsafe-macro-2.h
===
--- /dev/null
+++ clang/test/Lexer/Inputs/unsafe-macro-2.h
@@ -0,0 +1,70 @@
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#if UNSAFE_MACRO
+#endif
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#if defined(UNSAFE_MACRO)
+#endif
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#ifdef UNSAFE_MACRO
+#endif
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#ifndef UNSAFE_MACRO
+#endif
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+const int x = UNSAFE_MACRO;
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}}
+const int y = UNSAFE_MACRO_2;
+
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}}
+#undef UNSAFE_MACRO_2
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}}
+#define UNSAFE_MACRO_2 2
+
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}}
+const int z = UNSAFE_MACRO_2;
+
+
+// Test that we diagnose on #elif.
+#if 0
+#elif UNSAFE_MACRO
+// expected-warning@-1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#endif
+
+
+// Test that we diagnose on #elifdef.
+#ifdef baz
+#elif

[clang] 43de869 - Implement #pragma clang restrict_expansion

2021-08-23 Thread Chris Bieneman via cfe-commits


Author: Chris Bieneman
Date: 2021-08-23T09:46:38-07:00
New Revision: 43de869d77f77eedf9f8760f94940a249d2b5a41

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

LOG: Implement #pragma clang restrict_expansion

This patch adds `#pragma clang restrict_expansion ` to enable flagging
macros as unsafe for header use. This is to allow macros that may have
ABI implications to be avoided in headers that have ABI stability
promises.

Using macros in headers (particularly public headers) can cause a
variety of issues relating to ABI and modules. This new pragma logs
warnings when using annotated macros outside the main source file.

This warning is added under a new diagnostics group -Wpedantic-macros

Reviewed By: aaron.ballman

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

Added: 
clang/test/Lexer/Inputs/pedantic-macro-interplay.h
clang/test/Lexer/Inputs/unsafe-macro-2.h
clang/test/Lexer/Inputs/unsafe-macro.h
clang/test/Lexer/pedantic-macro-interplay.c
clang/test/Lexer/unsafe-macro.c

Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Basic/IdentifierTable.h
clang/include/clang/Lex/Preprocessor.h
clang/lib/Lex/Pragma.cpp
clang/lib/Lex/Preprocessor.cpp

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 087aa66c1b7af..fada65c487bc5 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3931,6 +3931,40 @@ provide deprecation warnings for macro uses. For example:
 ``#pragma GCC warning`` because the warning can be controlled with
 ``-Wdeprecated``.
 
+Restricted Expansion Macros
+===
+
+Clang supports the pragma ``#pragma clang restrict_expansion``, which can be
+used restrict macro expansion in headers. This can be valuable when providing
+headers with ABI stability requirements. Any expansion of the annotated macro
+processed by the preprocessor after the ``#pragma`` annotation will log a
+warning. Redefining the macro or undefining the macro will not be diagnosed, 
nor
+will expansion of the macro within the main source file. For example:
+
+.. code-block:: c
+
+   #define TARGET_ARM 1
+   #pragma clang restrict_expansion(TARGET_ARM, "")
+
+   /// Foo.h
+   struct Foo {
+   #if TARGET_ARM // warning: TARGET_ARM is marked unsafe in headers: 
+ uint32_t X;
+   #else
+ uint64_t X;
+   #endif
+   };
+
+   /// main.c
+   #include "foo.h"
+   #if TARGET_ARM // No warning in main source file
+   X_TYPE uint32_t
+   #else
+   X_TYPE uint64_t
+   #endif
+
+This warning is controlled by ``-Wpedantic-macros``.
+
 Extended Integer Types
 ==
 

diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index 17b5f419ef58c..753a3d5546e2f 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -647,6 +647,7 @@ def AmbiguousMacro : DiagGroup<"ambiguous-macro">;
 def KeywordAsMacro : DiagGroup<"keyword-macro">;
 def ReservedIdAsMacro : DiagGroup<"reserved-macro-identifier">;
 def ReservedIdAsMacroAlias : DiagGroup<"reserved-id-macro", 
[ReservedIdAsMacro]>;
+def RestrictExpansionMacro : DiagGroup<"restrict-expansion">;
 
 // Just silence warnings about -Wstrict-aliasing for now.
 def : DiagGroup<"strict-aliasing=0">;
@@ -1311,3 +1312,10 @@ def WebAssemblyExceptionSpec : 
DiagGroup<"wasm-exception-spec">;
 def RTTI : DiagGroup<"rtti">;
 
 def OpenCLCoreFeaturesDiagGroup : DiagGroup<"pedantic-core-features">;
+
+// Warnings and extensions to make preprocessor macro usage pedantic.
+def PedanticMacros : DiagGroup<"pedantic-macros",
+[DeprecatedPragma,
+ MacroRedefined,
+ BuiltinMacroRedefined,
+ RestrictExpansionMacro]>;

diff  --git a/clang/include/clang/Basic/DiagnosticLexKinds.td 
b/clang/include/clang/Basic/DiagnosticLexKinds.td
index c19adf104db1f..49c50fb27e624 100644
--- a/clang/include/clang/Basic/DiagnosticLexKinds.td
+++ b/clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -528,6 +528,16 @@ def warn_pragma_deprecated_macro_use :
   ExtWarn<"macro %0 has been marked as deprecated%select{|: %2}1">,
   InGroup;
 
+// - #pragma clang restrict_expansion(...)
+def warn_pragma_restrict_expansion_macro_use :
+  ExtWarn<"macro %0 has been marked as unsafe for use in headers"
+  "%select{|: %2}1">,
+  InGroup;
+
+// - Note for macro annotations.
+def note_pp_macro_annotation :
+  Note<"macro marked '%select{deprecated|restrict_expansion}0' here">;
+
 // - #pragma execution_character_set(...)
 def warn_pragma_exec_chars

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

2021-08-23 Thread Craig Topper via Phabricator via cfe-commits

craig.topper accepted this revision.
craig.topper added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

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

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

2021-08-23 Thread Erich Keane via Phabricator via cfe-commits

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

2 nits, give Craig a day or two to =1 as well please, particularly since he's 
the code-owner here.




Comment at: clang/lib/Basic/Targets/X86.cpp:1063
+#ifndef NDEBUG
+  // Check that priorities are set properly in the .def file, i.e.
+#define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY) PRIORITY,

Just a nit, I would like a better description here of the constraint we're 
trying to enforce.  I can imagine someone in the future failing this, and not 
getting the context without a few sentences of how no duplicates are allowed, 
and it must be all numbers from 0 to the-max-number.



Comment at: clang/lib/Basic/Targets/X86.cpp:1074
+ std::prev(std::end(Priorities))) &&
+ "Priorites don't form consecutive range!");
+#endif




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

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

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

2021-08-23 Thread Andrei Elovikov via Phabricator via cfe-commits

a.elovikov marked an inline comment as done.
a.elovikov added a comment.

Hi guys, do you want me to fix anything else? I think I've addressed what I 
could.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

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

[PATCH] D108525: Fix documentation and snippets for the handle attributes.

2021-08-23 Thread Paul Herman via Phabricator via cfe-commits

paulherman updated this revision to Diff 368127.
paulherman added a comment.

Explaining the tag argument.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108525

Files:
  clang/include/clang/Basic/AttrDocs.td


Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -5881,19 +5881,21 @@
 If this annotation is on a function or a function type it is assumed to return
 a new handle. In case this annotation is on an output parameter,
 the function is assumed to fill the corresponding argument with a new
-handle.
+handle. The attribute requires a string literal argument which used to
+identify the handle with later uses of ``use_handle`` or
+``release_handle``.
 
 .. code-block:: c++
 
   // Output arguments from Zircon.
   zx_status_t zx_socket_create(uint32_t options,
-   zx_handle_t __attribute__((acquire_handle)) * 
out0,
-   zx_handle_t* out1 [[clang::acquire_handle]]);
+   zx_handle_t 
__attribute__((acquire_handle("zircon"))) * out0,
+   zx_handle_t* out1 
[[clang::acquire_handle("zircon")]]);
 
 
   // Returned handle.
-  [[clang::acquire_handle]] int open(const char *path, int oflag, ... );
-  int open(const char *path, int oflag, ... ) __attribute__((acquire_handle));
+  [[clang::acquire_handle("tag")]] int open(const char *path, int oflag, ... );
+  int open(const char *path, int oflag, ... ) 
__attribute__((acquire_handle("tag")));
   }];
 }
 
@@ -5901,12 +5903,13 @@
   let Category = HandleDocs;
   let Content = [{
 A function taking a handle by value might close the handle. If a function
-parameter is annotated with ``use_handle`` it is assumed to not to change
+parameter is annotated with ``use_handle(tag)`` it is assumed to not to change
 the state of the handle. It is also assumed to require an open handle to work 
with.
+The attribute requires a string literal argument to identify the handle being 
used.
 
 .. code-block:: c++
 
-  zx_status_t zx_port_wait(zx_handle_t handle [[clang::use_handle]],
+  zx_status_t zx_port_wait(zx_handle_t handle [[clang::use_handle("zircon")]],
zx_time_t deadline,
zx_port_packet_t* packet);
   }];
@@ -5915,12 +5918,13 @@
 def ReleaseHandleDocs : Documentation {
   let Category = HandleDocs;
   let Content = [{
-If a function parameter is annotated with ``release_handle`` it is assumed to
-close the handle. It is also assumed to require an open handle to work with.
+If a function parameter is annotated with ``release_handle(tag)`` it is 
assumed to
+close the handle. It is also assumed to require an open handle to work with. 
The
+attribute requires a string literal argument to identify the handle being 
released.
 
 .. code-block:: c++
 
-  zx_status_t zx_handle_close(zx_handle_t handle [[clang::release_handle]]);
+  zx_status_t zx_handle_close(zx_handle_t handle 
[[clang::release_handle("tag")]]);
   }];
 }
 


Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -5881,19 +5881,21 @@
 If this annotation is on a function or a function type it is assumed to return
 a new handle. In case this annotation is on an output parameter,
 the function is assumed to fill the corresponding argument with a new
-handle.
+handle. The attribute requires a string literal argument which used to
+identify the handle with later uses of ``use_handle`` or
+``release_handle``.
 
 .. code-block:: c++
 
   // Output arguments from Zircon.
   zx_status_t zx_socket_create(uint32_t options,
-   zx_handle_t __attribute__((acquire_handle)) * out0,
-   zx_handle_t* out1 [[clang::acquire_handle]]);
+   zx_handle_t __attribute__((acquire_handle("zircon"))) * out0,
+   zx_handle_t* out1 [[clang::acquire_handle("zircon")]]);
 
 
   // Returned handle.
-  [[clang::acquire_handle]] int open(const char *path, int oflag, ... );
-  int open(const char *path, int oflag, ... ) __attribute__((acquire_handle));
+  [[clang::acquire_handle("tag")]] int open(const char *path, int oflag, ... );
+  int open(const char *path, int oflag, ... ) __attribute__((acquire_handle("tag")));
   }];
 }
 
@@ -5901,12 +5903,13 @@
   let Category = HandleDocs;
   let Content = [{
 A function taking a handle by value might close the handle. If a function
-parameter is annotated with ``use_handle`` it is assumed to not to change
+parameter is annotated with ``use_handle(tag)`` it is assumed to not to change
 the state of the handle. It is also assumed to require an open handle to w

[PATCH] D108533: [clang] Move the soname declaration in a variable at the top of the file

2021-08-23 Thread Sylvestre Ledru via Phabricator via cfe-commits

sylvestre.ledru updated this revision to Diff 368126.
sylvestre.ledru added a comment.

Move the comment too


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108533

Files:
  clang/tools/libclang/CMakeLists.txt


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -1,3 +1,9 @@
+# The SOVERSION should be updated only if a change is made to the libclang
+# ABI, and when it is updated, it should be updated to the current
+# LLVM_VERSION_MAJOR.
+# Please also see clang/tools/libclang/libclang.map
+set(CLANG_SONAME 13)
+
 set(SOURCES
   ARCMigrate.cpp
   BuildSystem.cpp
@@ -171,12 +177,9 @@
 set_property(SOURCE ARCMigrate.cpp APPEND PROPERTY
  OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/libclang.map)
 
-# The SOVERSION should be updated only if a change is made to the libclang
-# ABI, and when it is updated, it should be updated to the current
-# LLVM_VERSION_MAJOR.
 set_target_properties(libclang PROPERTIES
   VERSION 
${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}
-  SOVERSION 13)
+  SOVERSION ${CLANG_SONAME})
   endif()
 endif()
 


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -1,3 +1,9 @@
+# The SOVERSION should be updated only if a change is made to the libclang
+# ABI, and when it is updated, it should be updated to the current
+# LLVM_VERSION_MAJOR.
+# Please also see clang/tools/libclang/libclang.map
+set(CLANG_SONAME 13)
+
 set(SOURCES
   ARCMigrate.cpp
   BuildSystem.cpp
@@ -171,12 +177,9 @@
 set_property(SOURCE ARCMigrate.cpp APPEND PROPERTY
  OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/libclang.map)
 
-# The SOVERSION should be updated only if a change is made to the libclang
-# ABI, and when it is updated, it should be updated to the current
-# LLVM_VERSION_MAJOR.
 set_target_properties(libclang PROPERTIES
   VERSION ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}
-  SOVERSION 13)
+  SOVERSION ${CLANG_SONAME})
   endif()
 endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108533: [clang] Move the soname declaration in a variable at the top of the file

2021-08-23 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added inline comments.



Comment at: clang/tools/libclang/CMakeLists.txt:176
 
 # The SOVERSION should be updated only if a change is made to the libclang
 # ABI, and when it is updated, it should be updated to the current

The comment should be lifted as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108533

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

[PATCH] D108540: [clang][deps] Collect precompiled deps from submodules too

2021-08-23 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

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

LGTM.




Comment at: clang/test/ClangScanDeps/modules-pch-common-via-submodule.c:85
+// CHECK-TU:  "-emit-module"
+// CHECK-TU:  
"-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_COMMON:.*]]/ModCommon-{{.*}}.pcm"
+// CHECK-TU:  "-fmodules"

jansvoboda11 wrote:
> Previously, we'd miss this module included from `mod_tu_sub.h`, resulting in 
> a compilation error for `ModTU`.
Can you add a comment to the top of the testcase explaining what's interesting 
about it? (Something similar to what you have here.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108540

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

1 2 >

1 - 100 of 177 matches

Mail list logo