[clang] 40a3fcb - [DebugInfo][CallSites] Remove decl subprograms from 'retainedTypes:'

2020-06-01 Thread Djordje Todorovic via cfe-commits
Author: Djordje Todorovic
Date: 2020-06-01T09:10:05+02:00
New Revision: 40a3fcb05c83c41862038277aa667c956e7cac82

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

LOG: [DebugInfo][CallSites] Remove decl subprograms from 'retainedTypes:'

After the D70350, the retainedTypes: isn't being used for the purpose
of call site debug info for extern calls, so it is safe to delete it
from IR representation.
We are also adding a test to ensure the subprogram isn't stored within
the retainedTypes: from corresponding DICompileUnit.

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

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGen/debug-info-extern-call.c
clang/test/Modules/DebugInfoTransitiveImport.m
clang/test/Modules/ModuleDebugInfo.cpp
clang/test/Modules/ModuleDebugInfo.m

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 31f8df243017..5be8e77c0b49 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3900,7 +3900,7 @@ void CGDebugInfo::EmitFunctionDecl(GlobalDecl GD, 
SourceLocation Loc,
   if (IsDeclForCallSite)
 Fn->setSubprogram(SP);
 
-  DBuilder.retainType(SP);
+  DBuilder.finalizeSubprogram(SP);
 }
 
 void CGDebugInfo::EmitFuncDeclForCallSite(llvm::CallBase *CallOrInvoke,

diff  --git a/clang/test/CodeGen/debug-info-extern-call.c 
b/clang/test/CodeGen/debug-info-extern-call.c
index 072e578b5898..7ba115ad2ec9 100644
--- a/clang/test/CodeGen/debug-info-extern-call.c
+++ b/clang/test/CodeGen/debug-info-extern-call.c
@@ -1,6 +1,10 @@
 // When entry values are emitted, expect a subprogram for extern decls so that
 // the dwarf generator can describe call site parameters at extern call sites.
 //
+// Initial implementation relied on the 'retainedTypes:' from the corresponding
+// DICompileUnit, so we also ensure that we do not store the extern declaration
+// subprogram into the 'retainedTypes:'.
+//
 // RUN: %clang -g -O2 -target x86_64-none-linux-gnu -S -emit-llvm %s -o - \
 // RUN:   | FileCheck %s -check-prefix=DECLS-FOR-EXTERN
 
@@ -17,6 +21,8 @@
 // RUN: %clang -g -O2 -target x86_64-none-linux-gnu -gsce -S -emit-llvm %s -o 
- \
 // RUN:   | FileCheck %s -check-prefix=NO-DECLS-FOR-EXTERN
 
+// DECLS-FOR-EXTERN-NOT: !DICompileUnit({{.*}}retainedTypes: 
![[RETTYPES:[0-9]+]]
+// DECLS-FOR-EXTERN-NOT: ![[RETTYPES]] = !{
 // DECLS-FOR-EXTERN: !DISubprogram(name: "fn1"
 // DECLS-FOR-EXTERN-NOT: !DISubprogram(name: "memcmp"
 // DECLS-FOR-EXTERN-NOT: !DISubprogram(name: "__some_reserved_name"

diff  --git a/clang/test/Modules/DebugInfoTransitiveImport.m 
b/clang/test/Modules/DebugInfoTransitiveImport.m
index 08dfecfb7899..bd763e81cf85 100644
--- a/clang/test/Modules/DebugInfoTransitiveImport.m
+++ b/clang/test/Modules/DebugInfoTransitiveImport.m
@@ -12,10 +12,10 @@
 
 // Definition of left:
 // CHECK: !DICompileUnit({{.*}}dwoId:
-// CHECK: ![[LEFT:[0-9]+]] = !DIFile({{.*}}diamond_left.h
 // CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration,
-// CHECK-SAME:  entity: ![[MODULE:.*]], file: ![[LEFT]], line: 3)
+// CHECK-SAME:  entity: ![[MODULE:.*]], file: ![[LEFT:.*]], line: 
3)
 // CHECK: ![[MODULE]] = !DIModule(scope: null, name: "diamond_top"
+// CHECK: ![[LEFT]] = !DIFile({{.*}}diamond_left.h
 
 // Skeleton for top:
 // CHECK: !DICompileUnit({{.*}}splitDebugFilename: 
{{.*}}diamond_top{{.*}}dwoId:

diff  --git a/clang/test/Modules/ModuleDebugInfo.cpp 
b/clang/test/Modules/ModuleDebugInfo.cpp
index e6e99ed4e537..3121719e55a6 100644
--- a/clang/test/Modules/ModuleDebugInfo.cpp
+++ b/clang/test/Modules/ModuleDebugInfo.cpp
@@ -51,15 +51,6 @@
 // CHECK-SAME: )
 // CHECK: !DIEnumerator(name: "e5", value: 5, isUnsigned: true)
 
-// CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "B",
-// no mangled name here yet.
-
-// This type is anchored by a function parameter.
-// CHECK: !DICompositeType(tag: DW_TAG_class_type, name: "A"
-// CHECK-SAME: elements:
-// CHECK-SAME: templateParams:
-// CHECK-SAME: identifier: "_ZTSN8DebugCXX1AIJvEEE")
-
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "Struct"
 // CHECK-SAME: identifier: "_ZTSN8DebugCXX6StructE")
 
@@ -85,6 +76,12 @@
 // CHECK-SAME: templateParams:
 // CHECK-SAME: identifier: 
"_ZTSN8DebugCXX8TemplateIlNS_6traitsIl")
 
+// This type is anchored by a function parameter.
+// CHECK: !DICompositeType(tag: DW_TAG_class_type, name: "A"
+// CHECK-SAME: elements:
+// CHECK-SAME: templateParams:
+// CHECK-SAME: identifier: "_ZTSN8DebugCXX1AIJvEEE")
+
 // CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "FloatInstantiation"
 // no mangled name her

[PATCH] D80369: [DebugInfo][CallSites] Remove decl subprograms from 'retainedTypes:'

2020-06-01 Thread Djordje Todorovic via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG40a3fcb05c83: [DebugInfo][CallSites] Remove decl subprograms 
from 'retainedTypes:' (authored by djtodoro).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80369

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-info-extern-call.c
  clang/test/Modules/DebugInfoTransitiveImport.m
  clang/test/Modules/ModuleDebugInfo.cpp
  clang/test/Modules/ModuleDebugInfo.m

Index: clang/test/Modules/ModuleDebugInfo.m
===
--- clang/test/Modules/ModuleDebugInfo.m
+++ clang/test/Modules/ModuleDebugInfo.m
@@ -36,19 +36,13 @@
 // CHECK-NOT:  name:
 // CHECK-SAME: elements:
 
-// CHECK: !DISubprogram(name: "+[ObjCClass classMethod]",
-// CHECK-SAME:  scope: ![[MODULE]],
+// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "FwdDecl",
+// CHECK-SAME: scope: ![[MODULE]],
 
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "ObjCClass",
 // CHECK-SAME: scope: ![[MODULE]],
 // CHECK-SAME: elements
 
-// The forward declaration should not be in the module scope.
-// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "OpaqueData", file
-
-// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "FwdDecl",
-// CHECK-SAME: scope: ![[MODULE]],
-
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "ObjCClassWithPrivateIVars",
 // CHECK-SAME: scope: ![[MODULE]],
 // CHECK-SAME: elements
@@ -85,11 +79,8 @@
 // The output order is sublty different for module vs. pch,
 // so these are checked separately:
 //
-// CHECK2: !DISubprogram(name: "+[ObjCClass classMethod]"
-// CHECK2: !DISubprogram(name: "-[ObjCClass instanceMethodWithInt:]"
+// CHECK2: !DICompositeType(tag: DW_TAG_structure_type, name: "FwdDecl",
 // CHECK2: !DICompositeType(tag: DW_TAG_structure_type, name: "ObjCClass",
 // CHECK2: !DIObjCProperty(name: "property",
 // CHECK2: !DIDerivedType(tag: DW_TAG_member, name: "ivar"
-// CHECK2: !DISubprogram(name: "-[Category(Category) categoryMethod]"
-// CHECK2: !DICompositeType(tag: DW_TAG_structure_type, name: "FwdDecl",
 // CHECK2: !DIDerivedType(tag: DW_TAG_typedef, name: "InnerEnum"
Index: clang/test/Modules/ModuleDebugInfo.cpp
===
--- clang/test/Modules/ModuleDebugInfo.cpp
+++ clang/test/Modules/ModuleDebugInfo.cpp
@@ -51,15 +51,6 @@
 // CHECK-SAME: )
 // CHECK: !DIEnumerator(name: "e5", value: 5, isUnsigned: true)
 
-// CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "B",
-// no mangled name here yet.
-
-// This type is anchored by a function parameter.
-// CHECK: !DICompositeType(tag: DW_TAG_class_type, name: "A"
-// CHECK-SAME: elements:
-// CHECK-SAME: templateParams:
-// CHECK-SAME: identifier: "_ZTSN8DebugCXX1AIJvEEE")
-
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "Struct"
 // CHECK-SAME: identifier: "_ZTSN8DebugCXX6StructE")
 
@@ -85,6 +76,12 @@
 // CHECK-SAME: templateParams:
 // CHECK-SAME: identifier: "_ZTSN8DebugCXX8TemplateIlNS_6traitsIl")
 
+// This type is anchored by a function parameter.
+// CHECK: !DICompositeType(tag: DW_TAG_class_type, name: "A"
+// CHECK-SAME: elements:
+// CHECK-SAME: templateParams:
+// CHECK-SAME: identifier: "_ZTSN8DebugCXX1AIJvEEE")
+
 // CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "FloatInstantiation"
 // no mangled name here yet.
 
@@ -93,6 +90,9 @@
 // CHECK-SAME: flags: DIFlagFwdDecl
 // CHECK-SAME: identifier: "_ZTSN8DebugCXX8TemplateIfNS_6traitsIf")
 
+// CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "B",
+// no mangled name here yet.
+
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "Virtual"
 // CHECK-SAME: elements:
 // CHECK-SAME: identifier: "_ZTS7Virtual")
Index: clang/test/Modules/DebugInfoTransitiveImport.m
===
--- clang/test/Modules/DebugInfoTransitiveImport.m
+++ clang/test/Modules/DebugInfoTransitiveImport.m
@@ -12,10 +12,10 @@
 
 // Definition of left:
 // CHECK: !DICompileUnit({{.*}}dwoId:
-// CHECK: ![[LEFT:[0-9]+]] = !DIFile({{.*}}diamond_left.h
 // CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration,
-// CHECK-SAME:  entity: ![[MODULE:.*]], file: ![[LEFT]], line: 3)
+// CHECK-SAME:  entity: ![[MODULE:.*]], file: ![[LEFT:.*]], line: 3)
 // CHECK: ![[MODULE]] = !DIModule(scope: null, name: "diamond_top"
+// CHECK: ![[LEFT]] = !DIFile({{.*}}diamond_left.h
 
 // Skeleton for top:
 // CHECK: !DICompileUnit({{.*}}splitDebugFilename: {{.*}}diamond_top{{.*}}dwoId:
Index: clang/test/CodeGen/debug-info-extern-ca

[PATCH] D80896: [clang-tidy][misc-redundant-expression] Fix crash on CXXFoldExpr

2020-06-01 Thread Nathan James via Phabricator via cfe-commits
njames93 added a comment.

This fix has expanded from preventing the crash to adding support for 
`CXXFoldExpr` to misc-redundant-expression. Maybe rename the revision to 
explain that better. 
If that is the case then you may as well add a test case showing a redundant 
fold expression




Comment at: clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp:75
   while (LeftIter != Left->child_end() && RightIter != Right->child_end()) {
-if (!areEquivalentExpr(dyn_cast(*LeftIter),
+if (*LeftIter && *RightIter &&
+!areEquivalentExpr(dyn_cast(*LeftIter),

What happens when `*LeftIter` is null, but `*RightIter` isn't or vice versa, 
That case should also return false.


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

https://reviews.llvm.org/D80896



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


[PATCH] D80369: [DebugInfo][CallSites] Remove decl subprograms from 'retainedTypes:'

2020-06-01 Thread Djordje Todorovic via Phabricator via cfe-commits
djtodoro added a comment.

Thanks for the reviews!


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

https://reviews.llvm.org/D80369



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-06-01 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added inline comments.



Comment at: clang/test/CodeGen/arm-bf16-params-returns.c:5
+// RUN: %clang_cc1 -triple aarch64-arm-none-eabi -target-abi aapcs -mfloat-abi 
softfp -target-feature +bf16 -target-feature +neon -emit-llvm -O2 -o - %s | opt 
-S -mem2reg -sroa | FileCheck %s --check-prefix=CHECK64-SOFTFP
+
+// function return types

stuij wrote:
> SjoerdMeijer wrote:
> > what happens with `-mfloat-abi=soft`. Does that deserve a test?
> Yes, this one is interesting. I think we shouldn't support bfloat at all in 
> combination with -mfloat-abi=soft. We don't support software emulation of 
> bfloat instructions and all operations on bfloat are simd instructions.
> 
> It turns out cc1 will accept -mfloat-abi=soft with neon intrinsics, which 
> will happily churn out neon instructions. This doesn't sound very soft. The 
> driver will ignore -mfloat-abi=soft in certain combinations of cmdline 
> instructions, but I haven't delved deep enough to know what's what.
> 
> GCC doesn't allow soft+neon combination. Unfortunately it will actually crash 
> for just a bfloat type by itself, which is quite useless without intrinsics. 
> The Arm GCC folks will raise a ticket on this with as proposed solution to 
> not allow this combination.
> 
> As this issue seems bigger than just bfloat, and potentially there's driver 
> code involved as well I thought it'd make sense to handle this in a separate 
> patch.
I think we first need agreement what -mfloat-abi=soft  with bf16 means and how 
it should behave, document this, and have some tests. Possibly document how we 
diverge from this.

I think I tend to disagree with this:

> I think we shouldn't support bfloat at all in combination with 
> -mfloat-abi=soft.

why would it not be supported in some way (promotions to another type, or even 
library calls), like the other float-types? 

> It turns out cc1 will accept -mfloat-abi=soft with neon intrinsics, which 
> will happily churn out neon instructions.

I would say the fact that there are other problems, shouldn't distract us too 
much from trying to get this right; I think at this point that is not yet a 
justification. 

> As this issue seems bigger than just bfloat, and potentially there's driver 
> code involved as well I thought it'd make sense to handle this in a separate 
> patch.

I think at this point I disagree with this, mainly because of my first point: 
the behaviour should be specified. I would also say that not doing this, could 
be a bit of bad precedent for adding a new C type. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-06-01 Thread Alexandros Lamprineas via Phabricator via cfe-commits
labrinea added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:4493
+  case NeonTypeFlags::BFloat16:
+if (HasBFloat16Type)
+  return llvm::VectorType::get(CGF->BFloatTy, V1Ty ? 1 : (4 << IsQuad));

This is not what we should be checking for here. Imagine a command line with 
+bf16 and +mfloat-abi=softfp, that should generate i16, not bfloat. We 
therefore need a target hook to pass this information. I suggest 
`allowBFloatArgsAndRet()` in ABIInfo, returning false by default, overloaded 
for Arm and AArch64 to return `!IsFloatABISoftFP && hasBFloat16Type()` and 
`hasBFloat16Type()` respectively.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D80910: AArch64+ARM: make LLVM consider system registers volatile to prevent unsound optimizations.

2020-06-01 Thread Tim Northover via Phabricator via cfe-commits
t.p.northover abandoned this revision.
t.p.northover added a comment.

Sorry. Keyboard decided to create diff before I'd filled everything in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80910



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


[PATCH] D80910: AArch64+ARM: make LLVM consider system registers volatile to prevent unsound optimizations.

2020-06-01 Thread Tim Northover via Phabricator via cfe-commits
t.p.northover created this revision.
Herald added subscribers: llvm-commits, cfe-commits, danielkiss, jdoerfert, 
asbirlea, hiraditya, kristof.beyls, mcrosier.
Herald added projects: clang, LLVM.
t.p.northover abandoned this revision.
t.p.northover added a comment.

Sorry. Keyboard decided to create diff before I'd filled everything in.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80910

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-arm.c
  clang/test/CodeGen/builtins-arm64.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/test/Transforms/LICM/read-volatile-register.ll

Index: llvm/test/Transforms/LICM/read-volatile-register.ll
===
--- /dev/null
+++ llvm/test/Transforms/LICM/read-volatile-register.ll
@@ -0,0 +1,30 @@
+; RUN: opt -S -licm %s | FileCheck %s
+
+; Volatile register shouldn't be hoisted ourside loops.
+define i32 @test_read() {
+; CHECK-LABEL: define i32 @test_read()
+; CHECK: br label %loop
+; CHECK: loop:
+; CHECK: %counter = tail call i64 @llvm.read_volatile_register
+
+entry:
+  br label %loop
+
+loop:
+  %i = phi i32 [ 0, %entry ], [ %i.next, %inc ]
+  %counter = tail call i64 @llvm.read_volatile_register.i64(metadata !1)
+  %tst = icmp ult i64 %counter, 1000
+  br i1 %tst, label %inc, label %done
+
+inc:
+  %i.next = add nuw nsw i32 %i, 1
+  br label %loop
+
+done:
+  ret i32 %i
+}
+
+declare i64 @llvm.read_register.i64(metadata)
+declare i64 @llvm.read_volatile_register.i64(metadata)
+
+!1 = !{!"cntpct_el0"}
Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -5665,6 +5665,7 @@
  TLI.getFrameIndexTy(DAG.getDataLayout()),
  getValue(I.getArgOperand(0;
 return;
+  case Intrinsic::read_volatile_register:
   case Intrinsic::read_register: {
 Value *Reg = I.getArgOperand(0);
 SDValue Chain = getRoot();
Index: llvm/include/llvm/IR/Intrinsics.td
===
--- llvm/include/llvm/IR/Intrinsics.td
+++ llvm/include/llvm/IR/Intrinsics.td
@@ -456,6 +456,9 @@
[IntrReadMem], "llvm.read_register">;
 def int_write_register : Intrinsic<[], [llvm_metadata_ty, llvm_anyint_ty],
[], "llvm.write_register">;
+def int_read_volatile_register  : Intrinsic<[llvm_anyint_ty], [llvm_metadata_ty],
+[IntrHasSideEffects],
+ "llvm.read_volatile_register">;
 
 // Gets the address of the local variable area. This is typically a copy of the
 // stack, frame, or base pointer depending on the type of prologue.
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -11538,9 +11538,11 @@
 '``llvm.localrecover``'.
 
 .. _int_read_register:
+.. _int_read_volatile_register:
 .. _int_write_register:
 
-'``llvm.read_register``' and '``llvm.write_register``' Intrinsics
+'``llvm.read_register``', '``llvm.read_volatile_register``', and
+'``llvm.write_register``' Intrinsics
 ^
 
 Syntax:
@@ -11550,6 +11552,8 @@
 
   declare i32 @llvm.read_register.i32(metadata)
   declare i64 @llvm.read_register.i64(metadata)
+  declare i32 @llvm.read_volatile_register.i32(metadata)
+  declare i64 @llvm.read_volatile_register.i64(metadata)
   declare void @llvm.write_register.i32(metadata, i32 @value)
   declare void @llvm.write_register.i64(metadata, i64 @value)
   !0 = !{!"sp\00"}
@@ -11557,17 +11561,21 @@
 Overview:
 "
 
-The '``llvm.read_register``' and '``llvm.write_register``' intrinsics
-provides access to the named register. The register must be valid on
-the architecture being compiled to. The type needs to be compatible
-with the register being read.
+The '``llvm.read_register``', '``llvm.read_volatile_register``', and
+'``llvm.write_register``' intrinsics provide access to the named register.
+The register must be valid on the architecture being compiled to. The type
+needs to be compatible with the register being read.
 
 Semantics:
 ""
 
-The '``llvm.read_register``' intrinsic returns the current value of the
-register, where possible. The '``llvm.write_register``' intrinsic sets
-the current value of the register, where possible.
+The '``llvm.read_register``' and '``llvm.read_volatile_register``' intrinsics
+return the current value of the register, where possible. The
+'``llvm.write_register``' intrinsic sets the current value of the register,
+where possible.
+
+A call t

[PATCH] D80828: [Clang][A32/T32][Linux] -O2 implies -fomit-frame-pointer

2020-06-01 Thread Peter Smith via Phabricator via cfe-commits
psmith added a comment.

FWIW I'm happy for Clang to match GCC behaviour for Linux (non-Android) targets 
with respect to the frame pointer. Outside of Android I would expect most 
developers of linux applications to build with both GCC and clang so they 
should already have the -fno-omit-frame-pointer if they are using it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80828



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


[PATCH] D80911: AArch64+ARM: make LLVM consider system registers volatile to prevent unsound optimizations.

2020-06-01 Thread Tim Northover via Phabricator via cfe-commits
t.p.northover created this revision.
Herald added subscribers: danielkiss, jdoerfert, asbirlea, hiraditya, 
kristof.beyls, mcrosier.
Herald added projects: clang, LLVM.

Some of the system registers readable on AArch64 & ARM platforms return 
different values with each read (for example a timer counter), these shouldn't 
be hoisted outside loops or otherwise interfered with, but the normal 
@llvm.read_register intrinsic is only considered to read memory.

This introduces a separate @llvm.read_volatile_register intrinsic and maps all 
system-registers on ARM platforms to use it for the __builtin_arm_rsr calls. 
Registers declared with `asm("r9")` or similar are unaffected.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80911

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-arm.c
  clang/test/CodeGen/builtins-arm64.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/test/Transforms/LICM/read-volatile-register.ll

Index: llvm/test/Transforms/LICM/read-volatile-register.ll
===
--- /dev/null
+++ llvm/test/Transforms/LICM/read-volatile-register.ll
@@ -0,0 +1,30 @@
+; RUN: opt -S -licm %s | FileCheck %s
+
+; Volatile register shouldn't be hoisted ourside loops.
+define i32 @test_read() {
+; CHECK-LABEL: define i32 @test_read()
+; CHECK: br label %loop
+; CHECK: loop:
+; CHECK: %counter = tail call i64 @llvm.read_volatile_register
+
+entry:
+  br label %loop
+
+loop:
+  %i = phi i32 [ 0, %entry ], [ %i.next, %inc ]
+  %counter = tail call i64 @llvm.read_volatile_register.i64(metadata !1)
+  %tst = icmp ult i64 %counter, 1000
+  br i1 %tst, label %inc, label %done
+
+inc:
+  %i.next = add nuw nsw i32 %i, 1
+  br label %loop
+
+done:
+  ret i32 %i
+}
+
+declare i64 @llvm.read_register.i64(metadata)
+declare i64 @llvm.read_volatile_register.i64(metadata)
+
+!1 = !{!"cntpct_el0"}
Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -5665,6 +5665,7 @@
  TLI.getFrameIndexTy(DAG.getDataLayout()),
  getValue(I.getArgOperand(0;
 return;
+  case Intrinsic::read_volatile_register:
   case Intrinsic::read_register: {
 Value *Reg = I.getArgOperand(0);
 SDValue Chain = getRoot();
Index: llvm/include/llvm/IR/Intrinsics.td
===
--- llvm/include/llvm/IR/Intrinsics.td
+++ llvm/include/llvm/IR/Intrinsics.td
@@ -456,6 +456,9 @@
[IntrReadMem], "llvm.read_register">;
 def int_write_register : Intrinsic<[], [llvm_metadata_ty, llvm_anyint_ty],
[], "llvm.write_register">;
+def int_read_volatile_register  : Intrinsic<[llvm_anyint_ty], [llvm_metadata_ty],
+[IntrHasSideEffects],
+ "llvm.read_volatile_register">;
 
 // Gets the address of the local variable area. This is typically a copy of the
 // stack, frame, or base pointer depending on the type of prologue.
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -11538,9 +11538,11 @@
 '``llvm.localrecover``'.
 
 .. _int_read_register:
+.. _int_read_volatile_register:
 .. _int_write_register:
 
-'``llvm.read_register``' and '``llvm.write_register``' Intrinsics
+'``llvm.read_register``', '``llvm.read_volatile_register``', and
+'``llvm.write_register``' Intrinsics
 ^
 
 Syntax:
@@ -11550,6 +11552,8 @@
 
   declare i32 @llvm.read_register.i32(metadata)
   declare i64 @llvm.read_register.i64(metadata)
+  declare i32 @llvm.read_volatile_register.i32(metadata)
+  declare i64 @llvm.read_volatile_register.i64(metadata)
   declare void @llvm.write_register.i32(metadata, i32 @value)
   declare void @llvm.write_register.i64(metadata, i64 @value)
   !0 = !{!"sp\00"}
@@ -11557,17 +11561,21 @@
 Overview:
 "
 
-The '``llvm.read_register``' and '``llvm.write_register``' intrinsics
-provides access to the named register. The register must be valid on
-the architecture being compiled to. The type needs to be compatible
-with the register being read.
+The '``llvm.read_register``', '``llvm.read_volatile_register``', and
+'``llvm.write_register``' intrinsics provide access to the named register.
+The register must be valid on the architecture being compiled to. The type
+needs to be compatible with the register being read.
 
 Semantics:
 ""
 
-The '``llvm.read_register``' intrinsic returns the current value of the
-register, where possible. Th

[PATCH] D80800: Add an option to fully qualify classes and structs.

2020-06-01 Thread Jean-Baptiste Lespiau via Phabricator via cfe-commits
jblespiau marked an inline comment as done.
jblespiau added inline comments.



Comment at: clang/lib/AST/TypePrinter.cpp:326
+  if (Policy.FullyQualifiedName && Policy.GlobalScopeQualifiedName &&
+  T->isStructureOrClassType()) {
+OS << "::";

jblespiau wrote:
> sammccall wrote:
> > structure-or-class-type isn't quite the right check:
> >  - enums and typedefs for instance should also be qualified.
> >  - you're looking through sugar to the underlying type, which may not be 
> > what you want
> >  
> > It's going to be hard to get this right from here... I suspect it's better 
> > to fix where `FullyQualifiedName` is checked in DeclPrinter.
> > This ultimately calls through to NamedDecl::printNestedNameSpecifier, which 
> > is probably the right place to respect this option.
> > (I don't totally understand what's meant to happen if SuppressScope is 
> > false but FullyQualiifedName is also false, that calls through to 
> > NestedNameSpecifier::print which you may want to also fix, or not)
> There are several elements I do not understand (as you will see, I am 
> completely lost).
> 
> 1. I am trying to modify QualType::getAsString, and you suggest changing 
> NamecDecl. I do not understand the relationship between Qualtype and 
> NameDecl: I understand declaration within the context of C++:
> https://www.dummies.com/programming/cpp/expressions-and-declarations-in-c-programming/
> Thus, a Declaration will be made of several parts, some of which will be 
> Type. Thus, for me, the change should not be in NameDecl but in Type, to also 
> make sure the change is there both when we print a NameDecl and a type.. If 
> we modify NameDecl, then, when printing a type through Type::getAsString, we 
> won't get the global "::" specifier.
> I have understood NamedDecl::printQualifiedName calls 
> NamedDecl::printNestedNameSpecifier which calls the Type::print function, see
> https://github.com/llvm-mirror/clang/blob/master/lib/AST/Decl.cpp#L1630
> 
> => From that, I still understand I should modify how types are printed, not 
> NamedDecl. I may completely be incorrect, and I am only looking to understand.
> 
> Thus, I feel my change is correcly placed, but we can change it to be:
> 
>   if (!Policy.SuppressScope && Policy.GlobalScopeQualifiedName &&
>   (T->isStructureOrClassType() || T->isEnumeralType() ||
>isa(T))) {
> OS << "::";
>   }
> 
> Other remarks:
> 2. As documented:
> ```
>   /// When true, print the fully qualified name of function declarations.
>   /// This is the opposite of SuppressScope and thus overrules it.
>   unsigned FullyQualifiedName : 1;
> ```
> 
>  FullyQualifiedName is only controlling the fully-qualification of functions.
> https://github.com/llvm/llvm-project/blob/a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69/clang/lib/AST/DeclPrinter.cpp#L625
> 
> So I do not think we have to follow this.
> 
> I think it is `SuppressScope` which controls whether it is fully qualified or 
> not,:
> https://github.com/llvm/llvm-project/blob/a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69/clang/lib/AST/DeclPrinter.cpp#L629
> 
> If Policy.SuppressScope is False, then I understand it's fully qualified.
> 
> 3. "you're looking through sugar to the underlying type, which may not be 
> what you want": I do not understand "sugar" in that context. I have read this 
> name in the code in clang, but still, I do not understand it. I only know 
> https://en.wikipedia.org/wiki/Syntactic_sugar, which does not seem to apply 
> here (Obviously, I am not a native English speaker).
> 
> For the testing:
> 
> Building and running
> 
> 
> After > 90minutes of building with:
> cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm
> make check-clang
> 
> It took me quite a while to find how to execute a single test file:
> 
> ~/llvm-project/build/tools/clang/unittests/AST]
> └──╼ make -j12 ASTTests && ./ASTTests --gtest_filter=NamedDeclPrinter*
> 
> did the job. 
> 
> - NamedDeclPrinterTest.cpp  feels strange for the tests, as what I am 
> modifying is not NamedDecl, but Qualtype::getAsString. But given there is no 
> TypeTest.cpp, maybe it's best location.
> 
> 
> I must admit that I am struggling a lot to understand both the execution flow 
> and the code itself :(
> 
(I had issues with the formatting in Markdown. The big bold was not intended to 
be big and bold^^ Sorry).


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

https://reviews.llvm.org/D80800



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


[PATCH] D80896: [clang-tidy][misc-redundant-expression] Support for CXXFoldExpr

2020-06-01 Thread Zinovy Nis via Phabricator via cfe-commits
zinovy.nis marked 2 inline comments as done.
zinovy.nis added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp:18
 
+namespace no_crash {
+struct Foo {};

I had to move this up as no warnings were generated in the original test code 
despite -fno-delayed-template-parsing.


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

https://reviews.llvm.org/D80896



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


[PATCH] D80896: [clang-tidy][misc-redundant-expression] Support for CXXFoldExpr

2020-06-01 Thread Zinovy Nis via Phabricator via cfe-commits
zinovy.nis updated this revision to Diff 267565.
zinovy.nis added a comment.

- Fix test.
- Simplify the code.


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

https://reviews.llvm.org/D80896

Files:
  clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp


Index: clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
@@ -15,6 +15,30 @@
 extern int bar(int x);
 extern int bat(int x, int y);
 
+namespace no_crash {
+struct Foo {};
+bool operator<(const Foo &, const Foo &);
+template 
+struct Bar {
+  static const Foo &GetFoo();
+  static bool Test(const T &maybe_foo, const Foo &foo) {
+return foo < GetFoo() && foo < maybe_foo;
+  }
+};
+
+template 
+struct Bar2 {
+  static_assert((... && (sizeof(Values) > 0)) || (... && (sizeof(Values) > 
0)));
+  // CHECK-MESSAGES: :[[@LINE-1]]:47: warning: both sides of operator are 
equivalent [misc-redundant-expression]
+};
+} // namespace no_crash
+
+template 
+int TestOperatorConfusionDependent(int Y) {
+  int r1 = (Y << Shift) & 0xff;
+  int r2 = (Y << 8) & Mask;
+}
+
 int TestSimpleEquivalent(int X, int Y) {
   if (X - X) return 1;
   // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: both sides of operator are 
equivalent [misc-redundant-expression]
@@ -774,23 +798,6 @@
   // CHECK-FIXES: {{^}}  return ~(1 | 2 | 4);{{$}}
 }
 
-template 
-int TestOperatorConfusionDependent(int Y) {
-  int r1 = (Y << Shift) & 0xff;
-  int r2 = (Y << 8) & Mask;
-}
 #undef FLAG1
 #undef FLAG2
 #undef FLAG3
-
-namespace no_crash {
-struct Foo {};
-bool operator<(const Foo&, const Foo&);
-template 
-struct Bar {
-  static const Foo &GetFoo();
-  static bool Test(const T & maybe_foo, const Foo& foo) {
-return foo < GetFoo() && foo < maybe_foo;
-  }
-};
-}
Index: clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
===
--- clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
+++ clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
@@ -72,8 +72,8 @@
   Expr::const_child_iterator LeftIter = Left->child_begin();
   Expr::const_child_iterator RightIter = Right->child_begin();
   while (LeftIter != Left->child_end() && RightIter != Right->child_end()) {
-if (!areEquivalentExpr(dyn_cast(*LeftIter),
-   dyn_cast(*RightIter)))
+if (!areEquivalentExpr(dyn_cast_or_null(*LeftIter),
+   dyn_cast_or_null(*RightIter)))
   return false;
 ++LeftIter;
 ++RightIter;
@@ -117,6 +117,9 @@
   case Stmt::MemberExprClass:
 return cast(Left)->getMemberDecl() ==
cast(Right)->getMemberDecl();
+  case Stmt::CXXFoldExprClass:
+return cast(Left)->getOperator() ==
+   cast(Right)->getOperator();
   case Stmt::CXXFunctionalCastExprClass:
   case Stmt::CStyleCastExprClass:
 return cast(Left)->getTypeAsWritten() ==


Index: clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc-redundant-expression.cpp
@@ -15,6 +15,30 @@
 extern int bar(int x);
 extern int bat(int x, int y);
 
+namespace no_crash {
+struct Foo {};
+bool operator<(const Foo &, const Foo &);
+template 
+struct Bar {
+  static const Foo &GetFoo();
+  static bool Test(const T &maybe_foo, const Foo &foo) {
+return foo < GetFoo() && foo < maybe_foo;
+  }
+};
+
+template 
+struct Bar2 {
+  static_assert((... && (sizeof(Values) > 0)) || (... && (sizeof(Values) > 0)));
+  // CHECK-MESSAGES: :[[@LINE-1]]:47: warning: both sides of operator are equivalent [misc-redundant-expression]
+};
+} // namespace no_crash
+
+template 
+int TestOperatorConfusionDependent(int Y) {
+  int r1 = (Y << Shift) & 0xff;
+  int r2 = (Y << 8) & Mask;
+}
+
 int TestSimpleEquivalent(int X, int Y) {
   if (X - X) return 1;
   // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: both sides of operator are equivalent [misc-redundant-expression]
@@ -774,23 +798,6 @@
   // CHECK-FIXES: {{^}}  return ~(1 | 2 | 4);{{$}}
 }
 
-template 
-int TestOperatorConfusionDependent(int Y) {
-  int r1 = (Y << Shift) & 0xff;
-  int r2 = (Y << 8) & Mask;
-}
 #undef FLAG1
 #undef FLAG2
 #undef FLAG3
-
-namespace no_crash {
-struct Foo {};
-bool operator<(const Foo&, const Foo&);
-template 
-struct Bar {
-  static const Foo &GetFoo();
-  static bool Test(const T & maybe_foo, const Foo& foo) {
-return foo < GetFoo() && foo < maybe_foo;
-  }
-};
-}
Index: clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
=

[PATCH] D80913: [update_cc_test_checks.py] Correctly skip function definitions

2020-06-01 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson created this revision.
arichardson added a reviewer: MaskRay.
Herald added subscribers: llvm-commits, cfe-commits, kristof.beyls.
Herald added projects: clang, LLVM.

Function declarations can in fact have an 'inner' node that lists the
ParmVarDecls. It seems like either the JSON output has changed or that I
tested the original JSON parsing change with test files that only have
function definitions without arguments.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80913

Files:
  clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c
  clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c.expected
  llvm/utils/update_cc_test_checks.py

Index: llvm/utils/update_cc_test_checks.py
===
--- llvm/utils/update_cc_test_checks.py
+++ llvm/utils/update_cc_test_checks.py
@@ -73,8 +73,18 @@
 if line is None:
   common.debug('Skipping function without line number:', node['name'], '@', node['loc'])
   return
-# If there is no 'inner' object, it is a function declaration -> skip
-if 'inner' not in node:
+
+# If there is no 'inner' object, it is a function declaration and we can
+# skip it. However, function declarations may also contain an 'inner' list,
+# but in that case it will only contains ParmVarDecls. If we find an entry
+# that is not a ParmVarDecl, we know that this is a function definition.
+has_body = False
+if 'inner' in node:
+  for i in node['inner']:
+if i.get('kind', 'ParmVarDecl') != 'ParmVarDecl':
+  has_body = True
+  break
+if not has_body:
   common.debug('Skipping function without body:', node['name'], '@', node['loc'])
   return
 spell = node['name']
Index: clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c.expected
===
--- clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c.expected
+++ clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c.expected
@@ -2,33 +2,36 @@
 // Check that the CHECK lines are generated before the definition and not the declaration
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu %s -emit-llvm -o - | FileCheck %s
 
-int foo();
+int foo(int arg);
 
-void empty_function();
+void empty_function(void);
 
 // CHECK-LABEL: @main(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[RETVAL:%.*]] = alloca i32, align 4
 // CHECK-NEXT:store i32 0, i32* [[RETVAL]], align 4
 // CHECK-NEXT:call void @empty_function()
-// CHECK-NEXT:[[CALL:%.*]] = call i32 @foo()
+// CHECK-NEXT:[[CALL:%.*]] = call i32 @foo(i32 1)
 // CHECK-NEXT:ret i32 [[CALL]]
 //
 int main() {
   empty_function();
-  return foo();
+  return foo(1);
 }
 
 // CHECK-LABEL: @foo(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:ret i32 1
+// CHECK-NEXT:[[ARG_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i32 [[ARG:%.*]], i32* [[ARG_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[ARG_ADDR]], align 4
+// CHECK-NEXT:ret i32 [[TMP0]]
 //
-int foo() {
-  return 1;
+int foo(int arg) {
+  return arg;
 }
 
 // CHECK-LABEL: @empty_function(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:ret void
 //
-void empty_function() {}
+void empty_function(void) {}
Index: clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c
===
--- clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c
+++ clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c
@@ -1,17 +1,17 @@
 // Check that the CHECK lines are generated before the definition and not the declaration
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu %s -emit-llvm -o - | FileCheck %s
 
-int foo();
+int foo(int arg);
 
-void empty_function();
+void empty_function(void);
 
 int main() {
   empty_function();
-  return foo();
+  return foo(1);
 }
 
-int foo() {
-  return 1;
+int foo(int arg) {
+  return arg;
 }
 
-void empty_function() {}
+void empty_function(void) {}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80914: [update_cc_test_checks.py] Handle C++ methods

2020-06-01 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson created this revision.
arichardson added a reviewer: MaskRay.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Previously the script only handled C input, this change extends the JSON
parsing to to also include C++ function types such as methods, constructors
and destructors.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80914

Files:
  clang/test/utils/update_cc_test_checks/Inputs/basic-cplusplus.cpp
  clang/test/utils/update_cc_test_checks/Inputs/basic-cplusplus.cpp.expected
  clang/test/utils/update_cc_test_checks/basic-cplusplus.test
  llvm/utils/update_cc_test_checks.py

Index: llvm/utils/update_cc_test_checks.py
===
--- llvm/utils/update_cc_test_checks.py
+++ llvm/utils/update_cc_test_checks.py
@@ -58,11 +58,14 @@
   def parse_clang_ast_json(node):
 node_kind = node['kind']
 # Recurse for the following nodes that can contain nested function decls:
-if node_kind in ('NamespaceDecl', 'LinkageSpecDecl', 'TranslationUnitDecl'):
-  for inner in node['inner']:
-parse_clang_ast_json(inner)
+if node_kind in ('NamespaceDecl', 'LinkageSpecDecl', 'TranslationUnitDecl',
+ 'CXXRecordDecl'):
+  if 'inner' in node:
+for inner in node['inner']:
+  parse_clang_ast_json(inner)
 # Otherwise we ignore everything except functions:
-if node['kind'] != 'FunctionDecl':
+if node_kind not in ('FunctionDecl', 'CXXMethodDecl', 'CXXConstructorDecl',
+ 'CXXDestructorDecl', 'CXXConversionDecl'):
   return
 if node.get('isImplicit') is True and node.get('storageClass') == 'extern':
   common.debug('Skipping builtin function:', node['name'], '@', node['loc'])
Index: clang/test/utils/update_cc_test_checks/basic-cplusplus.test
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/basic-cplusplus.test
@@ -0,0 +1,7 @@
+## Test that CHECK lines are generated before the definion and not the declaration
+
+# RUN: cp %S/Inputs/basic-cplusplus.cpp %t.cpp && %update_cc_test_checks %t.cpp
+# RUN: diff -u %S/Inputs/basic-cplusplus.cpp.expected %t.cpp
+## Check that re-running update_cc_test_checks doesn't change the output
+# RUN: %update_cc_test_checks %t.cpp
+# RUN: diff -u %S/Inputs/basic-cplusplus.cpp.expected %t.cpp
Index: clang/test/utils/update_cc_test_checks/Inputs/basic-cplusplus.cpp.expected
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/Inputs/basic-cplusplus.cpp.expected
@@ -0,0 +1,80 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// Basic C++ test for update_cc_test_checks
+// RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s
+
+class Foo {
+  int x;
+
+public:
+  explicit Foo(int x);
+  ~Foo();
+// CHECK-LABEL: @_ZNK3Foo23function_defined_inlineEi(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[THIS_ADDR:%.*]] = alloca %class.Foo*, align 8
+// CHECK-NEXT:[[ARG_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store %class.Foo* [[THIS:%.*]], %class.Foo** [[THIS_ADDR]], align 8
+// CHECK-NEXT:store i32 [[ARG:%.*]], i32* [[ARG_ADDR]], align 4
+// CHECK-NEXT:[[THIS1:%.*]] = load %class.Foo*, %class.Foo** [[THIS_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[ARG_ADDR]], align 4
+// CHECK-NEXT:[[X:%.*]] = getelementptr inbounds [[CLASS_FOO:%.*]], %class.Foo* [[THIS1]], i32 0, i32 0
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[X]], align 4
+// CHECK-NEXT:[[ADD:%.*]] = add nsw i32 [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret i32 [[ADD]]
+//
+  inline int function_defined_inline(int arg) const {
+return arg + x;
+  }
+  inline int function_defined_out_of_line(int arg) const;
+};
+
+// CHECK-LABEL: @_ZN3FooC1Ei(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[THIS_ADDR:%.*]] = alloca %class.Foo*, align 8
+// CHECK-NEXT:[[X_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store %class.Foo* [[THIS:%.*]], %class.Foo** [[THIS_ADDR]], align 8
+// CHECK-NEXT:store i32 [[X:%.*]], i32* [[X_ADDR]], align 4
+// CHECK-NEXT:[[THIS1:%.*]] = load %class.Foo*, %class.Foo** [[THIS_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[X_ADDR]], align 4
+// CHECK-NEXT:call void @_ZN3FooC2Ei(%class.Foo* [[THIS1]], i32 [[TMP0]])
+// CHECK-NEXT:ret void
+//
+Foo::Foo(int x) : x(x) {}
+// CHECK-LABEL: @_ZN3FooD1Ev(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[THIS_ADDR:%.*]] = alloca %class.Foo*, align 8
+// CHECK-NEXT:store %class.Foo* [[THIS:%.*]], %class.Foo** [[THIS_ADDR]], align 8
+// CHECK-NEXT:[[THIS1:%.*]] = load %class.Foo*, %class.Foo** [[THIS_ADDR]], align 8
+// CHECK-NEXT:call void @_ZN3FooD2Ev(%class.Foo* [[THIS1]]) #2
+// CHECK-NEXT:ret void
+//
+Foo::~Foo() {}
+// CHECK-LABEL: @_ZNK3Foo28fu

[clang] e5b8772 - [utils] change default nameless value to "TMP"

2020-06-01 Thread Sanjay Patel via cfe-commits
Author: Sanjay Patel
Date: 2020-06-01T06:54:45-04:00
New Revision: e5b8772756737e41cb1e8ee1a5a33cb3d8a25be6

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

LOG: [utils] change default nameless value to "TMP"

This is effectively reverting rGbfdc2552664d to avoid test churn
while we figure out a better way forward.

We at least salvage the warning on name conflict from that patch
though.

If we change the default string again, we may want to mass update
tests at the same time. Alternatively, we could live with the poor
naming if we change -instnamer.

This also adds a test to LLVM as suggested in the post-commit
review. There's a clang test that is also affected. That seems
like a layering violation, but I have not looked at fixing that yet.

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

Added: 


Modified: 
clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.expected

clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.expected

llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
llvm/utils/UpdateTestChecks/common.py

Removed: 




diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.expected 
b/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.expected
index 6ea154286c15..d6ba7ae09b62 100644
--- a/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.expected
+++ b/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.expected
@@ -8,10 +8,10 @@
 // CHECK-NEXT:[[B_ADDR:%.*]] = alloca i32, align 4
 // CHECK-NEXT:store i64 [[A:%.*]], i64* [[A_ADDR]], align 8
 // CHECK-NEXT:store i32 [[B:%.*]], i32* [[B_ADDR]], align 4
-// CHECK-NEXT:[[NAMELESS0:%.*]] = load i64, i64* [[A_ADDR]], align 8
-// CHECK-NEXT:[[NAMELESS1:%.*]] = load i32, i32* [[B_ADDR]], align 4
-// CHECK-NEXT:[[CONV:%.*]] = sext i32 [[NAMELESS1]] to i64
-// CHECK-NEXT:[[ADD:%.*]] = add nsw i64 [[NAMELESS0]], [[CONV]]
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, i64* [[A_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[B_ADDR]], align 4
+// CHECK-NEXT:[[CONV:%.*]] = sext i32 [[TMP1]] to i64
+// CHECK-NEXT:[[ADD:%.*]] = add nsw i64 [[TMP0]], [[CONV]]
 // CHECK-NEXT:ret i64 [[ADD]]
 //
 long test(long a, int b) {
@@ -27,12 +27,12 @@ long test(long a, int b) {
 // CHECK-NEXT:store i64 [[A:%.*]], i64* [[A_ADDR]], align 8
 // CHECK-NEXT:store i32 [[B:%.*]], i32* [[B_ADDR]], align 4
 // CHECK-NEXT:store i32 [[C:%.*]], i32* [[C_ADDR]], align 4
-// CHECK-NEXT:[[NAMELESS0:%.*]] = load i64, i64* [[A_ADDR]], align 8
-// CHECK-NEXT:[[NAMELESS1:%.*]] = load i32, i32* [[B_ADDR]], align 4
-// CHECK-NEXT:[[CONV:%.*]] = sext i32 [[NAMELESS1]] to i64
-// CHECK-NEXT:[[ADD:%.*]] = add nsw i64 [[NAMELESS0]], [[CONV]]
-// CHECK-NEXT:[[NAMELESS2:%.*]] = load i32, i32* [[C_ADDR]], align 4
-// CHECK-NEXT:[[CONV1:%.*]] = sext i32 [[NAMELESS2]] to i64
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, i64* [[A_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[B_ADDR]], align 4
+// CHECK-NEXT:[[CONV:%.*]] = sext i32 [[TMP1]] to i64
+// CHECK-NEXT:[[ADD:%.*]] = add nsw i64 [[TMP0]], [[CONV]]
+// CHECK-NEXT:[[TMP2:%.*]] = load i32, i32* [[C_ADDR]], align 4
+// CHECK-NEXT:[[CONV1:%.*]] = sext i32 [[TMP2]] to i64
 // CHECK-NEXT:[[ADD2:%.*]] = add nsw i64 [[ADD]], [[CONV1]]
 // CHECK-NEXT:ret i64 [[ADD2]]
 //

diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
 
b/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
index dbe1296182aa..005b2f242747 100644
--- 
a/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
+++ 
b/clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
@@ -9,10 +9,10 @@
 // CHECK-NEXT:[[B_ADDR:%.*]] = alloca i32, align 4
 // CHECK-NEXT:store i64 [[A]], i64* [[A_ADDR]], align 8
 // CHECK-NEXT:store i32 [[B]], i32* [[B_ADDR]], align 4
-// CHECK-NEXT:[[NAMELESS0:%.*]] = load i64, i64* [[A_ADDR]], align 8
-// CHECK-NEXT:[[NAMELESS1:%.*]] = load i32, i32* [[B_ADDR]], align 4
-// CHECK-NEXT:[[CONV:%.*]] = sext i32 [[NAMELESS1]] to i64
-// CHECK-NEXT:[[ADD:%.*]] = add nsw i64 [[NAMELESS0]], [[CONV]]
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, i64* [[A_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[B_ADDR]], align 4
+// CHECK-NEXT:[[CONV:%.*]] = sext i32 [[TMP1]] to i64
+// CHECK-NEXT:[[ADD:%.*]] = add nsw i64 [[TMP0]], [[CONV]]
 // CHECK-NEXT:ret i64 [

[PATCH] D80903: [analyzer] Ignore calculated indices of <= 0 in VLASizeChecker

2020-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp:114-115
 // Convert the array length to size_t.
 NonLoc IndexLength =
 SVB.evalCast(SizeD, SizeTy, SizeE->getType()).castAs();
 // Multiply the array length by the element size.

Do i understand correctly that this cast is the only difference between the 
value that has been checked and the value on which the assertion is asserted?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80903



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


[PATCH] D80917: [OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 2

2020-06-01 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam created this revision.
saiislam added reviewers: arsenm, sameerds, jdoerfert, yaxunl, b-sumner, 
scchan, JonChesterfield.
Herald added subscribers: cfe-commits, sstefan1, kerbowa, guansong, nhaehnle, 
wdng, jvesely, jholewinski.
Herald added a project: clang.
saiislam added a parent revision: D79754: [OpenMP][AMDGCN] Support OpenMP 
offloading for AMDGCN architecture - Part 1.

New file include to support platform dependent grid constants. It will be
used by clang, libomptarget plugins, and deviceRTLs to access constant
values consistently and with fast access in the deviceRTLs.

Originally authored by Greg Rodgers (@gregrodgers).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80917

Files:
  clang/include/clang/Basic/OpenMPGridValues.h
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp

Index: clang/lib/Basic/Targets/NVPTX.cpp
===
--- clang/lib/Basic/Targets/NVPTX.cpp
+++ clang/lib/Basic/Targets/NVPTX.cpp
@@ -14,6 +14,7 @@
 #include "Targets.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Basic/MacroBuilder.h"
+#include "clang/Basic/OpenMPGridValues.h"
 #include "clang/Basic/TargetBuiltins.h"
 #include "llvm/ADT/StringSwitch.h"
 
@@ -62,6 +63,8 @@
   TLSSupported = false;
   VLASupported = false;
   AddrSpaceMap = &NVPTXAddrSpaceMap;
+  GridValues = (const int *)&(GPU::NVPTXGpuGridValues[0]);
+  LongGridValues = (const long long *)&(GPU::NVPTXGpuLongGridValues[0]);
   UseAddrSpaceMapMangling = true;
 
   // Define available target features
Index: clang/lib/Basic/Targets/AMDGPU.cpp
===
--- clang/lib/Basic/Targets/AMDGPU.cpp
+++ clang/lib/Basic/Targets/AMDGPU.cpp
@@ -15,6 +15,7 @@
 #include "clang/Basic/CodeGenOptions.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/MacroBuilder.h"
+#include "clang/Basic/OpenMPGridValues.h"
 #include "clang/Basic/TargetBuiltins.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/IR/DataLayout.h"
@@ -286,6 +287,8 @@
   resetDataLayout(isAMDGCN(getTriple()) ? DataLayoutStringAMDGCN
 : DataLayoutStringR600);
   assert(DataLayout->getAllocaAddrSpace() == Private);
+  GridValues = (const int *)&(GPU::AMDGPUGpuGridValues[0]);
+  LongGridValues = (const long long *)&(GPU::AMDGPUGpuLongGridValues[0]);
 
   setAddressSpaceMap(Triple.getOS() == llvm::Triple::Mesa3D ||
  !isAMDGCN(Triple));
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -15,8 +15,10 @@
 #define LLVM_CLANG_BASIC_TARGETINFO_H
 
 #include "clang/Basic/AddressSpaces.h"
+#include "clang/Basic/CodeGenOptions.h"
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/LangOptions.h"
+#include "clang/Basic/OpenMPGridValues.h"
 #include "clang/Basic/Specifiers.h"
 #include "clang/Basic/TargetCXXABI.h"
 #include "clang/Basic/TargetOptions.h"
@@ -196,6 +198,8 @@
   unsigned char RegParmMax, SSERegParmMax;
   TargetCXXABI TheCXXABI;
   const LangASMap *AddrSpaceMap;
+  const int *GridValues;
+  const long long int *LongGridValues;
 
   mutable StringRef PlatformName;
   mutable VersionTuple PlatformMinVersion;
@@ -1306,6 +1310,12 @@
 return LangAS::Default;
   }
 
+  int getGridValue(GPU::GVIDX gv) const { return GridValues[gv]; }
+
+  long long getLongGridValue(GPU::GVLIDX gv) const {
+return LongGridValues[gv];
+  }
+
   /// Retrieve the name of the platform as it is used in the
   /// availability attribute.
   StringRef getPlatformName() const { return PlatformName; }
Index: clang/include/clang/Basic/OpenMPGridValues.h
===
--- /dev/null
+++ clang/include/clang/Basic/OpenMPGridValues.h
@@ -0,0 +1,134 @@
+//===--- OpenMPGridValues.h - Language-specific address spaces --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+///
+/// \file
+/// \brief Provides definitions for Target specific Grid Values
+///
+//===--===//
+
+#ifndef LLVM_CLANG_BASIC_OPENMPGRIDVALUES_H
+#define LLVM_CLANG_BASIC_OPENMPGRIDVALUES_H
+
+namespace clang {
+
+namespace GPU {
+
+/// \brief Defines various target-specific Gpu grid values that must be
+///consistent between host RTL (plugin), device RTL, and clang.
+///By adding this to TargetInfo in clang, we can change grid values
+///for a "fat" binary so that different passes get the correct values
+///when generating code for a multi-target binary. Both amdgc

[PATCH] D80584: [utils] change update_test_checks.py use of 'TMP' value names

2020-06-01 Thread Sanjay Patel via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe5b877275673: [utils] change default nameless value to 
"TMP" (authored by spatel).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D80584?vs=267500&id=267582#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80584

Files:
  clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.expected
  clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
  llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll
  llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.expected
  
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
  llvm/utils/UpdateTestChecks/common.py

Index: llvm/utils/UpdateTestChecks/common.py
===
--- llvm/utils/UpdateTestChecks/common.py
+++ llvm/utils/UpdateTestChecks/common.py
@@ -218,7 +218,7 @@
 # spaces, commas, paren, or end of the string
 IR_VALUE_RE = re.compile(r'(\s+)%([\w.-]+?)([,\s\(\)]|\Z)')
 
-NAMELESS_PREFIX = "NAMELESS"
+NAMELESS_PREFIX = "TMP"
 
 # Create a FileCheck variable name based on an IR name.
 def get_value_name(var):
Index: llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
===
--- llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
+++ llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.funcsig.expected
@@ -1,5 +1,5 @@
 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --function-signature
-; Example input for update_llc_test_checks (taken from test/Transforms/InstSimplify/add.ll)
+; Example input for update_test_checks (taken from test/Transforms/InstSimplify/add.ll)
 ; RUN: opt < %s -instsimplify -S | FileCheck %s
 
 define i32 @common_sub_operand(i32 %X, i32 %Y) {
@@ -53,3 +53,13 @@
   %r = add <2 x i8> %yx, %xy
   ret <2 x i8> %r
 }
+
+define i32 @nameless_value(i32 %X) {
+; CHECK-LABEL: define {{[^@]+}}@nameless_value
+; CHECK-SAME: (i32 [[X:%.*]])
+; CHECK-NEXT:[[TMP1:%.*]] = sub i32 42, [[X]]
+; CHECK-NEXT:ret i32 [[TMP1]]
+;
+  %1 = sub i32 42, %X
+  ret i32 %1
+}
Index: llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.expected
===
--- llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.expected
+++ llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.expected
@@ -1,5 +1,5 @@
 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
-; Example input for update_llc_test_checks (taken from test/Transforms/InstSimplify/add.ll)
+; Example input for update_test_checks (taken from test/Transforms/InstSimplify/add.ll)
 ; RUN: opt < %s -instsimplify -S | FileCheck %s
 
 define i32 @common_sub_operand(i32 %X, i32 %Y) {
@@ -48,3 +48,12 @@
   %r = add <2 x i8> %yx, %xy
   ret <2 x i8> %r
 }
+
+define i32 @nameless_value(i32 %X) {
+; CHECK-LABEL: @nameless_value(
+; CHECK-NEXT:[[TMP1:%.*]] = sub i32 42, [[X:%.*]]
+; CHECK-NEXT:ret i32 [[TMP1]]
+;
+  %1 = sub i32 42, %X
+  ret i32 %1
+}
Index: llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll
===
--- llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll
+++ llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll
@@ -1,4 +1,4 @@
-; Example input for update_llc_test_checks (taken from test/Transforms/InstSimplify/add.ll)
+; Example input for update_test_checks (taken from test/Transforms/InstSimplify/add.ll)
 ; RUN: opt < %s -instsimplify -S | FileCheck %s
 
 define i32 @common_sub_operand(i32 %X, i32 %Y) {
@@ -47,3 +47,12 @@
   %r = add <2 x i8> %yx, %xy
   ret <2 x i8> %r
 }
+
+define i32 @nameless_value(i32 %X) {
+; CHECK-LABEL: @nameless_value(
+; CHECK-NEXT:[[TMP1:%.*]] = sub i32 42, [[X:%.*]]
+; CHECK-NEXT:ret i32 [[TMP1]]
+;
+  %1 = sub i32 42, %X
+  ret i32 %1
+}
Index: clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
===
--- clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
+++ clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
@@ -9,10 +9,10 @@
 // CHECK-NEXT:[[B_ADDR:%.*]] = alloca i32, align 4
 // CHECK-NEXT:store i64 [[A]], i64* [[A_ADDR]], align 8
 // CHECK-NEXT:store i32 [[B]], i32* [[B_ADDR]], align 4
-// CHECK-NEXT:[[NAMELESS0:%.*]] = load i64, i64* [[A_ADDR]], align 8
-// CHECK-NEXT:[[NAMELESS1:%.*]] = load i32, i32* [[B_ADDR]], align 4
-// CHECK-NEXT:[[CONV:%.*]] = sext i32 [[NAMELESS1]] to i64
-// 

[PATCH] D80905: [analyzer] Introduce weak dependencies to express *preferred* checker callback evaluation order

2020-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

I think this patch is a fairly historic moment to celebratte.

> checker callback evaluation order is ensured

And it will be the same for all callbacks, right? Like, we're not doing this 
thing yet where it intentionally goes like

  chk1->checkPreCall();
  chk2->checkPreCall();
  chk2->checkPostCall();
  chk1->checkPostCall();

?




Comment at: clang/include/clang/StaticAnalyzer/Checkers/CheckerBase.td:141-142
+/// Describes preferred registration and evaluation order in between checkers.
+/// Unlike strong dependencies, this expresses dependencies in between
+/// diagnostics, and *not* modeling. In the case of an unsatisfied (disabled)
+/// weak dependency, the dependent checker might still be registered. If the

I wouldn't mind having predictable callback evaluation order for modeling as 
well. What's causing you to drop this scenario?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80905



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


[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

2020-06-01 Thread Mateusz Mikuła via Phabricator via cfe-commits
mati865 added a comment.

Wouldn't it better fit in `AddLibGCC`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80880



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


[PATCH] D80584: [utils] change update_test_checks.py use of 'TMP' value names

2020-06-01 Thread Sanjay Patel via Phabricator via cfe-commits
spatel reopened this revision.
spatel added a comment.
This revision is now accepted and ready to land.

Effectively reverted (but still have the name conflict warning at least) with:
rGe5b877275673 


If we can change instnamer, we can probably keep living with this script as-is. 
Alternatively, let's re-fix this script and mass update test files, so there's 
no general concern about churn of existing tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80584



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


[PATCH] D80800: Add an option to fully qualify classes and structs.

2020-06-01 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

In D80800#2065643 , @jblespiau wrote:

> I did spend a few hours, just building and finding how to run tests :(


Sorry about that :-(
For what it's worth, building with Ninja should be significantly faster by 
default: https://llvm.org/docs/GettingStarted.html
But yes, building LLVM is very slow unless you have a powerful machine.

> I have a few additional questions, as I do not really understand what happen. 
> In my initial idea, I wanted to modify the way QualType are printed, not 
> really declarations, but I feel the logic is duplicated somewhere, and that 
> both NamedDecl and Type are implementing the logic.

Yes, I think you're right, sorry - I assumed these were sharing code. (This is 
why we need tests!)
Both cases need to be modified: PrintingPolicy is used for printing both Types 
and Decls, and the new option would need to apply to both cases.

The idea that the namespace prefix should be "sunk" down to where we know more 
about the structure of the type seems valid though: if you look at where the 
site you've found prints the scope, it calls printRecordBefore -> printTag -> 
AppendScope, the latter is probably the right place to modify for Type.




Comment at: clang/lib/AST/TypePrinter.cpp:326
+  if (Policy.FullyQualifiedName && Policy.GlobalScopeQualifiedName &&
+  T->isStructureOrClassType()) {
+OS << "::";

jblespiau wrote:
> jblespiau wrote:
> > sammccall wrote:
> > > structure-or-class-type isn't quite the right check:
> > >  - enums and typedefs for instance should also be qualified.
> > >  - you're looking through sugar to the underlying type, which may not be 
> > > what you want
> > >  
> > > It's going to be hard to get this right from here... I suspect it's 
> > > better to fix where `FullyQualifiedName` is checked in DeclPrinter.
> > > This ultimately calls through to NamedDecl::printNestedNameSpecifier, 
> > > which is probably the right place to respect this option.
> > > (I don't totally understand what's meant to happen if SuppressScope is 
> > > false but FullyQualiifedName is also false, that calls through to 
> > > NestedNameSpecifier::print which you may want to also fix, or not)
> > There are several elements I do not understand (as you will see, I am 
> > completely lost).
> > 
> > 1. I am trying to modify QualType::getAsString, and you suggest changing 
> > NamecDecl. I do not understand the relationship between Qualtype and 
> > NameDecl: I understand declaration within the context of C++:
> > https://www.dummies.com/programming/cpp/expressions-and-declarations-in-c-programming/
> > Thus, a Declaration will be made of several parts, some of which will be 
> > Type. Thus, for me, the change should not be in NameDecl but in Type, to 
> > also make sure the change is there both when we print a NameDecl and a 
> > type.. If we modify NameDecl, then, when printing a type through 
> > Type::getAsString, we won't get the global "::" specifier.
> > I have understood NamedDecl::printQualifiedName calls 
> > NamedDecl::printNestedNameSpecifier which calls the Type::print function, 
> > see
> > https://github.com/llvm-mirror/clang/blob/master/lib/AST/Decl.cpp#L1630
> > 
> > => From that, I still understand I should modify how types are printed, not 
> > NamedDecl. I may completely be incorrect, and I am only looking to 
> > understand.
> > 
> > Thus, I feel my change is correcly placed, but we can change it to be:
> > 
> >   if (!Policy.SuppressScope && Policy.GlobalScopeQualifiedName &&
> >   (T->isStructureOrClassType() || T->isEnumeralType() ||
> >isa(T))) {
> > OS << "::";
> >   }
> > 
> > Other remarks:
> > 2. As documented:
> > ```
> >   /// When true, print the fully qualified name of function declarations.
> >   /// This is the opposite of SuppressScope and thus overrules it.
> >   unsigned FullyQualifiedName : 1;
> > ```
> > 
> >  FullyQualifiedName is only controlling the fully-qualification of 
> > functions.
> > https://github.com/llvm/llvm-project/blob/a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69/clang/lib/AST/DeclPrinter.cpp#L625
> > 
> > So I do not think we have to follow this.
> > 
> > I think it is `SuppressScope` which controls whether it is fully qualified 
> > or not,:
> > https://github.com/llvm/llvm-project/blob/a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69/clang/lib/AST/DeclPrinter.cpp#L629
> > 
> > If Policy.SuppressScope is False, then I understand it's fully qualified.
> > 
> > 3. "you're looking through sugar to the underlying type, which may not be 
> > what you want": I do not understand "sugar" in that context. I have read 
> > this name in the code in clang, but still, I do not understand it. I only 
> > know https://en.wikipedia.org/wiki/Syntactic_sugar, which does not seem to 
> > apply here (Obviously, I am not a native English speaker).
> > 
> > For the testing:
> > 
> > Building and running
> > 
> > 
>

[PATCH] D78933: [analyzer] RangeConstraintManager optimizations in comparison expressions

2020-06-01 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov updated this revision to Diff 267587.
ASDenysPetrov added a comment.

Updated due to comments.


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

https://reviews.llvm.org/D78933

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constraint_manager_conditions.cpp

Index: clang/test/Analysis/constraint_manager_conditions.cpp
===
--- /dev/null
+++ clang/test/Analysis/constraint_manager_conditions.cpp
@@ -0,0 +1,213 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(int);
+
+void comparison_lt(int x, int y) {
+  if (x < y) {
+clang_analyzer_eval(x < y);  // expected-warning{{TRUE}}
+clang_analyzer_eval(y > x);  // expected-warning{{TRUE}}
+clang_analyzer_eval(x > y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y < x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x <= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y >= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x >= y); // expected-warning{{FALSE}}
+clang_analyzer_eval(y <= x); // expected-warning{{FALSE}}
+clang_analyzer_eval(x == y); // expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expected-warning{{FALSE}}
+clang_analyzer_eval(x != y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y != x); // expected-warning{{TRUE}}
+  } else {
+clang_analyzer_eval(x < y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y > x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x > y);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y < x);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x <= y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y >= x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x >= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y <= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x == y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x != y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y != x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+  }
+}
+
+void comparison_gt(int x, int y) {
+  if (x > y) {
+clang_analyzer_eval(x < y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y > x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x > y);  // expected-warning{{TRUE}}
+clang_analyzer_eval(y < x);  // expected-warning{{TRUE}}
+clang_analyzer_eval(x <= y); // expected-warning{{FALSE}}
+clang_analyzer_eval(y >= x); // expected-warning{{FALSE}}
+clang_analyzer_eval(x >= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y <= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x == y); // expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expected-warning{{FALSE}}
+clang_analyzer_eval(x != y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y != x); // expected-warning{{TRUE}}
+  } else {
+clang_analyzer_eval(x < y);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y > x);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x > y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y < x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x <= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y >= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x >= y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y <= x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x == y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x != y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y != x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+  }
+}
+
+void comparison_le(int x, int y) {
+  if (x <= y) {
+clang_analyzer_eval(x < y);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y > x);  // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x > y);  // expected-warning{{FALSE}}
+clang_analyzer_eval(y < x);  // expected-warning{{FALSE}}
+clang_analyzer_eval(x <= y); // expected-warning{{TRUE}}
+clang_analyzer_eval(y >= x); // expected-warning{{TRUE}}
+clang_analyzer_eval(x >= y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y <= x); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(x == y); // expected-warning{{TRUE}} expected-warning{{FALSE}}
+clang_analyzer_eval(y == x); 

[PATCH] D80522: [Analyzer] [NFC] Parameter Regions -- Alternative Approach

2020-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

Looks great, thanks! I like how it turned out, i guess let's prefer this to 
D79704 .




Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:921
+public:
+  const VarDecl *getDecl() const override = 0;
+

What's the point of overriding one pure virtual method with another pure 
virtual method?



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:977
+// implementing stack frame creations for functions without decl (functions
+// passed by function pointer) methods of `ParamVarRegion` must be updated.
+class ParamVarRegion : public VarRegion {

*unknown* function pointer!


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

https://reviews.llvm.org/D80522



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


[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

2020-06-01 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D80880#2066078 , @mati865 wrote:

> Wouldn't it better fit in `AddLibGCC`?


`AddLibGCC` is called twice, and we already add `-lkernel32` (plus a bunch of 
other libraries) after the first invocation, so that would either add another 
extra `-lkernel32` or require touching that code.

Also, with the other issue pointer out in 
https://github.com/msys2/MINGW-packages/pull/6539, I'm not sure if we also 
should try to another instance of `-lgcc` after `-lmingwex`, or move 
`-lmingwex` before `-lgcc` (as mingwex easily can contain references to libgcc 
builtins like division helper routines).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80880



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


[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

2020-06-01 Thread Mateusz Mikuła via Phabricator via cfe-commits
mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

I don't know why `AddLibGCC` has to be called twice but that doesn't really 
matter for this diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80880



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


[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

2020-06-01 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D80880#2066130 , @mati865 wrote:

> I don't know why `AddLibGCC` has to be called twice but that doesn't really 
> matter for this diff.


From the clang perspective, I guess it's to match GCC. Originally, I guess the 
reason is that there's some nontrivial dependencies among all the default 
linked libraries - for G++ with `-pthread`, this is what gcc links: `-lstdc++ 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 
-lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex 
-lmsvcrt`.

As there's functions in libmingwex which maybe used by libpthread - and we also 
occasionally move functions from libmingwex to libmsvcrt (for functions that 
aren't needed when on ucrt), and such functions may require both libgcc and 
libkernel32, it's all pretty fragile - a more robust solution would be to just 
add `--start-group` and `--end-group` around it (which would end up matching 
what lld always does anyway), but I'm not sure how receptive GCC would be to 
that. (Clang does add `--start-group` though, but only when linking with 
`-static`.)

As the issue in https://github.com/msys2/MINGW-packages/pull/6539 seems to end 
up resolved by using the "simpler" (linking wise) stdio functions in 
libwinpthread, lh_mouse also concluded that this added `-lkernel32` isn't 
really necessary in the end in that case, so if it ends up backed out from GCC 
I might skip pushing this one here as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80880



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


[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/utils/TableGen/ClangAttrEmitter.cpp:65
-bool Unset;
-K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);
   }

Doesn't this result in 'K' being uninitialized now?  


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

https://reviews.llvm.org/D80836



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


[PATCH] D80905: [analyzer] Introduce weak dependencies to express *preferred* checker callback evaluation order

2020-06-01 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

>> checker callback evaluation order is ensured
> 
> And it will be the same for all callbacks, right? Like, we're not doing this 
> thing yet where it intentionally goes like
> 
>   chk1->checkPreCall();
>   chk2->checkPreCall();
>   chk2->checkPostCall();
>   chk1->checkPostCall();
> 
> 
> ?

It should work for all callbacks. It'd be a nightmare to test and `assert`, but 
when `CheckerManager` registers a checker, all of its callbacks are registered 
to the appropriate container, which isn't sorted.

> NoQ added a reviewer: vsavchenko.

Woops O:)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80905



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


[PATCH] D80905: [analyzer] Introduce weak dependencies to express *preferred* checker callback evaluation order

2020-06-01 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

Mind that strong dependencies also ensure the order of evaluation, but that is 
a //guarantee// (**either** the dependency will be evaluated before the 
dependency, **or** none of them will be evaluated), and this patch is about 
//preference// (**if** both of them are enabled, the dependency will be 
evaluated first).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80905



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


[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/utils/TableGen/ClangAttrEmitter.cpp:65
-bool Unset;
-K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);
   }

aaron.ballman wrote:
> erichkeane wrote:
> > Doesn't this result in 'K' being uninitialized now?  
> `K` is still being initialized by the ctor init list above on line 56.
Isn't that in a different constructor?


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

https://reviews.llvm.org/D80836



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


[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman marked 3 inline comments as done.
aaron.ballman added inline comments.



Comment at: clang/utils/TableGen/ClangAttrEmitter.cpp:65
-bool Unset;
-K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);
   }

erichkeane wrote:
> aaron.ballman wrote:
> > erichkeane wrote:
> > > Doesn't this result in 'K' being uninitialized now?  
> > `K` is still being initialized by the ctor init list above on line 56.
> Isn't that in a different constructor?
Yes, yes it is. :-D Thank you for helping to point that out. I've fixed in the 
latest patch.


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

https://reviews.llvm.org/D80836



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


[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

2020-06-01 Thread Florian Hahn via Phabricator via cfe-commits
fhahn marked 2 inline comments as done.
fhahn added inline comments.



Comment at: clang/lib/CodeGen/CGExpr.cpp:3787
+   ColIdx->getType()->getScalarSizeInBits());
+  llvm::Type *IntTy = llvm::IntegerType::get(getLLVMContext(), MaxWidth);
+  RowIdx = Builder.CreateZExt(RowIdx, IntTy);

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > You should be able to assert that these have been coerced to the right 
> > > type by Sema (probably size_t or ptrdiff_t or something).
> > Hm I don't think that's currently happening. Is that required? It seems a 
> > bit unfortunate if we would have to force to wider bit-widths than 
> > necessary for the given index expressions.
> Can you explain what cost you're worried about?  I don't understand what the 
> benefit of using a smaller IR type for the indexes is, and usually it's 
> better to have stronger invariants coming out of Sema.
I now updated the code to force the index types to size_t in Sema and remove 
the zext generation here. If we have signed indices, we now generate sexts, 
which may require additional instructions down the road., which we would not 
require if we perform the math on the max bit width of the operands. But 
looking back now, I am not really sure if that would actually be safe in all 
cases. 

We  should probably just try to narrow the index types based on the number of 
vector elements as an IR optimization, if it becomes a problem.



Comment at: clang/lib/Sema/SemaExpr.cpp:4707
+  return false;
+}
+

rjmccall wrote:
> Somewhere in here would be where you'd do the index type conversion, FWIW.
> 
> I don't know if you want to allow a class with a conversion operator to an 
> integer type, but that function you added for +/- should do it.
> I don't know if you want to allow a class with a conversion operator to an 
> integer type, but that function you added for +/- should do it.

Yes I updated the code here to use the same conversion function and added tests 
for conversion operators.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76791



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


[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

2020-06-01 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 267601.
fhahn added a comment.

Force index types to size_t in Sema, remove code to extend index values in 
Codegen. Update tests to check more targeted IR.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76791

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/ComputeDependence.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/StmtNodes.td
  clang/include/clang/Sema/Initialization.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CGValue.h
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGenCXX/matrix-type-operators.cpp
  clang/test/CodeGenObjC/matrix-type-operators.m
  clang/test/Sema/matrix-type-operators.c
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaObjC/matrix-type-operators.m
  clang/tools/libclang/CXCursor.cpp
  llvm/include/llvm/IR/MatrixBuilder.h

Index: llvm/include/llvm/IR/MatrixBuilder.h
===
--- llvm/include/llvm/IR/MatrixBuilder.h
+++ llvm/include/llvm/IR/MatrixBuilder.h
@@ -175,15 +175,19 @@
 return B.CreateMul(LHS, ScalarVector);
   }
 
-  /// Extracts the element at (\p Row, \p Column) from \p Matrix.
-  Value *CreateExtractMatrix(Value *Matrix, Value *Row, Value *Column,
- unsigned NumRows, Twine const &Name = "") {
-
+  /// Extracts the element at (\p RowIdx, \p ColumnIdx) from \p Matrix.
+  Value *CreateExtractElement(Value *Matrix, Value *RowIdx, Value *ColumnIdx,
+  unsigned NumRows, Twine const &Name = "") {
+
+unsigned MaxWidth = std::max(RowIdx->getType()->getScalarSizeInBits(),
+ ColumnIdx->getType()->getScalarSizeInBits());
+Type *IntTy = IntegerType::get(RowIdx->getType()->getContext(), MaxWidth);
+RowIdx = B.CreateZExt(RowIdx, IntTy);
+ColumnIdx = B.CreateZExt(ColumnIdx, IntTy);
+Value *NumRowsV = B.getIntN(MaxWidth, NumRows);
 return B.CreateExtractElement(
-Matrix,
-B.CreateAdd(
-B.CreateMul(Column, ConstantInt::get(Column->getType(), NumRows)),
-Row));
+Matrix, B.CreateAdd(B.CreateMul(ColumnIdx, NumRowsV), RowIdx),
+"matext");
   }
 };
 
Index: clang/tools/libclang/CXCursor.cpp
===
--- clang/tools/libclang/CXCursor.cpp
+++ clang/tools/libclang/CXCursor.cpp
@@ -419,6 +419,11 @@
 K = CXCursor_ArraySubscriptExpr;
 break;
 
+  case Stmt::MatrixSubscriptExprClass:
+// TODO: add support for MatrixSubscriptExpr.
+K = CXCursor_UnexposedExpr;
+break;
+
   case Stmt::OMPArraySectionExprClass:
 K = CXCursor_OMPArraySectionExpr;
 break;
Index: clang/test/SemaObjC/matrix-type-operators.m
===
--- /dev/null
+++ clang/test/SemaObjC/matrix-type-operators.m
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -fenable-matrix %s
+
+struct Foo {};
+__attribute__((objc_root_class))
+@interface FooValue
+@property struct Foo value;
+@end
+
+typedef double double4x4 __attribute__((matrix_type(4, 4)));
+
+// Check that we generate proper error messages for invalid placeholder types.
+//
+double test_index_placeholders(double4x4 m, FooValue *iv) {
+  return m[iv.value][iv.value];
+  // expected-error@-1 {{matrix row index is not an integer}}
+  // expected-error@-2 {{matrix column index is not an integer}}
+}
+
+double test_base_and_index_placeholders(FooValue *m, FooValue *iv) {
+  return m.value[iv.value][iv.value];
+  // expected-error@-1 {{subscripted value is not an array, pointer, or vector}}
+}
Index: clang/test/SemaCXX/matrix-type-operators.cpp
==

[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman updated this revision to Diff 267603.
aaron.ballman added a comment.

New and improved with proper member initialization in all constructors.


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

https://reviews.llvm.org/D80836

Files:
  clang/include/clang/Basic/Attr.td
  clang/test/Sema/attr-c2x.c
  clang/utils/TableGen/ClangAttrEmitter.cpp

Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -48,7 +48,7 @@
 
 class FlattenedSpelling {
   std::string V, N, NS;
-  bool K;
+  bool K = false;
 
 public:
   FlattenedSpelling(const std::string &Variety, const std::string &Name,
@@ -60,9 +60,7 @@
 assert(V != "GCC" && V != "Clang" &&
"Given a GCC spelling, which means this hasn't been flattened!");
 if (V == "CXX11" || V == "C2x" || V == "Pragma")
-  NS = std::string(Spelling.getValueAsString("Namespace"));
-bool Unset;
-K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);
+  NS = std::string(Spelling.getValueAsString("Namespace"));  
   }
 
   const std::string &variety() const { return V; }
@@ -82,9 +80,10 @@
 StringRef Variety = Spelling->getValueAsString("Variety");
 StringRef Name = Spelling->getValueAsString("Name");
 if (Variety == "GCC") {
-  // Gin up two new spelling objects to add into the list.
   Ret.emplace_back("GNU", std::string(Name), "", true);
   Ret.emplace_back("CXX11", std::string(Name), "gnu", true);
+  if (Spelling->getValueAsBit("AllowInC"))
+Ret.emplace_back("C2x", std::string(Name), "gnu", true);
 } else if (Variety == "Clang") {
   Ret.emplace_back("GNU", std::string(Name), "", false);
   Ret.emplace_back("CXX11", std::string(Name), "clang", false);
Index: clang/test/Sema/attr-c2x.c
===
--- clang/test/Sema/attr-c2x.c
+++ clang/test/Sema/attr-c2x.c
@@ -27,3 +27,15 @@
 
 [[nodiscard]] int without_underscores(void);
 [[__nodiscard__]] int underscores(void);
+
+// Match GCC's behavior for C attributes as well.
+[[gnu::constructor]] void ctor_func(void);
+[[gnu::destructor]] void dtor_func(void);
+[[gnu::hot]] void hot_func(void);
+[[__gnu__::hot]] void hot_func2(void);
+[[gnu::__hot__]] void hot_func3(void);
+[[__gnu__::__hot__]] void hot_func4(void);
+
+// Note how not all GCC attributes are supported in C.
+[[gnu::abi_tag("")]] void abi_func(void); // expected-warning {{unknown attribute 'abi_tag' ignored}}
+struct S s [[gnu::init_priority(1)]]; // expected-warning {{unknown attribute 'init_priority' ignored}}
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -257,7 +257,6 @@
 class Spelling {
   string Name = name;
   string Variety = variety;
-  bit KnownToGCC;
 }
 
 class GNU : Spelling;
@@ -277,11 +276,11 @@
   string Namespace = namespace;
 }
 
-// The GCC spelling implies GNU and CXX11<"gnu", name> and also sets
-// KnownToGCC to 1. This spelling should be used for any GCC-compatible
+// The GCC spelling implies GNU, CXX11<"gnu", name>, and optionally,
+// C2x<"gnu", name>. This spelling should be used for any GCC-compatible
 // attributes.
-class GCC : Spelling {
-  let KnownToGCC = 1;
+class GCC : Spelling {
+  bit AllowInC = allowInC;
 }
 
 // The Clang spelling implies GNU, CXX11<"clang", name>, and optionally,
@@ -605,7 +604,7 @@
 //
 
 def AbiTag : Attr {
-  let Spellings = [GCC<"abi_tag">];
+  let Spellings = [GCC<"abi_tag", /*AllowInC*/0>];
   let Args = [VariadicStringArgument<"Tags">];
   let Subjects = SubjectList<[Struct, Var, Function, Namespace], ErrorDiag>;
   let MeaningfulToClassTemplateDefinition = 1;
@@ -2113,7 +2112,7 @@
 }
 
 def InitPriority : InheritableAttr {
-  let Spellings = [GCC<"init_priority">];
+  let Spellings = [GCC<"init_priority", /*AllowInC*/0>];
   let Args = [UnsignedArgument<"Priority">];
   let Subjects = SubjectList<[Var], ErrorDiag>;
   let Documentation = [Undocumented];
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman marked an inline comment as done.
aaron.ballman added inline comments.



Comment at: clang/utils/TableGen/ClangAttrEmitter.cpp:65
-bool Unset;
-K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);
   }

erichkeane wrote:
> Doesn't this result in 'K' being uninitialized now?  
`K` is still being initialized by the ctor init list above on line 56.


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

https://reviews.llvm.org/D80836



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-06-01 Thread Ties Stuij via Phabricator via cfe-commits
stuij marked 2 inline comments as done.
stuij added inline comments.



Comment at: clang/lib/Basic/Targets/ARM.cpp:80
 DoubleAlign = LongLongAlign = LongDoubleAlign = SuitableAlign = 32;
+  BFloat16Width = BFloat16Align = 16;
+  BFloat16Format = &llvm::APFloat::BFloat();

SjoerdMeijer wrote:
> Is this tested? Can it be tested?
Yes, I think it's a bit tricky to test this all by itself. Right now this is 
used when return a TypeInfo, which is used in all kinds of different contexts. 
I think alignment is better tested where it is eventually expressed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman updated this revision to Diff 267604.
aaron.ballman marked an inline comment as done.
aaron.ballman added a comment.

Whoops, *now* I'm properly setting the bit from the record.


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

https://reviews.llvm.org/D80836

Files:
  clang/include/clang/Basic/Attr.td
  clang/test/Sema/attr-c2x.c
  clang/utils/TableGen/ClangAttrEmitter.cpp


Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -82,9 +82,10 @@
 StringRef Variety = Spelling->getValueAsString("Variety");
 StringRef Name = Spelling->getValueAsString("Name");
 if (Variety == "GCC") {
-  // Gin up two new spelling objects to add into the list.
   Ret.emplace_back("GNU", std::string(Name), "", true);
   Ret.emplace_back("CXX11", std::string(Name), "gnu", true);
+  if (Spelling->getValueAsBit("AllowInC"))
+Ret.emplace_back("C2x", std::string(Name), "gnu", true);
 } else if (Variety == "Clang") {
   Ret.emplace_back("GNU", std::string(Name), "", false);
   Ret.emplace_back("CXX11", std::string(Name), "clang", false);
Index: clang/test/Sema/attr-c2x.c
===
--- clang/test/Sema/attr-c2x.c
+++ clang/test/Sema/attr-c2x.c
@@ -27,3 +27,15 @@
 
 [[nodiscard]] int without_underscores(void);
 [[__nodiscard__]] int underscores(void);
+
+// Match GCC's behavior for C attributes as well.
+[[gnu::constructor]] void ctor_func(void);
+[[gnu::destructor]] void dtor_func(void);
+[[gnu::hot]] void hot_func(void);
+[[__gnu__::hot]] void hot_func2(void);
+[[gnu::__hot__]] void hot_func3(void);
+[[__gnu__::__hot__]] void hot_func4(void);
+
+// Note how not all GCC attributes are supported in C.
+[[gnu::abi_tag("")]] void abi_func(void); // expected-warning {{unknown 
attribute 'abi_tag' ignored}}
+struct S s [[gnu::init_priority(1)]]; // expected-warning {{unknown attribute 
'init_priority' ignored}}
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -257,7 +257,6 @@
 class Spelling {
   string Name = name;
   string Variety = variety;
-  bit KnownToGCC;
 }
 
 class GNU : Spelling;
@@ -277,11 +276,11 @@
   string Namespace = namespace;
 }
 
-// The GCC spelling implies GNU and CXX11<"gnu", name> and also sets
-// KnownToGCC to 1. This spelling should be used for any GCC-compatible
+// The GCC spelling implies GNU, CXX11<"gnu", name>, and optionally,
+// C2x<"gnu", name>. This spelling should be used for any GCC-compatible
 // attributes.
-class GCC : Spelling {
-  let KnownToGCC = 1;
+class GCC : Spelling {
+  bit AllowInC = allowInC;
 }
 
 // The Clang spelling implies GNU, CXX11<"clang", name>, and optionally,
@@ -605,7 +604,7 @@
 //
 
 def AbiTag : Attr {
-  let Spellings = [GCC<"abi_tag">];
+  let Spellings = [GCC<"abi_tag", /*AllowInC*/0>];
   let Args = [VariadicStringArgument<"Tags">];
   let Subjects = SubjectList<[Struct, Var, Function, Namespace], ErrorDiag>;
   let MeaningfulToClassTemplateDefinition = 1;
@@ -2113,7 +2112,7 @@
 }
 
 def InitPriority : InheritableAttr {
-  let Spellings = [GCC<"init_priority">];
+  let Spellings = [GCC<"init_priority", /*AllowInC*/0>];
   let Args = [UnsignedArgument<"Priority">];
   let Subjects = SubjectList<[Var], ErrorDiag>;
   let Documentation = [Undocumented];


Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -82,9 +82,10 @@
 StringRef Variety = Spelling->getValueAsString("Variety");
 StringRef Name = Spelling->getValueAsString("Name");
 if (Variety == "GCC") {
-  // Gin up two new spelling objects to add into the list.
   Ret.emplace_back("GNU", std::string(Name), "", true);
   Ret.emplace_back("CXX11", std::string(Name), "gnu", true);
+  if (Spelling->getValueAsBit("AllowInC"))
+Ret.emplace_back("C2x", std::string(Name), "gnu", true);
 } else if (Variety == "Clang") {
   Ret.emplace_back("GNU", std::string(Name), "", false);
   Ret.emplace_back("CXX11", std::string(Name), "clang", false);
Index: clang/test/Sema/attr-c2x.c
===
--- clang/test/Sema/attr-c2x.c
+++ clang/test/Sema/attr-c2x.c
@@ -27,3 +27,15 @@
 
 [[nodiscard]] int without_underscores(void);
 [[__nodiscard__]] int underscores(void);
+
+// Match GCC's behavior for C attributes as well.
+[[gnu::constructor]] void ctor_func(void);
+[[gnu::destructor]] void dtor_func(void);
+[[gnu::hot]] void hot_func(void);
+[[__gnu__::hot]] void hot_func2(void);
+[[gnu::__hot__]] void hot_func3(void);
+[[__gnu__::__hot__]] void hot_func4(vo

[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D80836#2064181 , @erichkeane wrote:

> 1 more question, how did you arrive at the 'not supported in C' list?  Did 
> you find some GCC docs for that (if so, please put in the commit message)?  
> Or did you just try them all?


There's a documented list, and I'll add it to the commit message (though the 
format of the link makes me wonder how stable it will be): 
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes


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

https://reviews.llvm.org/D80836



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


[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

2020-06-01 Thread Mateusz Mikuła via Phabricator via cfe-commits
mati865 added a comment.

Thanks, sounds good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80880



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


[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman updated this revision to Diff 267606.
aaron.ballman added a comment.

Sorry for the back and forth, this Monday morning is not easy it seems.


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

https://reviews.llvm.org/D80836

Files:
  clang/include/clang/Basic/Attr.td
  clang/test/Sema/attr-c2x.c
  clang/utils/TableGen/ClangAttrEmitter.cpp


Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -48,7 +48,7 @@
 
 class FlattenedSpelling {
   std::string V, N, NS;
-  bool K;
+  bool K = false;
 
 public:
   FlattenedSpelling(const std::string &Variety, const std::string &Name,
@@ -61,8 +61,6 @@
"Given a GCC spelling, which means this hasn't been flattened!");
 if (V == "CXX11" || V == "C2x" || V == "Pragma")
   NS = std::string(Spelling.getValueAsString("Namespace"));
-bool Unset;
-K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);
   }
 
   const std::string &variety() const { return V; }
@@ -82,9 +80,10 @@
 StringRef Variety = Spelling->getValueAsString("Variety");
 StringRef Name = Spelling->getValueAsString("Name");
 if (Variety == "GCC") {
-  // Gin up two new spelling objects to add into the list.
   Ret.emplace_back("GNU", std::string(Name), "", true);
   Ret.emplace_back("CXX11", std::string(Name), "gnu", true);
+  if (Spelling->getValueAsBit("AllowInC"))
+Ret.emplace_back("C2x", std::string(Name), "gnu", true);
 } else if (Variety == "Clang") {
   Ret.emplace_back("GNU", std::string(Name), "", false);
   Ret.emplace_back("CXX11", std::string(Name), "clang", false);
Index: clang/test/Sema/attr-c2x.c
===
--- clang/test/Sema/attr-c2x.c
+++ clang/test/Sema/attr-c2x.c
@@ -27,3 +27,15 @@
 
 [[nodiscard]] int without_underscores(void);
 [[__nodiscard__]] int underscores(void);
+
+// Match GCC's behavior for C attributes as well.
+[[gnu::constructor]] void ctor_func(void);
+[[gnu::destructor]] void dtor_func(void);
+[[gnu::hot]] void hot_func(void);
+[[__gnu__::hot]] void hot_func2(void);
+[[gnu::__hot__]] void hot_func3(void);
+[[__gnu__::__hot__]] void hot_func4(void);
+
+// Note how not all GCC attributes are supported in C.
+[[gnu::abi_tag("")]] void abi_func(void); // expected-warning {{unknown 
attribute 'abi_tag' ignored}}
+struct S s [[gnu::init_priority(1)]]; // expected-warning {{unknown attribute 
'init_priority' ignored}}
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -257,7 +257,6 @@
 class Spelling {
   string Name = name;
   string Variety = variety;
-  bit KnownToGCC;
 }
 
 class GNU : Spelling;
@@ -277,11 +276,11 @@
   string Namespace = namespace;
 }
 
-// The GCC spelling implies GNU and CXX11<"gnu", name> and also sets
-// KnownToGCC to 1. This spelling should be used for any GCC-compatible
+// The GCC spelling implies GNU, CXX11<"gnu", name>, and optionally,
+// C2x<"gnu", name>. This spelling should be used for any GCC-compatible
 // attributes.
-class GCC : Spelling {
-  let KnownToGCC = 1;
+class GCC : Spelling {
+  bit AllowInC = allowInC;
 }
 
 // The Clang spelling implies GNU, CXX11<"clang", name>, and optionally,
@@ -605,7 +604,7 @@
 //
 
 def AbiTag : Attr {
-  let Spellings = [GCC<"abi_tag">];
+  let Spellings = [GCC<"abi_tag", /*AllowInC*/0>];
   let Args = [VariadicStringArgument<"Tags">];
   let Subjects = SubjectList<[Struct, Var, Function, Namespace], ErrorDiag>;
   let MeaningfulToClassTemplateDefinition = 1;
@@ -2113,7 +2112,7 @@
 }
 
 def InitPriority : InheritableAttr {
-  let Spellings = [GCC<"init_priority">];
+  let Spellings = [GCC<"init_priority", /*AllowInC*/0>];
   let Args = [UnsignedArgument<"Priority">];
   let Subjects = SubjectList<[Var], ErrorDiag>;
   let Documentation = [Undocumented];


Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -48,7 +48,7 @@
 
 class FlattenedSpelling {
   std::string V, N, NS;
-  bool K;
+  bool K = false;
 
 public:
   FlattenedSpelling(const std::string &Variety, const std::string &Name,
@@ -61,8 +61,6 @@
"Given a GCC spelling, which means this hasn't been flattened!");
 if (V == "CXX11" || V == "C2x" || V == "Pragma")
   NS = std::string(Spelling.getValueAsString("Namespace"));
-bool Unset;
-K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);
   }
 
   const std::string &variety() const { return V; }
@@ -82,9 +80,10 @@
 StringRef Variety = Spelling->getValueAsString("Variety");
 StringRef Name = Spelling->getValueAsString("Name");
 if (Variety == "GCC") {

[PATCH] D78442: Create a warning flag for 'warn_conv_*_not_used'

2020-06-01 Thread Ronald Wampler via Phabricator via cfe-commits
rdwampler added a comment.

Ping.


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

https://reviews.llvm.org/D78442



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


[PATCH] D80584: [utils] change update_test_checks.py use of 'TMP' value names

2020-06-01 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

First, I think the warning is strictly a good thing. Thanks for keeping that in!

I don't think the options are really "complexity to the user" given a sensible 
default (= the old value). If a user sees a warning that says: `Name conflict, 
use --nameless-prefix=X, where X is a string not otherwise used in your 
IR`, they will happily do so. The UTC_ARGS extension makes it permanent and no 
one needs to worry about this until they see a warning again. (If we can "hide" 
the option from the help message, I'm fine with that too.)

Adding a test is just something we should do as it is easy to accidentally 
break functionality like the warning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80584



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


[clang] c0303e5 - [CodeGen] remove instnamer dependency from test file; NFC

2020-06-01 Thread Sanjay Patel via cfe-commits
Author: Sanjay Patel
Date: 2020-06-01T10:21:17-04:00
New Revision: c0303e5391f65dbad3a6f1dbfa5ac9c9a83fa6c0

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

LOG: [CodeGen] remove instnamer dependency from test file; NFC

This file was originally added without instnamer at:
rL283716 / fe2b9b4fbf860e3dc7da7705f548bc8d7b6ab9c1

But that was reverted and the test file reappeared with instnamer at:
rL285688 / 62f516f5906f967179610a73e4cc1d852b908bbd

I'm not seeing any difference locally from checking nameless values,
so trying to remove a layering violation and see if that can
survive the build bots.

Added: 


Modified: 
clang/test/CodeGen/x86-inline-asm-v-constraint.c

Removed: 




diff  --git a/clang/test/CodeGen/x86-inline-asm-v-constraint.c 
b/clang/test/CodeGen/x86-inline-asm-v-constraint.c
index 215cccfa443e..b75a84d7a7bc 100644
--- a/clang/test/CodeGen/x86-inline-asm-v-constraint.c
+++ b/clang/test/CodeGen/x86-inline-asm-v-constraint.c
@@ -1,19 +1,19 @@
-// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu 
x86-64 -o - |opt -instnamer -S |FileCheck %s --check-prefix SSE
-// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu 
skylake -D AVX -o -|opt -instnamer -S  | FileCheck %s --check-prefixes AVX,SSE
-// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu 
skylake-avx512 -D AVX512 -D AVX -o -|opt -instnamer -S  | FileCheck %s 
--check-prefixes AVX512,AVX,SSE
-// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu 
knl -D AVX -D AVX512 -o - |opt -instnamer -S  | FileCheck %s --check-prefixes 
AVX512,AVX,SSE
+// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu 
x86-64 -o - |FileCheck %s --check-prefix SSE
+// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu 
skylake -D AVX -o - | FileCheck %s --check-prefixes AVX,SSE
+// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu 
skylake-avx512 -D AVX512 -D AVX -o - | FileCheck %s --check-prefixes 
AVX512,AVX,SSE
+// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu 
knl -D AVX -D AVX512 -o - | FileCheck %s --check-prefixes AVX512,AVX,SSE
 
 typedef float __m128 __attribute__ ((vector_size (16)));
 typedef float __m256 __attribute__ ((vector_size (32)));
 typedef float __m512 __attribute__ ((vector_size (64)));
 
-// SSE: call <4 x float> asm "vmovhlps $1, $2, $0", 
"=v,v,v,~{dirflag},~{fpsr},~{flags}"(i64 %tmp, <4 x float> %tmp1)
+// SSE: call <4 x float> asm "vmovhlps $1, $2, $0", 
"=v,v,v,~{dirflag},~{fpsr},~{flags}"(i64 %0, <4 x float> %1)
 __m128 testXMM(__m128 _xmm0, long _l) {
   __asm__("vmovhlps %1, %2, %0" :"=v"(_xmm0) : "v"(_l), "v"(_xmm0));
   return _xmm0;
 }
 
-// AVX: call <8 x float> asm "vmovsldup $1, $0", 
"=v,v,~{dirflag},~{fpsr},~{flags}"(<8 x float> %tmp)
+// AVX: call <8 x float> asm "vmovsldup $1, $0", 
"=v,v,~{dirflag},~{fpsr},~{flags}"(<8 x float> %0)
 __m256 testYMM(__m256 _ymm0) {
 #ifdef AVX
   __asm__("vmovsldup %1, %0" :"=v"(_ymm0) : "v"(_ymm0));
@@ -21,7 +21,7 @@ __m256 testYMM(__m256 _ymm0) {
   return _ymm0;
 }
 
-// AVX512: call <16 x float> asm "vpternlogd $$0, $1, $2, $0", 
"=v,v,v,~{dirflag},~{fpsr},~{flags}"(<16 x float> %tmp, <16 x float> %tmp1)
+// AVX512: call <16 x float> asm "vpternlogd $$0, $1, $2, $0", 
"=v,v,v,~{dirflag},~{fpsr},~{flags}"(<16 x float> %0, <16 x float> %1)
 __m512 testZMM(__m512 _zmm0, __m512 _zmm1) {
 #ifdef AVX512
   __asm__("vpternlogd $0, %1, %2, %0" :"=v"(_zmm0) : "v"(_zmm1), "v"(_zmm0));



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-06-01 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added a comment.

Can you summarise where we are? I.e.,

- float-abi=soft doesn't work. But what is the problem? Are we not simply 
passing i16s, is that not what we are supposed to do?

Can you also update the description of this patch, I got totally confused by:

- "introduces an opaque, storage-only C-type __bf16, which does not introduce a 
new LLVM IR type, but maps it to either i16 or half type."




Comment at: clang/test/CodeGen/arm-mangle-16bit-float.cpp:1
+// RUN: %clang_cc1 -triple aarch64-arm-none-eabi 
-fallow-half-arguments-and-returns -target-feature +fullfp16 -emit-llvm -o - %s 
| FileCheck %s --check-prefix=CHECK64
+// RUN: %clang_cc1 -triple arm-arm-none-eabi 
-fallow-half-arguments-and-returns -target-feature +fullfp16 -emit-llvm -o - %s 
| FileCheck %s --check-prefix=CHECK32

This is testing name mangling of __fp16, so is not related to this patch, 
please commit this separately if this is not tested yet. But I do suspect Dh is 
tested already, but I could be wrong.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D79781: [OpenCL] Add cl_khr_extended_subgroup extensions

2020-06-01 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.

In D79781#2063440 , @PiotrFusik wrote:

> Bumped the OpenCL version from 1.2 to 2.0.


Great! Thanks! Feel free to go ahead and commit this!

Can you please add a link to the bug describing incorrect optimization to this 
review once you create it.




Comment at: clang/include/clang/Basic/OpenCLExtensions.def:68
 OPENCLEXT_INTERNAL(cl_khr_spir, 120, ~0U)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_extended_types, 120, ~0U)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_non_uniform_vote, 120, ~0U)

PiotrFusik wrote:
> Anastasia wrote:
> > I think it makes sense to allow this extension from the same OpenCL version 
> > as normal subgroup. However the version listed somewhere in the spec?
> The spec doesn't mention the OpenCL version. Quoting the editor (Ben 
> Ashbaugh):
> > My view of OpenCL extensions is that they are "non-versioned" – some 
> > extensions certainly make more sense for specific OpenCL versions, but if 
> > an older OpenCL implementation wants to support a newer extension (perhaps 
> > with some caveats or restrictions), or if a newer OpenCL version wants to 
> > support an older OpenCL extension for backwards compatibility, that should 
> > be possible.
> I agree that matching the version of `cl_khr_subgroups` makes sense. Updated 
> together with the tests.
> 
I would say in upstream Clang we try to follow the commonly accepted and 
well-documented behavior. We have no capacity to work out what the behavior of 
every possible customization should be.

Also, we aim to implement already documented behavior that provides sufficient 
details to understand how things should be implemented. We can some times 
decide to deviate the implementation from the existing published documentation 
for which we should have a good reason and we should document anything that 
deviates any existing publicly documented feature.

Ideally OpenCL standard should decide whether extensions are associated with 
OpenCL versions or not and this should be clearly documented. It would 
certainly help the implementation as it saves us time to work out what language 
version should be taken as a base.

I believe that enabling extensions with incompatible language versions can 
cause the compiler failures without providing helpful information/diagnostic. 
Therefore, extensions should be aligned with a certain version of OpenCL C 
because they might require certain language features to be used. If they only 
require basic OpenCL language features then I guess it can say the extension is 
used with any language version starting from 1.0.


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

https://reviews.llvm.org/D79781



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


[PATCH] D80900: [clangd] Use different FS in PreambleThread

2020-06-01 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

TL;DR: I think there are three viable paths that we should consider:
A) minimal change: put the FSProvider in ParseInputs
B) this patch, but with more documentation and safety
C) fight to clean up VFS multithreading semantics

Assuming we don't want to block on C, I'm not sure whether A or B is 
conceptually better. But A is a smaller change and brings side benefits, so 
wondering if you see advantages in B.

---

You're right about the race condition of course and I'm sure this patch is 
correct.
But this rubs me the wrong way a bit - the API change doesn't seem clearly 
motivated either from a high level (we conceptually *want* a single FS to build 
a single version of code) or from a low level (what are we actually doing in 
parallel that isn't threadsafe?).

Looking at the low level perspective first. VFS has three classes threadsafety 
issues:

- it contains the "working directory" as mutable state, which isn't 
multi-threading friendly. We do set working directory concurrently with other 
work, but always to the same thing. We could factor our way around this by 
setting the working directory prior to any concurrency (to CDB.Directory) and 
ensuring we never set it again.
- the RealFilesystem in real-working-directory mode is a singleton so its use 
is thread-hostile. This isn't really relevant to us because we use 
emulated-working-directory mode and have distinct instances. But it probably 
informed VFS's lack of useful threading semantics.
- read operations aren't `const` or documented as threadsafe even though the 
canonical `RealFilesystem` is. In-tree implementations seem to be threadsafe, 
some out-of-tree ones are not :-( This definitely bites us here.

I think it would be fundamentally possible to use a single VFS here. We need to 
modify the VFS interface to make concurrent reads safe (and const, while here) 
and fix any implementations. This isn't trivial. I think it's worthwhile, but 
experience tells me different projects want different things from the VFS 
interface...

The high-level view: IMO FSProvider is basically a hack around VFS's 
thread-safety issues, rather than a fundamental part of the application - it's 
a filesystem that doesn't have an attached working directory and whose read 
operations (e.g. `getFileSystem()->status()`) are threadsafe. We could rename 
FSProvider -> ThreadsafeFS and getFileSystem() -> newCursor(WD) or something, 
and maybe we should. 
From this perspective, this patch is changing two things that have little to do 
with each other: it's replacing FS -> ThreadsafeFS and it's moving the FS 
ownership from one revision of the file to the TUScheduler itself.

I'm not really sure whether the latter is a good or a bad idea. If we want to 
do it, the use of ParseInputs as the interface to TUScheduler is a bit 
confusing - we should at least document that FS isn't used (as we do for 
CompileCommand) and probably assert that it's null, too.

But maybe simpler would be to "just" change the VFS member in ParseInputs to a 
`const FSProvider*`. This keeps the design approximately what it is now, but 
simplifies the ParseInputs concept: it's now truly readonly data, and functions 
that consume it won't have effects that escape.




Comment at: clang-tools-extra/clangd/TUScheduler.cpp:629
 std::vector CC1Args;
 std::unique_ptr Invocation = buildCompilerInvocation(
 Inputs, CompilerInvocationDiagConsumer, &CC1Args);

Yikes, ISTM we're getting the FS from Inputs here, and from this->FSProvider 
below. We should use one or the other (i.e. FSProvider only, following this 
patch) unless we're trying to do something really subtle...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80900



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


[clang] 522934d - Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Aaron Ballman via cfe-commits
Author: Aaron Ballman
Date: 2020-06-01T10:42:42-04:00
New Revision: 522934da1f0c78c1de1a80d4ba14204a11f5afa8

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

LOG: Support GCC [[gnu::attributes]] in C2x mode

GCC 10.1 introduced support for the [[]] style spelling of attributes in C
mode. Similar to how GCC supports __attribute__((foo)) as [[gnu::foo]] in
C++ mode, it now supports the same spelling in C mode as well. This patch
makes a change in Clang so that when you use the GCC attribute spelling,
the attribute is automatically available in all three spellings by default.
However, like Clang, GCC has some attributes it only recognizes in C++ mode
(specifically, abi_tag and init_priority), which this patch also honors.

Added: 


Modified: 
clang/include/clang/Basic/Attr.td
clang/test/Sema/attr-c2x.c
clang/utils/TableGen/ClangAttrEmitter.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index a691e2332ff7..bc4a380545af 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -257,7 +257,6 @@ class VariadicEnumArgument values,
 class Spelling {
   string Name = name;
   string Variety = variety;
-  bit KnownToGCC;
 }
 
 class GNU : Spelling;
@@ -277,11 +276,11 @@ class Pragma : 
Spelling {
   string Namespace = namespace;
 }
 
-// The GCC spelling implies GNU and CXX11<"gnu", name> and also sets
-// KnownToGCC to 1. This spelling should be used for any GCC-compatible
+// The GCC spelling implies GNU, CXX11<"gnu", name>, and optionally,
+// C2x<"gnu", name>. This spelling should be used for any GCC-compatible
 // attributes.
-class GCC : Spelling {
-  let KnownToGCC = 1;
+class GCC : Spelling {
+  bit AllowInC = allowInC;
 }
 
 // The Clang spelling implies GNU, CXX11<"clang", name>, and optionally,
@@ -605,7 +604,7 @@ class IgnoredAttr : Attr {
 //
 
 def AbiTag : Attr {
-  let Spellings = [GCC<"abi_tag">];
+  let Spellings = [GCC<"abi_tag", /*AllowInC*/0>];
   let Args = [VariadicStringArgument<"Tags">];
   let Subjects = SubjectList<[Struct, Var, Function, Namespace], ErrorDiag>;
   let MeaningfulToClassTemplateDefinition = 1;
@@ -2113,7 +2112,7 @@ def WorkGroupSizeHint :  InheritableAttr {
 }
 
 def InitPriority : InheritableAttr {
-  let Spellings = [GCC<"init_priority">];
+  let Spellings = [GCC<"init_priority", /*AllowInC*/0>];
   let Args = [UnsignedArgument<"Priority">];
   let Subjects = SubjectList<[Var], ErrorDiag>;
   let Documentation = [Undocumented];

diff  --git a/clang/test/Sema/attr-c2x.c b/clang/test/Sema/attr-c2x.c
index 561b88edfc84..fae4c5d0fa90 100644
--- a/clang/test/Sema/attr-c2x.c
+++ b/clang/test/Sema/attr-c2x.c
@@ -27,3 +27,15 @@ void bar(void) {
 
 [[nodiscard]] int without_underscores(void);
 [[__nodiscard__]] int underscores(void);
+
+// Match GCC's behavior for C attributes as well.
+[[gnu::constructor]] void ctor_func(void);
+[[gnu::destructor]] void dtor_func(void);
+[[gnu::hot]] void hot_func(void);
+[[__gnu__::hot]] void hot_func2(void);
+[[gnu::__hot__]] void hot_func3(void);
+[[__gnu__::__hot__]] void hot_func4(void);
+
+// Note how not all GCC attributes are supported in C.
+[[gnu::abi_tag("")]] void abi_func(void); // expected-warning {{unknown 
attribute 'abi_tag' ignored}}
+struct S s [[gnu::init_priority(1)]]; // expected-warning {{unknown attribute 
'init_priority' ignored}}

diff  --git a/clang/utils/TableGen/ClangAttrEmitter.cpp 
b/clang/utils/TableGen/ClangAttrEmitter.cpp
index 2b1719599785..1b9fd2d29bf9 100644
--- a/clang/utils/TableGen/ClangAttrEmitter.cpp
+++ b/clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -48,7 +48,7 @@ namespace {
 
 class FlattenedSpelling {
   std::string V, N, NS;
-  bool K;
+  bool K = false;
 
 public:
   FlattenedSpelling(const std::string &Variety, const std::string &Name,
@@ -61,8 +61,6 @@ class FlattenedSpelling {
"Given a GCC spelling, which means this hasn't been flattened!");
 if (V == "CXX11" || V == "C2x" || V == "Pragma")
   NS = std::string(Spelling.getValueAsString("Namespace"));
-bool Unset;
-K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);
   }
 
   const std::string &variety() const { return V; }
@@ -82,9 +80,10 @@ GetFlattenedSpellings(const Record &Attr) {
 StringRef Variety = Spelling->getValueAsString("Variety");
 StringRef Name = Spelling->getValueAsString("Name");
 if (Variety == "GCC") {
-  // Gin up two new spelling objects to add into the list.
   Ret.emplace_back("GNU", std::string(Name), "", true);
   Ret.emplace_back("CXX11", std::string(Name), "gnu", true);
+  if (Spelling->getValueAsBit("AllowInC"))
+Ret.emplace_back("C2x", std::string(Name), "gnu", true);
 } else if (Variety == "Clang") {
   Ret.emplace_ba

[PATCH] D80925: Fix compiler crash when trying to parse alignment argument as a constant expression.

2020-06-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added reviewers: rjmccall, rsmith.
Herald added a project: clang.

Clang crashes when trying to finish function body. MaybeODRUseExprs is
not empty because of const static data member parsed in outer evaluation
context, upon call for isTypeIdInParens() function. It builds
annot_primary_expr, later parsed in ParseConstantExpression() in
inner constant expression evaluation context.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80925

Files:
  clang/lib/Parse/ParseDecl.cpp
  clang/test/AST/alignas_maybe_odr_cleanup.cpp


Index: clang/test/AST/alignas_maybe_odr_cleanup.cpp
===
--- /dev/null
+++ clang/test/AST/alignas_maybe_odr_cleanup.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only %s -ast-dump | FileCheck %s
+
+struct FOO {
+  static const int vec_align_bytes = 32;
+  void foo() {
+double a alignas(vec_align_bytes);
+;
+  }
+};
+
+// CHECK: AlignedAttr {{.*}} alignas
+// CHECK: ConstantExpr {{.+}} 'int' Int: 32
+// CHECK: ImplicitCastExpr {{.*}} 'int' 
+// CHECK: DeclRefExpr {{.*}} 'const int' lvalue Var {{.*}} 'vec_align_bytes' 
'const int' non_odr_use_constant
+// CHECK: NullStmt
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -2827,6 +2827,8 @@
 /// [C++0x] assignment-expression ...[opt]
 ExprResult Parser::ParseAlignArgument(SourceLocation Start,
   SourceLocation &EllipsisLoc) {
+  EnterExpressionEvaluationContext ConstantEvaluated(
+  Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated);
   ExprResult ER;
   if (isTypeIdInParens()) {
 SourceLocation TypeLoc = Tok.getLocation();
@@ -2834,8 +2836,9 @@
 SourceRange TypeRange(Start, Tok.getLocation());
 ER = Actions.ActOnUnaryExprOrTypeTraitExpr(TypeLoc, UETT_AlignOf, true,
Ty.getAsOpaquePtr(), TypeRange);
-  } else
-ER = ParseConstantExpression();
+  } else {
+ER = ParseConstantExpressionInExprEvalContext();
+  }
 
   if (getLangOpts().CPlusPlus11)
 TryConsumeToken(tok::ellipsis, EllipsisLoc);


Index: clang/test/AST/alignas_maybe_odr_cleanup.cpp
===
--- /dev/null
+++ clang/test/AST/alignas_maybe_odr_cleanup.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only %s -ast-dump | FileCheck %s
+
+struct FOO {
+  static const int vec_align_bytes = 32;
+  void foo() {
+double a alignas(vec_align_bytes);
+;
+  }
+};
+
+// CHECK: AlignedAttr {{.*}} alignas
+// CHECK: ConstantExpr {{.+}} 'int' Int: 32
+// CHECK: ImplicitCastExpr {{.*}} 'int' 
+// CHECK: DeclRefExpr {{.*}} 'const int' lvalue Var {{.*}} 'vec_align_bytes' 'const int' non_odr_use_constant
+// CHECK: NullStmt
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -2827,6 +2827,8 @@
 /// [C++0x] assignment-expression ...[opt]
 ExprResult Parser::ParseAlignArgument(SourceLocation Start,
   SourceLocation &EllipsisLoc) {
+  EnterExpressionEvaluationContext ConstantEvaluated(
+  Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated);
   ExprResult ER;
   if (isTypeIdInParens()) {
 SourceLocation TypeLoc = Tok.getLocation();
@@ -2834,8 +2836,9 @@
 SourceRange TypeRange(Start, Tok.getLocation());
 ER = Actions.ActOnUnaryExprOrTypeTraitExpr(TypeLoc, UETT_AlignOf, true,
Ty.getAsOpaquePtr(), TypeRange);
-  } else
-ER = ParseConstantExpression();
+  } else {
+ER = ParseConstantExpressionInExprEvalContext();
+  }
 
   if (getLangOpts().CPlusPlus11)
 TryConsumeToken(tok::ellipsis, EllipsisLoc);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-06-01 Thread Ties Stuij via Phabricator via cfe-commits
stuij marked an inline comment as done.
stuij added a comment.

In D76077#2066323 , @SjoerdMeijer 
wrote:

> Can you summarise where we are? I.e.,
>
> - float-abi=soft doesn't work. But what is the problem? Are we not simply 
> passing i16s, is that not what we are supposed to do?


At the moment when going through the GCC compatibility driver (standard 
interface), we get `__bf16 is not supported on this target`.
When using -cc1, we can pass `-mfloat-abi=soft`, we can compile source-code 
that contains `__bf16`, and we can also compile neon intrinsics in general. It 
looks like we just ignore soft was passed and instead we use the hard 
float-abi. For intrinsics we should error.

In general we pass i32's btw, not i16's. Also for `__fp16`.

> Can you also update the description of this patch, I got totally confused by:
> 
> - "introduces an opaque, storage-only C-type __bf16, which does not introduce 
> a new LLVM IR type, but maps it to either i16 or half type."

willdo


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D80836: Support GCC [[gnu::attributes]] in C2x mode

2020-06-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman closed this revision.
aaron.ballman added a comment.

Thank you for the review, I've commit in 
522934da1f0c78c1de1a80d4ba14204a11f5afa8 



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

https://reviews.llvm.org/D80836



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


[PATCH] D80928: [BFloat] Add convert/copy instrinsic support

2020-06-01 Thread Alexandros Lamprineas via Phabricator via cfe-commits
labrinea created this revision.
labrinea added reviewers: fpetrogalli, LukeGeeson, stuij, momchil.velikov, 
SjoerdMeijer, miyuki.
Herald added subscribers: hiraditya, kristof.beyls.
Herald added projects: clang, LLVM.

This patch is part of a series implementing the Bfloat16 extension of the 
Armv8.6-a architecture, as detailed here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a

Specifically it adds intrinsic support in clang and llvm for Arm and AArch64.

The bfloat type, and its properties are specified in the Arm Architecture 
Reference Manual:

https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile

The following people contributed to this patch:

- Alexandros Lamprineas
- Luke Cheeseman
- Mikhail Maltsev
- Momchil Velikov


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80928

Files:
  clang/include/clang/Basic/arm_neon.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-bf16-lane-intrinsics.c
  clang/test/CodeGen/arm-bf16-conv-copy-intrinsics.c
  clang/test/Sema/aarch64-neon-bf16-ranges.c
  clang/utils/TableGen/NeonEmitter.cpp
  llvm/include/llvm/IR/IntrinsicsAArch64.td
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp
  llvm/test/CodeGen/AArch64/bf16-intrinsics.ll
  llvm/test/CodeGen/ARM/bf16-intrinsics-nofp16.ll
  llvm/test/CodeGen/ARM/bf16-intrinsics.ll

Index: llvm/test/CodeGen/ARM/bf16-intrinsics.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/bf16-intrinsics.ll
@@ -0,0 +1,24 @@
+; RUN: llc < %s -verify-machineinstrs -mtriple=armv8.6a-arm-none-eabi -mattr=+fullfp16 -mattr=+neon -mattr=+bf16 | FileCheck %s
+
+declare bfloat @llvm.arm.neon.vcvtbfp2bf.bf16.f32(float)
+declare <4 x bfloat> @llvm.arm.neon.vcvtfp2bf.v4bf16.v4f32(<4 x float>)
+
+; CHECK-LABEL: test_vcvth_bf16_f32
+; CHECK: vcvtb.bf16.f32  s0, s0
+define arm_aapcs_vfpcc float @test_vcvth_bf16_f32(float %a) {
+entry:
+  %vcvtbfp2bf.i = tail call bfloat @llvm.arm.neon.vcvtbfp2bf.bf16.f32(float %a)
+  %0 = bitcast bfloat %vcvtbfp2bf.i to i16
+  %tmp.0.insert.ext.i = zext i16 %0 to i32
+  %1 = bitcast i32 %tmp.0.insert.ext.i to float
+  ret float %1
+}
+
+; CHECK-LABEL: test_vcvt_bf16_f32
+; CHECK: vcvt.bf16.f32   d0, q0
+define arm_aapcs_vfpcc <4 x bfloat> @test_vcvt_bf16_f32(<4 x float> %a) {
+entry:
+  %vcvtfp2bf1.i.i = call <4 x bfloat> @llvm.arm.neon.vcvtfp2bf.v4bf16.v4f32(<4 x float> %a)
+  ret <4 x bfloat> %vcvtfp2bf1.i.i
+}
+
Index: llvm/test/CodeGen/ARM/bf16-intrinsics-nofp16.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/bf16-intrinsics-nofp16.ll
@@ -0,0 +1,23 @@
+; RUN: llc < %s -verify-machineinstrs -mtriple=armv8.6a-arm-none-eabi -mattr=+neon -mattr=+bf16 | FileCheck %s
+
+declare i32 @llvm.arm.neon.vcvtbfp2bf.i32.f32(float)
+declare <4 x i16> @llvm.arm.neon.vcvtfp2bf.v4i16.v4f32(<4 x float>)
+
+; CHECK-LABEL: test_vcvth_bf16_f32
+; CHECK: vcvtb.bf16.f32  s0, s0
+define arm_aapcs_vfpcc float @test_vcvth_bf16_f32(float %a) {
+entry:
+  %vcvtbfp2bf = tail call i32 @llvm.arm.neon.vcvtbfp2bf.i32.f32(float %a)
+  %tmp.0.insert.ext = and i32 %vcvtbfp2bf, 65535
+  %0 = bitcast i32 %tmp.0.insert.ext to float
+  ret float %0
+}
+
+; CHECK-LABEL: test_vcvt_bf16_f32
+; CHECK: vcvt.bf16.f32   d0, q0
+define arm_aapcs_vfpcc <2 x i32> @test_vcvt_bf16_f32(<4 x float> %a) {
+entry:
+  %vcvtfp2bf1.i.i = tail call <4 x i16> @llvm.arm.neon.vcvtfp2bf.v4i16.v4f32(<4 x float> %a)
+  %0 = bitcast <4 x i16> %vcvtfp2bf1.i.i to <2 x i32>
+  ret <2 x i32> %0
+}
Index: llvm/test/CodeGen/AArch64/bf16-intrinsics.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/bf16-intrinsics.ll
@@ -0,0 +1,34 @@
+; RUN: llc < %s -verify-machineinstrs -mtriple=aarch64-arm-none-eabi -mattr=+neon -mattr=+bf16 | FileCheck %s
+
+declare bfloat @llvm.aarch64.neon.bfcvt.f16.f32(float)
+declare <8 x bfloat> @llvm.aarch64.neon.bfcvtn.v8f16.v4f32(<4 x float>)
+declare <8 x bfloat> @llvm.aarch64.neon.bfcvtn2.v8f16.v8f16.v4f32(<8 x bfloat>, <4 x float>)
+
+; CHECK-LABEL: test_vcvth_bf16_f32
+; CHECK:  bfcvt h0, s0
+; CHECK-NEXT: ret
+define bfloat @test_vcvth_bf16_f32(float %a) {
+entry:
+  %vcvth_bf16_f32 = call bfloat @llvm.aarch64.neon.bfcvt.f16.f32(float %a)
+  ret bfloat %vcvth_bf16_f32
+}
+
+; CHECK-LABEL: test_vcvtq_low_bf16_f32
+; CHECK:  bfcvtn v0.4h, v0.4s
+; CHECK-NEXT: ret
+define <8 x bfloat> @test_vcvtq_low_bf16_f32(<4 x float> %a) {
+entry:
+  %cvt = call <8 x bfloat> @llvm.aarch64.neon.bfcvtn.v8f16.v4f32(<4 x float> %a)
+  ret <8 x bfloat> %cvt
+}
+
+; CHECK-LABEL: test_vcvtq_high_bf16_f32
+; CHECK:  bfcvtn2 v1.8h, v0.4s
+; CHECK-NEXT: mov v0.16b, v1.16b
+; CHECK-NEXT: ret
+define <8 x bfloat> @test_vcvtq_high_bf16

[PATCH] D80697: [clang-tidy] Reworked TransformerClangTidyCheck to simplify usage of Options

2020-06-01 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

Thanks for the changes!

In D80697#2062517 , @njames93 wrote:

> There are a few reasons for using the virtual method:


I think I'm missing something (or I didn't explain my intention well):

> - It keeps everything contained in the one class.

Everything is still in one class -- the constructor of the derived class just 
calls `setRule`.

> - In the case where options are needed it avoid extra work in the derived 
> class.

Why wouldn't this also avoid the extra work? The constructor of the derived 
class initializes the local variables and then in its body calls `setRule`. For 
example, in the class you modified above, the constructor barely changes. Just 
the body:

  ... {
setRule(buildRule());
  }

where `buildRule` is now just a static function are non-virtual private 
function and doesn't need to return optional, because the logic deciding about 
constructed it can just be used instead to guard the call to `setRule` as need 
be.  Given the virtual method `isLanguageVersionSupported`, there usually won't 
be any such logic.

> - It's consistent with how all base class checks handle the specifics of 
> derived checks.

Sorry, I'm not sure what you mean -- can you expand on this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80697



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


[PATCH] D76794: [Matrix] Implement * binary operator for MatrixType.

2020-06-01 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 267627.
fhahn added a comment.

Ping :)

Updated the patch to include the feedback from D76793 
 (adding overloads, conversions, more targeted 
tests)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76794

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGenCXX/matrix-type-operators.cpp
  clang/test/Sema/matrix-type-operators.c
  clang/test/SemaCXX/matrix-type-operators.cpp
  llvm/include/llvm/IR/MatrixBuilder.h

Index: llvm/include/llvm/IR/MatrixBuilder.h
===
--- llvm/include/llvm/IR/MatrixBuilder.h
+++ llvm/include/llvm/IR/MatrixBuilder.h
@@ -33,6 +33,21 @@
   IRBuilderTy &B;
   Module *getModule() { return B.GetInsertBlock()->getParent()->getParent(); }
 
+  std::pair splatScalarOperandIfNeeded(Value *LHS,
+ Value *RHS) {
+assert((LHS->getType()->isVectorTy() || RHS->getType()->isVectorTy()) &&
+   "One of the operands must be a matrix (embedded in a vector)");
+if (LHS->getType()->isVectorTy() && !RHS->getType()->isVectorTy())
+  RHS = B.CreateVectorSplat(
+  cast(LHS->getType())->getNumElements(), RHS,
+  "scalar.splat");
+else if (!LHS->getType()->isVectorTy() && RHS->getType()->isVectorTy())
+  LHS = B.CreateVectorSplat(
+  cast(RHS->getType())->getNumElements(), LHS,
+  "scalar.splat");
+return {LHS, RHS};
+  }
+
 public:
   MatrixBuilder(IRBuilderTy &Builder) : B(Builder) {}
 
@@ -164,15 +179,13 @@
: B.CreateSub(LHS, RHS);
   }
 
-  /// Multiply matrix \p LHS with scalar \p RHS.
+  /// Multiply matrix \p LHS with scalar \p RHS or scalar \p LHS with matrix \p
+  /// RHS.
   Value *CreateScalarMultiply(Value *LHS, Value *RHS) {
-Value *ScalarVector =
-B.CreateVectorSplat(cast(LHS->getType())->getNumElements(),
-RHS, "scalar.splat");
-if (RHS->getType()->isFloatingPointTy())
-  return B.CreateFMul(LHS, ScalarVector);
-
-return B.CreateMul(LHS, ScalarVector);
+std::tie(LHS, RHS) = splatScalarOperandIfNeeded(LHS, RHS);
+if (LHS->getType()->getScalarType()->isFloatingPointTy())
+  return B.CreateFMul(LHS, RHS);
+return B.CreateMul(LHS, RHS);
   }
 
   /// Extracts the element at (\p RowIdx, \p ColumnIdx) from \p Matrix.
Index: clang/test/SemaCXX/matrix-type-operators.cpp
===
--- clang/test/SemaCXX/matrix-type-operators.cpp
+++ clang/test/SemaCXX/matrix-type-operators.cpp
@@ -204,3 +204,26 @@
   a[2] = f;
   // expected-error@-1 {{single subscript expressions are not allowed for matrix values}}
 }
+
+template 
+typename MyMatrix::matrix_t multiply(MyMatrix &A, MyMatrix &B) {
+  char *v1 = A.value * B.value;
+  // expected-error@-1 {{cannot initialize a variable of type 'char *' with an rvalue of type 'unsigned int __attribute__((matrix_type(2, 2)))'}}
+  // expected-error@-2 {{invalid operands to binary expression ('MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))') and 'MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(3, 3)))'))}}
+
+  return A.value * B.value;
+  // expected-error@-1 {{invalid operands to binary expression ('MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))') and 'MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(3, 3)))'))}}
+}
+
+void test_multiply_template(unsigned *Ptr1, float *Ptr2) {
+  MyMatrix Mat1;
+  MyMatrix Mat2;
+  MyMatrix Mat3;
+  Mat1.value = *((decltype(Mat1)::matrix_t *)Ptr1);
+  unsigned v1 = multiply(Mat1, Mat1);
+  // expected-note@-1 {{in instantiation of function template specialization 'multiply' requested here}}
+  // expected-error@-2 {{cannot initialize a variable of type 'unsigned int' with an rvalue of type 'typename MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))')}}
+
+  Mat1.value = multiply(Mat1, Mat2);
+  // expected-note@-1 {{in instantiation of function template specialization 'multiply' requested here}}
+}
Index: clang/test/Sema/matrix-type-operators.c
===
--- clang/test/Sema/matrix-type-operators.c
+++ clang/test/Sema/matrix-type-operators.c
@@ -132,3 +132,9 @@
   return &(*a)[0][1];
   // expected-error@-1 {{address of matrix element requested}}
 }
+
+void mat_scalar_multiply(sx10x10_t a, sx5x10_t b, float scalar) {
+  // Shape of multiplication result does not match the type of b.
+  b = a * scalar;
+  // expected-error@-1 {{assigning to 'sx5x10_t' (aka 'float __attribute__((matrix_type(5, 10)))') from incompatible type 'sx10x10_t' (aka 'float __att

[PATCH] D80931: AMDGPU: Fix clang side null pointer value for private

2020-06-01 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm created this revision.
arsenm added reviewers: cfe-commits, cdevadas.
Herald added subscribers: kerbowa, t-tye, tpr, dstuttard, yaxunl, nhaehnle, 
wdng, jvesely, kzhuravl.

The change to fold_priv_arith looks strange to me, but this was
already the untested behavior for local.


https://reviews.llvm.org/D80931

Files:
  clang/lib/Basic/Targets/AMDGPU.h
  clang/test/CodeGenOpenCL/amdgpu-nullptr.cl

Index: clang/test/CodeGenOpenCL/amdgpu-nullptr.cl
===
--- clang/test/CodeGenOpenCL/amdgpu-nullptr.cl
+++ clang/test/CodeGenOpenCL/amdgpu-nullptr.cl
@@ -19,7 +19,7 @@
 
 // Test 0 as initializer.
 
-// CHECK: @private_p = local_unnamed_addr addrspace(1) global i8 addrspace(5)* null, align 4
+// CHECK: @private_p = local_unnamed_addr addrspace(1) global i8 addrspace(5)* addrspacecast (i8* null to i8 addrspace(5)*), align 4
 private char *private_p = 0;
 
 // CHECK: @local_p = local_unnamed_addr addrspace(1) global i8 addrspace(3)* addrspacecast (i8* null to i8 addrspace(3)*), align 4
@@ -36,7 +36,7 @@
 
 // Test NULL as initializer.
 
-// CHECK: @private_p_NULL = local_unnamed_addr addrspace(1) global i8 addrspace(5)* null, align 4
+// CHECK: @private_p_NULL = local_unnamed_addr addrspace(1) global i8 addrspace(5)* addrspacecast (i8* null to i8 addrspace(5)*), align 4
 private char *private_p_NULL = NULL;
 
 // CHECK: @local_p_NULL = local_unnamed_addr addrspace(1) global i8 addrspace(3)* addrspacecast (i8* null to i8 addrspace(3)*), align 4
@@ -57,25 +57,28 @@
 // CHECK: @fold_generic = local_unnamed_addr addrspace(1) global i32* null, align 8
 generic int *fold_generic = (global int*)(generic float*)(private char*)0;
 
-// CHECK: @fold_priv = local_unnamed_addr addrspace(1) global i16 addrspace(5)* null, align 4
+// CHECK: @fold_priv = local_unnamed_addr addrspace(1) global i16 addrspace(5)* addrspacecast (i16* null to i16 addrspace(5)*), align 4
 private short *fold_priv = (private short*)(generic int*)(global void*)0;
 
-// CHECK: @fold_priv_arith = local_unnamed_addr addrspace(1) global i8 addrspace(5)* inttoptr (i32 10 to i8 addrspace(5)*), align 4
+// CHECK: @fold_priv_arith = local_unnamed_addr addrspace(1) global i8 addrspace(5)* inttoptr (i32 9 to i8 addrspace(5)*), align 4
 private char *fold_priv_arith = (private char*)0 + 10;
 
-// CHECK: @fold_int = local_unnamed_addr addrspace(1) global i32 14, align 4
+// CHECK: @fold_local_arith = local_unnamed_addr addrspace(1) global i8 addrspace(3)* inttoptr (i32 9 to i8 addrspace(3)*), align 4
+local char *fold_local_arith = (local char*)0 + 10;
+
+// CHECK: @fold_int = local_unnamed_addr addrspace(1) global i32 13, align 4
 int fold_int = (int)(private void*)(generic char*)(global int*)0 + 14;
 
-// CHECK: @fold_int2 = local_unnamed_addr addrspace(1) global i32 13, align 4
+// CHECK: @fold_int2 = local_unnamed_addr addrspace(1) global i32 12, align 4
 int fold_int2 = (int) ((private void*)0 + 13);
 
-// CHECK: @fold_int3 = local_unnamed_addr addrspace(1) global i32 0, align 4
+// CHECK: @fold_int3 = local_unnamed_addr addrspace(1) global i32 -1, align 4
 int fold_int3 = (int) ((private int*)0);
 
-// CHECK: @fold_int4 = local_unnamed_addr addrspace(1) global i32 8, align 4
+// CHECK: @fold_int4 = local_unnamed_addr addrspace(1) global i32 7, align 4
 int fold_int4 = (int) &((private int*)0)[2];
 
-// CHECK: @fold_int5 = local_unnamed_addr addrspace(1) global i32 4, align 4
+// CHECK: @fold_int5 = local_unnamed_addr addrspace(1) global i32 3, align 4
 int fold_int5 = (int) &((private StructTy1*)0)->p2;
 
 
@@ -97,12 +100,12 @@
 
 // Test static variable initialization.
 
-// NOOPT: @test_static_var_private.sp1 = internal addrspace(1) global i8 addrspace(5)* null, align 4
-// NOOPT: @test_static_var_private.sp2 = internal addrspace(1) global i8 addrspace(5)* null, align 4
-// NOOPT: @test_static_var_private.sp3 = internal addrspace(1) global i8 addrspace(5)* null, align 4
+// NOOPT: @test_static_var_private.sp1 = internal addrspace(1) global i8 addrspace(5)* addrspacecast (i8* null to i8 addrspace(5)*), align 4
+// NOOPT: @test_static_var_private.sp2 = internal addrspace(1) global i8 addrspace(5)* addrspacecast (i8* null to i8 addrspace(5)*), align 4
+// NOOPT: @test_static_var_private.sp3 = internal addrspace(1) global i8 addrspace(5)* addrspacecast (i8* null to i8 addrspace(5)*), align 4
 // NOOPT: @test_static_var_private.sp4 = internal addrspace(1) global i8 addrspace(5)* null, align 4
 // NOOPT: @test_static_var_private.sp5 = internal addrspace(1) global i8 addrspace(5)* null, align 4
-// NOOPT: @test_static_var_private.SS1 = internal addrspace(1) global %struct.StructTy1 { i8 addrspace(5)* null, i8 addrspace(3)* addrspacecast (i8* null to i8 addrspace(3)*), i8 addrspace(4)* null, i8 addrspace(1)* null, i8* null }, align 8
+// NOOPT: @test_static_var_private.SS1 = internal addrspace(1) global %struct.StructTy1 { i8 addrspace(5)* addrspacecast (i8* null to i8 addrspace(5)*), i8 addrspace(

[PATCH] D80932: [SYCL] Make default address space a superset of OpenCL address spaces.

2020-06-01 Thread Alexey Bader via Phabricator via cfe-commits
bader created this revision.
bader added reviewers: Anastasia, keryell, Naghasan, asavonic, Fznamznon.
Herald added subscribers: cfe-commits, ebevhan, yaxunl.
Herald added a project: clang.

This change enables conversion between OpenCL address spaces and default
address space similar to conversions between OpenCL generic and OpenCL
global/local/private address spaces.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80932

Files:
  clang/include/clang/AST/Type.h
  clang/test/SemaOpenCLCXX/address-space-lambda.cl
  clang/test/SemaOpenCLCXX/pr-45472.cpp
  clang/test/SemaSYCL/address-space-parameter-conversions.cpp

Index: clang/test/SemaSYCL/address-space-parameter-conversions.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/address-space-parameter-conversions.cpp
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -fsycl -fsycl-is-device -verify -fsyntax-only %s
+
+void bar(int &Data) {}
+void bar2(int &Data) {}
+void bar(__attribute__((opencl_private)) int &Data) {}
+void foo(int *Data) {}
+void foo2(int *Data) {}
+void foo(__attribute__((opencl_private)) int *Data) {}
+
+template 
+void tmpl(T *t) {}
+
+void usages() {
+  __attribute__((opencl_global)) int *GLOB;
+  __attribute__((opencl_private)) int *PRIV;
+  __attribute__((opencl_local)) int *LOC;
+  int *NoAS;
+
+  bar(*GLOB);
+  bar2(*GLOB);
+
+  bar(*PRIV);
+  bar2(*PRIV);
+
+  bar(*NoAS);
+  bar2(*NoAS);
+
+  bar(*LOC);
+  bar2(*LOC);
+
+  foo(GLOB);
+  foo2(GLOB);
+  foo(PRIV);
+  foo2(PRIV);
+  foo(NoAS);
+  foo2(NoAS);
+  foo(LOC);
+  foo2(LOC);
+
+  tmpl(GLOB);
+  tmpl(PRIV);
+  tmpl(NoAS);
+  tmpl(LOC);
+
+  (void)static_cast(GLOB);
+  (void)static_cast(GLOB);
+  // FIXME: determine if we can warn on the below conversions.
+  int *i = GLOB;
+  void *v = GLOB;
+  (void)i;
+  (void)v;
+
+  // expected-error@+1{{address space is negative}}
+  __attribute__((address_space(-1))) int *TooLow;
+  // expected-error@+1{{unknown type name '__generic'}}
+  __generic int *IsGeneric;
+}
Index: clang/test/SemaOpenCLCXX/pr-45472.cpp
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/pr-45472.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 %s -cl-std=clc++ -pedantic -ast-dump -verify | FileCheck %s
+// FIXME: expected error is not emitted due to wrong address space inference
+// see https://bugs.llvm.org/show_bug.cgi?id=45472 for more details.
+// XFAIL: *
+
+__kernel void test_qual() {
+  auto priv3 = []() __global {}; //expected-note{{candidate function not viable: 'this' object is in address space '__private', but method expects object in address space '__global'}} //expected-note{{conversion candidate of type 'void (*)()'}}
+  priv3();   //expected-error{{no matching function for call to object of type}}
+}
\ No newline at end of file
Index: clang/test/SemaOpenCLCXX/address-space-lambda.cl
===
--- clang/test/SemaOpenCLCXX/address-space-lambda.cl
+++ clang/test/SemaOpenCLCXX/address-space-lambda.cl
@@ -31,8 +31,6 @@
 //CHECK: |-CXXMethodDecl {{.*}} constexpr operator() 'void () {{.*}}const __generic'
   auto priv2 = []() __generic {};
   priv2();
-  auto priv3 = []() __global {}; //expected-note{{candidate function not viable: 'this' object is in address space '__private', but method expects object in address space '__global'}} //expected-note{{conversion candidate of type 'void (*)()'}}
-  priv3(); //expected-error{{no matching function for call to object of type}}
 
   __constant auto const1 = []() __private{}; //expected-note{{candidate function not viable: 'this' object is in address space '__constant', but method expects object in address space '__private'}} //expected-note{{conversion candidate of type 'void (*)()'}}
   const1(); //expected-error{{no matching function for call to object of type '__constant (lambda at}}
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -488,7 +488,12 @@
   /// Returns true if the address space in these qualifiers is equal to or
   /// a superset of the address space in the argument qualifiers.
   bool isAddressSpaceSupersetOf(Qualifiers other) const {
-return isAddressSpaceSupersetOf(getAddressSpace(), other.getAddressSpace());
+return isAddressSpaceSupersetOf(getAddressSpace(),
+other.getAddressSpace()) ||
+   (!hasAddressSpace() &&
+(other.getAddressSpace() == LangAS::opencl_private ||
+ other.getAddressSpace() == LangAS::opencl_local ||
+ other.getAddressSpace() == LangAS::opencl_global));
   }
 
   /// Determines if these qualifiers compatibly include another set.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis

[PATCH] D80928: [BFloat] Add convert/copy instrinsic support

2020-06-01 Thread Luke Geeson via Phabricator via cfe-commits
LukeGeeson added a comment.

A few nits, it looks largely uncontroversial but I'll let someone else give the 
ok since an external eye is always good :)




Comment at: clang/utils/TableGen/NeonEmitter.cpp:1066
 
   if (Name == "vcvt_f16_f32" || Name == "vcvt_f32_f16" ||
+  Name == "vcvt_f32_f64" || Name == "vcvt_f64_f32" ||

I always wondered why we need special treatment for cvt intrinsics here, is 
there a better place to put this?



Comment at: llvm/test/CodeGen/ARM/bf16-intrinsics-nofp16.ll:1
+; RUN: llc < %s -verify-machineinstrs -mtriple=armv8.6a-arm-none-eabi 
-mattr=+neon -mattr=+bf16 | FileCheck %s
+

These files are very small, it's almost not worth having them on their own, can 
you merge them into 1 file unless we need 2 for a specific reason



Comment at: llvm/test/CodeGen/ARM/bf16-intrinsics.ll:1
+; RUN: llc < %s -verify-machineinstrs -mtriple=armv8.6a-arm-none-eabi 
-mattr=+fullfp16 -mattr=+neon -mattr=+bf16 | FileCheck %s
+

same here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80928



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-06-01 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added a comment.

> At the moment when going through the GCC compatibility driver (standard 
> interface), we get __bf16 is not supported on this target.

If this is the current behaviour, and consistent with GCC, that sounds 
reasonable. Probably best to be explicit about this and document this in 
LangRef. With a note that this is subject to change?
Oh, and I guess that means we can add a test this for this? We can check this 
error message?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D79710: [clang][BFloat] add create/set/get/dup intrinsics

2020-06-01 Thread Alexandros Lamprineas via Phabricator via cfe-commits
labrinea added inline comments.



Comment at: clang/include/clang/Basic/arm_neon.td:1854
+  def VDUP_LANE_BF : WOpInst<"vdup_lane", ".qI", "bQb", OP_DUP_LN>;
+  def VDUP_LANEQ_BF: WOpInst<"vdup_laneq", ".QI", "bQb", OP_DUP_LN> {
+let isLaneQ = 1;

My local build points here with:
`arm_neon.td:1926:3: error: No compatible intrinsic found - looking up 
intrinsic 'splat_laneq(bfloat16x8_t, int32_t)'`




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79710



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


[PATCH] D80490: [clang-tidy] Check for rule of five and zero.

2020-06-01 Thread Jonathan B Coe via Phabricator via cfe-commits
jbcoe added a comment.

https://reviews.llvm.org/D16376 was written by me, I'm afraid I don't recall 
why I abandoned it and was surprised to see that it had not been submitted.

I don't feel comfortable approving work based on my own but this patch looks 
great to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80490



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


[PATCH] D80757: [PowerPC] Add clang option -m[no-]pcrel

2020-06-01 Thread Stefan Pintilie via Phabricator via cfe-commits
stefanp accepted this revision as: stefanp.
stefanp added a comment.

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80757



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


[PATCH] D80584: [utils] change update_test_checks.py use of 'TMP' value names

2020-06-01 Thread Sanjay Patel via Phabricator via cfe-commits
spatel closed this revision.
spatel added a comment.

In D80584#2066319 , @jdoerfert wrote:

> First, I think the warning is strictly a good thing. Thanks for keeping that 
> in!


Sure - we've been missing that for a long time.

> I don't think the options are really "complexity to the user" given a 
> sensible default (= the old value). If a user sees a warning that says: `Name 
> conflict, use --nameless-prefix=X, where X is a string not otherwise 
> used in your IR`, they will happily do so. The UTC_ARGS extension makes it 
> permanent and no one needs to worry about this until they see a warning 
> again. (If we can "hide" the option from the help message, I'm fine with that 
> too.)

I'm still not convinced that's worth doing. I did change instnamer though:
rGdd54432a0f5a 

...so between the warning and at least 1 of these not using 'tmp', I think 
we're good enough.

> Adding a test is just something we should do as it is easy to accidentally 
> break functionality like the warning.

Yep, I didn't remember that we had tests for scripts. So we have that now, and 
there's a clang test that wiggles on this too...although that seems like we 
should generalize that file to avoid killing all of the bots like I did. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80584



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


[PATCH] D80490: [clang-tidy] Check for rule of five and zero.

2020-06-01 Thread Jonathan B Coe via Phabricator via cfe-commits
jbcoe added a comment.

Perhaps associated is https://github.com/isocpp/CppCoreGuidelines/issues/870 
which was closed but never (in my mind) resolved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80490



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


[PATCH] D80933: [clang-format] [PR46157] Wrong spacing of negative literals with use of operator

2020-06-01 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: krasimir, JakeMerdichAMD, curdeius, 
mitchell-stellar.
MyDeveloperDay added projects: clang, clang-format.
MyDeveloperDay added a reviewer: thopre.
MyDeveloperDay edited the summary of this revision.

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

  class A;
  
  void foo(A (*)(const A&, const A&), int);
  A operator+(const A&, const A&);
  
  void bar() {
return foo(operator+, -42);
  }

is incorrect formatted putting a space between the `-` and the 42

  return foo(operator+, - 42);

This revision tries to refine the annotating of the OverloadOperator to only 
mark the comma as an operator if its immediately after the operator keyword and 
to not mark the closing '(' as an TT_OverloadedOperatorLParen unless its 
actually a `(`

This code was assuming the usage of operator too much I suspect and not 
considering its use as a function ptr.

Probably a fairly rare corner case.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80933

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16417,6 +16417,17 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, OperatorPassedAsAFunctionPtr) {
+  FormatStyle Style = getLLVMStyle();
+  // PR46157
+  verifyFormat("foo(operator+, -42);", Style);
+  verifyFormat("foo(operator++, -42);", Style);
+  verifyFormat("foo(operator--, -42);", Style);
+  verifyFormat("foo(-42, operator--);", Style);
+  verifyFormat("foo(-42, operator, );", Style);
+  verifyFormat("foo(operator, , -42);", Style);
+}
+
 TEST_F(FormatTest, VeryLongNamespaceCommentSplit) {
   // These tests are not in NamespaceFixer because that doesn't
   // test its interaction with line wrapping
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -978,16 +978,18 @@
 if (CurrentToken->isOneOf(tok::star, tok::amp))
   CurrentToken->setType(TT_PointerOrReference);
 consumeToken();
+if (CurrentToken->is(tok::comma) &&
+CurrentToken->Previous->isNot(tok::kw_operator))
+  break;
 if (CurrentToken && CurrentToken->Previous->isOneOf(
 TT_BinaryOperator, TT_UnaryOperator, 
tok::comma,
 tok::star, tok::arrow, tok::amp, tok::ampamp))
   CurrentToken->Previous->setType(TT_OverloadedOperator);
   }
-  if (CurrentToken) {
+  if (CurrentToken && CurrentToken->is(tok::l_paren))
 CurrentToken->setType(TT_OverloadedOperatorLParen);
-if (CurrentToken->Previous->is(TT_BinaryOperator))
-  CurrentToken->Previous->setType(TT_OverloadedOperator);
-  }
+  if (CurrentToken && CurrentToken->Previous->is(TT_BinaryOperator))
+CurrentToken->Previous->setType(TT_OverloadedOperator);
   break;
 case tok::question:
   if (Tok->is(TT_CSharpNullConditionalLSquare)) {


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16417,6 +16417,17 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, OperatorPassedAsAFunctionPtr) {
+  FormatStyle Style = getLLVMStyle();
+  // PR46157
+  verifyFormat("foo(operator+, -42);", Style);
+  verifyFormat("foo(operator++, -42);", Style);
+  verifyFormat("foo(operator--, -42);", Style);
+  verifyFormat("foo(-42, operator--);", Style);
+  verifyFormat("foo(-42, operator, );", Style);
+  verifyFormat("foo(operator, , -42);", Style);
+}
+
 TEST_F(FormatTest, VeryLongNamespaceCommentSplit) {
   // These tests are not in NamespaceFixer because that doesn't
   // test its interaction with line wrapping
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -978,16 +978,18 @@
 if (CurrentToken->isOneOf(tok::star, tok::amp))
   CurrentToken->setType(TT_PointerOrReference);
 consumeToken();
+if (CurrentToken->is(tok::comma) &&
+CurrentToken->Previous->isNot(tok::kw_operator))
+  break;
 if (CurrentToken && CurrentToken->Previous->isOneOf(
 TT_BinaryOperator, TT_UnaryOperator, tok::comma,
 tok::star, tok::arrow, tok::amp, tok::ampamp))
   CurrentToken->Previous->setType(TT_OverloadedOperator);
   }
-  if (CurrentToken) {
+  if (CurrentToken && CurrentToken->is(tok::l_paren))

[clang] ef1d4be - [Clang][CGM] style cleanups NFC

2020-06-01 Thread Nick Desaulniers via cfe-commits
Author: Nick Desaulniers
Date: 2020-06-01T09:33:08-07:00
New Revision: ef1d4bec891b2121fffa68675e3792b2527a75ee

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

LOG: [Clang][CGM] style cleanups NFC

Summary:
Forked from:
https://reviews.llvm.org/D80242

Use the getter for access to DebugInfo consistently.
Use break in switch in CodeGenModule::EmitTopLevelDecl consistently.

Reviewers: dblaikie

Reviewed By: dblaikie

Subscribers: cfe-commits, srhines

Tags: #clang

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

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 89a95db08680..096e0bddf39c 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -527,7 +527,7 @@ void CodeGenModule::Release() {
   "StrictVTablePointersRequirement",
   llvm::MDNode::get(VMContext, Ops));
   }
-  if (DebugInfo)
+  if (getModuleDebugInfo())
 // We support a single version in the linked module. The LLVM
 // parser will drop debug info with a 
diff erent version number
 // (and warn about it, too).
@@ -653,8 +653,8 @@ void CodeGenModule::Release() {
   if (getCodeGenOpts().EmitGcovArcs || getCodeGenOpts().EmitGcovNotes)
 EmitCoverageFile();
 
-  if (DebugInfo)
-DebugInfo->finalize();
+  if (CGDebugInfo *DI = getModuleDebugInfo())
+DI->finalize();
 
   if (getCodeGenOpts().EmitVersionIdentMetadata)
 EmitVersionIdentMetadata();
@@ -5364,17 +5364,17 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) {
 break;
   case Decl::ClassTemplateSpecialization: {
 const auto *Spec = cast(D);
-if (DebugInfo &&
-Spec->getSpecializationKind() == TSK_ExplicitInstantiationDefinition &&
-Spec->hasDefinition())
-  DebugInfo->completeTemplateDefinition(*Spec);
+if (CGDebugInfo *DI = getModuleDebugInfo())
+  if (Spec->getSpecializationKind() ==
+  TSK_ExplicitInstantiationDefinition &&
+  Spec->hasDefinition())
+DI->completeTemplateDefinition(*Spec);
   } LLVM_FALLTHROUGH;
   case Decl::CXXRecord:
-if (DebugInfo) {
+if (CGDebugInfo *DI = getModuleDebugInfo())
   if (auto *ES = D->getASTContext().getExternalSource())
 if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
-  DebugInfo->completeUnusedClass(cast(*D));
-}
+  DI->completeUnusedClass(cast(*D));
 // Emit any static data members, they may be definitions.
 for (auto *I : cast(D)->decls())
   if (isa(I) || isa(I))
@@ -5395,15 +5395,15 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) {
   case Decl::Using:  // using X; [C++]
 if (CGDebugInfo *DI = getModuleDebugInfo())
 DI->EmitUsingDecl(cast(*D));
-return;
+break;
   case Decl::NamespaceAlias:
 if (CGDebugInfo *DI = getModuleDebugInfo())
 DI->EmitNamespaceAlias(cast(*D));
-return;
+break;
   case Decl::UsingDirective: // using namespace X; [C++]
 if (CGDebugInfo *DI = getModuleDebugInfo())
   DI->EmitUsingDirective(cast(*D));
-return;
+break;
   case Decl::CXXConstructor:
 getCXXABI().EmitCXXConstructors(cast(D));
 break;
@@ -5586,10 +5586,10 @@ void 
CodeGenModule::AddDeferredUnusedCoverageMapping(Decl *D) {
   case Decl::CXXConstructor:
   case Decl::CXXDestructor: {
 if (!cast(D)->doesThisDeclarationHaveABody())
-  return;
+  break;
 SourceManager &SM = getContext().getSourceManager();
 if (LimitedCoverage && SM.getMainFileID() != 
SM.getFileID(D->getBeginLoc()))
-  return;
+  break;
 auto I = DeferredEmptyCoverageMappingDecls.find(D);
 if (I == DeferredEmptyCoverageMappingDecls.end())
   DeferredEmptyCoverageMappingDecls[D] = true;



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-06-01 Thread Ties Stuij via Phabricator via cfe-commits
stuij added a comment.

In D76077#2066520 , @SjoerdMeijer 
wrote:

> > At the moment when going through the GCC compatibility driver (standard 
> > interface), we get __bf16 is not supported on this target.
>
> If this is the current behaviour, and consistent with GCC, that sounds 
> reasonable.


Unfortunately, this is not consistent with GCC. GCC will happily compile.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D80935: [PowerPC][Power10] Implement Parallel Bits Deposit/Extract Builtins in LLVM/Clang

2020-06-01 Thread Amy Kwan via Phabricator via cfe-commits
amyk created this revision.
amyk added reviewers: lei, stefanp, nemanjai, saghir, power-llvm-team.
Herald added subscribers: llvm-commits, cfe-commits, shchenz, hiraditya.
Herald added projects: clang, LLVM.
amyk updated this revision to Diff 267648.
amyk added a comment.

Updated a typo within the comment in 
`llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll`.


This patch implements builtins for the following prototypes:

  vector unsigned long long vec_pdep(vector unsigned long long, vector unsigned 
long long);
  vector unsigned long long vec_pext(vector unsigned long long, vector unsigned 
long long __b);
  unsigned long long __builtin_pdepd (unsigned long long, unsigned long long);
  unsigned long long __builtin_pextd (unsigned long long, unsigned long long);

Depends on D80758  


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80935

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p10.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/lib/Target/PowerPC/PPCScheduleP9.td
  llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
  llvm/test/MC/Disassembler/PowerPC/p10insts.txt
  llvm/test/MC/PowerPC/p10.s

Index: llvm/test/MC/PowerPC/p10.s
===
--- /dev/null
+++ llvm/test/MC/PowerPC/p10.s
@@ -0,0 +1,17 @@
+# RUN: llvm-mc -triple powerpc64-unknown-linux-gnu --show-encoding %s | \
+# RUN:   FileCheck -check-prefix=CHECK-BE %s
+# RUN: llvm-mc -triple powerpc64le-unknown-linux-gnu --show-encoding %s | \
+# RUN:   FileCheck -check-prefix=CHECK-LE %s
+
+# CHECK-BE: vpdepd 1, 2, 0# encoding: [0x10,0x22,0x05,0xcd]
+# CHECK-LE: vpdepd 1, 2, 0# encoding: [0xcd,0x05,0x22,0x10]
+vpdepd 1, 2, 0
+# CHECK-BE: vpextd 1, 2, 0# encoding: [0x10,0x22,0x05,0x8d]
+# CHECK-LE: vpextd 1, 2, 0# encoding: [0x8d,0x05,0x22,0x10]
+vpextd 1, 2, 0
+# CHECK-BE: pdepd 1, 2, 4 # encoding: [0x7c,0x41,0x21,0x38]
+# CHECK-LE: pdepd 1, 2, 4 # encoding: [0x38,0x21,0x41,0x7c]
+pdepd 1, 2, 4
+# CHECK-BE: pextd 1, 2, 4 # encoding: [0x7c,0x41,0x21,0x78]
+# CHECK-LE: pextd 1, 2, 4 # encoding: [0x78,0x21,0x41,0x7c]
+pextd 1, 2, 4
Index: llvm/test/MC/Disassembler/PowerPC/p10insts.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/PowerPC/p10insts.txt
@@ -0,0 +1,14 @@
+# RUN: llvm-mc --disassemble %s -triple powerpc64-unknown-linux-gnu \
+# RUN:   -mcpu=pwr10 | FileCheck %s
+
+# CHECK: vpdepd 1, 2, 0
+0x10 0x22 0x05 0xcd
+
+# CHECK: vpextd 1, 2, 0
+0x10 0x22 0x05 0x8d
+
+# CHECK: pdepd 1, 2, 4
+0x7c 0x41 0x21 0x38
+
+# CHECK: pextd 1, 2, 4
+0x7c 0x41 0x21 0x78
Index: llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
@@ -0,0 +1,51 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
+; RUN:   FileCheck %s
+
+; These test cases aim to test the bit manipulation operations on Power10.
+
+declare <2 x i64> @llvm.ppc.altivec.vpdepd(<2 x i64>, <2 x i64>)
+declare <2 x i64> @llvm.ppc.altivec.vpextd(<2 x i64>, <2 x i64>)
+declare i64 @llvm.ppc.pdepd(i64, i64)
+declare i64 @llvm.ppc.pextd(i64, i64)
+
+define <2 x i64> @test_vpdepd(<2 x i64> %a, <2 x i64> %b) {
+; CHECK-LABEL: test_vpdepd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vpdepd v2, v2, v3
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vpdepd(<2 x i64> %a, <2 x i64> %b)
+  ret <2 x i64> %tmp
+}
+
+define <2 x i64> @test_vpextd(<2 x i64> %a, <2 x i64> %b) {
+; CHECK-LABEL: test_vpextd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vpextd v2, v2, v3
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vpextd(<2 x i64> %a, <2 x i64> %b)
+  ret <2 x i64> %tmp
+}
+
+define i64 @test_pdepd(i64 %a, i64 %b) {
+; CHECK-LABEL: test_pdepd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:pdepd r3, r3, r4
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i64 @llvm.ppc.pdepd(i64 %a, i64 %b)
+  ret i64 %tmp
+}
+
+define i64 @test_pextd(i64 %a, i64 %b) {
+; CHECK-LABEL: test_pextd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:pextd r3, r3, r4
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i64 @llvm.ppc.pextd(i64 %a, i64 %b)
+  ret i64 %tmp
+}
Index: llvm/lib/Target/PowerPC/PPCScheduleP9.td
===
--- llvm/lib/Ta

[PATCH] D80935: [PowerPC][Power10] Implement Parallel Bits Deposit/Extract Builtins in LLVM/Clang

2020-06-01 Thread Amy Kwan via Phabricator via cfe-commits
amyk updated this revision to Diff 267648.
amyk added a comment.

Updated a typo within the comment in 
`llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80935

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p10.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/lib/Target/PowerPC/PPCScheduleP9.td
  llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
  llvm/test/MC/Disassembler/PowerPC/p10insts.txt
  llvm/test/MC/PowerPC/p10.s

Index: llvm/test/MC/PowerPC/p10.s
===
--- /dev/null
+++ llvm/test/MC/PowerPC/p10.s
@@ -0,0 +1,17 @@
+# RUN: llvm-mc -triple powerpc64-unknown-linux-gnu --show-encoding %s | \
+# RUN:   FileCheck -check-prefix=CHECK-BE %s
+# RUN: llvm-mc -triple powerpc64le-unknown-linux-gnu --show-encoding %s | \
+# RUN:   FileCheck -check-prefix=CHECK-LE %s
+
+# CHECK-BE: vpdepd 1, 2, 0# encoding: [0x10,0x22,0x05,0xcd]
+# CHECK-LE: vpdepd 1, 2, 0# encoding: [0xcd,0x05,0x22,0x10]
+vpdepd 1, 2, 0
+# CHECK-BE: vpextd 1, 2, 0# encoding: [0x10,0x22,0x05,0x8d]
+# CHECK-LE: vpextd 1, 2, 0# encoding: [0x8d,0x05,0x22,0x10]
+vpextd 1, 2, 0
+# CHECK-BE: pdepd 1, 2, 4 # encoding: [0x7c,0x41,0x21,0x38]
+# CHECK-LE: pdepd 1, 2, 4 # encoding: [0x38,0x21,0x41,0x7c]
+pdepd 1, 2, 4
+# CHECK-BE: pextd 1, 2, 4 # encoding: [0x7c,0x41,0x21,0x78]
+# CHECK-LE: pextd 1, 2, 4 # encoding: [0x78,0x21,0x41,0x7c]
+pextd 1, 2, 4
Index: llvm/test/MC/Disassembler/PowerPC/p10insts.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/PowerPC/p10insts.txt
@@ -0,0 +1,14 @@
+# RUN: llvm-mc --disassemble %s -triple powerpc64-unknown-linux-gnu \
+# RUN:   -mcpu=pwr10 | FileCheck %s
+
+# CHECK: vpdepd 1, 2, 0
+0x10 0x22 0x05 0xcd
+
+# CHECK: vpextd 1, 2, 0
+0x10 0x22 0x05 0x8d
+
+# CHECK: pdepd 1, 2, 4
+0x7c 0x41 0x21 0x38
+
+# CHECK: pextd 1, 2, 4
+0x7c 0x41 0x21 0x78
Index: llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
@@ -0,0 +1,51 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
+; RUN:   FileCheck %s
+
+; These test cases aim to test the bit manipulation operations on Power10.
+
+declare <2 x i64> @llvm.ppc.altivec.vpdepd(<2 x i64>, <2 x i64>)
+declare <2 x i64> @llvm.ppc.altivec.vpextd(<2 x i64>, <2 x i64>)
+declare i64 @llvm.ppc.pdepd(i64, i64)
+declare i64 @llvm.ppc.pextd(i64, i64)
+
+define <2 x i64> @test_vpdepd(<2 x i64> %a, <2 x i64> %b) {
+; CHECK-LABEL: test_vpdepd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vpdepd v2, v2, v3
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vpdepd(<2 x i64> %a, <2 x i64> %b)
+  ret <2 x i64> %tmp
+}
+
+define <2 x i64> @test_vpextd(<2 x i64> %a, <2 x i64> %b) {
+; CHECK-LABEL: test_vpextd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vpextd v2, v2, v3
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vpextd(<2 x i64> %a, <2 x i64> %b)
+  ret <2 x i64> %tmp
+}
+
+define i64 @test_pdepd(i64 %a, i64 %b) {
+; CHECK-LABEL: test_pdepd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:pdepd r3, r3, r4
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i64 @llvm.ppc.pdepd(i64 %a, i64 %b)
+  ret i64 %tmp
+}
+
+define i64 @test_pextd(i64 %a, i64 %b) {
+; CHECK-LABEL: test_pextd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:pextd r3, r3, r4
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i64 @llvm.ppc.pextd(i64 %a, i64 %b)
+  ret i64 %tmp
+}
Index: llvm/lib/Target/PowerPC/PPCScheduleP9.td
===
--- llvm/lib/Target/PowerPC/PPCScheduleP9.td
+++ llvm/lib/Target/PowerPC/PPCScheduleP9.td
@@ -41,8 +41,10 @@
   let CompleteModel = 1;
 
   // Do not support QPX (Quad Processing eXtension), SPE (Signal Processing
-  // Engine), prefixed instructions on Power 9 or PC relative mem ops.
-  let UnsupportedFeatures = [HasQPX, HasSPE, PrefixInstrs, PCRelativeMemops];
+  // Engine), prefixed instructions on Power 9, PC relative mem ops, or
+  // instructions introduced in ISA 3.1.
+  let UnsupportedFeatures = [HasQPX, HasSPE, PrefixInstrs, PCRelativeMemops,
+ IsISA3_1];
 
 }
 
Index: llvm/lib/T

[PATCH] D80933: [clang-format] [PR46157] Wrong spacing of negative literals with use of operator

2020-06-01 Thread Thomas Preud'homme via Phabricator via cfe-commits
thopre added a comment.

That was a speedy patch! I can confirm that my non reduced testcase (git diff 
-U0 23ac16cf9bd4cc0bb434efcf6385baf083a2ff7b 
^ 
23ac16cf9bd4cc0bb434efcf6385baf083a2ff7b 
 | 
clang-format-diff.py -i -p1) is fixed with this patch. Thanks! I don't feel 
confident reviewing the code unfortunately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80933



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


[PATCH] D80876: [clang] Default to windows response files when running on windows

2020-06-01 Thread Paul Robinson via Phabricator via cfe-commits
probinson added inline comments.



Comment at: clang/tools/driver/driver.cpp:391
+if (ClangCLMode ||
+llvm::Triple(llvm::sys::getProcessTriple()).isOSWindows())
+  Tokenizer = &llvm::cl::TokenizeWindowsCommandLine;

Testing the triple is a functional change.  I should think the test for CL mode 
is sufficient.  Note that for PS4 we run on Windows but use a GNU-compatible 
command line and response-file style.  If you want Windows-style on Windows, 
invoke the compiler as "clang-cl" instead of "clang".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80876



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


[PATCH] D80242: [Clang] implement -fno-eliminate-unused-debug-types

2020-06-01 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

In D80242#2045362 , @nickdesaulniers 
wrote:

> For C++, I'd imagine:
>
>   class foo {};
>   using my_foo = foo;
>   template 
>   struct baz {
> bar my_bar;
>   };
>
>
> but it seems that `g++` doesn't emit debug info the for the templated struct.


There's no debug info for templates, only for instantiations of templates.  HTH.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80242



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


[PATCH] D80840: [Clang][CGM] style cleanups NFC

2020-06-01 Thread Nick Desaulniers via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGef1d4bec891b: [Clang][CGM] style cleanups NFC (authored by 
nickdesaulniers).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80840

Files:
  clang/lib/CodeGen/CodeGenModule.cpp


Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -527,7 +527,7 @@
   "StrictVTablePointersRequirement",
   llvm::MDNode::get(VMContext, Ops));
   }
-  if (DebugInfo)
+  if (getModuleDebugInfo())
 // We support a single version in the linked module. The LLVM
 // parser will drop debug info with a different version number
 // (and warn about it, too).
@@ -653,8 +653,8 @@
   if (getCodeGenOpts().EmitGcovArcs || getCodeGenOpts().EmitGcovNotes)
 EmitCoverageFile();
 
-  if (DebugInfo)
-DebugInfo->finalize();
+  if (CGDebugInfo *DI = getModuleDebugInfo())
+DI->finalize();
 
   if (getCodeGenOpts().EmitVersionIdentMetadata)
 EmitVersionIdentMetadata();
@@ -5364,17 +5364,17 @@
 break;
   case Decl::ClassTemplateSpecialization: {
 const auto *Spec = cast(D);
-if (DebugInfo &&
-Spec->getSpecializationKind() == TSK_ExplicitInstantiationDefinition &&
-Spec->hasDefinition())
-  DebugInfo->completeTemplateDefinition(*Spec);
+if (CGDebugInfo *DI = getModuleDebugInfo())
+  if (Spec->getSpecializationKind() ==
+  TSK_ExplicitInstantiationDefinition &&
+  Spec->hasDefinition())
+DI->completeTemplateDefinition(*Spec);
   } LLVM_FALLTHROUGH;
   case Decl::CXXRecord:
-if (DebugInfo) {
+if (CGDebugInfo *DI = getModuleDebugInfo())
   if (auto *ES = D->getASTContext().getExternalSource())
 if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
-  DebugInfo->completeUnusedClass(cast(*D));
-}
+  DI->completeUnusedClass(cast(*D));
 // Emit any static data members, they may be definitions.
 for (auto *I : cast(D)->decls())
   if (isa(I) || isa(I))
@@ -5395,15 +5395,15 @@
   case Decl::Using:  // using X; [C++]
 if (CGDebugInfo *DI = getModuleDebugInfo())
 DI->EmitUsingDecl(cast(*D));
-return;
+break;
   case Decl::NamespaceAlias:
 if (CGDebugInfo *DI = getModuleDebugInfo())
 DI->EmitNamespaceAlias(cast(*D));
-return;
+break;
   case Decl::UsingDirective: // using namespace X; [C++]
 if (CGDebugInfo *DI = getModuleDebugInfo())
   DI->EmitUsingDirective(cast(*D));
-return;
+break;
   case Decl::CXXConstructor:
 getCXXABI().EmitCXXConstructors(cast(D));
 break;
@@ -5586,10 +5586,10 @@
   case Decl::CXXConstructor:
   case Decl::CXXDestructor: {
 if (!cast(D)->doesThisDeclarationHaveABody())
-  return;
+  break;
 SourceManager &SM = getContext().getSourceManager();
 if (LimitedCoverage && SM.getMainFileID() != 
SM.getFileID(D->getBeginLoc()))
-  return;
+  break;
 auto I = DeferredEmptyCoverageMappingDecls.find(D);
 if (I == DeferredEmptyCoverageMappingDecls.end())
   DeferredEmptyCoverageMappingDecls[D] = true;


Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -527,7 +527,7 @@
   "StrictVTablePointersRequirement",
   llvm::MDNode::get(VMContext, Ops));
   }
-  if (DebugInfo)
+  if (getModuleDebugInfo())
 // We support a single version in the linked module. The LLVM
 // parser will drop debug info with a different version number
 // (and warn about it, too).
@@ -653,8 +653,8 @@
   if (getCodeGenOpts().EmitGcovArcs || getCodeGenOpts().EmitGcovNotes)
 EmitCoverageFile();
 
-  if (DebugInfo)
-DebugInfo->finalize();
+  if (CGDebugInfo *DI = getModuleDebugInfo())
+DI->finalize();
 
   if (getCodeGenOpts().EmitVersionIdentMetadata)
 EmitVersionIdentMetadata();
@@ -5364,17 +5364,17 @@
 break;
   case Decl::ClassTemplateSpecialization: {
 const auto *Spec = cast(D);
-if (DebugInfo &&
-Spec->getSpecializationKind() == TSK_ExplicitInstantiationDefinition &&
-Spec->hasDefinition())
-  DebugInfo->completeTemplateDefinition(*Spec);
+if (CGDebugInfo *DI = getModuleDebugInfo())
+  if (Spec->getSpecializationKind() ==
+  TSK_ExplicitInstantiationDefinition &&
+  Spec->hasDefinition())
+DI->completeTemplateDefinition(*Spec);
   } LLVM_FALLTHROUGH;
   case Decl::CXXRecord:
-if (DebugInfo) {
+if (CGDebugInfo *DI = getModuleDebugInfo())
   if (auto *ES = D->getASTContext().getExternalSource())
 if (ES->hasExternalDefinitions(D) == E

[PATCH] D80584: [utils] change update_test_checks.py use of 'TMP' value names

2020-06-01 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

> I think we're good enough.

I agree. If this doesn't bother anyone anymore there is no need for any options 
;)

Thanks for the test!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80584



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


RE: [clang-tools-extra] 8e325cf - [clangd] Work around PS4 -fno-exceptions, easier than disabling tests?

2020-06-01 Thread Robinson, Paul via cfe-commits

> -Original Message-
> From: cfe-commits  On Behalf Of Sam
> McCall via cfe-commits
> Sent: Thursday, May 28, 2020 11:15 AM
> To: cfe-commits@lists.llvm.org
> Subject: [clang-tools-extra] 8e325cf - [clangd] Work around PS4 -fno-
> exceptions, easier than disabling tests?
> 
> 
> Author: Sam McCall
> Date: 2020-05-28T17:14:23+02:00
> New Revision: 8e325cfc1456820e2253909e4aa0c3014f1e050c
> 
> URL: https://github.com/llvm/llvm-
> project/commit/8e325cfc1456820e2253909e4aa0c3014f1e050c
> DIFF: https://github.com/llvm/llvm-
> project/commit/8e325cfc1456820e2253909e4aa0c3014f1e050c.diff
> 
> LOG: [clangd] Work around PS4 -fno-exceptions, easier than disabling
> tests?
> 
> Added:
> 
> 
> Modified:
> clang-tools-extra/clangd/unittests/XRefsTests.cpp
> 
> Removed:
> 
> 
> 
> ##
> ##
> diff  --git a/clang-tools-extra/clangd/unittests/XRefsTests.cpp b/clang-
> tools-extra/clangd/unittests/XRefsTests.cpp
> index b73a310e95fb..e260285a179c 100644
> --- a/clang-tools-extra/clangd/unittests/XRefsTests.cpp
> +++ b/clang-tools-extra/clangd/unittests/XRefsTests.cpp
> @@ -245,7 +245,9 @@ TEST(HighlightsTest, ControlFlow) {
>};
>for (const char *Test : Tests) {
>  Annotations T(Test);
> -auto AST = TestTU::withCode(T.code()).build();
> +auto TU = TestTU::withCode(T.code());
> +TU.ExtraArgs.push_back("-fexceptions"); // FIXME: stop testing on
> PS4.

Yeah, sorry for the inconvenience.  We haven't tried evaluating clangd
for a PS4 environment but in the meantime it feels like more coverage
is a good thing?
Thanks,
--paulr

> +auto AST = TU.build();
>  EXPECT_THAT(findDocumentHighlights(AST, T.point()),
> HighlightsFrom(T))
>  << Test;
>}
> 
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 7968981 - [SVE] Eliminate calls to default-false VectorType::get() from Clang

2020-06-01 Thread Christopher Tetreault via cfe-commits
Author: Christopher Tetreault
Date: 2020-06-01T10:02:14-07:00
New Revision: 796898172c48a475f27f038e587c35dbba9ab7a6

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

LOG: [SVE] Eliminate calls to default-false VectorType::get() from Clang

Reviewers: efriedma, david-arm, fpetrogalli, ddunbar, rjmccall

Reviewed By: fpetrogalli, rjmccall

Subscribers: tschuett, rkruppe, psnobl, dmgreen, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/CodeGen/CGExpr.cpp
clang/lib/CodeGen/CGExprScalar.cpp
clang/lib/CodeGen/CodeGenTypes.cpp
clang/lib/CodeGen/SwiftCallingConv.cpp
clang/lib/CodeGen/TargetInfo.cpp
clang/utils/TableGen/MveEmitter.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index b5129249c016..cf8c8a1669d7 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -4486,29 +4486,29 @@ static llvm::VectorType *GetNeonType(CodeGenFunction 
*CGF,
   switch (TypeFlags.getEltType()) {
   case NeonTypeFlags::Int8:
   case NeonTypeFlags::Poly8:
-return llvm::VectorType::get(CGF->Int8Ty, V1Ty ? 1 : (8 << IsQuad));
+return llvm::FixedVectorType::get(CGF->Int8Ty, V1Ty ? 1 : (8 << IsQuad));
   case NeonTypeFlags::Int16:
   case NeonTypeFlags::Poly16:
-return llvm::VectorType::get(CGF->Int16Ty, V1Ty ? 1 : (4 << IsQuad));
+return llvm::FixedVectorType::get(CGF->Int16Ty, V1Ty ? 1 : (4 << IsQuad));
   case NeonTypeFlags::Float16:
 if (HasLegalHalfType)
-  return llvm::VectorType::get(CGF->HalfTy, V1Ty ? 1 : (4 << IsQuad));
+  return llvm::FixedVectorType::get(CGF->HalfTy, V1Ty ? 1 : (4 << IsQuad));
 else
-  return llvm::VectorType::get(CGF->Int16Ty, V1Ty ? 1 : (4 << IsQuad));
+  return llvm::FixedVectorType::get(CGF->Int16Ty, V1Ty ? 1 : (4 << 
IsQuad));
   case NeonTypeFlags::Int32:
-return llvm::VectorType::get(CGF->Int32Ty, V1Ty ? 1 : (2 << IsQuad));
+return llvm::FixedVectorType::get(CGF->Int32Ty, V1Ty ? 1 : (2 << IsQuad));
   case NeonTypeFlags::Int64:
   case NeonTypeFlags::Poly64:
-return llvm::VectorType::get(CGF->Int64Ty, V1Ty ? 1 : (1 << IsQuad));
+return llvm::FixedVectorType::get(CGF->Int64Ty, V1Ty ? 1 : (1 << IsQuad));
   case NeonTypeFlags::Poly128:
 // FIXME: i128 and f128 doesn't get fully support in Clang and llvm.
 // There is a lot of i128 and f128 API missing.
 // so we use v16i8 to represent poly128 and get pattern matched.
-return llvm::VectorType::get(CGF->Int8Ty, 16);
+return llvm::FixedVectorType::get(CGF->Int8Ty, 16);
   case NeonTypeFlags::Float32:
-return llvm::VectorType::get(CGF->FloatTy, V1Ty ? 1 : (2 << IsQuad));
+return llvm::FixedVectorType::get(CGF->FloatTy, V1Ty ? 1 : (2 << IsQuad));
   case NeonTypeFlags::Float64:
-return llvm::VectorType::get(CGF->DoubleTy, V1Ty ? 1 : (1 << IsQuad));
+return llvm::FixedVectorType::get(CGF->DoubleTy, V1Ty ? 1 : (1 << IsQuad));
   }
   llvm_unreachable("Unknown vector element type!");
 }
@@ -4518,11 +4518,11 @@ static llvm::VectorType 
*GetFloatNeonType(CodeGenFunction *CGF,
   int IsQuad = IntTypeFlags.isQuad();
   switch (IntTypeFlags.getEltType()) {
   case NeonTypeFlags::Int16:
-return llvm::VectorType::get(CGF->HalfTy, (4 << IsQuad));
+return llvm::FixedVectorType::get(CGF->HalfTy, (4 << IsQuad));
   case NeonTypeFlags::Int32:
-return llvm::VectorType::get(CGF->FloatTy, (2 << IsQuad));
+return llvm::FixedVectorType::get(CGF->FloatTy, (2 << IsQuad));
   case NeonTypeFlags::Int64:
-return llvm::VectorType::get(CGF->DoubleTy, (1 << IsQuad));
+return llvm::FixedVectorType::get(CGF->DoubleTy, (1 << IsQuad));
   default:
 llvm_unreachable("Type can't be converted to floating-point!");
   }
@@ -5403,7 +5403,7 @@ Function 
*CodeGenFunction::LookupNeonLLVMIntrinsic(unsigned IntrinsicID,
   if (Modifier & AddRetType) {
 llvm::Type *Ty = ConvertType(E->getCallReturnType(getContext()));
 if (Modifier & VectorizeRetType)
-  Ty = llvm::VectorType::get(
+  Ty = llvm::FixedVectorType::get(
   Ty, VectorSize ? VectorSize / Ty->getPrimitiveSizeInBits() : 1);
 
 Tys.push_back(Ty);
@@ -5412,7 +5412,7 @@ Function 
*CodeGenFunction::LookupNeonLLVMIntrinsic(unsigned IntrinsicID,
   // Arguments.
   if (Modifier & VectorizeArgTypes) {
 int Elts = VectorSize ? VectorSize / ArgType->getPrimitiveSizeInBits() : 1;
-ArgType = llvm::VectorType::get(ArgType, Elts);
+ArgType = llvm::FixedVectorType::get(ArgType, Elts);
   }
 
   if (Modifier & (Add1ArgType | Add2ArgTypes))
@@ -5586,7 +5586,7 @@ Value *CodeGenFunction::EmitCommonNeonBuiltinExpr(
   Ty = HalfTy;
   break;
 }
-llvm::Type *

[PATCH] D80936: [OPENMP]Fix PR46146: Do not consider globalized variables as NRVO candidates.

2020-06-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: sstefan1, guansong, yaxunl.
Herald added a project: clang.

If the variables must be globalized in OpenMP mode (local automatic
variable, GPU compilation mode, the variable may escape its declaration
context by the reference or by the pointer), it should not be considered
as the NRVO candidate. Otherwise, incorrect the return value of the
function might not be updated.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80936

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/OpenMP/nvptx_NRVO_variable.cpp


Index: clang/test/OpenMP/nvptx_NRVO_variable.cpp
===
--- /dev/null
+++ clang/test/OpenMP/nvptx_NRVO_variable.cpp
@@ -0,0 +1,30 @@
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+struct S {
+  int a;
+  S() : a(1) {}
+};
+
+#pragma omp declare target
+void bar(S &);
+// CHECK-LABEL: foo
+S foo() {
+  // CHECK: [[RETVAL:%.+]] = alloca %struct.S,
+  S s;
+  // CHECK: call void @{{.+}}bar{{.+}}(%struct.S* {{.*}}[[S_REF:%.+]])
+  bar(s);
+  // CHECK: [[DEST:%.+]] = bitcast %struct.S* [[RETVAL]] to i8*
+  // CHECK: [[SOURCE:%.+]] = bitcast %struct.S* [[S_REF]] to i8*
+  // CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* {{.*}}[[DEST]], i8* 
{{.*}}[[SOURCE]], i64 4, i1 false)
+  // CHECK: [[VAL:%.+]] = load %struct.S, %struct.S* [[RETVAL]],
+  // CHECK: ret %struct.S [[VAL]]
+  return s;
+}
+#pragma omp end declare target
+
+#endif
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -11,6 +11,7 @@
 
//===--===//
 
 #include "CGDebugInfo.h"
+#include "CGOpenMPRuntime.h"
 #include "CodeGenFunction.h"
 #include "CodeGenModule.h"
 #include "TargetInfo.h"
@@ -1106,8 +1107,13 @@
 
   // FIXME: Clean this up by using an LValue for ReturnTemp,
   // EmitStoreThroughLValue, and EmitAnyExpr.
-  if (getLangOpts().ElideConstructors &&
-  S.getNRVOCandidate() && S.getNRVOCandidate()->isNRVOVariable()) {
+  // Check if the NRVO candidate was not globalized in OpenMP mode.
+  if (getLangOpts().ElideConstructors && S.getNRVOCandidate() &&
+  S.getNRVOCandidate()->isNRVOVariable() &&
+  (!getLangOpts().OpenMP ||
+   !CGM.getOpenMPRuntime()
+.getAddressOfLocalVariable(*this, S.getNRVOCandidate())
+.isValid())) {
 // Apply the named return value optimization for this return statement,
 // which means doing nothing: the appropriate result has already been
 // constructed into the NRVO variable.


Index: clang/test/OpenMP/nvptx_NRVO_variable.cpp
===
--- /dev/null
+++ clang/test/OpenMP/nvptx_NRVO_variable.cpp
@@ -0,0 +1,30 @@
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+struct S {
+  int a;
+  S() : a(1) {}
+};
+
+#pragma omp declare target
+void bar(S &);
+// CHECK-LABEL: foo
+S foo() {
+  // CHECK: [[RETVAL:%.+]] = alloca %struct.S,
+  S s;
+  // CHECK: call void @{{.+}}bar{{.+}}(%struct.S* {{.*}}[[S_REF:%.+]])
+  bar(s);
+  // CHECK: [[DEST:%.+]] = bitcast %struct.S* [[RETVAL]] to i8*
+  // CHECK: [[SOURCE:%.+]] = bitcast %struct.S* [[S_REF]] to i8*
+  // CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* {{.*}}[[DEST]], i8* {{.*}}[[SOURCE]], i64 4, i1 false)
+  // CHECK: [[VAL:%.+]] = load %struct.S, %struct.S* [[RETVAL]],
+  // CHECK: ret %struct.S [[VAL]]
+  return s;
+}
+#pragma omp end declare target
+
+#endif
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -11,6 +11,7 @@
 //===--===//
 
 #include "CGDebugInfo.h"
+#include "CGOpenMPRuntime.h"
 #include "CodeGenFunction.h"
 #include "CodeGenModule.h"
 #include "TargetInfo.h"
@@ -1106,8 +1107,13 @@
 
   // FIXME: Clean this up by using an LValue for Re

[PATCH] D80917: [OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 2

2020-06-01 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: clang/include/clang/Basic/OpenMPGridValues.h:96
+256,  // GV_Slot_Size
+64,   // GV_Warp_Size
+6,// GV_Warp_Size_Log2

What about wave32?



Comment at: clang/include/clang/Basic/TargetInfo.h:1315
+
+  long long getLongGridValue(GPU::GVLIDX gv) const {
+return LongGridValues[gv];

long long is the worst C type and should never be used. int64_t?



Comment at: clang/lib/Basic/Targets/AMDGPU.cpp:290
   assert(DataLayout->getAllocaAddrSpace() == Private);
+  GridValues = (const int *)&(GPU::AMDGPUGpuGridValues[0]);
+  LongGridValues = (const long long *)&(GPU::AMDGPUGpuLongGridValues[0]);

Why do these need casts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80917



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


[PATCH] D80323: [SVE] Eliminate calls to default-false VectorType::get() from Clang

2020-06-01 Thread Christopher Tetreault via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG796898172c48: [SVE] Eliminate calls to default-false 
VectorType::get() from Clang (authored by ctetreau).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80323

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/SwiftCallingConv.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/utils/TableGen/MveEmitter.cpp

Index: clang/utils/TableGen/MveEmitter.cpp
===
--- clang/utils/TableGen/MveEmitter.cpp
+++ clang/utils/TableGen/MveEmitter.cpp
@@ -300,7 +300,7 @@
 return Element->cNameBase() + "x" + utostr(Lanes);
   }
   std::string llvmName() const override {
-return "llvm::VectorType::get(" + Element->llvmName() + ", " +
+return "llvm::FixedVectorType::get(" + Element->llvmName() + ", " +
utostr(Lanes) + ")";
   }
 
@@ -354,7 +354,7 @@
 // explanation.
 unsigned ModifiedLanes = (Lanes == 2 ? 4 : Lanes);
 
-return "llvm::VectorType::get(Builder.getInt1Ty(), " +
+return "llvm::FixedVectorType::get(Builder.getInt1Ty(), " +
utostr(ModifiedLanes) + ")";
   }
 
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -1478,8 +1478,8 @@
   // registers and we need to make sure to pick a type the LLVM
   // backend will like.
   if (Size == 128)
-return ABIArgInfo::getDirect(llvm::VectorType::get(
-  llvm::Type::getInt64Ty(getVMContext()), 2));
+return ABIArgInfo::getDirect(llvm::FixedVectorType::get(
+llvm::Type::getInt64Ty(getVMContext()), 2));
 
   // Always return in register if it fits in a general purpose
   // register, or if it is 64 bits and has a single element.
@@ -3122,8 +3122,8 @@
 cast(IRType)->getElementType()->isIntegerTy(128)) {
   // Use a vXi64 vector.
   uint64_t Size = getContext().getTypeSize(Ty);
-  return llvm::VectorType::get(llvm::Type::getInt64Ty(getVMContext()),
-   Size / 64);
+  return llvm::FixedVectorType::get(llvm::Type::getInt64Ty(getVMContext()),
+Size / 64);
 }
 
 return IRType;
@@ -3138,8 +3138,8 @@
 
 
   // Return a LLVM IR vector type based on the size of 'Ty'.
-  return llvm::VectorType::get(llvm::Type::getDoubleTy(getVMContext()),
-   Size / 64);
+  return llvm::FixedVectorType::get(llvm::Type::getDoubleTy(getVMContext()),
+Size / 64);
 }
 
 /// BitsContainNoUserData - Return true if the specified [start,end) bit range
@@ -3273,7 +3273,8 @@
   // case.
   if (ContainsFloatAtOffset(IRType, IROffset, getDataLayout()) &&
   ContainsFloatAtOffset(IRType, IROffset+4, getDataLayout()))
-return llvm::VectorType::get(llvm::Type::getFloatTy(getVMContext()), 2);
+return llvm::FixedVectorType::get(llvm::Type::getFloatTy(getVMContext()),
+  2);
 
   return llvm::Type::getDoubleTy(getVMContext());
 }
@@ -4140,8 +4141,8 @@
 
   // Mingw64 GCC returns i128 in XMM0. Coerce to v2i64 to handle that.
   // Clang matches them for compatibility.
-  return ABIArgInfo::getDirect(
-  llvm::VectorType::get(llvm::Type::getInt64Ty(getVMContext()), 2));
+  return ABIArgInfo::getDirect(llvm::FixedVectorType::get(
+  llvm::Type::getInt64Ty(getVMContext()), 2));
 
 default:
   break;
@@ -5478,13 +5479,13 @@
   return ABIArgInfo::getDirect(ResType);
 }
 if (Size == 64) {
-  llvm::Type *ResType =
-  llvm::VectorType::get(llvm::Type::getInt32Ty(getVMContext()), 2);
+  auto *ResType =
+  llvm::FixedVectorType::get(llvm::Type::getInt32Ty(getVMContext()), 2);
   return ABIArgInfo::getDirect(ResType);
 }
 if (Size == 128) {
-  llvm::Type *ResType =
-  llvm::VectorType::get(llvm::Type::getInt32Ty(getVMContext()), 4);
+  auto *ResType =
+  llvm::FixedVectorType::get(llvm::Type::getInt32Ty(getVMContext()), 4);
   return ABIArgInfo::getDirect(ResType);
 }
 return getNaturalAlignIndirect(Ty, /*ByVal=*/false);
@@ -6209,7 +6210,7 @@
 return ABIArgInfo::getDirect(ResType);
   }
   if (Size == 64 || Size == 128) {
-llvm::Type *ResType = llvm::VectorType::get(
+auto *ResType = llvm::FixedVectorType::get(
 llvm::Type::getInt32Ty(getVMContext()), Size / 32);
 return ABIArgInfo::getDirect(ResType);
   }
@@ -6225,7 +6226,7 @@
 // FP16 vectors should be converted to integer vectors
 if (!getTarget().hasLegalHalfType() && containsAnyFP16Vectors(Ty)) {
   uint64_t Size = getConte

[PATCH] D80876: [clang] Default to windows response files when running on windows

2020-06-01 Thread Sam Clegg via Phabricator via cfe-commits
sbc100 marked an inline comment as done.
sbc100 added inline comments.



Comment at: clang/tools/driver/driver.cpp:391
+if (ClangCLMode ||
+llvm::Triple(llvm::sys::getProcessTriple()).isOSWindows())
+  Tokenizer = &llvm::cl::TokenizeWindowsCommandLine;

probinson wrote:
> Testing the triple is a functional change.  I should think the test for CL 
> mode is sufficient.  Note that for PS4 we run on Windows but use a 
> GNU-compatible command line and response-file style.  If you want 
> Windows-style on Windows, invoke the compiler as "clang-cl" instead of 
> "clang".
Yes this is a functional change.  It changes the default when running on 
windows.I will see if I can write a (windows-only) test for it.

Some more background for why I think this change is right way to go:

In the emscripten toolchain we run clang as a cross compiler, we don't want 
cl.exe emulation.

We drive the compiler and other tools from a python script and we create 
response files whenever a command line is tool long.

 It doesn't make sense to me that we should use windows response files for all 
other tools except for `clang`. In particular, `llvm-ar`, `llc`, `opt`, 
`wasm-ld` all default to windows response files on windows.  

The function in question in our toolchain looks like this:

```
def generate_response_file(command):
if is_windows:
   use_windows_style
else:
   use_gnu_style

```

Without this change I have to write something like this:

```
def generate_response_file(command):
   # On windows all the tools we run use windows style response files.
   # Except for clang (for some reason?).
if is_windows and 'clang.exe' not in command[0] :
   use_windows_style
else:
   use_gnu_style

```

I don't see why clang would want to be different here. Can you think of any 
reason?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80876



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


[PATCH] D80897: [OpenMP] Initial support for std::complex in target regions

2020-06-01 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

Hmm. I'm pretty sure tensorflow is using std::complex for various types. I'm 
surprised that we haven't seen these functions missing.
Plain CUDA (e.g. https://godbolt.org/z/Us6oXC) code appears to have no 
references to `__mul*` or `__div*`, at least for optimized builds, but they do 
popup in unoptimized ones. Curiously enough, unoptimized code compiled with 
`-stdlib=libc++ --std=c++11` does not need the soft-float functions. That would 
explain why we don't see the build breaks.

These differences suggest that these changes may need to be more nuanced with 
regard to the standard c++ library version and, possibly, the C++ standard used.
If possible, I would prefer to limit interference with the standard libraries 
only to the cases where it's necessary.




Comment at: clang/lib/Headers/__clang_cuda_complex_builtins.h:29
+#define _ISNANd std::isnan
+#define _ISNANf _ISNANd
+#define _ISINFd std::isinf

Nit: this creates impression that we fall back on `double` variant of the 
function, while in reality we'll end up using `std::isnan`.
Perhaps it would be better to use fully specialized function template name in 
all these macros. It would also avoid potential issues if someone/somewhere 
adds other overloads. E.g. we may end up facing `std::complex` which may 
overload resolution ambiguous in some cases. 



Comment at: clang/lib/Headers/__clang_cuda_complex_builtins.h:63
+
+__DEVICE__ double _Complex __muldc3(double __a, double __b, double __c,
+double __d) {

Soft-float library has bunch of other functions. 
https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html

I wonder why only the complex variants of the soft-float support functions are 
missing. 
Does it mean that x86 code also does rely on the library to do complex 
multiplication?
If x86 can do complex ops, why can't nvptx?
If x86 can't, would make sense to teach it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80897



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


[PATCH] D80925: Fix compiler crash when trying to parse alignment argument as a constant expression.

2020-06-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Narrowly this seems to fix the immediate problem, but I feel like we're in 
trouble if tentative parsing is changing the semantic context in ways that 
persist.  In particular, I'm concerned that we could end up tentatively parsing 
an ODR use as part of an expression and then completely discarding it, causing 
Sema to think that there's an ODR use later because it never sees an L2R 
conversion (because the expression is not actually used).  Probably the most 
architectural thing would be for tentative expression parsing to push a 
possibly-unevaluated context, and then when we claim an expression annotation 
token we can do the retroactive work necessary to make it an expression in the 
proper context.  We already have most of the logic to support that because of 
C99 `sizeof`, which is usually not evaluated but can be in the narrow 
circumstance of a VLA.

If we do decide to solve this more narrowly, then we should audit our use of 
the tentative-parsing queries to make sure that we're pushing contexts 
consistently, and we should leave comments in places like this to make sure 
that maintainers understand the subtleties.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80925



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


[PATCH] D80933: [clang-format] [PR46157] Wrong spacing of negative literals with use of operator

2020-06-01 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

In D80933#2066648 , @thopre wrote:

> That was a speedy patch! I can confirm that my non reduced testcase (git diff 
> -U0 23ac16cf9bd4cc0bb434efcf6385baf083a2ff7b 
> ^ 
> 23ac16cf9bd4cc0bb434efcf6385baf083a2ff7b 
>  | 
> clang-format-diff.py -i -p1) is fixed with this patch. Thanks! I don't feel 
> confident reviewing the code unfortunately.


No problems, we can wait for the others.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80933



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


[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

2020-06-01 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, thanks.




Comment at: clang/lib/CodeGen/CGExpr.cpp:3787
+   ColIdx->getType()->getScalarSizeInBits());
+  llvm::Type *IntTy = llvm::IntegerType::get(getLLVMContext(), MaxWidth);
+  RowIdx = Builder.CreateZExt(RowIdx, IntTy);

fhahn wrote:
> rjmccall wrote:
> > fhahn wrote:
> > > rjmccall wrote:
> > > > You should be able to assert that these have been coerced to the right 
> > > > type by Sema (probably size_t or ptrdiff_t or something).
> > > Hm I don't think that's currently happening. Is that required? It seems a 
> > > bit unfortunate if we would have to force to wider bit-widths than 
> > > necessary for the given index expressions.
> > Can you explain what cost you're worried about?  I don't understand what 
> > the benefit of using a smaller IR type for the indexes is, and usually it's 
> > better to have stronger invariants coming out of Sema.
> I now updated the code to force the index types to size_t in Sema and remove 
> the zext generation here. If we have signed indices, we now generate sexts, 
> which may require additional instructions down the road., which we would not 
> require if we perform the math on the max bit width of the operands. But 
> looking back now, I am not really sure if that would actually be safe in all 
> cases. 
> 
> We  should probably just try to narrow the index types based on the number of 
> vector elements as an IR optimization, if it becomes a problem.
It's UB if it's actually negative, right?  So the `sext` really shouldn't be a 
problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76791



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


[PATCH] D80828: [Clang][A32/T32][Linux] -O2 implies -fomit-frame-pointer

2020-06-01 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers updated this revision to Diff 267663.
nickdesaulniers added a comment.

- add Android target triple handling, see 
https://developer.android.com/ndk/guides/other_build_systems#overview


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80828

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/frame-pointer-elim.c
  llvm/docs/ReleaseNotes.rst

Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -91,6 +91,12 @@
 
 * Implemented C-language intrinsics  for the CDE instruction set.
 
+* Clang now defaults to `-fomit-frame-pointer` when targeting Linux for arm
+  and thumb when optimizations are enabled. Users that were previously not
+  specifying a value and relying on the implicit compiler default may wish
+  to specify `-fno-omit-frame-pointer` to get the old behavior. This improves
+  compatibility with GCC.
+
 Changes to the MIPS Target
 --
 
Index: clang/test/Driver/frame-pointer-elim.c
===
--- clang/test/Driver/frame-pointer-elim.c
+++ clang/test/Driver/frame-pointer-elim.c
@@ -103,5 +103,33 @@
 // RUN: %clang -### -target powerpc64 -S -O1 %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=KEEP-NONE %s
 
+// For AAarch32 (A32, T32) linux targets, default omit frame pointer when
+// optimizations are enabled.
+// RUN: %clang -### -target arm-linux-gnueabihf- -marm -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-ALL %s
+// RUN: %clang -### -target arm-linux-gnueabihf- -mthumb -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-ALL %s
+// RUN: %clang -### -target arm-linux-gnueabihf- -marm -mbig-endian -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-ALL %s
+// RUN: %clang -### -target arm-linux-gnueabihf- -mthumb -mbig-endian -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-ALL %s
+// RUN: %clang -### -target arm-linux-gnueabihf- -marm -O2 -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-NONE %s
+// RUN: %clang -### -target arm-linux-gnueabihf- -mthumb -O2 -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-NONE %s
+// RUN: %clang -### -target arm-linux-gnueabihf- -marm -mbig-endian -O2 -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-NONE %s
+// RUN: %clang -### -target arm-linux-gnueabihf- -mthumb -mbig-endian -O2 -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-NONE %s
+// For Android, keep the framepointers always.
+// RUN: %clang -### -target armv7a-linux-androideabi- -marm -O2 -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-ALL %s
+// RUN: %clang -### -target armv7a-linux-androideabi- -mthumb -O2 -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-ALL %s
+// RUN: %clang -### -target armv7a-linux-androideabi- -marm -mbig-endian -O2 -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-ALL %s
+// RUN: %clang -### -target armv7a-linux-androideabi- -mthumb -mbig-endian -O2 -S %s 2>&1 | \
+// RUN:   FileCheck --check-prefix=KEEP-ALL %s
+
 void f0() {}
 void f1() { f0(); }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "Clang.h"
+#include "AMDGPU.h"
 #include "Arch/AArch64.h"
 #include "Arch/ARM.h"
 #include "Arch/Mips.h"
@@ -15,11 +16,10 @@
 #include "Arch/Sparc.h"
 #include "Arch/SystemZ.h"
 #include "Arch/X86.h"
-#include "AMDGPU.h"
 #include "CommonArgs.h"
 #include "Hexagon.h"
-#include "MSP430.h"
 #include "InputInfo.h"
+#include "MSP430.h"
 #include "PS4CPU.h"
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/CodeGenOptions.h"
@@ -35,6 +35,7 @@
 #include "llvm/Config/llvm-config.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/CodeGen.h"
+#include "llvm/Support/Compiler.h"
 #include "llvm/Support/Compression.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
@@ -557,6 +558,13 @@
   Triple.isOSHurd()) {
 switch (Triple.getArch()) {
 // Don't use a frame pointer on linux if optimizing for certain targets.
+case llvm::Triple::arm:
+case llvm::Triple::armeb:
+case llvm::Triple::thumb:
+case llvm::Triple::thumbeb:
+  if (Triple.getEnvironment() == llvm::Triple::Android)
+return true;
+  LLVM_FALLTHROUGH;
 case llvm::Triple::mips64:
 case llvm::Triple::mips64el:
 case llvm::Triple::mips:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80828: [Clang][A32/T32][Linux] -O2 implies -fomit-frame-pointer

2020-06-01 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers marked 2 inline comments as done.
nickdesaulniers added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:22
 #include "InputInfo.h"
+#include "MSP430.h"
 #include "PS4CPU.h"

Note to reviewers: the linter really wanted to touch this header inclusion 
list, since I add "llvm/Support/Compiler.h" below.  Hopefully it's ok to just 
include with this patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80828



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


[PATCH] D80876: [clang] Default to windows response files when running on windows

2020-06-01 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

As a functional change it should definitely have a functional test.
Let me double-check on how our stuff behaves, I may be mis-remembering.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80876



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


[PATCH] D80917: [OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 2

2020-06-01 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/include/clang/Basic/OpenMPGridValues.h:134
+} // namespace clang
+#endif

Can we move this into llvm core (subfolder `Frontend/OpenMP/`)? We probably 
need this during OpenMPOpt, and for Flang as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80917



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


[PATCH] D79830: Add support of __builtin_expect_with_probability

2020-06-01 Thread Zhi Zhuang via Phabricator via cfe-commits
LukeZhuang added a comment.

ping :)


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

https://reviews.llvm.org/D79830



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


[PATCH] D80876: [clang] Default to windows response files when running on windows

2020-06-01 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

Indeed I am mis-remembering, sorry about that!  We use gnu-style command-line 
options but we change RSPQuoting from Default to Windows; assuming 
getProcessTriple() is the host not the target, your change should have the same 
effect.  I'll try removing our private patch and adding yours, and see what 
happens.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80876



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


[PATCH] D80828: [Clang][A32/T32][Linux] -O2 implies -fomit-frame-pointer

2020-06-01 Thread Stephen Hines via Phabricator via cfe-commits
srhines added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:565
+case llvm::Triple::thumbeb:
+  if (Triple.getEnvironment() == llvm::Triple::Android)
+return true;

Triple.isAndroid() is more clear.



Comment at: llvm/docs/ReleaseNotes.rst:94
 
+* Clang now defaults to `-fomit-frame-pointer` when targeting Linux for arm
+  and thumb when optimizations are enabled. Users that were previously not

"non-Android Linux" is probably going to make things easier to understand here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80828



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


[PATCH] D80940: [clang-format] [PR46159] Linux kernel 'C' code uses 'try' as a variable name, allow clang-format to handle such cases

2020-06-01 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: krasimir, JakeMerdichAMD, mitchell-stellar.
MyDeveloperDay added projects: clang, clang-format.

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

Linux Kernel code using is try as a variable name (as its 'C' code they can), 
they interpreted as the 'try' keyword by clang-format causing odd formatting 
(see below)

We have no specific 'C' code handling, as this code could easily be in a '.h' 
file so need to handle this not based on extension alone.

This revision adds a FormatTokenLexer rule to identify either  try blocks "try 
{" or  function try block "try :" and if not, rename the "try" token to be an 
identifier

  static size_t get_kcore_size(int *nphdr, size_t *phdrs_len, size_t *notes_len,
 size_t *data_offset)
  {
size_t try, size;
struct kcore_list *m;
  
*nphdr = 1; /* PT_NOTE */
size = 0;
  
list_for_each_entry(m, &kclist_head, list) {
try = kc_vaddr_to_offset((size_t)m->addr + m->size);
if (try1 > size)
size = try1;
*nphdr = *nphdr + 1;
}
  }
  
  clang-format-10 formats it as:
  
  static size_t get_kcore_size(int *nphdr, size_t *phdrs_len, size_t *notes_len,
   size_t *data_offset) {
size_t try
  , size;
struct kcore_list *m;
  
*nphdr = 1; /* PT_NOTE */
size = 0;
  
list_for_each_entry(m, &kclist_head, list) {
  try
= kc_vaddr_to_offset((size_t)m->addr + m->size);
  if (try > size)
size = try
  ;
  *nphdr = *nphdr + 1;
}
  }


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80940

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2664,6 +2664,18 @@
   verifyIncompleteFormat("try {} catch (");
 }
 
+TEST_F(FormatTest, FormatTryAsAVariable) {
+  verifyFormat("int try;");
+  verifyFormat("int try, size;");
+  verifyFormat("try = foo();");
+  verifyFormat("if (try < size) {\n  return true;\n}");
+
+  verifyFormat("int catch;");
+  verifyFormat("int catch, size;");
+  verifyFormat("catch = foo();");
+  verifyFormat("if (catch < size) {\n  return true;\n}");
+}
+
 TEST_F(FormatTest, FormatSEHTryCatch) {
   verifyFormat("__try {\n"
"  int a = b * c;\n"
Index: clang/lib/Format/FormatTokenLexer.h
===
--- clang/lib/Format/FormatTokenLexer.h
+++ clang/lib/Format/FormatTokenLexer.h
@@ -56,6 +56,7 @@
   bool tryMergeCSharpNullConditional();
   bool tryTransformCSharpForEach();
   bool tryMergeForEach();
+  bool tryTransformTryUsageForC();
 
   bool tryMergeTokens(ArrayRef Kinds, TokenType NewType);
 
Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -76,6 +76,8 @@
 return;
   if (tryMergeForEach())
 return;
+  if (Style.isCpp() && tryTransformTryUsageForC())
+return;
 
   if (Style.isCSharp()) {
 if (tryMergeCSharpKeywordVariables())
@@ -383,6 +385,26 @@
   return true;
 }
 
+bool FormatTokenLexer::tryTransformTryUsageForC() {
+  if (Tokens.size() < 2)
+return false;
+  auto &Try = *(Tokens.end() - 2);
+  auto &Brace = *(Tokens.end() - 1);
+  if (!Try->is(tok::kw_try))
+return false;
+  if (Brace->isOneOf(tok::l_brace, tok::colon))
+return false;
+
+  if (Tokens.size() > 2) {
+auto &At = *(Tokens.end() - 3);
+if (At->is(tok::at))
+  return false;
+  }
+
+  Try->Tok.setKind(tok::identifier);
+  return true;
+}
+
 bool FormatTokenLexer::tryMergeLessLess() {
   // Merge X,less,less,Y into X,lessless,Y unless X or Y is less.
   if (Tokens.size() < 3)


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2664,6 +2664,18 @@
   verifyIncompleteFormat("try {} catch (");
 }
 
+TEST_F(FormatTest, FormatTryAsAVariable) {
+  verifyFormat("int try;");
+  verifyFormat("int try, size;");
+  verifyFormat("try = foo();");
+  verifyFormat("if (try < size) {\n  return true;\n}");
+
+  verifyFormat("int catch;");
+  verifyFormat("int catch, size;");
+  verifyFormat("catch = foo();");
+  verifyFormat("if (catch < size) {\n  return true;\n}");
+}
+
 TEST_F(FormatTest, FormatSEHTryCatch) {
   verifyFormat("__try {\n"
"  int a = b * c;\n"
Index: clang/lib/Format/FormatTokenLexer.h
===
--- clang/lib/Format/FormatTokenLexer.h
+++ clang/lib/Format/Form

[PATCH] D80876: [clang] Default to windows response files when running on windows

2020-06-01 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a subscriber: rnk.
probinson added a comment.

I was about to add @rnk who I remember has been in Windows driver behavior 
discussions in the past; except he has cleverly left a note that he's away 
June-Sept.  Oh well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80876



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


[PATCH] D68049: Propeller: Clang options for basic block sections

2020-06-01 Thread Sriraman Tallam via Phabricator via cfe-commits
tmsriram added a comment.

Ping.


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

https://reviews.llvm.org/D68049



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


[PATCH] D80941: [PowerPC][Power10] Implement Count Leading/Trailing Zeroes Builtins in LLVM/Clang

2020-06-01 Thread Amy Kwan via Phabricator via cfe-commits
amyk created this revision.
amyk added reviewers: nemanjai, lei, stefanp, saghir, power-llvm-team, hfinkel.
amyk added a project: LLVM.
Herald added subscribers: shchenz, hiraditya.
Herald added a project: clang.

This patch implements builtins for the following prototypes:

  unsigned long long __builtin_cntlzdm (unsigned long long, unsigned long long)
  unsigned long long __builtin_cnttzdm (unsigned long long, unsigned long long)
  vector unsigned long long vec_cntlzm (vector unsigned long long, vector 
unsigned long long)
  vector unsigned long long vec_cnttzm (vector unsigned long long, vector 
unsigned long long)

Depends on D80935 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80941

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p10.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
  llvm/test/MC/Disassembler/PowerPC/p10insts.txt
  llvm/test/MC/PowerPC/p10.s

Index: llvm/test/MC/PowerPC/p10.s
===
--- llvm/test/MC/PowerPC/p10.s
+++ llvm/test/MC/PowerPC/p10.s
@@ -15,3 +15,15 @@
 # CHECK-BE: pextd 1, 2, 4 # encoding: [0x7c,0x41,0x21,0x78]
 # CHECK-LE: pextd 1, 2, 4 # encoding: [0x78,0x21,0x41,0x7c]
 pextd 1, 2, 4
+# CHECK-BE: vclzdm 1, 2, 3# encoding: [0x10,0x22,0x1f,0x84]
+# CHECK-LE: vclzdm 1, 2, 3# encoding: [0x84,0x1f,0x22,0x10]
+vclzdm 1, 2, 3
+# CHECK-BE: vctzdm 1, 2, 3# encoding: [0x10,0x22,0x1f,0xc4]
+# CHECK-LE: vctzdm 1, 2, 3# encoding: [0xc4,0x1f,0x22,0x10]
+vctzdm 1, 2, 3
+# CHECK-BE: cntlzdm 1, 3, 2   # encoding: [0x7c,0x61,0x10,0x76]
+# CHECK-LE: cntlzdm 1, 3, 2   # encoding: [0x76,0x10,0x61,0x7c]
+cntlzdm 1, 3, 2
+# CHECK-BE: cnttzdm 1, 3, 2   # encoding: [0x7c,0x61,0x14,0x76]
+# CHECK-LE: cnttzdm 1, 3, 2   # encoding: [0x76,0x14,0x61,0x7c]
+cnttzdm 1, 3, 2
Index: llvm/test/MC/Disassembler/PowerPC/p10insts.txt
===
--- llvm/test/MC/Disassembler/PowerPC/p10insts.txt
+++ llvm/test/MC/Disassembler/PowerPC/p10insts.txt
@@ -12,3 +12,15 @@
 
 # CHECK: pextd 1, 2, 4
 0x7c 0x41 0x21 0x78
+
+# CHECK: vclzdm 1, 2, 3
+0x10 0x22 0x1f 0x84
+
+# CHECK: vctzdm 1, 2, 3
+0x10 0x22 0x1f 0xc4
+
+# CHECK: cntlzdm 1, 3, 2
+0x7c 0x61 0x10 0x76
+
+# CHECK: cnttzdm 1, 3, 2
+0x7c 0x61 0x14 0x76
Index: llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
===
--- llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
+++ llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
@@ -9,6 +9,10 @@
 declare <2 x i64> @llvm.ppc.altivec.vpextd(<2 x i64>, <2 x i64>)
 declare i64 @llvm.ppc.pdepd(i64, i64)
 declare i64 @llvm.ppc.pextd(i64, i64)
+declare <2 x i64> @llvm.ppc.altivec.vclzdm(<2 x i64>, <2 x i64>)
+declare <2 x i64> @llvm.ppc.altivec.vctzdm(<2 x i64>, <2 x i64>)
+declare i64 @llvm.ppc.cntlzdm(i64, i64)
+declare i64 @llvm.ppc.cnttzdm(i64, i64)
 
 define <2 x i64> @test_vpdepd(<2 x i64> %a, <2 x i64> %b) {
 ; CHECK-LABEL: test_vpdepd:
@@ -49,3 +53,43 @@
   %tmp = tail call i64 @llvm.ppc.pextd(i64 %a, i64 %b)
   ret i64 %tmp
 }
+
+define <2 x i64> @test_vclzdm(<2 x i64> %a, <2 x i64> %b) {
+; CHECK-LABEL: test_vclzdm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vclzdm v2, v2, v3
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vclzdm(<2 x i64> %a, <2 x i64> %b)
+  ret <2 x i64> %tmp
+}
+
+define <2 x i64> @test_vctzdm(<2 x i64> %a, <2 x i64> %b) {
+; CHECK-LABEL: test_vctzdm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vctzdm v2, v2, v3
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vctzdm(<2 x i64> %a, <2 x i64> %b)
+  ret <2 x i64> %tmp
+}
+
+define i64 @test_cntlzdm(i64 %a, i64 %b) {
+; CHECK-LABEL: test_cntlzdm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:cntlzdm r3, r3, r4
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i64 @llvm.ppc.cntlzdm(i64 %a, i64 %b)
+  ret i64 %tmp
+}
+
+define i64 @test_cnttzdm(i64 %a, i64 %b) {
+; CHECK-LABEL: test_cnttzdm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:cnttzdm r3, r3, r4
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i64 @llvm.ppc.cnttzdm(i64 %a, i64 %b)
+  ret i64 %tmp
+}
Index: llvm/lib/Target/PowerPC/PPCInstrPrefix.td
===
--- llvm/lib/Target/PowerPC/PPCInstrPrefix.td
+++ llvm/lib/Target/PowerPC/PPCInstrPrefix.td
@@ -516,4 +516,20 @@
def PEXTD : XForm_6<31, 188, (outs g8rc:$rA), (ins g8rc:$rS, g8rc:$rB),
  

[PATCH] D80925: Fix compiler crash when trying to parse alignment argument as a constant expression.

2020-06-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D80925#2066728 , @rjmccall wrote:

> Narrowly this seems to fix the immediate problem, but I feel like we're in 
> trouble if tentative parsing is changing the semantic context in ways that 
> persist.  In particular, I'm concerned that we could end up tentatively 
> parsing an ODR use as part of an expression and then completely discarding 
> it, causing Sema to think that there's an ODR use later because it never sees 
> an L2R conversion (because the expression is not actually used).  Probably 
> the most architectural thing would be for tentative expression parsing to 
> push a possibly-unevaluated context, and then when we claim an expression 
> annotation token we can do the retroactive work necessary to make it an 
> expression in the proper context.  We already have most of the logic to 
> support that because of C99 `sizeof`, which is usually not evaluated but can 
> be in the narrow circumstance of a VLA.
>
> If we do decide to solve this more narrowly, then we should audit our use of 
> the tentative-parsing queries to make sure that we're pushing contexts 
> consistently, and we should leave comments in places like this to make sure 
> that maintainers understand the subtleties.


So, you suggest to not create annot_primary_expr during tentative parsing and 
revert parsing completely, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80925



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


[PATCH] D68049: Propeller: Clang options for basic block sections

2020-06-01 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: lld/ELF/LTO.cpp:79
   // Check if basic block sections must be used.
   // Allowed values for --lto-basicblock-sections are "all", "labels",
   // "", or none.  This is the equivalent

`--lto-basic-block-sections`

I think it should be fine updating it here, and probably preferable, since you 
already touched some related LLD code. It does not affect any tests. (You did 
not add any tests for `--lto-basicblock-sections` in the original LLD patch.)


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

https://reviews.llvm.org/D68049



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


[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

2020-06-01 Thread Adrian McCarthy via Phabricator via cfe-commits
amccarth accepted this revision.
amccarth added a comment.

Yowza.  Mingw still links against MSVCRT?!

Anyway, I think the patch is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80880



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


[PATCH] D80941: [PowerPC][Power10] Implement Count Leading/Trailing Zeroes Builtins in LLVM/Clang

2020-06-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Why not lower it to `@llvm.cttz(and(a, b))`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80941



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


[PATCH] D68049: Propeller: Clang options for basic block sections

2020-06-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Clang side of these changes LGTM


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

https://reviews.llvm.org/D68049



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


  1   2   >