[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Andrew via Phabricator via cfe-commits]

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



Comment at: llvm/include/llvm/ADT/SmallVector.h:19
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MathExtras.h"

nikic wrote:
> Is this include still needed?
SmallVectorTemplateBase::grow() still remains in the 
header and uses report_bad_alloc_error().


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Andrew via Phabricator via cfe-commits]

browneee updated this revision to Diff 260064.
browneee added a comment.

Change uintptr_t to uint64_t to ensure this does not instantiate the same 
template twice on platforms where uintptr_t is equivalent to uint32_t.

Also considered using the preprocessor to disable the uintptr_t instantiation, 
but chose to avoid preprocessor use.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621

Files:
  llvm/include/llvm/ADT/SmallVector.h
  llvm/lib/Support/SmallVector.cpp

Index: llvm/lib/Support/SmallVector.cpp
===
--- llvm/lib/Support/SmallVector.cpp
+++ llvm/lib/Support/SmallVector.cpp
@@ -37,24 +37,30 @@
   sizeof(unsigned) * 2 + sizeof(void *) * 2,
   "wasted space in SmallVector size 1");
 
-/// grow_pod - This is an implementation of the grow() method which only works
-/// on POD-like datatypes and is out of line to reduce code duplication.
-/// This function will report a fatal error if it cannot increase capacity.
-void SmallVectorBase::grow_pod(void *FirstEl, size_t MinCapacity,
-   size_t TSize) {
-  // Ensure we can fit the new capacity in 32 bits.
-  if (MinCapacity > UINT32_MAX)
+static_assert(sizeof(SmallVector) ==
+  sizeof(void *) * 2 + sizeof(void *),
+  "1 byte elements have word-sized type for size and capacity");
+
+// Note: Moving this function into the header may cause performance regression.
+template 
+void SmallVectorBase::grow_pod(void *FirstEl, size_t MinCapacity,
+   size_t TSize) {
+  // Ensure we can fit the new capacity.
+  // This is only going to be applicable when the capacity is 32 bit.
+  if (MinCapacity > SizeTypeMax())
 report_bad_alloc_error("SmallVector capacity overflow during allocation");
 
   // Ensure we can meet the guarantee of space for at least one more element.
   // The above check alone will not catch the case where grow is called with a
   // default MinCapacity of 0, but the current capacity cannot be increased.
-  if (capacity() == size_t(UINT32_MAX))
+  // This is only going to be applicable when the capacity is 32 bit.
+  if (capacity() == SizeTypeMax())
 report_bad_alloc_error("SmallVector capacity unable to grow");
 
+  // In theory 2*capacity can overflow if the capacity is 64 bit, but the
+  // original capacity would never be large enough for this to be a problem.
   size_t NewCapacity = 2 * capacity() + 1; // Always grow.
-  NewCapacity =
-  std::min(std::max(NewCapacity, MinCapacity), size_t(UINT32_MAX));
+  NewCapacity = std::min(std::max(NewCapacity, MinCapacity), SizeTypeMax());
 
   void *NewElts;
   if (BeginX == FirstEl) {
@@ -70,3 +76,6 @@
   this->BeginX = NewElts;
   this->Capacity = NewCapacity;
 }
+
+template class llvm::SmallVectorBase;
+template class llvm::SmallVectorBase;
Index: llvm/include/llvm/ADT/SmallVector.h
===
--- llvm/include/llvm/ADT/SmallVector.h
+++ llvm/include/llvm/ADT/SmallVector.h
@@ -16,10 +16,10 @@
 #include "llvm/ADT/iterator_range.h"
 #include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemAlloc.h"
 #include "llvm/Support/type_traits.h"
-#include "llvm/Support/ErrorHandling.h"
 #include 
 #include 
 #include 
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,11 +35,23 @@
 
 namespace llvm {
 
-/// This is all the non-templated stuff common to all SmallVectors.
-class SmallVectorBase {
+/// This is all the stuff common to all SmallVectors.
+///
+/// The template parameter specifies the type which should be used to hold the
+/// Size and Capacity of the SmallVector, so it can be adjusted.
+/// Using 32 bit size is desirable to shink the size of the SmallVector.
+/// Using 64 bit size is desirable for cases like SmallVector, where a
+/// 32 bit size would limit the vector to ~4GB. SmallVectors are used for
+/// buffering bitcode output - which can exceed 4GB.
+template  class SmallVectorBase {
 protected:
   void *BeginX;
-  unsigned Size = 0, Capacity;
+  Size_T Size = 0, Capacity;
+
+  /// The maximum value of the Size_T used.
+  static constexpr size_t SizeTypeMax() {
+return std::numeric_limits::max();
+  }
 
   SmallVectorBase() = delete;
   SmallVectorBase(void *FirstEl, size_t TotalCapacity)
@@ -70,9 +83,14 @@
   }
 };
 
+template 
+using SmallVectorSizeType =
+typename std::conditional= 8, uint64_t,
+  uint32_t>::type;
+
 /// Figure out the offset of the first element.
 template  struct SmallVectorAlignmentAndSize {
-  AlignedCharArrayUnion Base;
+  AlignedCharArrayUnion>> Base;
   AlignedCharArrayUnion FirstEl;
 };
 
@@ -80,7 +98,10 @@
 /// the type T is a POD. 

[PATCH] D78853: [Sema] Fix null pointer dereference warnings [1/n]

[Mandeep Singh Grang via Phabricator via cfe-commits]

mgrang created this revision.
mgrang added reviewers: rsmith, efriedma, rnk, dblaikie.

Running the PREfast static analysis tool on clang resulted in several null
pointer dereference warnings. This is the first of several patches to fix
these.

The full list of warnings reported is here: 
https://docs.google.com/spreadsheets/d/1h_3tHxsgBampxb7PXoB5lgwiBSpTty9RLe5maIQxnTk/edit#gid=2014408543


https://reviews.llvm.org/D78853

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaExprObjC.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h

Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -13921,7 +13921,7 @@
   }
 
   // Determine whether this should be a builtin operation.
-  if (Op == OO_Subscript) {
+  if (Op == OO_Subscript && Second) {
 if (!First->getType()->isOverloadableType() &&
 !Second->getType()->isOverloadableType())
   return getSema().CreateBuiltinArraySubscriptExpr(
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -8289,7 +8289,7 @@
   // unless it's actually needed.
   if (Tag || IFace) {
 // Avoid diagnosing invalid decls as incomplete.
-if (Def->isInvalidDecl())
+if (Def && Def->isInvalidDecl())
   return true;
 
 // Give the external AST source a chance to complete the type.
Index: clang/lib/Sema/SemaTemplateVariadic.cpp
===
--- clang/lib/Sema/SemaTemplateVariadic.cpp
+++ clang/lib/Sema/SemaTemplateVariadic.cpp
@@ -765,6 +765,8 @@
   // retain an expansion.
   if (NumPartialExpansions) {
 if (NumExpansions && *NumExpansions < *NumPartialExpansions) {
+  assert(CurrentInstantiationScope && "!CurrentInstantiationScope");
+
   NamedDecl *PartialPack =
   CurrentInstantiationScope->getPartiallySubstitutedPack();
   Diag(EllipsisLoc, diag::err_pack_expansion_length_conflict_partial)
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5186,7 +5186,7 @@
   LocalEagerInstantiationScope LocalInstantiations(*this);
 
   VarDecl *OldVar = Var;
-  if (Def->isStaticDataMember() && !Def->isOutOfLine()) {
+  if (Def && Def->isStaticDataMember() && !Def->isOutOfLine()) {
 // We're instantiating an inline static data member whose definition was
 // provided inside the class.
 InstantiateVariableInitializer(Var, Def, TemplateArgs);
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -10413,7 +10413,8 @@
 !ToRefTy->getPointeeType()->isIncompleteType() &&
 S.IsDerivedFrom(SourceLocation(), ToRefTy->getPointeeType(), FromTy)) {
   BaseToDerivedConversion = 3;
-} else if (ToTy->isLValueReferenceType() && !FromExpr->isLValue() &&
+} else if (ToTy->isLValueReferenceType() && FromExpr &&
+   !FromExpr->isLValue() &&
ToTy.getNonReferenceType().getCanonicalType() ==
FromTy.getNonReferenceType().getCanonicalType()) {
   S.Diag(Fn->getLocation(), diag::note_ovl_candidate_bad_lvalue)
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -5912,11 +5912,11 @@
 DeclAccessPair dap;
 if (isLibstdcxxPointerReturnFalseHack(S, Entity, Initializer)) {
   AddZeroInitializationStep(Entity.getType());
-} else if (Initializer->getType() == Context.OverloadTy &&
+} else if (Initializer && Initializer->getType() == Context.OverloadTy &&
!S.ResolveAddressOfOverloadedFunction(Initializer, DestType,
  false, dap))
   SetFailed(InitializationSequence::FK_AddressOfOverloadFailed);
-else if (Initializer->getType()->isFunctionType() &&
+else if (Initializer && Initializer->getType()->isFunctionType() &&
  isExprAnUnaddressableFunction(S, Initializer))
   SetFailed(InitializationSequence::FK_AddressOfUnaddressableFunction);
 else
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -589,6 +589,8 @@
   }
 
   BoxingMethod = StringWithUTF8StringMethod;
+   

[PATCH] D78836: [clangd] Strip /showIncludes in clangd compile commands

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang/lib/Tooling/ArgumentsAdjusters.cpp:101
   // -MF, -MG, -MP, -MT, -MQ, -MD, and -MMD.
-  if (!Arg.startswith("-M")) {
+  if (!Arg.startswith("-M") && Arg != "/showIncludes") {
 AdjustedArgs.push_back(Args[i]);

this can also be --show-includes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78836



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Andrew via Phabricator via cfe-commits]

browneee added a comment.

Reverted in 5cb4c3776a34d48e43d9118921d2191aee0e3d21 


Fails on plaforms where uintptr_t is the same type as uint32_t.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Andrew via Phabricator via cfe-commits]

browneee closed this revision.
browneee added a comment.

Comitted: b5f0eae1dc3c09c020cdf9d07238dec9acdacf5f 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D75917: Expose llvm fence instruction as clang intrinsic

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam updated this revision to Diff 260053.
saiislam added a comment.

Updated description and added a failing test case for integer scope.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75917

Files:
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGenCXX/builtin-amdgcn-fence.cpp
  clang/test/Sema/builtin-amdgcn-fence-failure.cpp
  clang/test/SemaOpenCL/builtins-amdgcn-error.cl

Index: clang/test/SemaOpenCL/builtins-amdgcn-error.cl
===
--- clang/test/SemaOpenCL/builtins-amdgcn-error.cl
+++ clang/test/SemaOpenCL/builtins-amdgcn-error.cl
@@ -128,3 +128,14 @@
   *out = __builtin_amdgcn_ds_fmaxf(out, src, 0, a, false); // expected-error {{argument to '__builtin_amdgcn_ds_fmaxf' must be a constant integer}}
   *out = __builtin_amdgcn_ds_fmaxf(out, src, 0, 0, a); // expected-error {{argument to '__builtin_amdgcn_ds_fmaxf' must be a constant integer}}
 }
+
+void test_fence() {
+  __builtin_amdgcn_fence(__ATOMIC_SEQ_CST + 1, "workgroup"); // expected-warning {{memory order argument to atomic operation is invalid}}
+  __builtin_amdgcn_fence(__ATOMIC_ACQUIRE - 1, "workgroup"); // expected-warning {{memory order argument to atomic operation is invalid}}
+  __builtin_amdgcn_fence(4); // expected-error {{too few arguments to function call, expected 2}}
+  __builtin_amdgcn_fence(4, 4, 4); // expected-error {{too many arguments to function call, expected 2}}
+  __builtin_amdgcn_fence(3.14, ""); // expected-warning {{implicit conversion from 'double' to 'unsigned int' changes value from 3.14 to 3}}
+  __builtin_amdgcn_fence(__ATOMIC_ACQUIRE, 5); // expected-warning {{incompatible integer to pointer conversion passing 'int' to parameter of type 'const char *'}}
+  const char ptr[] = "workgroup";
+  __builtin_amdgcn_fence(__ATOMIC_ACQUIRE, ptr); // expected-error {{expression is not a string literal}}
+}
Index: clang/test/Sema/builtin-amdgcn-fence-failure.cpp
===
--- /dev/null
+++ clang/test/Sema/builtin-amdgcn-fence-failure.cpp
@@ -0,0 +1,9 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: not %clang_cc1 %s -S \
+// RUN:   -triple=amdgcn-amd-amdhsa 2>&1 | FileCheck %s
+
+void test_amdgcn_fence_failure() {
+
+  // CHECK: error: Unsupported atomic synchronization scope
+  __builtin_amdgcn_fence(__ATOMIC_SEQ_CST, "foobar");
+}
Index: clang/test/CodeGenCXX/builtin-amdgcn-fence.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/builtin-amdgcn-fence.cpp
@@ -0,0 +1,22 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 %s -emit-llvm -O0 -o - \
+// RUN:   -triple=amdgcn-amd-amdhsa  | opt -S | FileCheck %s
+
+void test_memory_fence_success() {
+// CHECK-LABEL: test_memory_fence_success
+
+  // CHECK: fence syncscope("workgroup") seq_cst
+  __builtin_amdgcn_fence(__ATOMIC_SEQ_CST,  "workgroup");
+
+   // CHECK: fence syncscope("agent") acquire
+  __builtin_amdgcn_fence(__ATOMIC_ACQUIRE, "agent");
+
+  // CHECK: fence seq_cst
+  __builtin_amdgcn_fence(__ATOMIC_SEQ_CST, "");
+
+  // CHECK: fence syncscope("agent") acq_rel
+  __builtin_amdgcn_fence(4, "agent");
+
+// CHECK: fence syncscope("workgroup") release
+  __builtin_amdgcn_fence(3, "workgroup");
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1920,6 +1920,10 @@
 if (CheckPPCBuiltinFunctionCall(BuiltinID, TheCall))
   return ExprError();
 break;
+  case llvm::Triple::amdgcn:
+if (CheckAMDGCNBuiltinFunctionCall(BuiltinID, TheCall))
+  return ExprError();
+break;
   default:
 break;
 }
@@ -2921,6 +2925,45 @@
   return SemaBuiltinConstantArgRange(TheCall, i, l, u);
 }
 
+bool Sema::CheckAMDGCNBuiltinFunctionCall(unsigned BuiltinID, CallExpr *TheCall) {
+  switch (BuiltinID) {
+case AMDGPU::BI__builtin_amdgcn_fence: {
+  ExprResult Arg = TheCall->getArg(0);
+  auto ArgExpr = Arg.get();
+  Expr::EvalResult ArgResult;
+
+  if(!ArgExpr->EvaluateAsInt(ArgResult, Context))
+return Diag(ArgExpr->getExprLoc(), diag::err_typecheck_expect_int)
+  << ArgExpr->getType();
+  int ord = ArgResult.Val.getInt().getZExtValue();
+
+  // Check valididty of memory ordering as per C11 / C++11's memody model.
+  switch (static_cast(ord)) {
+case llvm::AtomicOrderingCABI::acquire:
+case llvm::AtomicOrderingCABI::release:
+case llvm::AtomicOrderingCABI::acq_rel:
+case llvm::AtomicOrderingCABI::seq_cst:
+  break;
+default: {
+  return Diag(ArgExpr->getBeginLoc(),
+

Re: [PATCH] D78192: Support compiler extensions as a normal component

[Michael Kruse via cfe-commits]

Weird. I already tried the patch under Windows/msvc and had no such problem.

Michael

Am Fr., 24. Apr. 2020 um 04:15 Uhr schrieb Russell Gallop
:
>
> Hi Serge,
>
> It looks like this is failing to build on Windows bots (e.g. 
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/32003).
>  Error below.
>
> Please could you take a look?
>
> Thanks
> Russ
>
> FAILED: tools/llvm-config/CMakeFiles/llvm-config.dir/llvm-config.cpp.obj 
> C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1425~1.286\bin\Hostx64\x64\cl.exe
>  /nologo /TP -DBUILD_EXAMPLES -DCMAKE_CFG_INTDIR=\".\" -DGTEST_HAS_RTTI=0 
> -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS 
> -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 
> -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE 
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -Itools\llvm-config 
> -IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm-project\llvm\tools\llvm-config
>  -Iinclude 
> -IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm-project\llvm\include
>  /DWIN32 /D_WINDOWS /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4 
> -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 
> -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 
> -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 
> -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 
> -we4238 /Gw /MD /O2 /Ob2 /EHs-c- /GR- -UNDEBUG -std:c++14 /showIncludes 
> /Fotools\llvm-config\CMakeFiles\llvm-config.dir\llvm-config.cpp.obj 
> /Fdtools\llvm-config\CMakeFiles\llvm-config.dir\ /FS -c 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm-project\llvm\tools\llvm-config\llvm-config.cpp
>  tools\llvm-config\ExtensionDependencies.inc(6): error C2280: 
> 'ExtensionDescriptor::ExtensionDescriptor(void)': attempting to reference a 
> deleted function tools\llvm-config\ExtensionDependencies.inc(5): note: 
> compiler has generated 'ExtensionDescriptor::ExtensionDescriptor' here 
> tools\llvm-config\ExtensionDependencies.inc(5): note: 
> 'ExtensionDescriptor::ExtensionDescriptor(void)': function was implicitly 
> deleted because 'ExtensionDescriptor' has an uninitialized const-qualified 
> data member 'ExtensionDescriptor::RequiredLibraries' 
> tools\llvm-config\ExtensionDependencies.inc(4): note: see declaration of 
> 'ExtensionDescriptor::RequiredLibraries'
>
> On Fri, 24 Apr 2020 at 09:02, serge via Phabricator via cfe-commits 
>  wrote:
>>
>> This revision was automatically updated to reflect the committed changes.
>> Closed by commit rG8f766e382b77: Update compiler extension integration into 
>> the build system (authored by serge-sans-paille).
>>
>> Changed prior to commit:
>>   https://reviews.llvm.org/D78192?vs=259495=259827#toc
>>
>> Repository:
>>   rG LLVM Github Monorepo
>>
>> CHANGES SINCE LAST ACTION
>>   https://reviews.llvm.org/D78192/new/
>>
>> https://reviews.llvm.org/D78192
>>
>> Files:
>>   clang/lib/CodeGen/CMakeLists.txt
>>   llvm/cmake/modules/AddLLVM.cmake
>>   llvm/lib/CMakeLists.txt
>>   llvm/lib/Extensions/CMakeLists.txt
>>   llvm/lib/Extensions/Extensions.cpp
>>   llvm/lib/Extensions/LLVMBuild.txt
>>   llvm/lib/LLVMBuild.txt
>>   llvm/lib/LTO/CMakeLists.txt
>>   llvm/lib/LTO/LLVMBuild.txt
>>   llvm/tools/bugpoint/CMakeLists.txt
>>   llvm/tools/llvm-config/llvm-config.cpp
>>   llvm/tools/opt/CMakeLists.txt
>>
>> ___
>> 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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D78659#2003152 , @zequanwu wrote:

> Add check in LICM to prevent sink or hoist on `nomerge` call


Does sinking and hoisting remove the debug source location? I assumed that it 
wouldn't, but now after all the smooth stepping work, maybe it does.

Maybe we should audit for calls to `DILocation::getMergedLocation`, and use 
that to guide our changes. It would also be good to build an API that ensures 
that passes do not use `getMergedLocation` for instructions marked this way.

---

This also needs to be documented in llvm/docs/LangRef.rst with the other 
function attributes. Check out Arthur's preallocated patch for an example of 
that: D74651 




Comment at: clang/include/clang/Basic/AttrDocs.td:356-357
+  let Content = [{
+A function declared as ``nomerge`` shall not be tail merged at call sites 
during
+optimization phase.
+  }];

I think we need to expand on this. This is user facing documentation visible 
here:
http://clang.llvm.org/docs/AttributeReference.html

Here's a suggestion:
"Calls to functions marked ``nomerge`` will not be merged during optimization. 
This attribute can be used to prevent the optimizer from obscuring the source 
location of certain calls. For example, it will prevent tail merging otherwise 
identical code sequences that raise an exception or terminate the program. Tail 
merging normally reduces the precision of source location information, making 
stack traces less useful for debugging. This attribute gives the user control 
over the tradeoff between code size and debug information precision."


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

https://reviews.llvm.org/D78659



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

[PATCH] D78848: [clangd] Disable delayed template parsing in the main file

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

This is on by default in windows and breaks most features in template bodies.
We'd already disabled it in code completion, now disable it for building ASTs.

Potential regressions:

- we may give spurious errors where files with templates relying on delayed 
parsing are directly opened
- we may misparse such template bodies that are instantiated (and therefore 
*were* previously parsed)

Still *probably* a win overall. Avoiding the regressions entirely would be
substantial work and we don't have plans for it now.

Fixes https://github.com/clangd/clangd/issues/302 (again)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78848

Files:
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/unittests/ParsedASTTests.cpp


Index: clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
===
--- clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
+++ clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
@@ -175,6 +175,17 @@
 AllOf(DeclNamed("foo"), WithTemplateArgs(""))}));
 }
 
+TEST(ParsedASTTest, IgnoresDelayedTemplateParsing) {
+  auto TU = TestTU::withCode(R"cpp(
+template  void xxx() {
+  int yyy = 0;
+}
+  )cpp");
+  TU.ExtraArgs.push_back("-fdelayed-template-parsing");
+  auto AST = TU.build();
+  EXPECT_EQ(Decl::Var, findUnqualifiedDecl(AST, "yyy").getKind());
+}
+
 TEST(ParsedASTTest, TokensAfterPreamble) {
   TestTU TU;
   TU.AdditionalFiles["foo.h"] = R"(
Index: clang-tools-extra/clangd/ParsedAST.cpp
===
--- clang-tools-extra/clangd/ParsedAST.cpp
+++ clang-tools-extra/clangd/ParsedAST.cpp
@@ -256,6 +256,9 @@
   // Recovery expression currently only works for C++.
   if (CI->getLangOpts()->CPlusPlus)
 CI->getLangOpts()->RecoveryAST = Opts.BuildRecoveryAST;
+  // This is on-by-default in windows to allow parsing SDK headers, but it
+  // breaks many features. Disable it for the main-file (not preamble).
+  CI->getLangOpts()->DelayedTemplateParsing = false;
 
   StoreDiags ASTDiags;
   std::string Content = std::string(Buffer->getBuffer());


Index: clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
===
--- clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
+++ clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
@@ -175,6 +175,17 @@
 AllOf(DeclNamed("foo"), WithTemplateArgs(""))}));
 }
 
+TEST(ParsedASTTest, IgnoresDelayedTemplateParsing) {
+  auto TU = TestTU::withCode(R"cpp(
+template  void xxx() {
+  int yyy = 0;
+}
+  )cpp");
+  TU.ExtraArgs.push_back("-fdelayed-template-parsing");
+  auto AST = TU.build();
+  EXPECT_EQ(Decl::Var, findUnqualifiedDecl(AST, "yyy").getKind());
+}
+
 TEST(ParsedASTTest, TokensAfterPreamble) {
   TestTU TU;
   TU.AdditionalFiles["foo.h"] = R"(
Index: clang-tools-extra/clangd/ParsedAST.cpp
===
--- clang-tools-extra/clangd/ParsedAST.cpp
+++ clang-tools-extra/clangd/ParsedAST.cpp
@@ -256,6 +256,9 @@
   // Recovery expression currently only works for C++.
   if (CI->getLangOpts()->CPlusPlus)
 CI->getLangOpts()->RecoveryAST = Opts.BuildRecoveryAST;
+  // This is on-by-default in windows to allow parsing SDK headers, but it
+  // breaks many features. Disable it for the main-file (not preamble).
+  CI->getLangOpts()->DelayedTemplateParsing = false;
 
   StoreDiags ASTDiags;
   std::string Content = std::string(Buffer->getBuffer());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78843: [clangd] Remove unused bits after 67b2dbd5a33583. NFC

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev added inline comments.



Comment at: clang-tools-extra/clangd/Features.inc.in:2
 #define CLANGD_BUILD_XPC @CLANGD_BUILD_XPC@
-#define CLANGD_ENABLE_REMOTE @CLANGD_ENABLE_REMOTE@

I don't know how much code will have with `ifdefs` in the Clangd itself, but I 
can think of several places, so I'm not sure whether removing this is really 
needed (since I'd most likely add this back in the next patch or two). However, 
I'm OK with doing that, things might change.

The cleanup which will be correct regardless is removing the last implicit 
remnants of `CLANGD_ENABLE_REMOTE` from Dexp:

* `Features.in` include is no longer needed
* CMake's directive to include the directory with `Features.in` is also no 
longer needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78843



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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

[Zequan Wu via Phabricator via cfe-commits]

zequanwu updated this revision to Diff 260039.
zequanwu added a comment.

Add check in LICM to prevent sink or hoist on `nomerge` call


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

https://reviews.llvm.org/D78659

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/attr-nomerge.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Scalar/LICM.cpp
  llvm/lib/Transforms/Utils/SimplifyCFG.cpp

Index: llvm/lib/Transforms/Utils/SimplifyCFG.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -1287,6 +1287,14 @@
 if (!TTI.isProfitableToHoist(I1) || !TTI.isProfitableToHoist(I2))
   return Changed;
 
+// If any of the two call sites has nomerge attribute, stop hoisting.
+if (const auto *CB1 = dyn_cast(I1))
+  if (CB1->cannotMerge())
+return Changed;
+if (const auto *CB2 = dyn_cast(I2))
+  if (CB2->cannotMerge())
+return Changed;
+
 if (isa(I1) || isa(I2)) {
   assert (isa(I1) && isa(I2));
   // The debug location is an integral part of a debug info intrinsic
@@ -1472,8 +1480,9 @@
 // Conservatively return false if I is an inline-asm instruction. Sinking
 // and merging inline-asm instructions can potentially create arguments
 // that cannot satisfy the inline-asm constraints.
+// If the instruction has nomerge attribute, return false.
 if (const auto *C = dyn_cast(I))
-  if (C->isInlineAsm())
+  if (C->isInlineAsm() || C->cannotMerge())
 return false;
 
 // Each instruction must have zero or one use.
Index: llvm/lib/Transforms/Scalar/LICM.cpp
===
--- llvm/lib/Transforms/Scalar/LICM.cpp
+++ llvm/lib/Transforms/Scalar/LICM.cpp
@@ -1091,6 +1091,10 @@
 if (isa(I))
   return false;
 
+// Don't sink or hoist call with nomerge attr.
+if (CI->cannotMerge())
+  return false;
+  
 // Don't sink calls which can throw.
 if (CI->mayThrow())
   return false;
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1509,6 +1509,7 @@
 /// Return true if this attribute kind only applies to functions.
 static bool isFuncOnlyAttr(Attribute::AttrKind Kind) {
   switch (Kind) {
+  case Attribute::NoMerge:
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -368,6 +368,8 @@
 return "noinline";
   if (hasAttribute(Attribute::NonLazyBind))
 return "nonlazybind";
+  if (hasAttribute(Attribute::NoMerge))
+return "nomerge";
   if (hasAttribute(Attribute::NonNull))
 return "nonnull";
   if (hasAttribute(Attribute::NoRedZone))
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -204,6 +204,7 @@
   kw_noinline,
   kw_norecurse,
   kw_nonlazybind,
+  kw_nomerge,
   kw_nonnull,
   kw_noredzone,
   kw_noreturn,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1306,6 +1306,7 @@
   B.addAttribute(Attribute::NoImplicitFloat); break;
 case lltok::kw_noinline: B.addAttribute(Attribute::NoInline); break;
 case lltok::kw_nonlazybind: B.addAttribute(Attribute::NonLazyBind); break;
+case lltok::kw_nomerge: B.addAttribute(Attribute::NoMerge); break;
 case lltok::kw_noredzone: B.addAttribute(Attribute::NoRedZone); break;
 case lltok::kw_noreturn: B.addAttribute(Attribute::NoReturn); break;
 case lltok::kw_nosync: B.addAttribute(Attribute::NoSync); break;
@@ -1682,6 +1683,7 @@
 case lltok::kw_noimplicitfloat:
 case lltok::kw_noinline:
 case lltok::kw_nonlazybind:
+case lltok::kw_nomerge:
 case lltok::kw_noredzone:
 case lltok::kw_noreturn:
 case lltok::kw_nocf_check:
@@ -1781,6 +1783,7 @@
 case lltok::kw_noimplicitfloat:
 case lltok::kw_noinline:
 case lltok::kw_nonlazybind:
+case lltok::kw_nomerge:
 case lltok::kw_noredzone:
 case lltok::kw_noreturn:
 case lltok::kw_nocf_check:
Index: llvm/lib/AsmParser/LLLexer.cpp
===
--- llvm/lib/AsmParser/LLLexer.cpp
+++ 

[PATCH] D78836: [clangd] Strip /showIncludes in clangd compile commands

[Arthur Eubanks via Phabricator via cfe-commits]

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

Add test in ToolingTest


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78836

Files:
  clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
  clang/lib/Tooling/ArgumentsAdjusters.cpp
  clang/unittests/Tooling/ToolingTest.cpp


Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -530,6 +530,34 @@
   EXPECT_TRUE(HasFlag("-w"));
 }
 
+// Check getClangStripDependencyFileAdjuster strips /showIncludes
+TEST(ClangToolTest, StripDependencyFileAdjusterShowIncludes) {
+  FixedCompilationDatabase Compilations("/", {"/showIncludes", "-c"});
+
+  ClangTool Tool(Compilations, std::vector(1, "/a.cc"));
+  Tool.mapVirtualFile("/a.cc", "void a() {}");
+
+  std::unique_ptr Action(
+  newFrontendActionFactory());
+
+  CommandLineArguments FinalArgs;
+  ArgumentsAdjuster CheckFlagsAdjuster =
+[](const CommandLineArguments , StringRef /*unused*/) {
+  FinalArgs = Args;
+  return Args;
+};
+  Tool.clearArgumentsAdjusters();
+  Tool.appendArgumentsAdjuster(getClangStripDependencyFileAdjuster());
+  Tool.appendArgumentsAdjuster(CheckFlagsAdjuster);
+  Tool.run(Action.get());
+
+  auto HasFlag = [](const std::string ) {
+return llvm::find(FinalArgs, Flag) != FinalArgs.end();
+  };
+  EXPECT_FALSE(HasFlag("/showIncludes"));
+  EXPECT_TRUE(HasFlag("-c"));
+}
+
 // Check getClangStripPluginsAdjuster strips plugin related args.
 TEST(ClangToolTest, StripPluginsAdjuster) {
   FixedCompilationDatabase Compilations(
Index: clang/lib/Tooling/ArgumentsAdjusters.cpp
===
--- clang/lib/Tooling/ArgumentsAdjusters.cpp
+++ clang/lib/Tooling/ArgumentsAdjusters.cpp
@@ -98,7 +98,7 @@
   StringRef Arg = Args[i];
   // All dependency-file options begin with -M. These include -MM,
   // -MF, -MG, -MP, -MT, -MQ, -MD, and -MMD.
-  if (!Arg.startswith("-M")) {
+  if (!Arg.startswith("-M") && Arg != "/showIncludes") {
 AdjustedArgs.push_back(Args[i]);
 continue;
   }
Index: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
===
--- clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
+++ clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
@@ -79,6 +79,13 @@
 EXPECT_THAT(Cmd, Not(Contains(Stripped)));
 }
 
+TEST(CommandMangler, StripShowIncludes) {
+  auto Mangler = CommandMangler::forTests();
+  std::vector Cmd = {"clang-cl", "/showIncludes", "foo.cc"};
+  Mangler.adjust(Cmd);
+  EXPECT_THAT(Cmd, Not(Contains("/showIncludes")));
+}
+
 TEST(CommandMangler, ClangPath) {
   auto Mangler = CommandMangler::forTests();
   Mangler.ClangPath = testPath("fake/clang");


Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -530,6 +530,34 @@
   EXPECT_TRUE(HasFlag("-w"));
 }
 
+// Check getClangStripDependencyFileAdjuster strips /showIncludes
+TEST(ClangToolTest, StripDependencyFileAdjusterShowIncludes) {
+  FixedCompilationDatabase Compilations("/", {"/showIncludes", "-c"});
+
+  ClangTool Tool(Compilations, std::vector(1, "/a.cc"));
+  Tool.mapVirtualFile("/a.cc", "void a() {}");
+
+  std::unique_ptr Action(
+  newFrontendActionFactory());
+
+  CommandLineArguments FinalArgs;
+  ArgumentsAdjuster CheckFlagsAdjuster =
+[](const CommandLineArguments , StringRef /*unused*/) {
+  FinalArgs = Args;
+  return Args;
+};
+  Tool.clearArgumentsAdjusters();
+  Tool.appendArgumentsAdjuster(getClangStripDependencyFileAdjuster());
+  Tool.appendArgumentsAdjuster(CheckFlagsAdjuster);
+  Tool.run(Action.get());
+
+  auto HasFlag = [](const std::string ) {
+return llvm::find(FinalArgs, Flag) != FinalArgs.end();
+  };
+  EXPECT_FALSE(HasFlag("/showIncludes"));
+  EXPECT_TRUE(HasFlag("-c"));
+}
+
 // Check getClangStripPluginsAdjuster strips plugin related args.
 TEST(ClangToolTest, StripPluginsAdjuster) {
   FixedCompilationDatabase Compilations(
Index: clang/lib/Tooling/ArgumentsAdjusters.cpp
===
--- clang/lib/Tooling/ArgumentsAdjusters.cpp
+++ clang/lib/Tooling/ArgumentsAdjusters.cpp
@@ -98,7 +98,7 @@
   StringRef Arg = Args[i];
   // All dependency-file options begin with -M. These include -MM,
   // -MF, -MG, -MP, -MT, -MQ, -MD, and -MMD.
-  if (!Arg.startswith("-M")) {
+  if (!Arg.startswith("-M") && Arg != "/showIncludes") {
 AdjustedArgs.push_back(Args[i]);
 continue;
   }
Index: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp

[PATCH] D78836: [clangd] Strip /showIncludes in clangd compile commands

[Arthur Eubanks via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp:82
 
+TEST(CommandMangler, StripShowIncludes) {
+  auto Mangler = CommandMangler::forTests();

sammccall wrote:
> It's useful to have this test to verify the behavior at the clangd level, but 
> the arg adjuster is a separate library and also used in other contexts.
> 
> The unit-test for this arg-adjuster lives in 
> clang/unittests/Tooling/ToolingTest.cpp around line 500. Could you add a test 
> for the new behavior there, too?
Done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78836



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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

[Zequan Wu via Phabricator via cfe-commits]

zequanwu updated this revision to Diff 260038.

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

https://reviews.llvm.org/D78659

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/attr-nomerge.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/SimplifyCFG.cpp

Index: llvm/lib/Transforms/Utils/SimplifyCFG.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -1287,6 +1287,14 @@
 if (!TTI.isProfitableToHoist(I1) || !TTI.isProfitableToHoist(I2))
   return Changed;
 
+// If any of the two call sites has nomerge attribute, stop hoisting.
+if (const auto *CB1 = dyn_cast(I1))
+  if (CB1->cannotMerge())
+return Changed;
+if (const auto *CB2 = dyn_cast(I2))
+  if (CB2->cannotMerge())
+return Changed;
+
 if (isa(I1) || isa(I2)) {
   assert (isa(I1) && isa(I2));
   // The debug location is an integral part of a debug info intrinsic
@@ -1472,8 +1480,9 @@
 // Conservatively return false if I is an inline-asm instruction. Sinking
 // and merging inline-asm instructions can potentially create arguments
 // that cannot satisfy the inline-asm constraints.
+// If the instruction has nomerge attribute, return false.
 if (const auto *C = dyn_cast(I))
-  if (C->isInlineAsm())
+  if (C->isInlineAsm() || C->cannotMerge())
 return false;
 
 // Each instruction must have zero or one use.
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1509,6 +1509,7 @@
 /// Return true if this attribute kind only applies to functions.
 static bool isFuncOnlyAttr(Attribute::AttrKind Kind) {
   switch (Kind) {
+  case Attribute::NoMerge:
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -368,6 +368,8 @@
 return "noinline";
   if (hasAttribute(Attribute::NonLazyBind))
 return "nonlazybind";
+  if (hasAttribute(Attribute::NoMerge))
+return "nomerge";
   if (hasAttribute(Attribute::NonNull))
 return "nonnull";
   if (hasAttribute(Attribute::NoRedZone))
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -204,6 +204,7 @@
   kw_noinline,
   kw_norecurse,
   kw_nonlazybind,
+  kw_nomerge,
   kw_nonnull,
   kw_noredzone,
   kw_noreturn,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1306,6 +1306,7 @@
   B.addAttribute(Attribute::NoImplicitFloat); break;
 case lltok::kw_noinline: B.addAttribute(Attribute::NoInline); break;
 case lltok::kw_nonlazybind: B.addAttribute(Attribute::NonLazyBind); break;
+case lltok::kw_nomerge: B.addAttribute(Attribute::NoMerge); break;
 case lltok::kw_noredzone: B.addAttribute(Attribute::NoRedZone); break;
 case lltok::kw_noreturn: B.addAttribute(Attribute::NoReturn); break;
 case lltok::kw_nosync: B.addAttribute(Attribute::NoSync); break;
@@ -1682,6 +1683,7 @@
 case lltok::kw_noimplicitfloat:
 case lltok::kw_noinline:
 case lltok::kw_nonlazybind:
+case lltok::kw_nomerge:
 case lltok::kw_noredzone:
 case lltok::kw_noreturn:
 case lltok::kw_nocf_check:
@@ -1781,6 +1783,7 @@
 case lltok::kw_noimplicitfloat:
 case lltok::kw_noinline:
 case lltok::kw_nonlazybind:
+case lltok::kw_nomerge:
 case lltok::kw_noredzone:
 case lltok::kw_noreturn:
 case lltok::kw_nocf_check:
Index: llvm/lib/AsmParser/LLLexer.cpp
===
--- llvm/lib/AsmParser/LLLexer.cpp
+++ llvm/lib/AsmParser/LLLexer.cpp
@@ -658,6 +658,7 @@
   KEYWORD(noinline);
   KEYWORD(norecurse);
   KEYWORD(nonlazybind);
+  KEYWORD(nomerge);
   KEYWORD(nonnull);
   KEYWORD(noredzone);
   KEYWORD(noreturn);
Index: llvm/include/llvm/IR/InstrTypes.h
===
--- llvm/include/llvm/IR/InstrTypes.h
+++ llvm/include/llvm/IR/InstrTypes.h
@@ -1717,6 +1717,9 @@
 addAttribute(AttributeList::FunctionIndex, Attribute::NoDuplicate);
   }
 
+  /// Determine if the invoke cannot be tail merged.
+  bool cannotMerge() const { return 

[clang-tools-extra] 226b045 - [clangd] Look for compilation database in `build` subdirectory of parents.

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-04-25T02:18:17+02:00
New Revision: 226b045b1fe5c436ebd4d9bc1023e508789822c9

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

LOG: [clangd] Look for compilation database in `build` subdirectory of parents.

Summary:
This matches the conventional location of cmake build directories.
It also allows creating a `build` symlink, which seems more flexible than the
compile_commands.json symlinks.

Reviewers: kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp 
b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
index aa6727fc20f5..3f8a7d8219f7 100644
--- a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -110,14 +110,24 @@ static bool pathEqual(PathRef A, PathRef B) {
 DirectoryBasedGlobalCompilationDatabase::CachedCDB &
 DirectoryBasedGlobalCompilationDatabase::getCDBInDirLocked(PathRef Dir) const {
   // FIXME(ibiryukov): Invalidate cached compilation databases on changes
-  // FIXME(sammccall): this function hot, avoid copying key when hitting cache.
   auto Key = maybeCaseFoldPath(Dir);
   auto R = CompilationDatabases.try_emplace(Key);
   if (R.second) { // Cache miss, try to load CDB.
 CachedCDB  = R.first->second;
 std::string Error;
-Entry.CDB = tooling::CompilationDatabase::loadFromDirectory(Dir, Error);
 Entry.Path = std::string(Dir);
+Entry.CDB = tooling::CompilationDatabase::loadFromDirectory(Dir, Error);
+// Check for $src/build, the conventional CMake build root.
+// Probe existence first to avoid each plugin doing IO if it doesn't exist.
+if (!CompileCommandsDir && !Entry.CDB) {
+  llvm::SmallString<256> BuildDir = Dir;
+  llvm::sys::path::append(BuildDir, "build");
+  if (llvm::sys::fs::is_directory(BuildDir)) {
+vlog("Found candidate build directory {0}", BuildDir);
+Entry.CDB =
+tooling::CompilationDatabase::loadFromDirectory(BuildDir, Error);
+  }
+}
 if (Entry.CDB)
   log("Loaded compilation database from {0}", Dir);
   }

diff  --git 
a/clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp 
b/clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
index a6835a00b886..aaae58bacd8e 100644
--- a/clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
+++ b/clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
@@ -8,6 +8,7 @@
 
 #include "GlobalCompilationDatabase.h"
 
+#include "Matchers.h"
 #include "Path.h"
 #include "TestFS.h"
 #include "clang/Tooling/CompilationDatabase.h"
@@ -164,6 +165,47 @@ TEST_F(OverlayCDBTest, Adjustments) {
"-DFallback", "-DAdjust_baz.cc"));
 }
 
+// Allows placement of files for tests and cleans them up after.
+class ScratchFS {
+  llvm::SmallString<128> Root;
+
+public:
+  ScratchFS() {
+EXPECT_FALSE(llvm::sys::fs::createUniqueDirectory("clangd-cdb-test", Root))
+<< "Failed to create unique directory";
+  }
+
+  ~ScratchFS() {
+EXPECT_FALSE(llvm::sys::fs::remove_directories(Root))
+<< "Failed to cleanup " << Root;
+  }
+
+  llvm::StringRef root() const { return Root; }
+
+  void write(PathRef RelativePath, llvm::StringRef Contents) {
+std::string AbsPath = path(RelativePath);
+EXPECT_FALSE(llvm::sys::fs::create_directories(
+llvm::sys::path::parent_path(AbsPath)))
+<< "Failed to create directories for: " << AbsPath;
+
+std::error_code EC;
+llvm::raw_fd_ostream OS(AbsPath, EC);
+EXPECT_FALSE(EC) << "Failed to open " << AbsPath << " for writing";
+OS << llvm::formatv(Contents.data(),
+llvm::sys::path::convert_to_slash(Root));
+OS.close();
+
+EXPECT_FALSE(OS.has_error());
+  }
+
+  std::string path(PathRef RelativePath) const {
+llvm::SmallString<128> AbsPath(Root);
+llvm::sys::path::append(AbsPath, RelativePath);
+llvm::sys::path::native(AbsPath);
+return AbsPath.str().str();
+  }
+};
+
 TEST(GlobalCompilationDatabaseTest, DiscoveryWithNestedCDBs) {
   const char *const CDBOuter =
   R"cdb(
@@ -195,44 +237,9 @@ TEST(GlobalCompilationDatabaseTest, 
DiscoveryWithNestedCDBs) {
 }
   ]
   )cdb";
-  class CleaningFS {
-  public:
-llvm::SmallString<128> Root;
-
-CleaningFS() {
-  EXPECT_FALSE(
-  llvm::sys::fs::createUniqueDirectory("clangd-cdb-test", Root))
-  

[PATCH] D78843: [clangd] Remove unused bits after 67b2dbd5a33583. NFC

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: kbobyrev.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay, ilya-biryukov, mgorny.
Herald added a project: clang.

I think these are all safe to remove, but this doesn't build for me right now
(https://github.com/clangd/clangd/issues/351) so please verify...


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78843

Files:
  clang-tools-extra/clangd/Features.inc.in
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/Server.cpp


Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -11,7 +11,6 @@
 #include "index/remote/marshalling/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
-#include "llvm/LineEditor/LineEditor.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
Index: clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -1,5 +1,4 @@
 set(LLVM_LINK_COMPONENTS
-  LineEditor
   Support
   )
 add_clang_executable(clangd-index-server
Index: clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
===
--- clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
+++ clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
@@ -13,7 +13,7 @@
 #ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_REMOTE_MARSHALLING_H
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_REMOTE_MARSHALLING_H
 
-#include "Index.grpc.pb.h"
+#include "Index.pb.h"
 #include "index/Index.h"
 #include "llvm/Support/StringSaver.h"
 
Index: clang-tools-extra/clangd/index/remote/Client.cpp
===
--- clang-tools-extra/clangd/index/remote/Client.cpp
+++ clang-tools-extra/clangd/index/remote/Client.cpp
@@ -14,7 +14,6 @@
 #include "Trace.h"
 #include "index/Serialization.h"
 #include "marshalling/Marshalling.h"
-#include "llvm/Support/YAMLTraits.h"
 
 namespace clang {
 namespace clangd {
Index: clang-tools-extra/clangd/Features.inc.in
===
--- clang-tools-extra/clangd/Features.inc.in
+++ clang-tools-extra/clangd/Features.inc.in
@@ -1,2 +1 @@
 #define CLANGD_BUILD_XPC @CLANGD_BUILD_XPC@
-#define CLANGD_ENABLE_REMOTE @CLANGD_ENABLE_REMOTE@


Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -11,7 +11,6 @@
 #include "index/remote/marshalling/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
-#include "llvm/LineEditor/LineEditor.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
Index: clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
@@ -1,5 +1,4 @@
 set(LLVM_LINK_COMPONENTS
-  LineEditor
   Support
   )
 add_clang_executable(clangd-index-server
Index: clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
===
--- clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
+++ clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
@@ -13,7 +13,7 @@
 #ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_REMOTE_MARSHALLING_H
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_REMOTE_MARSHALLING_H
 
-#include "Index.grpc.pb.h"
+#include "Index.pb.h"
 #include "index/Index.h"
 #include "llvm/Support/StringSaver.h"
 
Index: clang-tools-extra/clangd/index/remote/Client.cpp
===
--- clang-tools-extra/clangd/index/remote/Client.cpp
+++ clang-tools-extra/clangd/index/remote/Client.cpp
@@ -14,7 +14,6 @@
 #include "Trace.h"
 #include "index/Serialization.h"
 #include "marshalling/Marshalling.h"
-#include "llvm/Support/YAMLTraits.h"
 
 namespace clang {
 namespace clangd {
Index: clang-tools-extra/clangd/Features.inc.in
===
--- clang-tools-extra/clangd/Features.inc.in
+++ 

[PATCH] D78760: Check a class has a definition before iterating over its base classes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

We should reject a definition of a class that has a non-dependent base class 
that's an incomplete type. We need non-dependent bases to be complete in order 
to be able to do name lookup into them when processing the template definition. 
(The C++ standard permits us to reject such cases but does not require it, 
because "a hypothetical instantiation of [the templated class] immediately 
following its definition would be ill-formed due to a construct that does not 
depend on a template parameter".)

Then there's a question of error recovery and AST invariants: should we permit 
a base specifier to name a non-dependent type that's not a complete class type? 
If so, we'll need to make sure that all code that iterates over base classes 
checks for this condition (I bet there are more cases than the two that you 
found). But tooling use cases probably do want to know that such base 
specifiers were written. So perhaps we should allow such base classes but mark 
the class definition as invalid if we find them -- in which case we would want 
something like this patch as part of the error recovery.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78760



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

[PATCH] D78629: [clangd] Look for compilation database in `build` subdirectory of parents.

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG226b045b1fe5: [clangd] Look for compilation database in 
`build` subdirectory of parents. (authored by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78629

Files:
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp

Index: clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
===
--- clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
+++ clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
@@ -8,6 +8,7 @@
 
 #include "GlobalCompilationDatabase.h"
 
+#include "Matchers.h"
 #include "Path.h"
 #include "TestFS.h"
 #include "clang/Tooling/CompilationDatabase.h"
@@ -164,6 +165,47 @@
"-DFallback", "-DAdjust_baz.cc"));
 }
 
+// Allows placement of files for tests and cleans them up after.
+class ScratchFS {
+  llvm::SmallString<128> Root;
+
+public:
+  ScratchFS() {
+EXPECT_FALSE(llvm::sys::fs::createUniqueDirectory("clangd-cdb-test", Root))
+<< "Failed to create unique directory";
+  }
+
+  ~ScratchFS() {
+EXPECT_FALSE(llvm::sys::fs::remove_directories(Root))
+<< "Failed to cleanup " << Root;
+  }
+
+  llvm::StringRef root() const { return Root; }
+
+  void write(PathRef RelativePath, llvm::StringRef Contents) {
+std::string AbsPath = path(RelativePath);
+EXPECT_FALSE(llvm::sys::fs::create_directories(
+llvm::sys::path::parent_path(AbsPath)))
+<< "Failed to create directories for: " << AbsPath;
+
+std::error_code EC;
+llvm::raw_fd_ostream OS(AbsPath, EC);
+EXPECT_FALSE(EC) << "Failed to open " << AbsPath << " for writing";
+OS << llvm::formatv(Contents.data(),
+llvm::sys::path::convert_to_slash(Root));
+OS.close();
+
+EXPECT_FALSE(OS.has_error());
+  }
+
+  std::string path(PathRef RelativePath) const {
+llvm::SmallString<128> AbsPath(Root);
+llvm::sys::path::append(AbsPath, RelativePath);
+llvm::sys::path::native(AbsPath);
+return AbsPath.str().str();
+  }
+};
+
 TEST(GlobalCompilationDatabaseTest, DiscoveryWithNestedCDBs) {
   const char *const CDBOuter =
   R"cdb(
@@ -195,44 +237,9 @@
 }
   ]
   )cdb";
-  class CleaningFS {
-  public:
-llvm::SmallString<128> Root;
-
-CleaningFS() {
-  EXPECT_FALSE(
-  llvm::sys::fs::createUniqueDirectory("clangd-cdb-test", Root))
-  << "Failed to create unique directory";
-}
-
-~CleaningFS() {
-  EXPECT_FALSE(llvm::sys::fs::remove_directories(Root))
-  << "Failed to cleanup " << Root;
-}
-
-void registerFile(PathRef RelativePath, llvm::StringRef Contents) {
-  llvm::SmallString<128> AbsPath(Root);
-  llvm::sys::path::append(AbsPath, RelativePath);
-
-  EXPECT_FALSE(llvm::sys::fs::create_directories(
-  llvm::sys::path::parent_path(AbsPath)))
-  << "Failed to create directories for: " << AbsPath;
-
-  std::error_code EC;
-  llvm::raw_fd_ostream OS(AbsPath, EC);
-  EXPECT_FALSE(EC) << "Failed to open " << AbsPath << " for writing";
-  OS << llvm::formatv(Contents.data(),
-  llvm::sys::path::convert_to_slash(Root));
-  OS.close();
-
-  EXPECT_FALSE(OS.has_error());
-}
-  };
-
-  CleaningFS FS;
-  FS.registerFile("compile_commands.json", CDBOuter);
-  FS.registerFile("build/compile_commands.json", CDBInner);
-  llvm::SmallString<128> File;
+  ScratchFS FS;
+  FS.write("compile_commands.json", CDBOuter);
+  FS.write("build/compile_commands.json", CDBInner);
 
   // Note that gen2.cc goes missing with our following model, not sure this
   // happens in practice though.
@@ -244,43 +251,50 @@
   DiscoveredFiles = Changes;
 });
 
-File = FS.Root;
-llvm::sys::path::append(File, "build", "..", "a.cc");
-DB.getCompileCommand(File.str());
+DB.getCompileCommand(FS.path("build/../a.cc"));
 EXPECT_THAT(DiscoveredFiles, UnorderedElementsAre(AllOf(
  EndsWith("a.cc"), Not(HasSubstr("..");
 DiscoveredFiles.clear();
 
-File = FS.Root;
-llvm::sys::path::append(File, "build", "gen.cc");
-DB.getCompileCommand(File.str());
+DB.getCompileCommand(FS.path("build/gen.cc"));
 EXPECT_THAT(DiscoveredFiles, UnorderedElementsAre(EndsWith("gen.cc")));
   }
 
   // With a custom compile commands dir.
   {
-DirectoryBasedGlobalCompilationDatabase DB(FS.Root.str().str());
+DirectoryBasedGlobalCompilationDatabase DB(FS.root().str());
 std::vector DiscoveredFiles;
 auto Sub =
 DB.watch([](const std::vector Changes) {
   DiscoveredFiles = Changes;
 });
 
-File = FS.Root;
-

[PATCH] D78842: [SVE][NFC] Use ScalableVectorType in CGBuiltin

[Christopher Tetreault via Phabricator via cfe-commits]

ctetreau created this revision.
Herald added subscribers: cfe-commits, psnobl, rkruppe, tschuett.
Herald added a reviewer: efriedma.
Herald added a project: clang.
ctetreau added a parent revision: D78841: [SVE] Add specialized overloads of 
VectorType::get.
ctetreau added reviewers: david-arm, fpetrogalli, kmclaughlin.

- Upgrade some usages of VectorType to use ScalableVectorType


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78842

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h

Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -3911,8 +3911,8 @@
   SmallVector getSVEOverloadTypes(SVETypeFlags TypeFlags,
ArrayRef Ops);
   llvm::Type *getEltType(SVETypeFlags TypeFlags);
-  llvm::VectorType *getSVEType(const SVETypeFlags );
-  llvm::VectorType *getSVEPredType(SVETypeFlags TypeFlags);
+  llvm::ScalableVectorType *getSVEType(const SVETypeFlags );
+  llvm::ScalableVectorType *getSVEPredType(SVETypeFlags TypeFlags);
   llvm::Value *EmitSVEDupX(llvm::Value *Scalar);
   llvm::Value *EmitSVEPredicateCast(llvm::Value *Pred, llvm::VectorType *VTy);
   llvm::Value *EmitSVEGatherLoad(SVETypeFlags TypeFlags,
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -7541,66 +7541,68 @@
 
 // Return the llvm predicate vector type corresponding to the specified element
 // TypeFlags.
-llvm::VectorType* CodeGenFunction::getSVEPredType(SVETypeFlags TypeFlags) {
+llvm::ScalableVectorType *
+CodeGenFunction::getSVEPredType(SVETypeFlags TypeFlags) {
   switch (TypeFlags.getEltType()) {
   default: llvm_unreachable("Unhandled SVETypeFlag!");
 
   case SVETypeFlags::EltTyInt8:
-return llvm::VectorType::get(Builder.getInt1Ty(), { 16, true });
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 16);
   case SVETypeFlags::EltTyInt16:
-return llvm::VectorType::get(Builder.getInt1Ty(), { 8, true });
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 8);
   case SVETypeFlags::EltTyInt32:
-return llvm::VectorType::get(Builder.getInt1Ty(), { 4, true });
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 4, );
   case SVETypeFlags::EltTyInt64:
-return llvm::VectorType::get(Builder.getInt1Ty(), { 2, true });
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 2);
 
   case SVETypeFlags::EltTyFloat16:
-return llvm::VectorType::get(Builder.getInt1Ty(), { 8, true });
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 8);
   case SVETypeFlags::EltTyFloat32:
-return llvm::VectorType::get(Builder.getInt1Ty(), { 4, true });
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 4);
   case SVETypeFlags::EltTyFloat64:
-return llvm::VectorType::get(Builder.getInt1Ty(), { 2, true });
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 2);
   }
 }
 
 // Return the llvm vector type corresponding to the specified element TypeFlags.
-llvm::VectorType *CodeGenFunction::getSVEType(const SVETypeFlags ) {
+llvm::ScalableVectorType *
+CodeGenFunction::getSVEType(const SVETypeFlags ) {
   switch (TypeFlags.getEltType()) {
   default:
 llvm_unreachable("Invalid SVETypeFlag!");
 
   case SVETypeFlags::EltTyInt8:
-return llvm::VectorType::get(Builder.getInt8Ty(), {16, true});
+return llvm::ScalableVectorType::get(Builder.getInt8Ty(), 16);
   case SVETypeFlags::EltTyInt16:
-return llvm::VectorType::get(Builder.getInt16Ty(), {8, true});
+return llvm::ScalableVectorType::get(Builder.getInt16Ty(), 8);
   case SVETypeFlags::EltTyInt32:
-return llvm::VectorType::get(Builder.getInt32Ty(), {4, true});
+return llvm::ScalableVectorType::get(Builder.getInt32Ty(), 4);
   case SVETypeFlags::EltTyInt64:
-return llvm::VectorType::get(Builder.getInt64Ty(), {2, true});
+return llvm::ScalableVectorType::get(Builder.getInt64Ty(), 2);
 
   case SVETypeFlags::EltTyFloat16:
-return llvm::VectorType::get(Builder.getHalfTy(), {8, true});
+return llvm::ScalableVectorType::get(Builder.getHalfTy(), 8);
   case SVETypeFlags::EltTyFloat32:
-return llvm::VectorType::get(Builder.getFloatTy(), {4, true});
+return llvm::ScalableVectorType::get(Builder.getFloatTy(), 4);
   case SVETypeFlags::EltTyFloat64:
-return llvm::VectorType::get(Builder.getDoubleTy(), {2, true});
+return llvm::ScalableVectorType::get(Builder.getDoubleTy(), 2);
 
   case SVETypeFlags::EltTyBool8:
-return llvm::VectorType::get(Builder.getInt1Ty(), {16, true});
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 16);
   case SVETypeFlags::EltTyBool16:
-return llvm::VectorType::get(Builder.getInt1Ty(), {8, true});
+return llvm::ScalableVectorType::get(Builder.getInt1Ty(), 

[PATCH] D76452: Use LLD by default for Android.

[Dan Albert via Phabricator via cfe-commits]

danalbert added a comment.

In D76452#2002981 , @danalbert wrote:

> In D76452#2002917 , @MaskRay wrote:
>
> > In D76452#2002875 , @danalbert 
> > wrote:
> >
> > > In D76452#2002856 , @int3 wrote:
> > >
> > > > Yes, I was referring to that question too :) I'm working on the new 
> > > > lld-macho implementation, under the `DarwinNew` flavor. I'm not sure if 
> > > > anything depends on the old `Darwin` flavor, which is why we haven't 
> > > > removed it yet, though we plan to do that once we get the new 
> > > > implementation to a more mature stage.
> > >
> > >
> > > Ah, gotcha :) Thanks! Will wait for @ruiu to chime in.
> >
> >
> > I vote for deleting the `#ifdef __APPLE__` chunk so we don't have to add 
> > more code to either clang or lld
> >  The code owner of the existing lld darwin has explicitly expressed that we 
> > can drop the existing `Darwin` flavor at any time.
>
>
> SGTM. Abandoning this. I'll send a patch to remove the LLD side shortly.


https://reviews.llvm.org/D78837


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76452



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

[PATCH] D78836: [clangd] Strip /showIncludes in clangd compile commands

[Sam McCall via Phabricator via cfe-commits]

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

Thanks!




Comment at: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp:82
 
+TEST(CommandMangler, StripShowIncludes) {
+  auto Mangler = CommandMangler::forTests();

It's useful to have this test to verify the behavior at the clangd level, but 
the arg adjuster is a separate library and also used in other contexts.

The unit-test for this arg-adjuster lives in 
clang/unittests/Tooling/ToolingTest.cpp around line 500. Could you add a test 
for the new behavior there, too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78836



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

[PATCH] D78836: [clangd] Strip /showIncludes in clangd compile commands

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added a comment.
Herald added a subscriber: ormris.

I did verify that clangd on vscode now works on Windows on the LLVM codebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78836



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

[clang] 65f5887 - [ObjC generics] Fix not inheriting type bounds in categories/extensions.

[Volodymyr Sapsai via cfe-commits]

Author: Volodymyr Sapsai
Date: 2020-04-24T16:32:28-07:00
New Revision: 65f58878e72a40d68ef3899c766846ee9ec7cf29

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

LOG: [ObjC generics] Fix not inheriting type bounds in categories/extensions.

When a category/extension doesn't repeat a type bound, corresponding
type parameter is substituted with `id` when used as a type argument. As
a result, in the added test case it was causing errors like

> type argument 'T' (aka 'id') does not satisfy the bound ('id') of 
> type parameter 'T'

We are already checking that type parameters should be consistent
everywhere (see `checkTypeParamListConsistency`) and update
`ObjCTypeParamDecl` to have correct underlying type. And when we use the
type parameter as a method return type or a method parameter type, it is
substituted to the bounded type. But when we use the type parameter as a
type argument, we check `ObjCTypeParamType` that wasn't updated and
remains `id`.

Fix by updating not only `ObjCTypeParamDecl` UnderlyingType but also
TypeForDecl as we use the underlying type to create a canonical type for
`ObjCTypeParamType` (see `ASTContext::getObjCTypeParamType`).

This is a different approach to fixing the issue. The previous one was
02c2ab3d8872416589bd1a6ca3dfb96ba373a3b9 which was reverted in
4c539e8da1b3de38a53ef3f7497f5c45a3243b61. The problem with the previous
approach was that `ObjCTypeParamType::desugar` was returning underlying
type for `ObjCTypeParamDecl` without applying any protocols stored in
`ObjCTypeParamType`. It caused inconsistencies in comparing types before
and after desugaring.

Re-applying after fixing intermittent test failures.

rdar://problem/54329242

Reviewed By: erik.pilkington

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

Added: 


Modified: 
clang/include/clang/AST/ASTContext.h
clang/include/clang/AST/Type.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/Type.cpp
clang/lib/Sema/SemaDeclObjC.cpp
clang/test/SemaObjC/parameterized_classes_collection_literal.m
clang/test/SemaObjC/parameterized_classes_subst.m

Removed: 




diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index dedbd857819d..82b8a51b9551 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -1459,6 +1459,8 @@ class ASTContext : public RefCountedBase {
 
   QualType getObjCTypeParamType(const ObjCTypeParamDecl *Decl,
 ArrayRef protocols) const;
+  void adjustObjCTypeParamBoundType(const ObjCTypeParamDecl *Orig,
+ObjCTypeParamDecl *New) const;
 
   bool ObjCObjectAdoptsQTypeProtocols(QualType QT, ObjCInterfaceDecl *Decl);
 

diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 322b14ce641a..cf746d9b947a 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -5605,6 +5605,7 @@ class ObjCTypeParamType : public Type,
   void Profile(llvm::FoldingSetNodeID );
   static void Profile(llvm::FoldingSetNodeID ,
   const ObjCTypeParamDecl *OTPDecl,
+  QualType CanonicalType,
   ArrayRef protocols);
 
   ObjCTypeParamDecl *getDecl() const { return OTPDecl; }

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index fffcfac60ca7..47834d41b919 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -4898,7 +4898,7 @@ ASTContext::getObjCTypeParamType(const ObjCTypeParamDecl 
*Decl,
  ArrayRef protocols) const 
{
   // Look in the folding set for an existing type.
   llvm::FoldingSetNodeID ID;
-  ObjCTypeParamType::Profile(ID, Decl, protocols);
+  ObjCTypeParamType::Profile(ID, Decl, Decl->getUnderlyingType(), protocols);
   void *InsertPos = nullptr;
   if (ObjCTypeParamType *TypeParam =
   ObjCTypeParamTypes.FindNodeOrInsertPos(ID, InsertPos))
@@ -4924,6 +4924,17 @@ ASTContext::getObjCTypeParamType(const ObjCTypeParamDecl 
*Decl,
   return QualType(newType, 0);
 }
 
+void ASTContext::adjustObjCTypeParamBoundType(const ObjCTypeParamDecl *Orig,
+  ObjCTypeParamDecl *New) const {
+  New->setTypeSourceInfo(getTrivialTypeSourceInfo(Orig->getUnderlyingType()));
+  // Update TypeForDecl after updating TypeSourceInfo.
+  auto NewTypeParamTy = cast(New->getTypeForDecl());
+  SmallVector protocols;
+  protocols.append(NewTypeParamTy->qual_begin(), NewTypeParamTy->qual_end());
+  QualType UpdatedTy = getObjCTypeParamType(New, protocols);
+  New->setTypeForDecl(UpdatedTy.getTypePtr());
+}
+
 /// ObjCObjectAdoptsQTypeProtocols - Checks that protocols in IC's
 /// protocol list adopt all protocols in QT's 

[PATCH] D76452: Use LLD by default for Android.

[Dan Albert via Phabricator via cfe-commits]

danalbert abandoned this revision.
danalbert added a comment.

In D76452#2002917 , @MaskRay wrote:

> In D76452#2002875 , @danalbert wrote:
>
> > In D76452#2002856 , @int3 wrote:
> >
> > > Yes, I was referring to that question too :) I'm working on the new 
> > > lld-macho implementation, under the `DarwinNew` flavor. I'm not sure if 
> > > anything depends on the old `Darwin` flavor, which is why we haven't 
> > > removed it yet, though we plan to do that once we get the new 
> > > implementation to a more mature stage.
> >
> >
> > Ah, gotcha :) Thanks! Will wait for @ruiu to chime in.
>
>
> I vote for deleting the `#ifdef __APPLE__` chunk so we don't have to add more 
> code to either clang or lld
>  The code owner of the existing lld darwin has explicitly expressed that we 
> can drop the existing `Darwin` flavor at any time.


SGTM. Abandoning this. I'll send a patch to remove the LLD side shortly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76452



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

[PATCH] D78836: [clangd] Strip /showIncludes in clangd compile commandsIn command lines with /showIncludes, clangd would output includes to stdout, breaking clients.

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks created this revision.
aeubanks added reviewers: sammccall, kadircet.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Fixes https://github.com/clangd/clangd/issues/322.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78836

Files:
  clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
  clang/lib/Tooling/ArgumentsAdjusters.cpp


Index: clang/lib/Tooling/ArgumentsAdjusters.cpp
===
--- clang/lib/Tooling/ArgumentsAdjusters.cpp
+++ clang/lib/Tooling/ArgumentsAdjusters.cpp
@@ -98,7 +98,7 @@
   StringRef Arg = Args[i];
   // All dependency-file options begin with -M. These include -MM,
   // -MF, -MG, -MP, -MT, -MQ, -MD, and -MMD.
-  if (!Arg.startswith("-M")) {
+  if (!Arg.startswith("-M") && Arg != "/showIncludes") {
 AdjustedArgs.push_back(Args[i]);
 continue;
   }
Index: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
===
--- clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
+++ clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
@@ -79,6 +79,13 @@
 EXPECT_THAT(Cmd, Not(Contains(Stripped)));
 }
 
+TEST(CommandMangler, StripShowIncludes) {
+  auto Mangler = CommandMangler::forTests();
+  std::vector Cmd = {"clang-cl", "/showIncludes", "foo.cc"};
+  Mangler.adjust(Cmd);
+  EXPECT_THAT(Cmd, Not(Contains("/showIncludes")));
+}
+
 TEST(CommandMangler, ClangPath) {
   auto Mangler = CommandMangler::forTests();
   Mangler.ClangPath = testPath("fake/clang");


Index: clang/lib/Tooling/ArgumentsAdjusters.cpp
===
--- clang/lib/Tooling/ArgumentsAdjusters.cpp
+++ clang/lib/Tooling/ArgumentsAdjusters.cpp
@@ -98,7 +98,7 @@
   StringRef Arg = Args[i];
   // All dependency-file options begin with -M. These include -MM,
   // -MF, -MG, -MP, -MT, -MQ, -MD, and -MMD.
-  if (!Arg.startswith("-M")) {
+  if (!Arg.startswith("-M") && Arg != "/showIncludes") {
 AdjustedArgs.push_back(Args[i]);
 continue;
   }
Index: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
===
--- clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
+++ clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
@@ -79,6 +79,13 @@
 EXPECT_THAT(Cmd, Not(Contains(Stripped)));
 }
 
+TEST(CommandMangler, StripShowIncludes) {
+  auto Mangler = CommandMangler::forTests();
+  std::vector Cmd = {"clang-cl", "/showIncludes", "foo.cc"};
+  Mangler.adjust(Cmd);
+  EXPECT_THAT(Cmd, Not(Contains("/showIncludes")));
+}
+
 TEST(CommandMangler, ClangPath) {
   auto Mangler = CommandMangler::forTests();
   Mangler.ClangPath = testPath("fake/clang");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78762: build: use `find_package(Python3)` if available

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd updated this revision to Diff 260010.
compnerd added a comment.

Add missed case of `PYTHON_EXECUTABLE`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762

Files:
  clang-tools-extra/test/lit.site.cfg.py.in
  clang/CMakeLists.txt
  clang/bindings/python/tests/CMakeLists.txt
  clang/test/lit.site.cfg.py.in
  clang/utils/perf-training/CMakeLists.txt
  clang/utils/perf-training/lit.site.cfg.in
  clang/utils/perf-training/order-files.lit.site.cfg.in
  llvm/CMakeLists.txt
  llvm/cmake/config-ix.cmake
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/lit.site.cfg.py.in
  llvm/tools/llvm-shlib/CMakeLists.txt

Index: llvm/tools/llvm-shlib/CMakeLists.txt
===
--- llvm/tools/llvm-shlib/CMakeLists.txt
+++ llvm/tools/llvm-shlib/CMakeLists.txt
@@ -164,7 +164,7 @@
   endif()
 
   add_custom_command(OUTPUT ${LLVM_EXPORTED_SYMBOL_FILE}
-COMMAND ${PYTHON_EXECUTABLE} ${GEN_SCRIPT} --libsfile ${LIBSFILE} ${GEN_UNDERSCORE} --nm "${llvm_nm}" -o ${LLVM_EXPORTED_SYMBOL_FILE}
+COMMAND "${Python3_EXECUTABLE}" ${GEN_SCRIPT} --libsfile ${LIBSFILE} ${GEN_UNDERSCORE} --nm "${llvm_nm}" -o ${LLVM_EXPORTED_SYMBOL_FILE}
 DEPENDS ${LIB_NAMES} ${llvm_nm_target}
 COMMENT "Generating export list for LLVM-C"
 VERBATIM )
Index: llvm/test/lit.site.cfg.py.in
===
--- llvm/test/lit.site.cfg.py.in
+++ llvm/test/lit.site.cfg.py.in
@@ -12,7 +12,7 @@
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
 config.lit_tools_dir = path(r"@LLVM_LIT_TOOLS_DIR@")
-config.python_executable = "@PYTHON_EXECUTABLE@"
+config.python_executable = "@Python3_EXECUTABLE@"
 config.gold_executable = "@GOLD_EXECUTABLE@"
 config.ld64_executable = "@LD64_EXECUTABLE@"
 config.ocamlfind_executable = "@OCAMLFIND@"
Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -117,7 +117,7 @@
 set(native_export_file "${target_name}.def")
 
 add_custom_command(OUTPUT ${native_export_file}
-  COMMAND ${PYTHON_EXECUTABLE} -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))"
+  COMMAND "${Python3_EXECUTABLE}" -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))"
 < ${export_file} > ${native_export_file}
   DEPENDS ${export_file}
   VERBATIM
@@ -1001,7 +1001,7 @@
   set(mangling itanium)
 endif()
 add_custom_command(OUTPUT ${exported_symbol_file}
-   COMMAND ${PYTHON_EXECUTABLE} ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file}
+   COMMAND "${Python3_EXECUTABLE}" ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file}
WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR}
DEPENDS ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py ${static_libs}
VERBATIM
@@ -1402,7 +1402,7 @@
   # empty list entries. So escape the ;s in the list and do the splitting
   # ourselves. cmake has no relpath function, so use Python for that.
   string(REPLACE ";" "\\;" pathlist_escaped "${pathlist}")
-  execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "\n
+  execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "\n
 import os, sys\n
 base = sys.argv[1]
 def haslink(p):\n
@@ -1477,7 +1477,6 @@
   # SHLIBDIR points the build tree.
   string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" SHLIBDIR "${LLVM_SHLIB_OUTPUT_INTDIR}")
 
-  set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE})
   # FIXME: "ENABLE_SHARED" doesn't make sense, since it is used just for
   # plugins. We may rename it.
   if(LLVM_ENABLE_PLUGINS)
@@ -1635,7 +1634,7 @@
 ALLOW_EXTERNAL
 )
 
-  set(LIT_COMMAND "${PYTHON_EXECUTABLE};${lit_base_dir}/${lit_file_name}")
+  set(LIT_COMMAND "${Python3_EXECUTABLE};${lit_base_dir}/${lit_file_name}")
   list(APPEND LIT_COMMAND ${LIT_ARGS})
   foreach(param ${ARG_PARAMS})
 list(APPEND LIT_COMMAND --param ${param})
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -639,7 +639,7 @@
 return()
   endif()
 
-  execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "import ${module}"
+  execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "import ${module}"
 RESULT_VARIABLE status
 ERROR_QUIET)
 
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -672,16 +672,38 @@
 
 include(HandleLLVMOptions)
 
-include(FindPythonInterp)
-if( NOT PYTHONINTERP_FOUND )
-  message(FATAL_ERROR
-"Unable to find Python interpreter, required 

[PATCH] D76452: Use LLD by default for Android.

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D76452#2002875 , @danalbert wrote:

> In D76452#2002856 , @int3 wrote:
>
> > Yes, I was referring to that question too :) I'm working on the new 
> > lld-macho implementation, under the `DarwinNew` flavor. I'm not sure if 
> > anything depends on the old `Darwin` flavor, which is why we haven't 
> > removed it yet, though we plan to do that once we get the new 
> > implementation to a more mature stage.
>
>
> Ah, gotcha :) Thanks! Will wait for @ruiu to chime in.


I vote for deleting the `#ifdef __APPLE__` chunk so we don't have to add more 
code to either clang or lld
The code owner of the existing lld darwin has explicitly expressed that we can 
drop the existing `Darwin` flavor at any time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76452



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

[PATCH] D76452: Use LLD by default for Android.

[Dan Albert via Phabricator via cfe-commits]

danalbert added a comment.

In D76452#2002856 , @int3 wrote:

> Yes, I was referring to that question too :) I'm working on the new lld-macho 
> implementation, under the `DarwinNew` flavor. I'm not sure if anything 
> depends on the old `Darwin` flavor, which is why we haven't removed it yet, 
> though we plan to do that once we get the new implementation to a more mature 
> stage.


Ah, gotcha :) Thanks! Will wait for @ruiu to chime in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76452



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Andrew via Phabricator via cfe-commits]

browneee updated this revision to Diff 260006.
browneee marked 4 inline comments as done.
browneee added a comment.

- Change SizeTypeMax to a static constexpr function.
- Fix comment typos.
- Add comment to alert others to possible performance loss if that function is 
moved to the header.

@nikic: Thank you for detecting, analyzing, and solving the performance 
regression!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621

Files:
  llvm/include/llvm/ADT/SmallVector.h
  llvm/lib/Support/SmallVector.cpp

Index: llvm/lib/Support/SmallVector.cpp
===
--- llvm/lib/Support/SmallVector.cpp
+++ llvm/lib/Support/SmallVector.cpp
@@ -37,24 +37,30 @@
   sizeof(unsigned) * 2 + sizeof(void *) * 2,
   "wasted space in SmallVector size 1");
 
-/// grow_pod - This is an implementation of the grow() method which only works
-/// on POD-like datatypes and is out of line to reduce code duplication.
-/// This function will report a fatal error if it cannot increase capacity.
-void SmallVectorBase::grow_pod(void *FirstEl, size_t MinCapacity,
-   size_t TSize) {
-  // Ensure we can fit the new capacity in 32 bits.
-  if (MinCapacity > UINT32_MAX)
+static_assert(sizeof(SmallVector) ==
+  sizeof(void *) * 2 + sizeof(void *),
+  "1 byte elements have word-sized type for size and capacity");
+
+// Note: Moving this function into the header may cause performance regression.
+template 
+void SmallVectorBase::grow_pod(void *FirstEl, size_t MinCapacity,
+   size_t TSize) {
+  // Ensure we can fit the new capacity.
+  // This is only going to be applicable when the capacity is 32 bit.
+  if (MinCapacity > SizeTypeMax())
 report_bad_alloc_error("SmallVector capacity overflow during allocation");
 
   // Ensure we can meet the guarantee of space for at least one more element.
   // The above check alone will not catch the case where grow is called with a
   // default MinCapacity of 0, but the current capacity cannot be increased.
-  if (capacity() == size_t(UINT32_MAX))
+  // This is only going to be applicable when the capacity is 32 bit.
+  if (capacity() == SizeTypeMax())
 report_bad_alloc_error("SmallVector capacity unable to grow");
 
+  // In theory 2*capacity can overflow if the capacity is 64 bit, but the
+  // original capacity would never be large enough for this to be a problem.
   size_t NewCapacity = 2 * capacity() + 1; // Always grow.
-  NewCapacity =
-  std::min(std::max(NewCapacity, MinCapacity), size_t(UINT32_MAX));
+  NewCapacity = std::min(std::max(NewCapacity, MinCapacity), SizeTypeMax());
 
   void *NewElts;
   if (BeginX == FirstEl) {
@@ -70,3 +76,6 @@
   this->BeginX = NewElts;
   this->Capacity = NewCapacity;
 }
+
+template class llvm::SmallVectorBase;
+template class llvm::SmallVectorBase;
Index: llvm/include/llvm/ADT/SmallVector.h
===
--- llvm/include/llvm/ADT/SmallVector.h
+++ llvm/include/llvm/ADT/SmallVector.h
@@ -16,10 +16,10 @@
 #include "llvm/ADT/iterator_range.h"
 #include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemAlloc.h"
 #include "llvm/Support/type_traits.h"
-#include "llvm/Support/ErrorHandling.h"
 #include 
 #include 
 #include 
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,11 +35,23 @@
 
 namespace llvm {
 
-/// This is all the non-templated stuff common to all SmallVectors.
-class SmallVectorBase {
+/// This is all the stuff common to all SmallVectors.
+///
+/// The template parameter specifies the type which should be used to hold the
+/// Size and Capacity of the SmallVector, so it can be adjusted.
+/// Using 32 bit size is desirable to shink the size of the SmallVector.
+/// Using 64 bit size is desirable for cases like SmallVector, where a
+/// 32 bit size would limit the vector to ~4GB. SmallVectors are used for
+/// buffering bitcode output - which can exceed 4GB.
+template  class SmallVectorBase {
 protected:
   void *BeginX;
-  unsigned Size = 0, Capacity;
+  Size_T Size = 0, Capacity;
+
+  /// The maximum value of the Size_T used.
+  static constexpr size_t SizeTypeMax() {
+return std::numeric_limits::max();
+  }
 
   SmallVectorBase() = delete;
   SmallVectorBase(void *FirstEl, size_t TotalCapacity)
@@ -70,9 +83,13 @@
   }
 };
 
+template 
+using SmallVectorSizeType =
+typename std::conditional::type;
+
 /// Figure out the offset of the first element.
 template  struct SmallVectorAlignmentAndSize {
-  AlignedCharArrayUnion Base;
+  AlignedCharArrayUnion>> Base;
   AlignedCharArrayUnion FirstEl;
 };
 
@@ -80,7 +97,10 @@
 /// the type T is a POD. The extra dummy 

[PATCH] D76452: Use LLD by default for Android.

[Jez Ng via Phabricator via cfe-commits]

int3 added a comment.

Yes, I was referring to that question too :) I'm working on the new lld-macho 
implementation, under the `DarwinNew` flavor. I'm not sure if anything depends 
on the old `Darwin` flavor, which is why we haven't removed it yet, though we 
plan to do that once we get the new implementation to a more mature stage.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76452



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

[PATCH] D77836: [Attribute] Fix noderef attribute false-negatives

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaCast.cpp:734
 void CastOperation::CheckDynamicCast() {
+  CheckNoDerefRAII noderef_check(*this);
+

Please use UpperCamelCase for local variables.



Comment at: clang/lib/Sema/SemaCast.cpp:2557-2558
   return;
+CheckNoDeref(Self, SrcExpr.get()->getType(), ResultType,
+ OpRange.getBegin());
   }

Should we be checking this for a C-style cast?  You previously said  you were 
going to turn off the checks for C-style casts. Did you change your mind on 
that?



Comment at: clang/lib/Sema/SemaCast.cpp:2982
 
+  CheckNoDeref(*this, Op.SrcExpr.get()->getType(), Op.ResultType, LPLoc);
+

As above, should we be checking this for a C-style cast? (It also looks like 
we're doing this check twice in C++.)



Comment at: clang/lib/Sema/SemaInit.cpp:8182-8184
+// Do not check static casts here because they are checked earlier
+// in Sema::ActOnCXXNamedCast()
+if (!Kind.isStaticCast()) {

leonardchan wrote:
> leonardchan wrote:
> > rsmith wrote:
> > > Are there any `static_cast` cases that don't get here? I'm also a little 
> > > surprised that `static_cast` would get here but the `static_cast` 
> > > interpretation of a C-style or functional cast would not.
> > I'll double check on this. The reason I added this here was because the 
> > cast in `static_cast_from_same_ptr_type()` triggered 2 of the 
> > `warn_noderef_to_dereferenceable_pointer` warnings and one of them was 
> > triggered here.
> Yeah it seems the `int *a = static_cast(x);` case in 
> `cast_from_void_ptr()` is an example of a static_cast that doesn't go through 
> here.
I see, this is only reached for the part of `static_cast` that considers 
implicit conversion sequences. OK.

I expect there's similar overlap for all the other kinds of cast too. Should we 
be suppressing this check for *all* casts, given that we perform the check in 
`SemaCast` instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77836



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

[PATCH] D78833: [clangd] Disable all dependency outputs

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet created this revision.
kadircet added a reviewer: sammccall.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Fixes https://github.com/clangd/clangd/issues/322


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78833

Files:
  clang-tools-extra/clangd/Compiler.cpp
  clang-tools-extra/clangd/test/dependency-output.test


Index: clang-tools-extra/clangd/test/dependency-output.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/dependency-output.test
@@ -0,0 +1,12 @@
+# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{"compilationDatabaseChanges":{"/clangd-test/foo.c":
+{"workingDirectory":"/clangd-test", "compilationCommand": ["clang", "-c", 
"-Xclang", "--show-includes", "-Xclang", "-sys-header-deps", "foo.c"]}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///foo.c","languageId":"cpp","version":1,"text":"int
 a;\n#include "}}}
+#CHECK-NOT: Note: including file
+---
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Compiler.cpp
===
--- clang-tools-extra/clangd/Compiler.cpp
+++ clang-tools-extra/clangd/Compiler.cpp
@@ -65,6 +65,15 @@
   CI->getFrontendOpts().DisableFree = false;
   CI->getLangOpts()->CommentOpts.ParseAllComments = true;
   CI->getLangOpts()->RetainCommentsFromSystemHeaders = true;
+
+  // Disable any dependency outputting, we don't want to generate files or 
write
+  // to stdout/stderr.
+  CI->getDependencyOutputOpts().ShowIncludesDest =
+  ShowIncludesDestination::None;
+  CI->getDependencyOutputOpts().OutputFile.clear();
+  CI->getDependencyOutputOpts().HeaderIncludeOutputFile.clear();
+  CI->getDependencyOutputOpts().DOTOutputFile.clear();
+  CI->getDependencyOutputOpts().ModuleDependencyOutputDir.clear();
   return CI;
 }
 


Index: clang-tools-extra/clangd/test/dependency-output.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/dependency-output.test
@@ -0,0 +1,12 @@
+# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{"compilationDatabaseChanges":{"/clangd-test/foo.c":
+{"workingDirectory":"/clangd-test", "compilationCommand": ["clang", "-c", "-Xclang", "--show-includes", "-Xclang", "-sys-header-deps", "foo.c"]}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///foo.c","languageId":"cpp","version":1,"text":"int a;\n#include "}}}
+#CHECK-NOT: Note: including file
+---
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Compiler.cpp
===
--- clang-tools-extra/clangd/Compiler.cpp
+++ clang-tools-extra/clangd/Compiler.cpp
@@ -65,6 +65,15 @@
   CI->getFrontendOpts().DisableFree = false;
   CI->getLangOpts()->CommentOpts.ParseAllComments = true;
   CI->getLangOpts()->RetainCommentsFromSystemHeaders = true;
+
+  // Disable any dependency outputting, we don't want to generate files or write
+  // to stdout/stderr.
+  CI->getDependencyOutputOpts().ShowIncludesDest =
+  ShowIncludesDestination::None;
+  CI->getDependencyOutputOpts().OutputFile.clear();
+  CI->getDependencyOutputOpts().HeaderIncludeOutputFile.clear();
+  CI->getDependencyOutputOpts().DOTOutputFile.clear();
+  CI->getDependencyOutputOpts().ModuleDependencyOutputDir.clear();
   return CI;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

Thanks, I plan to submit this on Monday and then make sure the patches on the 
clang side align with the draft.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76612



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/include/llvm/ADT/SmallVector.h:84
 
+template  const size_t SmallVectorBase::SizeTypeMax;
+

dblaikie wrote:
> nikic wrote:
> > Is this needed? I don't think it makes a lot of sense to allow odr-use of 
> > `SizeTypeMax`. As it's a protected member, it's only used in the 
> > SmallVector implementation, where we control how it is used.
> It's used as a parameter to std::min, so it's already odr used & I'd rather 
> not leave it as a trap to walk around even if we addressed that issue.
> 
> I assume if it were a constexpr local in a protected inline function it 
> wouldn't hinder optimizations in any real way?
> It's used as a parameter to std::min, so it's already odr used & I'd rather 
> not leave it as a trap to walk around even if we addressed that issue.

Oh, right you are! In that case this seems fine :)

> I assume if it were a constexpr local in a protected inline function it 
> wouldn't hinder optimizations in any real way?

The change from constexpr function to constexpr static didn't change anything 
performance-wise, so either way works for me.

Another option is:

```
enum : size_t { SizeTypeMax = std::numeric_limits::max() };
```

Kind of sad that in C++14, using an enum is still the only "no nonsense" way to 
declare a constant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D76452: Use LLD by default for Android.

[Dan Albert via Phabricator via cfe-commits]

danalbert added a comment.

In D76452#2002620 , @int3 wrote:

> I don't think I have enough context here to answer the question, but I'm 
> pretty sure that change wouldn't affect what I'm working on


Sorry, wasn't referring to that question specifically, but the LLD one that 
@MaskRay CC'd you for a little further up.

> But hope @ruiu or @int3 can clarify that we can't get rid of the __APPLE__ 
> special case in:
> 
>   // lld/tools/lld/lld.cpp
>   static Flavor parseProgname(StringRef progname) {
>   #if __APPLE__
> // Use Darwin driver for "ld" on Darwin.
> if (progname == "ld")
>   return Darwin;
>   #endif
>   
>   #if LLVM_ON_UNIX
> // Use GNU driver for "ld" on other Unix-like system.
> if (progname == "ld")
>   return Gnu;
>   #endif


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76452



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

[PATCH] D78762: build: use `find_package(Python3)` if available

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd updated this revision to Diff 259987.
compnerd added a comment.

Adjust clang-tools-extra at the same time


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762

Files:
  clang-tools-extra/test/lit.site.cfg.py.in
  clang/CMakeLists.txt
  clang/bindings/python/tests/CMakeLists.txt
  clang/test/lit.site.cfg.py.in
  clang/utils/perf-training/CMakeLists.txt
  clang/utils/perf-training/lit.site.cfg.in
  clang/utils/perf-training/order-files.lit.site.cfg.in
  llvm/CMakeLists.txt
  llvm/cmake/config-ix.cmake
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/lit.site.cfg.py.in

Index: llvm/test/lit.site.cfg.py.in
===
--- llvm/test/lit.site.cfg.py.in
+++ llvm/test/lit.site.cfg.py.in
@@ -12,7 +12,7 @@
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
 config.lit_tools_dir = path(r"@LLVM_LIT_TOOLS_DIR@")
-config.python_executable = "@PYTHON_EXECUTABLE@"
+config.python_executable = "@Python3_EXECUTABLE@"
 config.gold_executable = "@GOLD_EXECUTABLE@"
 config.ld64_executable = "@LD64_EXECUTABLE@"
 config.ocamlfind_executable = "@OCAMLFIND@"
Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -117,7 +117,7 @@
 set(native_export_file "${target_name}.def")
 
 add_custom_command(OUTPUT ${native_export_file}
-  COMMAND ${PYTHON_EXECUTABLE} -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))"
+  COMMAND "${Python3_EXECUTABLE}" -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))"
 < ${export_file} > ${native_export_file}
   DEPENDS ${export_file}
   VERBATIM
@@ -1001,7 +1001,7 @@
   set(mangling itanium)
 endif()
 add_custom_command(OUTPUT ${exported_symbol_file}
-   COMMAND ${PYTHON_EXECUTABLE} ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file}
+   COMMAND "${Python3_EXECUTABLE}" ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file}
WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR}
DEPENDS ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py ${static_libs}
VERBATIM
@@ -1402,7 +1402,7 @@
   # empty list entries. So escape the ;s in the list and do the splitting
   # ourselves. cmake has no relpath function, so use Python for that.
   string(REPLACE ";" "\\;" pathlist_escaped "${pathlist}")
-  execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "\n
+  execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "\n
 import os, sys\n
 base = sys.argv[1]
 def haslink(p):\n
@@ -1477,7 +1477,6 @@
   # SHLIBDIR points the build tree.
   string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" SHLIBDIR "${LLVM_SHLIB_OUTPUT_INTDIR}")
 
-  set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE})
   # FIXME: "ENABLE_SHARED" doesn't make sense, since it is used just for
   # plugins. We may rename it.
   if(LLVM_ENABLE_PLUGINS)
@@ -1635,7 +1634,7 @@
 ALLOW_EXTERNAL
 )
 
-  set(LIT_COMMAND "${PYTHON_EXECUTABLE};${lit_base_dir}/${lit_file_name}")
+  set(LIT_COMMAND "${Python3_EXECUTABLE};${lit_base_dir}/${lit_file_name}")
   list(APPEND LIT_COMMAND ${LIT_ARGS})
   foreach(param ${ARG_PARAMS})
 list(APPEND LIT_COMMAND --param ${param})
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -639,7 +639,7 @@
 return()
   endif()
 
-  execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "import ${module}"
+  execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "import ${module}"
 RESULT_VARIABLE status
 ERROR_QUIET)
 
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -672,16 +672,38 @@
 
 include(HandleLLVMOptions)
 
-include(FindPythonInterp)
-if( NOT PYTHONINTERP_FOUND )
-  message(FATAL_ERROR
-"Unable to find Python interpreter, required for builds and testing.
+if(CMAKE_VERSION VERSION_LESS 3.12)
+  include(FindPythonInterp)
+  if( NOT PYTHONINTERP_FOUND )
+message(FATAL_ERROR
+  "Unable to find Python interpreter, required for builds and testing.
 
-Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
-endif()
+  Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
+  endif()
+
+  if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
+message(FATAL_ERROR "Python 2.7 or newer is required")
+  endif()
 
-if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
-  message(FATAL_ERROR "Python 2.7 or newer is required")
+  add_executable(Python3::Interpreter IMPORTED)
+  

[PATCH] D77704: [gold] Add support for loading pass plugins

[Dominic Chen via Phabricator via cfe-commits]

ddcc added a comment.

In order to reload the gold plugin, I'm modifying the Clang driver to pass in 
our own path as a separate argument, which is the most generic approach. 
Another method would be to use e.g. `dladdr()` to grab our own path from one of 
our exported functions, but that method appears to be a glibc extension which 
isn't cross-platform.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77704



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

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D77954#2002580 , @tra wrote:

> Go ahead. I'll revert it if it breaks anything on our side.


Thanks. Done by b46b1a916d44216f0c70de55ae2123eb9de69027 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77954



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

[PATCH] D77704: [gold] Add support for loading pass plugins

[Dominic Chen via Phabricator via cfe-commits]

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

Thanks, seems to be working now for statically-built passes on a default LLVM 
build without `LLVM_LINK_LLVM_DYLIB`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77704



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

[PATCH] D77704: [gold] Add support for loading pass plugins

[Dominic Chen via Phabricator via cfe-commits]

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

Support statically-built passes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77704

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  llvm/tools/gold/CMakeLists.txt
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/gold/gold.exports


Index: llvm/tools/gold/gold.exports
===
--- llvm/tools/gold/gold.exports
+++ /dev/null
@@ -1 +0,0 @@
-onload
Index: llvm/tools/gold/gold-plugin.cpp
===
--- llvm/tools/gold/gold-plugin.cpp
+++ llvm/tools/gold/gold-plugin.cpp
@@ -23,6 +23,7 @@
 #include "llvm/Object/Error.h"
 #include "llvm/Support/CachePruning.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -207,6 +208,12 @@
   static std::string stats_file;
   // Asserts that LTO link has whole program visibility
   static bool whole_program_visibility = false;
+  // List of new PM pass plugins
+  static std::vector pass_plugins;
+  // Path to ourselves, and whether we have been reloaded for pass plugin 
symbol
+  // resolution
+  static std::string self;
+  static bool self_reloaded = false;
 
   // Optimization remarks filename, accepted passes and hotness options
   static std::string RemarksFilename;
@@ -300,6 +307,30 @@
   RemarksFormat = std::string(opt);
 } else if (opt.consume_front("stats-file=")) {
   stats_file = std::string(opt);
+} else if (opt.consume_front("self=")) {
+  // Store our own path, in case we need to be reloaded
+  self = std::string(opt);
+} else if (opt.consume_front("load=")) {
+  std::string Error, Path(opt);
+
+  // This plugin is loaded by gold under RTLD_LOCAL, which means that our
+  // LLVM symbols are not available to subsequent pass plugins. Since this
+  // will break statically-built pass plugins, we reload with RTLD_GLOBAL.
+  if (!self_reloaded) {
+if (self.size()) {
+  if (sys::DynamicLibrary::LoadLibraryPermanently(self.c_str(), 
))
+message(LDPL_ERROR, "Unable to reload LLVM gold plugin: %s",
+Error.c_str());
+  else
+self_reloaded = true;
+} else
+  message(LDPL_ERROR, "Unable to retrieve path to LLVM gold plugin!");
+  }
+
+  if (sys::DynamicLibrary::LoadLibraryPermanently(Path.c_str(), ))
+message(LDPL_ERROR, "Unable to load plugin: %s", Error.c_str());
+} else if (opt.consume_front("load-pass-plugin=")) {
+  pass_plugins.push_back(opt.data());
 } else {
   // Save this option to pass to the code generator.
   // ParseCommandLineOptions() expects argv[0] to be program name. Lazily
@@ -935,6 +966,8 @@
   Conf.UseNewPM = options::new_pass_manager;
   // Debug new pass manager if requested
   Conf.DebugPassManager = options::debug_pass_manager;
+  // Pass plugins to load
+  Conf.PassPlugins = std::move(options::pass_plugins);
 
   Conf.HasWholeProgramVisibility = options::whole_program_visibility;
 
Index: llvm/tools/gold/CMakeLists.txt
===
--- llvm/tools/gold/CMakeLists.txt
+++ llvm/tools/gold/CMakeLists.txt
@@ -1,5 +1,3 @@
-set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/gold.exports)
-
 if( LLVM_ENABLE_PIC AND LLVM_BINUTILS_INCDIR )
   include_directories( ${LLVM_BINUTILS_INCDIR} )
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -379,6 +379,9 @@
 Suffix,
 Plugin);
 CmdArgs.push_back(Args.MakeArgString(Plugin));
+
+// Pass in our own path in case we need to reload
+CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=self=") + Plugin));
   }
 
   // Try to pass driver level flags relevant to LTO code generation down to


Index: llvm/tools/gold/gold.exports
===
--- llvm/tools/gold/gold.exports
+++ /dev/null
@@ -1 +0,0 @@
-onload
Index: llvm/tools/gold/gold-plugin.cpp
===
--- llvm/tools/gold/gold-plugin.cpp
+++ llvm/tools/gold/gold-plugin.cpp
@@ -23,6 +23,7 @@
 #include "llvm/Object/Error.h"
 #include "llvm/Support/CachePruning.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -207,6 +208,12 @@
   static std::string 

[PATCH] D78655: [HIP] Let lambda be host device by default

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/test/CodeGenCUDA/lambda.cu:16-26
+template
+__global__ void g(F f) { f(); }
+
+template
+void h(F f) { g<<<1,1>>>(f); }
+
+__device__ int a;

yaxunl wrote:
> tra wrote:
> > The test example may not be doing what it's seemingly supposed to be doing:
> > https://cppinsights.io/s/3a5c42ff
> > 
> > `h()` gets a temporary host-side object which keeps the reference to `a` 
> > and that reference will actually point to the host-side shadow of the 
> > actual device-side `a`. When you get to execute `g` it's `this` may not be 
> > very usable on device side and thus `f.operator()` will probably not work.
> > 
> > Alas, we currently have no diagnostics for that kind of error.
> > 
> > Change it to a non-capturing lambda, perhaps?
> It works.
> 
> We need to think about this in device compilation. In device compilation, 
> global variable is a device variable, the lambda is a device host function, 
> therefore the lambda is accessing the real a, not the shadow.
> 
> In the host compilation, the lambda is not really called, therefore it is not 
> emitted.
> 
> I will update the lit test with these checks.
Clang manages to see through to the initializer of `a`, but I'm not sure how 
much we can rely on this.
In general, `f.operator()` for a capturing lambda needs to access captured 
variables via `this` which points to a temporary objects created and passed to 
`g` by the host. You can see it if you capture a local variable: 
https://godbolt.org/z/99389o

Anyways, it's an issue orthogonal to this patch. My concern is that tests are 
often used as an example of things that are OK to do, and capturing lambdas are 
a pretty big foot-shooting gun when used with CUDA. It's very easy to do wrong 
thing without compiler complaining about them.
While accessing `a` does work, it appears to do so by accident, rather than by 
design. 

I'm fairly confident that I can hide the initializer with sufficiently 
complicated code, force clang to access `a` via `this` and make everything fail 
at runtime. IMO, what we have here is a 'happens to work' situation. I do not 
want to call it 'guaranteed to work' without making sure that it always does.

In order to demonstrate that lambda is host/device, you do not need it to be a 
capturing lambda. You can make it call an overloaded function with host and 
device variants and verify that the lambda works on host and device sides.




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

https://reviews.llvm.org/D78655



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

[PATCH] D76452: Use LLD by default for Android.

[Jez Ng via Phabricator via cfe-commits]

int3 added a comment.

I don't think I have enough context here to answer the question, but I'm pretty 
sure that change wouldn't affect what I'm working on


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76452



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: llvm/include/llvm/ADT/SmallVector.h:84
 
+template  const size_t SmallVectorBase::SizeTypeMax;
+

nikic wrote:
> Is this needed? I don't think it makes a lot of sense to allow odr-use of 
> `SizeTypeMax`. As it's a protected member, it's only used in the SmallVector 
> implementation, where we control how it is used.
It's used as a parameter to std::min, so it's already odr used & I'd rather not 
leave it as a trap to walk around even if we addressed that issue.

I assume if it were a constexpr local in a protected inline function it 
wouldn't hinder optimizations in any real way?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[clang] b46b1a9 - recommit c77a4078e01033aa2206c31a579d217c8a07569b

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-04-24T16:53:18-04:00
New Revision: b46b1a916d44216f0c70de55ae2123eb9de69027

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

LOG: recommit c77a4078e01033aa2206c31a579d217c8a07569b

Added: 


Modified: 
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCUDA/function-overload.cu

Removed: 




diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index a32bc0c84c70..ecc4e7ee19fb 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -9374,16 +9374,22 @@ static Comparison compareEnableIfAttrs(const Sema , 
const FunctionDecl *Cand1,
   return Comparison::Equal;
 }
 
-static bool isBetterMultiversionCandidate(const OverloadCandidate ,
-  const OverloadCandidate ) {
+static Comparison
+isBetterMultiversionCandidate(const OverloadCandidate ,
+  const OverloadCandidate ) {
   if (!Cand1.Function || !Cand1.Function->isMultiVersion() || !Cand2.Function 
||
   !Cand2.Function->isMultiVersion())
-return false;
+return Comparison::Equal;
 
-  // If Cand1 is invalid, it cannot be a better match, if Cand2 is invalid, 
this
-  // is obviously better.
-  if (Cand1.Function->isInvalidDecl()) return false;
-  if (Cand2.Function->isInvalidDecl()) return true;
+  // If both are invalid, they are equal. If one of them is invalid, the other
+  // is better.
+  if (Cand1.Function->isInvalidDecl()) {
+if (Cand2.Function->isInvalidDecl())
+  return Comparison::Equal;
+return Comparison::Worse;
+  }
+  if (Cand2.Function->isInvalidDecl())
+return Comparison::Better;
 
   // If this is a cpu_dispatch/cpu_specific multiversion situation, prefer
   // cpu_dispatch, else arbitrarily based on the identifiers.
@@ -9393,16 +9399,18 @@ static bool isBetterMultiversionCandidate(const 
OverloadCandidate ,
   const auto *Cand2CPUSpec = Cand2.Function->getAttr();
 
   if (!Cand1CPUDisp && !Cand2CPUDisp && !Cand1CPUSpec && !Cand2CPUSpec)
-return false;
+return Comparison::Equal;
 
   if (Cand1CPUDisp && !Cand2CPUDisp)
-return true;
+return Comparison::Better;
   if (Cand2CPUDisp && !Cand1CPUDisp)
-return false;
+return Comparison::Worse;
 
   if (Cand1CPUSpec && Cand2CPUSpec) {
 if (Cand1CPUSpec->cpus_size() != Cand2CPUSpec->cpus_size())
-  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size();
+  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size()
+ ? Comparison::Better
+ : Comparison::Worse;
 
 std::pair
 FirstDiff = std::mismatch(
@@ -9415,7 +9423,9 @@ static bool isBetterMultiversionCandidate(const 
OverloadCandidate ,
 assert(FirstDiff.first != Cand1CPUSpec->cpus_end() &&
"Two 
diff erent cpu-specific versions should not have the same "
"identifier list, otherwise they'd be the same decl!");
-return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName();
+return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName()
+   ? Comparison::Better
+   : Comparison::Worse;
   }
   llvm_unreachable("No way to get here unless both had cpu_dispatch");
 }
@@ -9475,6 +9485,50 @@ bool clang::isBetterOverloadCandidate(
   else if (!Cand1.Viable)
 return false;
 
+  // [CUDA] A function with 'never' preference is marked not viable, therefore
+  // is never shown up here. The worst preference shown up here is 'wrong 
side',
+  // e.g. a host function called by a device host function in device
+  // compilation. This is valid AST as long as the host device function is not
+  // emitted, e.g. it is an inline function which is called only by a host
+  // function. A deferred diagnostic will be triggered if it is emitted.
+  // However a wrong-sided function is still a viable candidate here.
+  //
+  // If Cand1 can be emitted and Cand2 cannot be emitted in the current
+  // context, Cand1 is better than Cand2. If Cand1 can not be emitted and Cand2
+  // can be emitted, Cand1 is not better than Cand2. This rule should have
+  // precedence over other rules.
+  //
+  // If both Cand1 and Cand2 can be emitted, or neither can be emitted, then
+  // other rules should be used to determine which is better. This is because
+  // host/device based overloading resolution is mostly for determining
+  // viability of a function. If two functions are both viable, other factors
+  // should take precedence in preference, e.g. the standard-defined 
preferences
+  // like argument conversion ranks or enable_if partial-ordering. The
+  // preference for pass-object-size parameters is probably most similar to a
+  // type-based-overloading decision and so should take priority.
+  //
+  

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

Go ahead. I'll revert it if it breaks anything on our side.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77954



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Nikita Popov via Phabricator via cfe-commits]

nikic accepted this revision.
nikic added inline comments.



Comment at: llvm/include/llvm/ADT/SmallVector.h:19
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MathExtras.h"

Is this include still needed?



Comment at: llvm/include/llvm/ADT/SmallVector.h:84
 
+template  const size_t SmallVectorBase::SizeTypeMax;
+

Is this needed? I don't think it makes a lot of sense to allow odr-use of 
`SizeTypeMax`. As it's a protected member, it's only used in the SmallVector 
implementation, where we control how it is used.



Comment at: llvm/lib/Support/SmallVector.cpp:48
+  // Ensure we can fit the new capacity.
+  // This is only going to be applicable if the when the capacity is 32 bit.
+  if (MinCapacity > SizeTypeMax)

Nit: `if the when` => `if the` or `when`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D78812: [SVE][CodeGen] Fix legalisation for scalable types

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:738
+  *DAG.getContext(), IntermediateVT.getScalarType(), DestVectorNoElts,
+  ValueVT.isScalableVector());
   if (ValueVT != BuiltVectorTy) {

Can we use ElementCount here?



Comment at: llvm/lib/CodeGen/TargetLoweringBase.cpp:1429
+  while (NumElts > 1 &&
+ !isTypeLegal(EVT::getVectorVT(Context, EltTy, NumElts, IsScalable))) {
 NumElts >>= 1;

Can we use ElementCount here?



Comment at: llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll:107
+  ret  %div
+}

Maybe also worth adding a testcase for ``, assuming that 
doesn't expose anything really tricky.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78812



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

[PATCH] D78827: Add support for #pragma clang fp reassoc(on|off) -- floating point control of associative math transformations

[Melanie Blower via Phabricator via cfe-commits]

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

added an inline comment




Comment at: clang/include/clang/AST/Stmt.h:618
 // Only meaningful for floating point types.
-unsigned FPFeatures : 8;
+unsigned FPFeatures : 14;
   };

This correction belongs in the parent revision, i will move it there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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

[PATCH] D72841: Add support for pragma float_control, to control precision and exception behavior at the source level

[Melanie Blower via Phabricator via cfe-commits]

mibintc added a comment.

noted bug in an inline comment. i will upload a fix


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841



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

[PATCH] D78767: [Sema] Teach -Wcast-align to compute a more accurate alignment when the source expression has array subscript or pointer arithmetic operators

[Akira Hatanaka via Phabricator via cfe-commits]

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



Comment at: clang/lib/AST/ExprConstant.cpp:14844
+  if (auto *VD = Result.Base.dyn_cast())
+return Ctx.getDeclAlign(VD).alignmentAtOffset(Result.Offset);
+

rjmccall wrote:
> Does this do the right thing if `getDeclAlign` returns 0, or can that never 
> happen?
I looked at `getDeclAlign` and, as far as I can tell, it returns an alignment 
that is larger than 0.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78767



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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

[Alina Sbirlea via Phabricator via cfe-commits]

asbirlea added a comment.

I think that expanding the patch description will help motivate this and 
clarify the use-cases for which this is useful, and how it differentiates from 
`noinline`.
Perhaps include that the attribute aims to avoid merging identical calls so as 
to keep the separate debug-information for those calls, and that there is an 
asan usecase where having this attribute would be beneficial to avoid 
alternative work-arounds.
If you have a link to the feature request for this, include that in the 
description as well, or include the motivation behind it.

Note there are other LLVM passes (beside SimplifyCFG) that may need to check 
for this argument to prevent optimizations (e.g. LICM does instruction 
sinking/hoising, add check ~LICM.cpp:1092?).

Include a comment in the `clang/test/CodeGen/attr-nomerge.c` test on the 
expected outcome of the test. Something like:
"The attribute no-merge prevents the 3 bar() calls from being merged into one 
inside foo. Check that there are still 3 tail calls."


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

https://reviews.llvm.org/D78659



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

[PATCH] D78827: Add support for #pragma clang fp reassoc(on|off) -- floating point control of associative math transformations

[Melanie Blower via Phabricator via cfe-commits]

mibintc created this revision.
mibintc added reviewers: rjmccall, sepavloff, andrew.w.kaylor.
Herald added a project: clang.
mibintc marked an inline comment as done.
mibintc added a comment.

added an inline comment




Comment at: clang/include/clang/AST/Stmt.h:618
 // Only meaningful for floating point types.
-unsigned FPFeatures : 8;
+unsigned FPFeatures : 14;
   };

This correction belongs in the parent revision, i will move it there.


The folks at Intel who program FPGA would like to be able to control the 
FastMathFlag that governs reassociating operations at the source level using 
pragma's e.g.
#pragma clang fp reassoc(on) // allow reassociation of operations

This patch builds on reviews.llvm.org/D72841 

I just realized that I need to update the user manual to describe the syntax, 
so I owe you an update.  Hoping you will take a look


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78827

Files:
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/CodeGen/fp-reassoc-pragma-fails.cpp
  clang/test/CodeGen/fp-reassoc-pragma.cpp

Index: clang/test/CodeGen/fp-reassoc-pragma.cpp
===
--- /dev/null
+++ clang/test/CodeGen/fp-reassoc-pragma.cpp
@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -O3 -triple %itanium_abi_triple -emit-llvm -o - %s | FileCheck %s
+// Simple case
+float fp_reassoc_simple(float a, float b, float c) {
+// CHECK: _Z17fp_reassoc_simplefff
+// CHECK: %[[M:.+]] = fmul reassoc float %a, %b
+// CHECK-NEXT: fadd reassoc float %[[M]], %c
+#pragma clang fp reassoc(on)
+  return a * b + c;
+}
+
+// Reassoc pragma should only apply to its scope
+float fp_reassoc_scoped(float a, float b, float c) {
+  // CHECK: _Z17fp_reassoc_scopedfff
+  // CHECK: %[[M:.+]] = fmul float %a, %b
+  // CHECK-NEXT: fadd float %[[M]], %c
+  {
+#pragma clang fp reassoc(on)
+  }
+  return a * b + c;
+}
+
+// Reassoc pragma should apply to templates as well
+class Foo {};
+Foo operator+(Foo, Foo);
+template 
+T template_reassoc(T a, T b, T c) {
+#pragma clang fp reassoc(on)
+  return ((a + b) - c) + c;
+}
+
+float fp_reassoc_template(float a, float b, float c) {
+  // CHECK: _Z19fp_reassoc_templatefff
+  // CHECK: %[[A1:.+]] = fadd reassoc float %a, %b
+  // CHECK-NEXT: %[[A2:.+]] = fsub reassoc float %[[A1]], %c
+  // CHECK-NEXT: fadd reassoc float %[[A2]], %c
+  return template_reassoc(a, b, c);
+}
+
+// File Scoping should work across functions
+#pragma clang fp reassoc(on)
+float fp_file_scope_on(float a, float b, float c) {
+  // CHECK: _Z16fp_file_scope_onfff
+  // CHECK: %[[M1:.+]] = fmul reassoc float %a, %c
+  // CHECK-NEXT: %[[M2:.+]] = fmul reassoc float %b, %c
+  // CHECK-NEXT: fadd reassoc float %[[M1]], %[[M2]]
+  return (a * c) + (b * c);
+}
+
+// Inner pragma has precedence
+float fp_file_scope_stop(float a, float b, float c) {
+  // CHECK: _Z18fp_file_scope_stopfff
+  // CHECK: %[[A:.+]] = fadd reassoc float %a, %a
+  // CHECK: %[[M1:.+]] = fmul float %[[A]], %c
+  // CHECK-NEXT: %[[M2:.+]] = fmul float %b, %c
+  // CHECK-NEXT: fsub float %[[M1]], %[[M2]]
+  a = a + a;
+  {
+#pragma clang fp reassoc(off)
+return (a * c) - (b * c);
+  }
+}
+
+#pragma clang fp reassoc(off)
+float fp_reassoc_off(float a, float b, float c) {
+  // CHECK: _Z14fp_reassoc_of
+  // CHECK: %[[D1:.+]] = fdiv float %a, %c
+  // CHECK-NEXT: %[[D2:.+]] = fdiv float %b, %c
+  // CHECK-NEXT: fadd float %[[D1]], %[[D2]]
+  return (a / c) + (b / c);
+}
+
+// Takes latest flag
+float fp_reassoc_many(float a, float b, float c) {
+// CHECK: _Z15fp_reassoc_manyfff
+// CHECK: %[[D1:.+]] = fdiv reassoc float %a, %c
+// CHECK-NEXT: %[[D2:.+]] = fdiv reassoc float %b, %c
+// CHECK-NEXT: fadd reassoc float %[[D1]], %[[D2]]
+#pragma clang fp reassoc(off) reassoc(on)
+  return (a / c) + (b / c);
+}
+
+// Pragma does not propagate through called functions
+float helper_func(float a, float b, float c) { return a + b + c; }
+float fp_reassoc_call_helper(float a, float b, float c) {
+// CHECK: _Z22fp_reassoc_call_helperfff
+// CHECK: %[[S1:.+]] = fadd float %a, %b
+// CHECK-NEXT: fadd float %[[S1]], %c
+#pragma clang fp reassoc(on)
+  return helper_func(a, b, c);
+}
Index: clang/test/CodeGen/fp-reassoc-pragma-fails.cpp
===
--- /dev/null
+++ clang/test/CodeGen/fp-reassoc-pragma-fails.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+float fp_reassoc_fail(float a, float b) {
+  // CHECK-LABEL: fp_reassoc_fail
+  // expected-error@+2{{'#pragma clang fp' can only appear at file scope or at the start of a compound 

[PATCH] D78687: [Fuchsia] Build compiler-rt builtins for 32-bit x86

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG063128f97930: [Fuchsia] Build compiler-rt builtins for 
32-bit x86 (authored by phosek).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78687

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/lib/Basic/Targets.cpp


Index: clang/lib/Basic/Targets.cpp
===
--- clang/lib/Basic/Targets.cpp
+++ clang/lib/Basic/Targets.cpp
@@ -480,6 +480,8 @@
   return new OpenBSDI386TargetInfo(Triple, Opts);
 case llvm::Triple::FreeBSD:
   return new FreeBSDTargetInfo(Triple, Opts);
+case llvm::Triple::Fuchsia:
+  return new FuchsiaTargetInfo(Triple, Opts);
 case llvm::Triple::KFreeBSD:
   return new KFreeBSDTargetInfo(Triple, Opts);
 case llvm::Triple::Minix:
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -105,15 +105,16 @@
 
 if(FUCHSIA_SDK)
   set(FUCHSIA_aarch64_NAME arm64)
+  set(FUCHSIA_i386_NAME x64)
   set(FUCHSIA_x86_64_NAME x64)
   set(FUCHSIA_riscv64_NAME riscv64)
-  foreach(target x86_64;aarch64;riscv64)
+  foreach(target i386;x86_64;aarch64;riscv64)
 set(FUCHSIA_${target}_COMPILER_FLAGS "-I${FUCHSIA_SDK}/pkg/fdio/include")
 set(FUCHSIA_${target}_LINKER_FLAGS 
"-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
 set(FUCHSIA_${target}_SYSROOT 
"${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
   endforeach()
 
-  foreach(target x86_64;aarch64;riscv64)
+  foreach(target i386;x86_64;aarch64;riscv64)
 # Set the per-target builtins options.
 list(APPEND BUILTIN_TARGETS "${target}-unknown-fuchsia")
 set(BUILTINS_${target}-unknown-fuchsia_CMAKE_SYSTEM_NAME Fuchsia CACHE 
STRING "")


Index: clang/lib/Basic/Targets.cpp
===
--- clang/lib/Basic/Targets.cpp
+++ clang/lib/Basic/Targets.cpp
@@ -480,6 +480,8 @@
   return new OpenBSDI386TargetInfo(Triple, Opts);
 case llvm::Triple::FreeBSD:
   return new FreeBSDTargetInfo(Triple, Opts);
+case llvm::Triple::Fuchsia:
+  return new FuchsiaTargetInfo(Triple, Opts);
 case llvm::Triple::KFreeBSD:
   return new KFreeBSDTargetInfo(Triple, Opts);
 case llvm::Triple::Minix:
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -105,15 +105,16 @@
 
 if(FUCHSIA_SDK)
   set(FUCHSIA_aarch64_NAME arm64)
+  set(FUCHSIA_i386_NAME x64)
   set(FUCHSIA_x86_64_NAME x64)
   set(FUCHSIA_riscv64_NAME riscv64)
-  foreach(target x86_64;aarch64;riscv64)
+  foreach(target i386;x86_64;aarch64;riscv64)
 set(FUCHSIA_${target}_COMPILER_FLAGS "-I${FUCHSIA_SDK}/pkg/fdio/include")
 set(FUCHSIA_${target}_LINKER_FLAGS "-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
 set(FUCHSIA_${target}_SYSROOT "${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
   endforeach()
 
-  foreach(target x86_64;aarch64;riscv64)
+  foreach(target i386;x86_64;aarch64;riscv64)
 # Set the per-target builtins options.
 list(APPEND BUILTIN_TARGETS "${target}-unknown-fuchsia")
 set(BUILTINS_${target}-unknown-fuchsia_CMAKE_SYSTEM_NAME Fuchsia CACHE STRING "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc77a4078e010: [CUDA][HIP] Fix host/device based overload 
resolution (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77954

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCUDA/function-overload.cu

Index: clang/test/SemaCUDA/function-overload.cu
===
--- clang/test/SemaCUDA/function-overload.cu
+++ clang/test/SemaCUDA/function-overload.cu
@@ -331,9 +331,6 @@
 // If we have a mix of HD and H-only or D-only candidates in the overload set,
 // normal C++ overload resolution rules apply first.
 template  TemplateReturnTy template_vs_hd_function(T arg)
-#ifdef __CUDA_ARCH__
-//expected-note@-2 {{declared here}}
-#endif
 {
   return TemplateReturnTy();
 }
@@ -342,11 +339,13 @@
 }
 
 __host__ __device__ void test_host_device_calls_hd_template() {
-  HostDeviceReturnTy ret1 = template_vs_hd_function(1.0f);
-  TemplateReturnTy ret2 = template_vs_hd_function(1);
 #ifdef __CUDA_ARCH__
-  // expected-error@-2 {{reference to __host__ function 'template_vs_hd_function' in __host__ __device__ function}}
+  typedef HostDeviceReturnTy ExpectedReturnTy;
+#else
+  typedef TemplateReturnTy ExpectedReturnTy;
 #endif
+  HostDeviceReturnTy ret1 = template_vs_hd_function(1.0f);
+  ExpectedReturnTy ret2 = template_vs_hd_function(1);
 }
 
 __host__ void test_host_calls_hd_template() {
@@ -367,14 +366,14 @@
 __device__ DeviceReturnTy device_only_function(int arg) { return DeviceReturnTy(); }
 __device__ DeviceReturnTy2 device_only_function(float arg) { return DeviceReturnTy2(); }
 #ifndef __CUDA_ARCH__
-  // expected-note@-3 {{'device_only_function' declared here}}
-  // expected-note@-3 {{'device_only_function' declared here}}
+  // expected-note@-3 2{{'device_only_function' declared here}}
+  // expected-note@-3 2{{'device_only_function' declared here}}
 #endif
 __host__ HostReturnTy host_only_function(int arg) { return HostReturnTy(); }
 __host__ HostReturnTy2 host_only_function(float arg) { return HostReturnTy2(); }
 #ifdef __CUDA_ARCH__
-  // expected-note@-3 {{'host_only_function' declared here}}
-  // expected-note@-3 {{'host_only_function' declared here}}
+  // expected-note@-3 2{{'host_only_function' declared here}}
+  // expected-note@-3 2{{'host_only_function' declared here}}
 #endif
 
 __host__ __device__ void test_host_device_single_side_overloading() {
@@ -392,6 +391,37 @@
 #endif
 }
 
+// wrong-sided overloading should not cause diagnostic unless it is emitted.
+// This inline function is not emitted.
+inline __host__ __device__ void test_host_device_wrong_side_overloading_inline_no_diag() {
+  DeviceReturnTy ret1 = device_only_function(1);
+  DeviceReturnTy2 ret2 = device_only_function(1.0f);
+  HostReturnTy ret3 = host_only_function(1);
+  HostReturnTy2 ret4 = host_only_function(1.0f);
+}
+
+// wrong-sided overloading should cause diagnostic if it is emitted.
+// This inline function is emitted since it is called by an emitted function.
+inline __host__ __device__ void test_host_device_wrong_side_overloading_inline_diag() {
+  DeviceReturnTy ret1 = device_only_function(1);
+  DeviceReturnTy2 ret2 = device_only_function(1.0f);
+#ifndef __CUDA_ARCH__
+  // expected-error@-3 {{reference to __device__ function 'device_only_function' in __host__ __device__ function}}
+  // expected-error@-3 {{reference to __device__ function 'device_only_function' in __host__ __device__ function}}
+#endif
+  HostReturnTy ret3 = host_only_function(1);
+  HostReturnTy2 ret4 = host_only_function(1.0f);
+#ifdef __CUDA_ARCH__
+  // expected-error@-3 {{reference to __host__ function 'host_only_function' in __host__ __device__ function}}
+  // expected-error@-3 {{reference to __host__ function 'host_only_function' in __host__ __device__ function}}
+#endif
+}
+
+__host__ __device__ void test_host_device_wrong_side_overloading_inline_diag_caller() {
+  test_host_device_wrong_side_overloading_inline_diag();
+  // expected-note@-1 {{called by 'test_host_device_wrong_side_overloading_inline_diag_caller'}}
+}
+
 // Verify that we allow overloading function templates.
 template  __host__ T template_overload(const T ) { return a; };
 template  __device__ T template_overload(const T ) { return a; };
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -9374,16 +9374,22 @@
   return Comparison::Equal;
 }
 
-static bool isBetterMultiversionCandidate(const OverloadCandidate ,
-  const OverloadCandidate ) {
+static Comparison
+isBetterMultiversionCandidate(const OverloadCandidate ,
+  const OverloadCandidate ) {
   if (!Cand1.Function || 

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[David Blaikie via Phabricator via cfe-commits]

dblaikie accepted this revision.
dblaikie added a comment.

In D77621#2001099 , @dexonsmith wrote:

> In D77621#2000237 , @nikic wrote:
>
> > Okay, I'm basically fine with that, if it is our stance that SmallVector 
> > should always be preferred over std::vector. Not really related to this 
> > revision, but it would probably help to do some renaming/aliasing to 
> > facilitate that view. Right now, the number of `SmallVector` uses in 
> > LLVM is really small compared to the `std::vector` uses (100 vs 6000 
> > based on a not very accurate grep). I think part of that is in the name, 
> > and calling it `using Vector = SmallVector` and `using 
> > VectorImpl = SmallVectorImpl` would make it a lot more obvious that 
> > this is our preferred general purpose vector type, even if the stored data 
> > is not small.
>
>
> Those aliases SGTM.


I'd be slightly against, just because having a name that differs from the 
standard name only in case seems pretty subtle - that and momentum, we've had 
SmallVector around for a while & I think it's OK. I don't mind some places 
using std::vector either, though. Don't feel strongly enough that I'd outright 
stand against such an alias/change, but just expressing this amount of disfavor.

In D77621#2001378 , @nikic wrote:

> So tl;dr looks like as long as we keep `grow_pod` outside the header file, 
> this change seems to be approximately free in terms of compile-time and 
> memory usage both.


Awesome - thanks for looking into it!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D78655: [HIP] Let lambda be host device by default

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 259957.
yaxunl marked 2 inline comments as done.
yaxunl added a comment.

Fix typo


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

https://reviews.llvm.org/D78655

Files:
  clang/lib/Sema/SemaCUDA.cpp
  clang/test/CodeGenCUDA/lambda.cu
  clang/test/SemaCUDA/lambda.cu


Index: clang/test/SemaCUDA/lambda.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/lambda.cu
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify %s
+
+#include "Inputs/cuda.h"
+
+__device__ int a;
+
+int main(void) {
+  auto lambda_kernel = [&]__global__(){ a = 1;};
+  // expected-error@-1 {{kernel function 'operator()' must be a free function 
or static member function}}
+  lambda_kernel<<<1, 1>>>();
+  return 0;
+}
Index: clang/test/CodeGenCUDA/lambda.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/lambda.cu
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -x hip -emit-llvm -std=c++11 %s -o - \
+// RUN:   -triple x86_64-linux-gnu | FileCheck -check-prefix=HOST %s
+// RUN: %clang_cc1 -x hip -emit-llvm -std=c++11 %s -o - \
+// RUN:   -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN:   | FileCheck -check-prefix=DEV %s
+
+#include "Inputs/cuda.h"
+
+// Device side kernel name.
+// HOST: @[[KERN:[0-9]+]] = private unnamed_addr constant [22 x i8] 
c"_Z1gIZ4mainEUlvE_EvT_\00"
+
+// Template instantiation for h.
+// HOST-LABEL: define internal void @_Z1hIZ4mainEUlvE_EvT_
+
+// HOST-LABEL: define internal void @_Z16__device_stub__gIZ4mainEUlvE_EvT_
+
+// Check kernel is registered with correct device side kernel name.
+// HOST: @__hipRegisterFunction(i8** %0, i8* bitcast ({{.*}}@[[KERN]]
+
+// Check lambda is not emitted in host compilation.
+// HOST-NOT: define{{.*}}@_ZZ4mainENKUlvE_clEv
+
+// DEV: @a = addrspace(1) externally_initialized global i32 0
+
+// Check kernel is calling lambda function.
+// DEV-LABEL: define amdgpu_kernel void @_Z1gIZ4mainEUlvE_EvT_
+// DEV: call void @_ZZ4mainENKUlvE_clEv
+
+// Check lambda is emitted in device compilation and accessing device variable.
+// DEV-LABEL: define internal void @_ZZ4mainENKUlvE_clEv
+// DEV: store i32 1, i32* addrspacecast (i32 addrspace(1)* @a to i32*)
+template
+__global__ void g(F f) { f(); }
+
+template
+void h(F f) { g<<<1,1>>>(f); }
+
+__device__ int a;
+
+int main(void) {
+  h([&](){ a=1;});
+}
Index: clang/lib/Sema/SemaCUDA.cpp
===
--- clang/lib/Sema/SemaCUDA.cpp
+++ clang/lib/Sema/SemaCUDA.cpp
@@ -718,6 +718,11 @@
   FunctionDecl *CurFn = dyn_cast(CurContext);
   if (!CurFn)
 return;
+  if (getLangOpts().HIP) {
+Method->addAttr(CUDADeviceAttr::CreateImplicit(Context));
+Method->addAttr(CUDAHostAttr::CreateImplicit(Context));
+return;
+  }
   CUDAFunctionTarget Target = IdentifyCUDATarget(CurFn);
   if (Target == CFT_Global || Target == CFT_Device) {
 Method->addAttr(CUDADeviceAttr::CreateImplicit(Context));


Index: clang/test/SemaCUDA/lambda.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/lambda.cu
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify %s
+
+#include "Inputs/cuda.h"
+
+__device__ int a;
+
+int main(void) {
+  auto lambda_kernel = [&]__global__(){ a = 1;};
+  // expected-error@-1 {{kernel function 'operator()' must be a free function or static member function}}
+  lambda_kernel<<<1, 1>>>();
+  return 0;
+}
Index: clang/test/CodeGenCUDA/lambda.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/lambda.cu
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -x hip -emit-llvm -std=c++11 %s -o - \
+// RUN:   -triple x86_64-linux-gnu | FileCheck -check-prefix=HOST %s
+// RUN: %clang_cc1 -x hip -emit-llvm -std=c++11 %s -o - \
+// RUN:   -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN:   | FileCheck -check-prefix=DEV %s
+
+#include "Inputs/cuda.h"
+
+// Device side kernel name.
+// HOST: @[[KERN:[0-9]+]] = private unnamed_addr constant [22 x i8] c"_Z1gIZ4mainEUlvE_EvT_\00"
+
+// Template instantiation for h.
+// HOST-LABEL: define internal void @_Z1hIZ4mainEUlvE_EvT_
+
+// HOST-LABEL: define internal void @_Z16__device_stub__gIZ4mainEUlvE_EvT_
+
+// Check kernel is registered with correct device side kernel name.
+// HOST: @__hipRegisterFunction(i8** %0, i8* bitcast ({{.*}}@[[KERN]]
+
+// Check lambda is not emitted in host compilation.
+// HOST-NOT: define{{.*}}@_ZZ4mainENKUlvE_clEv
+
+// DEV: @a = addrspace(1) externally_initialized global i32 0
+
+// Check kernel is calling lambda function.
+// DEV-LABEL: define amdgpu_kernel void @_Z1gIZ4mainEUlvE_EvT_
+// DEV: call void @_ZZ4mainENKUlvE_clEv
+
+// Check lambda is emitted in device compilation and accessing device variable.
+// DEV-LABEL: define internal void @_ZZ4mainENKUlvE_clEv
+// DEV: store i32 1, i32* addrspacecast (i32 

[PATCH] D77597: [SveEmitter] Add IsAppendSVALL and builtins for svptrue and svcnt[bhwd]

[Eli Friedman via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D77597



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Andrew via Phabricator via cfe-commits]

browneee updated this revision to Diff 259949.
browneee added a comment.

Switch back to size and capacity type conditionally larger approach (appologies 
for the noise here).

Apply performance regression solutions from @nikic


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621

Files:
  llvm/include/llvm/ADT/SmallVector.h
  llvm/lib/Support/SmallVector.cpp

Index: llvm/lib/Support/SmallVector.cpp
===
--- llvm/lib/Support/SmallVector.cpp
+++ llvm/lib/Support/SmallVector.cpp
@@ -37,24 +37,29 @@
   sizeof(unsigned) * 2 + sizeof(void *) * 2,
   "wasted space in SmallVector size 1");
 
-/// grow_pod - This is an implementation of the grow() method which only works
-/// on POD-like datatypes and is out of line to reduce code duplication.
-/// This function will report a fatal error if it cannot increase capacity.
-void SmallVectorBase::grow_pod(void *FirstEl, size_t MinCapacity,
-   size_t TSize) {
-  // Ensure we can fit the new capacity in 32 bits.
-  if (MinCapacity > UINT32_MAX)
+static_assert(sizeof(SmallVector) ==
+  sizeof(void *) * 2 + sizeof(void *),
+  "1 byte elements have word-sized type for size and capacity");
+
+template 
+void SmallVectorBase::grow_pod(void *FirstEl, size_t MinCapacity,
+   size_t TSize) {
+  // Ensure we can fit the new capacity.
+  // This is only going to be applicable if the when the capacity is 32 bit.
+  if (MinCapacity > SizeTypeMax)
 report_bad_alloc_error("SmallVector capacity overflow during allocation");
 
   // Ensure we can meet the guarantee of space for at least one more element.
   // The above check alone will not catch the case where grow is called with a
   // default MinCapacity of 0, but the current capacity cannot be increased.
-  if (capacity() == size_t(UINT32_MAX))
+  // This is only going to be applicable if the when the capacity is 32 bit.
+  if (capacity() == SizeTypeMax)
 report_bad_alloc_error("SmallVector capacity unable to grow");
 
+  // In theory 2*capacity can overflow if the capacity is 64 bit, but the
+  // original capacity would never be large enough for this to be a problem.
   size_t NewCapacity = 2 * capacity() + 1; // Always grow.
-  NewCapacity =
-  std::min(std::max(NewCapacity, MinCapacity), size_t(UINT32_MAX));
+  NewCapacity = std::min(std::max(NewCapacity, MinCapacity), SizeTypeMax);
 
   void *NewElts;
   if (BeginX == FirstEl) {
@@ -70,3 +75,6 @@
   this->BeginX = NewElts;
   this->Capacity = NewCapacity;
 }
+
+template class llvm::SmallVectorBase;
+template class llvm::SmallVectorBase;
Index: llvm/include/llvm/ADT/SmallVector.h
===
--- llvm/include/llvm/ADT/SmallVector.h
+++ llvm/include/llvm/ADT/SmallVector.h
@@ -16,10 +16,10 @@
 #include "llvm/ADT/iterator_range.h"
 #include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemAlloc.h"
 #include "llvm/Support/type_traits.h"
-#include "llvm/Support/ErrorHandling.h"
 #include 
 #include 
 #include 
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,11 +35,21 @@
 
 namespace llvm {
 
-/// This is all the non-templated stuff common to all SmallVectors.
-class SmallVectorBase {
+/// This is all the stuff common to all SmallVectors.
+///
+/// The template parameter specifies the type which should be used to hold the
+/// Size and Capacity of the SmallVector, so it can be adjusted.
+/// Using 32 bit size is desirable to shink the size of the SmallVector.
+/// Using 64 bit size is desirable for cases like SmallVector, where a
+/// 32 bit size would limit the vector to ~4GB. SmallVectors are used for
+/// buffering bitcode output - which can exceed 4GB.
+template  class SmallVectorBase {
 protected:
   void *BeginX;
-  unsigned Size = 0, Capacity;
+  Size_T Size = 0, Capacity;
+
+  /// The maximum value of the Size_T used.
+  static constexpr size_t SizeTypeMax = std::numeric_limits::max();
 
   SmallVectorBase() = delete;
   SmallVectorBase(void *FirstEl, size_t TotalCapacity)
@@ -70,9 +81,15 @@
   }
 };
 
+template  const size_t SmallVectorBase::SizeTypeMax;
+
+template 
+using SmallVectorSizeType =
+typename std::conditional::type;
+
 /// Figure out the offset of the first element.
 template  struct SmallVectorAlignmentAndSize {
-  AlignedCharArrayUnion Base;
+  AlignedCharArrayUnion>> Base;
   AlignedCharArrayUnion FirstEl;
 };
 
@@ -80,7 +97,10 @@
 /// the type T is a POD. The extra dummy template argument is used by ArrayRef
 /// to avoid unnecessarily requiring T to be complete.
 template 
-class SmallVectorTemplateCommon : public SmallVectorBase {
+class 

[PATCH] D76452: Use LLD by default for Android.

[Dan Albert via Phabricator via cfe-commits]

danalbert added a comment.

In D76452#2000812 , @nickdesaulniers 
wrote:

> Can we use `-DCLANG_DEFAULT_LINKER=lld` to configure AOSP's distribution of 
> LLD, then require the use of `-fuse-ld= that is currently used>` when targeting OSX host tools?


It'd work (and might be a good short term solution here until we can get 
feedback from @ruiu, and @int3) but I'm not sure I like the idea of breaking 
the default Darwin configuration much more than the default Android 
configuration. It's less commonly used by our toolchain, but it's definitely 
used.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76452



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

[PATCH] D78762: build: use `find_package(Python3)` if available

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added a comment.

@JDevlieghere I dont think that adding another mechanism for finding the python 
executable is not the right approach.  You already have the variables that you 
are talking about, you just need to specify it in triplicate if you want 
compatibility across all the versions, but specifying `-DPython3_EXECUTABLE=` 
gives you the control over the executable for python3.  If you want to use 
python2, `-DPython3_EXECUTABLE=` and `-DPython2_EXECUTABLE=` will ensure that 
python2 is always used.  If you are using an older CMake, specifying 
`-DPython3_EXECUTABLE=`, `-DPython2_EXECUTABLE=` and `-DPYTHON_EXECUTABLE=` 
will ensure that the specified version is used.  I'm not sure what the scenario 
is that you believe will be made more difficult with this approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762



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

[clang] 063128f - [Fuchsia] Build compiler-rt builtins for 32-bit x86

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2020-04-24T12:18:30-07:00
New Revision: 063128f97930c551a43a657084f1632e33245bf6

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

LOG: [Fuchsia] Build compiler-rt builtins for 32-bit x86

While we don't support 32-bit architectures in Fuchsia, these are needed
in the early boot phase on x86, so we build just these to satisfy that
use case.

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

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake
clang/lib/Basic/Targets.cpp

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index e2be68be2284..eb2a03e164dd 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -105,15 +105,16 @@ endforeach()
 
 if(FUCHSIA_SDK)
   set(FUCHSIA_aarch64_NAME arm64)
+  set(FUCHSIA_i386_NAME x64)
   set(FUCHSIA_x86_64_NAME x64)
   set(FUCHSIA_riscv64_NAME riscv64)
-  foreach(target x86_64;aarch64;riscv64)
+  foreach(target i386;x86_64;aarch64;riscv64)
 set(FUCHSIA_${target}_COMPILER_FLAGS "-I${FUCHSIA_SDK}/pkg/fdio/include")
 set(FUCHSIA_${target}_LINKER_FLAGS 
"-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
 set(FUCHSIA_${target}_SYSROOT 
"${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
   endforeach()
 
-  foreach(target x86_64;aarch64;riscv64)
+  foreach(target i386;x86_64;aarch64;riscv64)
 # Set the per-target builtins options.
 list(APPEND BUILTIN_TARGETS "${target}-unknown-fuchsia")
 set(BUILTINS_${target}-unknown-fuchsia_CMAKE_SYSTEM_NAME Fuchsia CACHE 
STRING "")

diff  --git a/clang/lib/Basic/Targets.cpp b/clang/lib/Basic/Targets.cpp
index 9181c715085e..69133ca31fec 100644
--- a/clang/lib/Basic/Targets.cpp
+++ b/clang/lib/Basic/Targets.cpp
@@ -480,6 +480,8 @@ TargetInfo *AllocateTarget(const llvm::Triple ,
   return new OpenBSDI386TargetInfo(Triple, Opts);
 case llvm::Triple::FreeBSD:
   return new FreeBSDTargetInfo(Triple, Opts);
+case llvm::Triple::Fuchsia:
+  return new FuchsiaTargetInfo(Triple, Opts);
 case llvm::Triple::KFreeBSD:
   return new KFreeBSDTargetInfo(Triple, Opts);
 case llvm::Triple::Minix:



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

[clang] 7eae004 - Revert "[CUDA][HIP] Fix host/device based overload resolution"

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-04-24T14:57:10-04:00
New Revision: 7eae00477fddf3943b92d485a6055f4043852f9b

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

LOG: Revert "[CUDA][HIP] Fix host/device based overload resolution"

This reverts commit c77a4078e01033aa2206c31a579d217c8a07569b.

Added: 


Modified: 
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCUDA/function-overload.cu

Removed: 




diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index ecc4e7ee19fb..a32bc0c84c70 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -9374,22 +9374,16 @@ static Comparison compareEnableIfAttrs(const Sema , 
const FunctionDecl *Cand1,
   return Comparison::Equal;
 }
 
-static Comparison
-isBetterMultiversionCandidate(const OverloadCandidate ,
-  const OverloadCandidate ) {
+static bool isBetterMultiversionCandidate(const OverloadCandidate ,
+  const OverloadCandidate ) {
   if (!Cand1.Function || !Cand1.Function->isMultiVersion() || !Cand2.Function 
||
   !Cand2.Function->isMultiVersion())
-return Comparison::Equal;
+return false;
 
-  // If both are invalid, they are equal. If one of them is invalid, the other
-  // is better.
-  if (Cand1.Function->isInvalidDecl()) {
-if (Cand2.Function->isInvalidDecl())
-  return Comparison::Equal;
-return Comparison::Worse;
-  }
-  if (Cand2.Function->isInvalidDecl())
-return Comparison::Better;
+  // If Cand1 is invalid, it cannot be a better match, if Cand2 is invalid, 
this
+  // is obviously better.
+  if (Cand1.Function->isInvalidDecl()) return false;
+  if (Cand2.Function->isInvalidDecl()) return true;
 
   // If this is a cpu_dispatch/cpu_specific multiversion situation, prefer
   // cpu_dispatch, else arbitrarily based on the identifiers.
@@ -9399,18 +9393,16 @@ isBetterMultiversionCandidate(const OverloadCandidate 
,
   const auto *Cand2CPUSpec = Cand2.Function->getAttr();
 
   if (!Cand1CPUDisp && !Cand2CPUDisp && !Cand1CPUSpec && !Cand2CPUSpec)
-return Comparison::Equal;
+return false;
 
   if (Cand1CPUDisp && !Cand2CPUDisp)
-return Comparison::Better;
+return true;
   if (Cand2CPUDisp && !Cand1CPUDisp)
-return Comparison::Worse;
+return false;
 
   if (Cand1CPUSpec && Cand2CPUSpec) {
 if (Cand1CPUSpec->cpus_size() != Cand2CPUSpec->cpus_size())
-  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size()
- ? Comparison::Better
- : Comparison::Worse;
+  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size();
 
 std::pair
 FirstDiff = std::mismatch(
@@ -9423,9 +9415,7 @@ isBetterMultiversionCandidate(const OverloadCandidate 
,
 assert(FirstDiff.first != Cand1CPUSpec->cpus_end() &&
"Two 
diff erent cpu-specific versions should not have the same "
"identifier list, otherwise they'd be the same decl!");
-return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName()
-   ? Comparison::Better
-   : Comparison::Worse;
+return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName();
   }
   llvm_unreachable("No way to get here unless both had cpu_dispatch");
 }
@@ -9485,50 +9475,6 @@ bool clang::isBetterOverloadCandidate(
   else if (!Cand1.Viable)
 return false;
 
-  // [CUDA] A function with 'never' preference is marked not viable, therefore
-  // is never shown up here. The worst preference shown up here is 'wrong 
side',
-  // e.g. a host function called by a device host function in device
-  // compilation. This is valid AST as long as the host device function is not
-  // emitted, e.g. it is an inline function which is called only by a host
-  // function. A deferred diagnostic will be triggered if it is emitted.
-  // However a wrong-sided function is still a viable candidate here.
-  //
-  // If Cand1 can be emitted and Cand2 cannot be emitted in the current
-  // context, Cand1 is better than Cand2. If Cand1 can not be emitted and Cand2
-  // can be emitted, Cand1 is not better than Cand2. This rule should have
-  // precedence over other rules.
-  //
-  // If both Cand1 and Cand2 can be emitted, or neither can be emitted, then
-  // other rules should be used to determine which is better. This is because
-  // host/device based overloading resolution is mostly for determining
-  // viability of a function. If two functions are both viable, other factors
-  // should take precedence in preference, e.g. the standard-defined 
preferences
-  // like argument conversion ranks or enable_if partial-ordering. The
-  // preference for pass-object-size parameters is probably most similar to a
-  // 

[clang] c77a407 - [CUDA][HIP] Fix host/device based overload resolution

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-04-24T14:55:18-04:00
New Revision: c77a4078e01033aa2206c31a579d217c8a07569b

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

LOG: [CUDA][HIP] Fix host/device based overload resolution

Currently clang fails to compile the following CUDA program in device 
compilation:

__host__ int foo(int x) {
 return 1;
}

template
__device__ __host__ int foo(T x) {
return 2;
}

__device__ __host__ int bar() {
return foo(1);
}

__global__ void test(int *a) {
*a = bar();
}

This is due to foo is resolved to the __host__ foo instead of __device__ 
__host__ foo.
This seems to be a bug since __device__ __host__ foo is a viable callee for foo 
whereas
clang is unable to choose it.

This patch fixes that.

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

Added: 


Modified: 
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCUDA/function-overload.cu

Removed: 




diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index a32bc0c84c70..ecc4e7ee19fb 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -9374,16 +9374,22 @@ static Comparison compareEnableIfAttrs(const Sema , 
const FunctionDecl *Cand1,
   return Comparison::Equal;
 }
 
-static bool isBetterMultiversionCandidate(const OverloadCandidate ,
-  const OverloadCandidate ) {
+static Comparison
+isBetterMultiversionCandidate(const OverloadCandidate ,
+  const OverloadCandidate ) {
   if (!Cand1.Function || !Cand1.Function->isMultiVersion() || !Cand2.Function 
||
   !Cand2.Function->isMultiVersion())
-return false;
+return Comparison::Equal;
 
-  // If Cand1 is invalid, it cannot be a better match, if Cand2 is invalid, 
this
-  // is obviously better.
-  if (Cand1.Function->isInvalidDecl()) return false;
-  if (Cand2.Function->isInvalidDecl()) return true;
+  // If both are invalid, they are equal. If one of them is invalid, the other
+  // is better.
+  if (Cand1.Function->isInvalidDecl()) {
+if (Cand2.Function->isInvalidDecl())
+  return Comparison::Equal;
+return Comparison::Worse;
+  }
+  if (Cand2.Function->isInvalidDecl())
+return Comparison::Better;
 
   // If this is a cpu_dispatch/cpu_specific multiversion situation, prefer
   // cpu_dispatch, else arbitrarily based on the identifiers.
@@ -9393,16 +9399,18 @@ static bool isBetterMultiversionCandidate(const 
OverloadCandidate ,
   const auto *Cand2CPUSpec = Cand2.Function->getAttr();
 
   if (!Cand1CPUDisp && !Cand2CPUDisp && !Cand1CPUSpec && !Cand2CPUSpec)
-return false;
+return Comparison::Equal;
 
   if (Cand1CPUDisp && !Cand2CPUDisp)
-return true;
+return Comparison::Better;
   if (Cand2CPUDisp && !Cand1CPUDisp)
-return false;
+return Comparison::Worse;
 
   if (Cand1CPUSpec && Cand2CPUSpec) {
 if (Cand1CPUSpec->cpus_size() != Cand2CPUSpec->cpus_size())
-  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size();
+  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size()
+ ? Comparison::Better
+ : Comparison::Worse;
 
 std::pair
 FirstDiff = std::mismatch(
@@ -9415,7 +9423,9 @@ static bool isBetterMultiversionCandidate(const 
OverloadCandidate ,
 assert(FirstDiff.first != Cand1CPUSpec->cpus_end() &&
"Two 
diff erent cpu-specific versions should not have the same "
"identifier list, otherwise they'd be the same decl!");
-return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName();
+return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName()
+   ? Comparison::Better
+   : Comparison::Worse;
   }
   llvm_unreachable("No way to get here unless both had cpu_dispatch");
 }
@@ -9475,6 +9485,50 @@ bool clang::isBetterOverloadCandidate(
   else if (!Cand1.Viable)
 return false;
 
+  // [CUDA] A function with 'never' preference is marked not viable, therefore
+  // is never shown up here. The worst preference shown up here is 'wrong 
side',
+  // e.g. a host function called by a device host function in device
+  // compilation. This is valid AST as long as the host device function is not
+  // emitted, e.g. it is an inline function which is called only by a host
+  // function. A deferred diagnostic will be triggered if it is emitted.
+  // However a wrong-sided function is still a viable candidate here.
+  //
+  // If Cand1 can be emitted and Cand2 cannot be emitted in the current
+  // context, Cand1 is better than Cand2. If Cand1 can not be emitted and Cand2
+  // can be emitted, Cand1 is not better than Cand2. This rule should have
+  // precedence over other rules.
+  //
+  // If both Cand1 and Cand2 can 

[PATCH] D77979: [clang-tidy] modernize-use-using: Fix broken fixit with InjectedClassName

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM aside from a commenting nit.




Comment at: clang/include/clang/AST/PrettyPrinter.h:248
+  /// Whether to print an InjectedClassNameType with template arguments or as
+  /// written. When a template arguments are unnamed, printing them results in
+  /// invalid C++ code.

When a template arguments are... -> When a template argument is unnamed, 
printing it results in invalid C++ code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77979



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

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

@tra Is it OK I commit it now? Or better wait next Monday morning? Thanks.


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

https://reviews.llvm.org/D77954



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

[PATCH] D78777: [AST] Use PrintingPolicy for format string diagnosis

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78777



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

[PATCH] D78762: build: use `find_package(Python3)` if available

[Jonas Devlieghere via Phabricator via cfe-commits]

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

I would strongly prefer to do this differently. While we hope to drop Python 2 
support in LLDB as soon as possible, we are not there yet. This patch as it 
stands will make it really hard for us to keep doing so (even internally) if 
upstream decides to drop support. I have looked into this change myself a while 
ago with these limitations in mind, and believe we can achieve the same in a 
way that would make this easier.

My suggestion is to have 4 new CMake variable that abstract over this: 
`LLVM_PYTHON_EXECUTABLE`, `LLVM_PYTHON_LIBRARIES`, `LLVM_PYTHON_INCLUDE_DIRS` 
and finally `LLVM_PYTHON_HINT`.  We can then populate the first three depending 
on what machinery we want to use, i.e. the old CMake way of finding Python 
(until we bump the requirement across llvm), as well as the new `FindPython3` 
and `FindPython2`. Similarly for the `HINT` variable, having our own 
abstraction means we don't clobber any of the variables used internally by 
CMake.

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762



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

[PATCH] D78192: Support compiler extensions as a normal component

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

The patch landed without much errors, only added the patchset 
e307eeba0137700e75893089cf0de03383d851ca 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78192



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

[PATCH] D72959: Relative VTables ABI on Fuchsia

[Leonard Chan via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGVTables.cpp:623
+llvm::Constant *C, llvm::GlobalVariable *VTable, unsigned vtableIdx,
+unsigned lastAddrPoint) const {
+  // No need to get the offset of a nullptr.

rjmccall wrote:
> There's already an `addRelativeOffset` on `ConstantArrayBuilder`; is that 
> insufficient for some reason?  I think that, if v-table building were 
> refactored so that the places that build components also add them to the 
> v-table, we'd end up with a lot more flexibility for the ABIs.  We needed a 
> similar sort of change for pointer authentication, which we haven't 
> upstreamed to LLVM yet, but which you can see here:
> 
> https://github.com/apple/llvm-project/blob/apple/master/clang/lib/CodeGen/CGVTables.cpp
> 
> 
I actually did not know about this method, but it does seem to boil down to the 
same arithmetic used here. Will update to see if I can use the existing 
builders instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72959



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

[PATCH] D78817: clang: Allow backend unsupported warnings

[Yaxun Liu via Phabricator via cfe-commits]

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

LGTM. Thanks.


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

https://reviews.llvm.org/D78817



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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

[Zequan Wu via Phabricator via cfe-commits]

zequanwu updated this revision to Diff 259938.
Herald added subscribers: dexonsmith, steven_wu.

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

https://reviews.llvm.org/D78659

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/attr-nomerge.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/SimplifyCFG.cpp

Index: llvm/lib/Transforms/Utils/SimplifyCFG.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -1287,6 +1287,14 @@
 if (!TTI.isProfitableToHoist(I1) || !TTI.isProfitableToHoist(I2))
   return Changed;
 
+// If any of the two call sites has nomerge attribute, stop hoisting.
+if (const auto *CB1 = dyn_cast(I1))
+  if (CB1->cannotMerge())
+return Changed;
+if (const auto *CB2 = dyn_cast(I2))
+  if (CB2->cannotMerge())
+return Changed;
+
 if (isa(I1) || isa(I2)) {
   assert (isa(I1) && isa(I2));
   // The debug location is an integral part of a debug info intrinsic
@@ -1472,8 +1480,9 @@
 // Conservatively return false if I is an inline-asm instruction. Sinking
 // and merging inline-asm instructions can potentially create arguments
 // that cannot satisfy the inline-asm constraints.
+// If the instruction has nomerge attribute, return false.
 if (const auto *C = dyn_cast(I))
-  if (C->isInlineAsm())
+  if (C->isInlineAsm() || C->cannotMerge())
 return false;
 
 // Each instruction must have zero or one use.
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1509,6 +1509,7 @@
 /// Return true if this attribute kind only applies to functions.
 static bool isFuncOnlyAttr(Attribute::AttrKind Kind) {
   switch (Kind) {
+  case Attribute::NoMerge:
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -368,6 +368,8 @@
 return "noinline";
   if (hasAttribute(Attribute::NonLazyBind))
 return "nonlazybind";
+  if (hasAttribute(Attribute::NoMerge))
+return "nomerge";
   if (hasAttribute(Attribute::NonNull))
 return "nonnull";
   if (hasAttribute(Attribute::NoRedZone))
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -204,6 +204,7 @@
   kw_noinline,
   kw_norecurse,
   kw_nonlazybind,
+  kw_nomerge,
   kw_nonnull,
   kw_noredzone,
   kw_noreturn,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1306,6 +1306,7 @@
   B.addAttribute(Attribute::NoImplicitFloat); break;
 case lltok::kw_noinline: B.addAttribute(Attribute::NoInline); break;
 case lltok::kw_nonlazybind: B.addAttribute(Attribute::NonLazyBind); break;
+case lltok::kw_nomerge: B.addAttribute(Attribute::NoMerge); break;
 case lltok::kw_noredzone: B.addAttribute(Attribute::NoRedZone); break;
 case lltok::kw_noreturn: B.addAttribute(Attribute::NoReturn); break;
 case lltok::kw_nosync: B.addAttribute(Attribute::NoSync); break;
@@ -1682,6 +1683,7 @@
 case lltok::kw_noimplicitfloat:
 case lltok::kw_noinline:
 case lltok::kw_nonlazybind:
+case lltok::kw_nomerge:
 case lltok::kw_noredzone:
 case lltok::kw_noreturn:
 case lltok::kw_nocf_check:
@@ -1781,6 +1783,7 @@
 case lltok::kw_noimplicitfloat:
 case lltok::kw_noinline:
 case lltok::kw_nonlazybind:
+case lltok::kw_nomerge:
 case lltok::kw_noredzone:
 case lltok::kw_noreturn:
 case lltok::kw_nocf_check:
Index: llvm/lib/AsmParser/LLLexer.cpp
===
--- llvm/lib/AsmParser/LLLexer.cpp
+++ llvm/lib/AsmParser/LLLexer.cpp
@@ -658,6 +658,7 @@
   KEYWORD(noinline);
   KEYWORD(norecurse);
   KEYWORD(nonlazybind);
+  KEYWORD(nomerge);
   KEYWORD(nonnull);
   KEYWORD(noredzone);
   KEYWORD(noreturn);
Index: llvm/include/llvm/IR/InstrTypes.h
===
--- llvm/include/llvm/IR/InstrTypes.h
+++ llvm/include/llvm/IR/InstrTypes.h
@@ -1717,6 +1717,9 @@
 addAttribute(AttributeList::FunctionIndex, Attribute::NoDuplicate);
   }
 
+  /// Determine if the invoke cannot be tail merged.
+  

[PATCH] D77621: Change BitcodeWriter buffer to std::vector instead of SmallVector.

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

@nikic, great news!  Thanks for doing the detailed analysis.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[clang] 0ed5b0d - [X86] Don't use types when getting the intrinsic declaration for x86_avx512_mask_vcvtph2ps_512.

[Craig Topper via cfe-commits]

Author: Craig Topper
Date: 2020-04-24T11:01:22-07:00
New Revision: 0ed5b0d517cb781d4949cc4bfa9854bc276ee13a

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

LOG: [X86] Don't use types when getting the intrinsic declaration for 
x86_avx512_mask_vcvtph2ps_512.

This intrinsic isn't overloaded so we should query with types.
Doing so causes the backend to miss the intrinsic and not codegen it.
This eventually leads to a linker error.

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/avx512f-builtins.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 3a66583e20e8..18ad1664aa56 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -10961,10 +10961,8 @@ static Value *EmitX86CvtF16ToFloatExpr(CodeGenFunction 
,
 
   // If the SAE intrinsic doesn't use default rounding then we can't upgrade.
   if (Ops.size() == 4 && cast(Ops[3])->getZExtValue() != 4) 
{
-Intrinsic::ID IID = Intrinsic::x86_avx512_mask_vcvtph2ps_512;
 Function *F =
-CGF.CGM.getIntrinsic(IID, {DstTy, Ops[0]->getType(), Ops[1]->getType(),
-   Ops[2]->getType(), Ops[3]->getType()});
+CGF.CGM.getIntrinsic(Intrinsic::x86_avx512_mask_vcvtph2ps_512);
 return CGF.Builder.CreateCall(F, {Ops[0], Ops[1], Ops[2], Ops[3]});
   }
 

diff  --git a/clang/test/CodeGen/avx512f-builtins.c 
b/clang/test/CodeGen/avx512f-builtins.c
index c193e7d3a477..7be73ecbd1cd 100644
--- a/clang/test/CodeGen/avx512f-builtins.c
+++ b/clang/test/CodeGen/avx512f-builtins.c
@@ -4976,21 +4976,21 @@ __m256i test_mm512_maskz_cvt_roundps_ph(__mmask16 __U, 
__m512  __A)
 __m512 test_mm512_cvt_roundph_ps(__m256i __A)
 {
 // CHECK-LABEL: @test_mm512_cvt_roundph_ps
-// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512
+// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512(
 return _mm512_cvt_roundph_ps(__A, _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_mask_cvt_roundph_ps(__m512 __W, __mmask16 __U, __m256i __A)
 {
 // CHECK-LABEL: @test_mm512_mask_cvt_roundph_ps
-// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512
+// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512(
 return _mm512_mask_cvt_roundph_ps(__W, __U, __A, _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_maskz_cvt_roundph_ps(__mmask16 __U, __m256i __A)
 {
 // CHECK-LABEL: @test_mm512_maskz_cvt_roundph_ps
-// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512
+// CHECK: @llvm.x86.avx512.mask.vcvtph2ps.512(
 return _mm512_maskz_cvt_roundph_ps(__U, __A, _MM_FROUND_NO_EXC);
 }
 



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

[PATCH] D77592: [NFC][CodeGen] Add enum for selecting the layout of components in the vtable

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a comment.

In D77592#2002148 , @rjmccall wrote:

> Okay.  The plan sounds good to me.  So you want to roll out this enum in this 
> patch, but not really use it for much until the follow-up?


That was the plan, but I can also add include the cc1 flag for selecting the 
`Relative` layout and some initial vtable changes in this patch so it can be 
tested. The first patch after this that would be using it will be large 
regardless.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77592



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

[PATCH] D78762: build: use `find_package(Python3)` if available

[Saleem Abdulrasool via Phabricator via cfe-commits]

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

Include clang as some of the CI uses the unified build which fails without the 
update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762

Files:
  clang/CMakeLists.txt
  clang/bindings/python/tests/CMakeLists.txt
  clang/test/lit.site.cfg.py.in
  clang/utils/perf-training/CMakeLists.txt
  clang/utils/perf-training/lit.site.cfg.in
  clang/utils/perf-training/order-files.lit.site.cfg.in
  llvm/CMakeLists.txt
  llvm/cmake/config-ix.cmake
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/lit.site.cfg.py.in

Index: llvm/test/lit.site.cfg.py.in
===
--- llvm/test/lit.site.cfg.py.in
+++ llvm/test/lit.site.cfg.py.in
@@ -12,7 +12,7 @@
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
 config.lit_tools_dir = path(r"@LLVM_LIT_TOOLS_DIR@")
-config.python_executable = "@PYTHON_EXECUTABLE@"
+config.python_executable = "@Python3_EXECUTABLE@"
 config.gold_executable = "@GOLD_EXECUTABLE@"
 config.ld64_executable = "@LD64_EXECUTABLE@"
 config.ocamlfind_executable = "@OCAMLFIND@"
Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -117,7 +117,7 @@
 set(native_export_file "${target_name}.def")
 
 add_custom_command(OUTPUT ${native_export_file}
-  COMMAND ${PYTHON_EXECUTABLE} -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))"
+  COMMAND "${Python3_EXECUTABLE}" -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))"
 < ${export_file} > ${native_export_file}
   DEPENDS ${export_file}
   VERBATIM
@@ -1001,7 +1001,7 @@
   set(mangling itanium)
 endif()
 add_custom_command(OUTPUT ${exported_symbol_file}
-   COMMAND ${PYTHON_EXECUTABLE} ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file}
+   COMMAND "${Python3_EXECUTABLE}" ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file}
WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR}
DEPENDS ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py ${static_libs}
VERBATIM
@@ -1402,7 +1402,7 @@
   # empty list entries. So escape the ;s in the list and do the splitting
   # ourselves. cmake has no relpath function, so use Python for that.
   string(REPLACE ";" "\\;" pathlist_escaped "${pathlist}")
-  execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "\n
+  execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "\n
 import os, sys\n
 base = sys.argv[1]
 def haslink(p):\n
@@ -1477,7 +1477,6 @@
   # SHLIBDIR points the build tree.
   string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" SHLIBDIR "${LLVM_SHLIB_OUTPUT_INTDIR}")
 
-  set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE})
   # FIXME: "ENABLE_SHARED" doesn't make sense, since it is used just for
   # plugins. We may rename it.
   if(LLVM_ENABLE_PLUGINS)
@@ -1635,7 +1634,7 @@
 ALLOW_EXTERNAL
 )
 
-  set(LIT_COMMAND "${PYTHON_EXECUTABLE};${lit_base_dir}/${lit_file_name}")
+  set(LIT_COMMAND "${Python3_EXECUTABLE};${lit_base_dir}/${lit_file_name}")
   list(APPEND LIT_COMMAND ${LIT_ARGS})
   foreach(param ${ARG_PARAMS})
 list(APPEND LIT_COMMAND --param ${param})
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -639,7 +639,7 @@
 return()
   endif()
 
-  execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "import ${module}"
+  execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "import ${module}"
 RESULT_VARIABLE status
 ERROR_QUIET)
 
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -672,16 +672,38 @@
 
 include(HandleLLVMOptions)
 
-include(FindPythonInterp)
-if( NOT PYTHONINTERP_FOUND )
-  message(FATAL_ERROR
-"Unable to find Python interpreter, required for builds and testing.
+if(CMAKE_VERSION VERSION_LESS 3.12)
+  include(FindPythonInterp)
+  if( NOT PYTHONINTERP_FOUND )
+message(FATAL_ERROR
+  "Unable to find Python interpreter, required for builds and testing.
 
-Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
-endif()
+  Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
+  endif()
+
+  if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
+message(FATAL_ERROR "Python 2.7 or newer is required")
+  endif()
 
-if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
-  message(FATAL_ERROR "Python 2.7 or newer is required")
+  

[PATCH] D72959: Relative VTables ABI on Fuchsia

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGVTables.cpp:623
+llvm::Constant *C, llvm::GlobalVariable *VTable, unsigned vtableIdx,
+unsigned lastAddrPoint) const {
+  // No need to get the offset of a nullptr.

There's already an `addRelativeOffset` on `ConstantArrayBuilder`; is that 
insufficient for some reason?  I think that, if v-table building were 
refactored so that the places that build components also add them to the 
v-table, we'd end up with a lot more flexibility for the ABIs.  We needed a 
similar sort of change for pointer authentication, which we haven't upstreamed 
to LLVM yet, but which you can see here:

https://github.com/apple/llvm-project/blob/apple/master/clang/lib/CodeGen/CGVTables.cpp




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72959



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[Erich Keane via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/TargetInfo.cpp:2980
 
-return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)
-  : ABIArgInfo::getDirect());
+if (!Ty->isExtIntType())
+  return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)

rjmccall wrote:
> Presumably *some* `ExtInt` types should be returned directly.
Right, and they are.  This is only for cases where we request an 'indirect 
result', so cases where we've already decided that it cannot be passed direct.

At this point, the 'classify' step has already been done, which would have 
decided that <=128 bit values are passed 'direct', and we've requested an 
indirect.  At least as far as I can tell from this code/debugging.


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

https://reviews.llvm.org/D78785



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Is there something currently restricting these types to just x86, or do you 
need to do a much broader audit?




Comment at: clang/lib/CodeGen/TargetInfo.cpp:2980
 
-return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)
-  : ABIArgInfo::getDirect());
+if (!Ty->isExtIntType())
+  return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)

Presumably *some* `ExtInt` types should be returned directly.


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

https://reviews.llvm.org/D78785



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

[PATCH] D77592: [NFC][CodeGen] Add enum for selecting the layout of components in the vtable

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Okay.  The plan sounds good to me.  So you want to roll out this enum in this 
patch, but not really use it for much until the follow-up?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77592



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

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

LGTM with one very minor fix.




Comment at: clang/docs/LanguageExtensions.rst:511
+*r = *a +  (*b * *c);
+  }
+

fhahn wrote:
> rjmccall wrote:
> > This is kindof an unnecessarily unreadable example.  I know you haven't 
> > decided on calling convention treatment yet, but maybe the leading example 
> > could be just a little ahead of the implementation and just take the 
> > matrices as arguments and then return the result.
> I wasn't sure if that would be fine, but it indeed makes things much more 
> readable. Updated.
Extra space after the `+`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76612



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

[PATCH] D78655: [HIP] Let lambda be host device by default

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Seems reasonable




Comment at: clang/test/CodeGenCUDA/lambda.cu:29
+
+// Check lambda is emitted in device compilation and accessind device variable.
+// DEV-LABEL: define internal void @_ZZ4mainENKUlvE_clEv

Typo


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

https://reviews.llvm.org/D78655



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

[PATCH] D78767: [Sema] Teach -Wcast-align to compute a more accurate alignment when the source expression has array subscript or pointer arithmetic operators

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/include/clang/AST/Expr.h:710
+  /// possible to compute the alignment, return zero.
+  CharUnits getAlignmentFromDecl(ASTContext ) const;
+

Nothing about the name here suggests that it only works on expressions of 
pointer type.  Maybe call it `getPresumedAlignmentOfPointer` or something and 
then make it also consider the type alignment?



Comment at: clang/lib/AST/ExprConstant.cpp:14844
+  if (auto *VD = Result.Base.dyn_cast())
+return Ctx.getDeclAlign(VD).alignmentAtOffset(Result.Offset);
+

Does this do the right thing if `getDeclAlign` returns 0, or can that never 
happen?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78767



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

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall added a comment.

Thanks, Yaxun.  LGTM.


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

https://reviews.llvm.org/D77954



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

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:9749
+  if (isBetterMultiversionCandidate(Cand1, Cand2))
+return true;
+

yaxunl wrote:
> rjmccall wrote:
> > tra wrote:
> > > rjmccall wrote:
> > > > erichkeane wrote:
> > > > > yaxunl wrote:
> > > > > > echristo wrote:
> > > > > > > rjmccall wrote:
> > > > > > > > yaxunl wrote:
> > > > > > > > > rjmccall wrote:
> > > > > > > > > > If we move anything below this check, it needs to figure 
> > > > > > > > > > out a tri-state so that it can return false if `Cand2` is a 
> > > > > > > > > > better candidate than `Cand1`.  Now, that only matters if 
> > > > > > > > > > multiversion functions are supported under CUDA, but if 
> > > > > > > > > > you're relying on them not being supported, that should at 
> > > > > > > > > > least be commented on.
> > > > > > > > > multiversion host functions is orthogonal to CUDA therefore 
> > > > > > > > > should be supported. multiversion in device, host device, and 
> > > > > > > > > global functions are not supported. However this change does 
> > > > > > > > > not make things worse, and should continue to work if they 
> > > > > > > > > are supported.
> > > > > > > > > 
> > > > > > > > > host/device based overloading resolution is mostly for 
> > > > > > > > > determining viability of a function. If two functions are 
> > > > > > > > > both viable, other factors should take precedence in 
> > > > > > > > > preference. This general rule has been taken for cases other 
> > > > > > > > > than multiversion, I think it should also apply to 
> > > > > > > > > multiversion.
> > > > > > > > > 
> > > > > > > > > I will make isBetterMultiversionCandidate three states.
> > > > > > > > > This general rule has been taken for cases other than 
> > > > > > > > > multiversion, I think it should also apply to multiversion.
> > > > > > > > 
> > > > > > > > Well, but the multiversion people could say the same: that 
> > > > > > > > multiversioning is for picking an alternative among 
> > > > > > > > otherwise-identical functions, and HD and H functions are not 
> > > > > > > > otherwise-identical.
> > > > > > > > 
> > > > > > > > CC'ing @echristo for his thoughts on the right ordering here.
> > > > > > > Adding @erichkeane here as well.
> > > > > > > 
> > > > > > > I think this makes sense, but I can see a reason to multiversion 
> > > > > > > a function that will run on host and device. A version of some 
> > > > > > > matrix mult that takes advantage of 3 host architectures and one 
> > > > > > > cuda one? Am I missing something here?
> > > > > > My understanding is that a multiversion function is for a specific 
> > > > > > cpu(gpu). Let's say we want to have a function f for gfx900, 
> > > > > > gfx906, sandybridge, ivybridge, shouldn't they be more like
> > > > > > 
> > > > > > ```
> > > > > > __host__ __attribute__((cpu_specific(sandybridge))) f();
> > > > > > __host__ __attribute__((cpu_specific(ivybridge))) f();
> > > > > > __device__ __attribute__((cpu_specific(gfx900))) f();
> > > > > > __device__ __attribute__((cpu_specific(gfx906))) f();
> > > > > > ```
> > > > > > instead of all `__device__ __host__` functions?
> > > > > IMO, it doesn't make sense for functions to functions be BOTH host 
> > > > > and device, they'd have to be just one.  Otherwise I'm not sure how 
> > > > > the resolver behavior is supposed to work.  The whole idea is that 
> > > > > the definition is chosen at runtime.
> > > > > 
> > > > > Unless __host__ __device void foo(); is TWO declaration chains 
> > > > > (meaning two separate AST entries), it doesn't make sense to have 
> > > > > multiverison on it (and then, how it would be spelled is 
> > > > > awkward/confusing to me).
> > > > > 
> > > > > In the above case, if those 4 declarations are not 2 separate root- 
> > > > > AST nodes, multiversioning won't work.
> > > > There are certainly functions that ought to be usable from either host 
> > > > or device context — any inline function that just does ordinary 
> > > > language things should be in that category.  Also IIUC many 
> > > > declarations are *inferred* to be `__host__ __device__`, or can be 
> > > > mass-annotated with pragmas, and those reasons are probably the main 
> > > > ones this might matter — we might include a header in CUDA mode that 
> > > > declares a multi-versioned function, and we should handle it right.
> > > > 
> > > > My read of how CUDA programmers expect this to work is that they see 
> > > > the `__host__` / `__device__` attributes as primarily a mechanism for 
> > > > catching problems where you're using the wrong functions for the 
> > > > current configuration.  That is, while we allow overloading by 
> > > > `__host__`/`__device__`-ness, users expect those attributes to mostly 
> > > > be used as a filter for what's "really there" rather than really 
> > > > strictly segregating the namespace.  So I would say that CUDA 
> > > > programmers would probably 

[PATCH] D78817: clang: Allow backend unsupported warnings

[Matt Arsenault via Phabricator via cfe-commits]

arsenm created this revision.
arsenm added reviewers: yaxunl, Anastasia, olista01, ostannard, xur.
Herald added subscribers: tpr, wdng.

Currently this asserts on anything other than errors. In one
workaround scenario, AMDGPU emits DiagnosticInfoUnsupported as a
warning for functions that can't be correctly codegened, but should
never be executed.


https://reviews.llvm.org/D78817

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/CodeGenOpenCL/backend-unsupported-warning.ll


Index: clang/test/CodeGenOpenCL/backend-unsupported-warning.ll
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/backend-unsupported-warning.ll
@@ -0,0 +1,30 @@
+; RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -S -o - %s 2>&1 | FileCheck %s
+
+; Check that a DiagnosticUnsupported reported as a warning works
+; correctly, and is not emitted as an error.
+
+; CHECK: warning: test.c:2:20: in function use_lds_global_in_func i32 (): 
local memory global used by non-kernel function
+
+target triple = "amdgcn-amd-amdhsa"
+
+@lds = external addrspace(3) global i32, align 4
+
+define i32 @use_lds_global_in_func() !dbg !5 {
+  %load = load i32, i32 addrspace(3)* @lds, !dbg !9
+  ret i32 %load, !dbg !10
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang 
version 3.9.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, 
enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 2, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type: 
!6, scopeLine: 2, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!6 = !DISubroutineType(types: !7)
+!7 = !{!8}
+!8 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
+!9 = !DILocation(line: 2, column: 20, scope: !5)
+!10 = !DILocation(line: 2, column: 13, scope: !5)
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -633,8 +633,9 @@
 
 void BackendConsumer::UnsupportedDiagHandler(
 const llvm::DiagnosticInfoUnsupported ) {
-  // We only support errors.
-  assert(D.getSeverity() == llvm::DS_Error);
+  // We only support warnings or errors.
+  assert(D.getSeverity() == llvm::DS_Error ||
+ D.getSeverity() == llvm::DS_Warning);
 
   StringRef Filename;
   unsigned Line, Column;
@@ -652,7 +653,11 @@
 DiagnosticPrinterRawOStream DP(MsgStream);
 D.print(DP);
   }
-  Diags.Report(Loc, diag::err_fe_backend_unsupported) << MsgStream.str();
+
+  auto DiagType = D.getSeverity() == llvm::DS_Error
+  ? diag::err_fe_backend_unsupported
+  : diag::warn_fe_backend_unsupported;
+  Diags.Report(Loc, DiagType) << MsgStream.str();
 
   if (BadDebugInfo)
 // If we were not able to translate the file:line:col information
Index: clang/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -61,6 +61,7 @@
   "not determine the original source location for %0:%1:%2">, BackendInfo;
 
 def err_fe_backend_unsupported : Error<"%0">, BackendInfo;
+def warn_fe_backend_unsupported : Warning<"%0">, BackendInfo;
 
 def err_fe_invalid_code_complete_file : Error<
 "cannot locate code-completion file %0">, DefaultFatal;


Index: clang/test/CodeGenOpenCL/backend-unsupported-warning.ll
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/backend-unsupported-warning.ll
@@ -0,0 +1,30 @@
+; RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -S -o - %s 2>&1 | FileCheck %s
+
+; Check that a DiagnosticUnsupported reported as a warning works
+; correctly, and is not emitted as an error.
+
+; CHECK: warning: test.c:2:20: in function use_lds_global_in_func i32 (): local memory global used by non-kernel function
+
+target triple = "amdgcn-amd-amdhsa"
+
+@lds = external addrspace(3) global i32, align 4
+
+define i32 @use_lds_global_in_func() !dbg !5 {
+  %load = load i32, i32 addrspace(3)* @lds, !dbg !9
+  ret i32 %load, !dbg !10
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 3.9.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 2, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type: !6, scopeLine: 2, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!6 = 

Re: [Lldb-commits] [PATCH] D78807: Fix gendered documentation

[Jim Ingham via cfe-commits]

A lot of our comments and documentation was written a while ago when the “good” 
practice was to be careful to use “he” and “she” in equal measure when 
referring to our users.  The consensus has shifted to using “they” instead, so 
there are probably a bunch of other places using he and she.  Please feel free 
to fix this wherever you see it!

Thanks!

Jim

> On Apr 24, 2020, at 9:43 AM, Jonas Devlieghere via Phabricator via 
> lldb-commits  wrote:
> 
> JDevlieghere accepted this revision.
> JDevlieghere added a comment.
> 
> Thank you!
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D78807/new/
> 
> https://reviews.llvm.org/D78807
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[PATCH] D73845: [Gnu toolchain] Move GCC multilib/multiarch paths support from Linux to Gnu

[Fangrui Song via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG63959803702c: [Driver] Move GCC multilib/multiarch paths 
support from Linux.cpp to Gnu.cpp (authored by sthibaul, committed by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73845

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Gnu.h
  clang/lib/Driver/ToolChains/Linux.cpp

Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -208,15 +208,6 @@
   return Triple.isArch32Bit() ? "lib" : "lib64";
 }
 
-static void addMultilibsFilePaths(const Driver , const MultilibSet ,
-  const Multilib ,
-  StringRef InstallPath,
-  ToolChain::path_list ) {
-  if (const auto  = Multilibs.filePathsCallback())
-for (const auto  : PathsCallback(Multilib))
-  addPathIfExists(D, InstallPath + Path, Paths);
-}
-
 Linux::Linux(const Driver , const llvm::Triple , const ArgList )
 : Generic_ELF(D, Triple, Args) {
   GCCInstallation.init(Triple, Args);
@@ -224,21 +215,9 @@
   SelectedMultilib = GCCInstallation.getMultilib();
   llvm::Triple::ArchType Arch = Triple.getArch();
   std::string SysRoot = computeSysRoot();
-
-  // Cross-compiling binutils and GCC installations (vanilla and openSUSE at
-  // least) put various tools in a triple-prefixed directory off of the parent
-  // of the GCC installation. We use the GCC triple here to ensure that we end
-  // up with tools that support the same amount of cross compiling as the
-  // detected GCC installation. For example, if we find a GCC installation
-  // targeting x86_64, but it is a bi-arch GCC installation, it can also be
-  // used to target i386.
-  // FIXME: This seems unlikely to be Linux-specific.
   ToolChain::path_list  = getProgramPaths();
-  if (GCCInstallation.isValid()) {
-PPaths.push_back(Twine(GCCInstallation.getParentLibPath() + "/../" +
-   GCCInstallation.getTriple().str() + "/bin")
- .str());
-  }
+
+  Generic_GCC::PushPPaths(PPaths);
 
   Distro Distro(D.getVFS(), Triple);
 
@@ -316,58 +295,7 @@
   const std::string OSLibDir = std::string(getOSLibDir(Triple, Args));
   const std::string MultiarchTriple = getMultiarchTriple(D, Triple, SysRoot);
 
-  // Add the multilib suffixed paths where they are available.
-  if (GCCInstallation.isValid()) {
-const llvm::Triple  = GCCInstallation.getTriple();
-const std::string  =
-std::string(GCCInstallation.getParentLibPath());
-
-// Add toolchain / multilib specific file paths.
-addMultilibsFilePaths(D, Multilibs, SelectedMultilib,
-  GCCInstallation.getInstallPath(), Paths);
-
-// Sourcery CodeBench MIPS toolchain holds some libraries under
-// a biarch-like suffix of the GCC installation.
-addPathIfExists(
-D, GCCInstallation.getInstallPath() + SelectedMultilib.gccSuffix(),
-Paths);
-
-// GCC cross compiling toolchains will install target libraries which ship
-// as part of the toolchain under // rather than as
-// any part of the GCC installation in
-// //gcc//. This decision is somewhat
-// debatable, but is the reality today. We need to search this tree even
-// when we have a sysroot somewhere else. It is the responsibility of
-// whomever is doing the cross build targeting a sysroot using a GCC
-// installation that is *not* within the system root to ensure two things:
-//
-//  1) Any DSOs that are linked in from this tree or from the install path
-// above must be present on the system root and found via an
-// appropriate rpath.
-//  2) There must not be libraries installed into
-// // unless they should be preferred over
-// those within the system root.
-//
-// Note that this matches the GCC behavior. See the below comment for where
-// Clang diverges from GCC's behavior.
-addPathIfExists(D, LibPath + "/../" + GCCTriple.str() + "/lib/../" +
-   OSLibDir + SelectedMultilib.osSuffix(),
-Paths);
-
-// If the GCC installation we found is inside of the sysroot, we want to
-// prefer libraries installed in the parent prefix of the GCC installation.
-// It is important to *not* use these paths when the GCC installation is
-// outside of the system root as that can pick up unintended libraries.
-// This usually happens when there is an external cross compiler on the
-// host system, and a more minimal sysroot available that is the target of
-// the cross. Note that GCC does include some of these directories in some
-// configurations but this seems somewhere between 

[PATCH] D78807: Fix gendered documentation

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere accepted this revision.
JDevlieghere added a comment.

Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78807



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

[PATCH] D78812: [SVE][CodeGen] Fix legalisation for scalable types

[Kerry McLaughlin via Phabricator via cfe-commits]

kmclaughlin created this revision.
kmclaughlin added reviewers: sdesmalen, efriedma, huntergr.
Herald added subscribers: psnobl, rkruppe, hiraditya, tschuett.
Herald added a project: LLVM.

This patch handles illegal scalable types when lowering IR operations,
addressing several places where the value of isScalableVector() is
ignored.

For types such as , this means splitting the
operations. In this example, we would split it into two
operations of type  for the low and high halves.

In cases such as , the elements in the vector
will be promoted. In this case they will be promoted to
i64 (with a vector of type )


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78812

Files:
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/TargetLoweringBase.cpp
  llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll

Index: llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
===
--- llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
+++ llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
@@ -22,6 +22,37 @@
   ret  %div
 }
 
+define  @sdiv_split_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_split_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: sdiv z0.s, p0/m, z0.s, z2.s
+; CHECK-DAG: sdiv z1.s, p0/m, z1.s, z3.s
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_widen_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_widen_i32
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sxtw z1.d, p0/m, z1.d
+; CHECK-DAG: sxtw z0.d, p0/m, z0.d
+; CHECK-DAG: sdiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_split_i64( %a,  %b) {
+; CHECK-LABEL: @sdiv_split_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sdiv z0.d, p0/m, z0.d, z2.d
+; CHECK-DAG: sdiv z1.d, p0/m, z1.d, z3.d
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
 ;
 ; UDIV
 ;
@@ -43,3 +74,34 @@
   %div = udiv  %a, %b
   ret  %div
 }
+
+define  @udiv_split_i32( %a,  %b) {
+; CHECK-LABEL: @udiv_split_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: udiv z0.s, p0/m, z0.s, z2.s
+; CHECK-DAG: udiv z1.s, p0/m, z1.s, z3.s
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
+
+define  @udiv_widen_i32( %a,  %b) {
+; CHECK-LABEL: @udiv_widen_i32
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: and z1.d, z1.d, #0x
+; CHECK-DAG: and z0.d, z0.d, #0x
+; CHECK-DAG: udiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
+
+define  @udiv_split_i64( %a,  %b) {
+; CHECK-LABEL: @udiv_split_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: udiv z0.d, p0/m, z0.d, z2.d
+; CHECK-DAG: udiv z1.d, p0/m, z1.d, z3.d
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
Index: llvm/lib/CodeGen/TargetLoweringBase.cpp
===
--- llvm/lib/CodeGen/TargetLoweringBase.cpp
+++ llvm/lib/CodeGen/TargetLoweringBase.cpp
@@ -1393,6 +1393,7 @@
 unsigned ,
 MVT ) const {
   unsigned NumElts = VT.getVectorNumElements();
+  bool IsScalable = VT.isScalableVector();
 
   // If there is a wider vector type with the same element type as this one,
   // or a promoted vector type that has the same number of elements which
@@ -1424,15 +1425,15 @@
 
   // Divide the input until we get to a supported size.  This will always
   // end with a scalar if the target doesn't support vectors.
-  while (NumElts > 1 && !isTypeLegal(
-   EVT::getVectorVT(Context, EltTy, NumElts))) {
+  while (NumElts > 1 &&
+ !isTypeLegal(EVT::getVectorVT(Context, EltTy, NumElts, IsScalable))) {
 NumElts >>= 1;
 NumVectorRegs <<= 1;
   }
 
   NumIntermediates = NumVectorRegs;
 
-  EVT NewVT = EVT::getVectorVT(Context, EltTy, NumElts);
+  EVT NewVT = EVT::getVectorVT(Context, EltTy, NumElts, IsScalable);
   if (!isTypeLegal(NewVT))
 NewVT = EltTy;
   IntermediateVT = NewVT;
Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -734,7 +734,8 @@
   unsigned DestVectorNoElts = NumIntermediates * IntermediateNumElts;
 
   EVT BuiltVectorTy = EVT::getVectorVT(
-  *DAG.getContext(), IntermediateVT.getScalarType(), DestVectorNoElts);
+  *DAG.getContext(), IntermediateVT.getScalarType(), DestVectorNoElts,
+  ValueVT.isScalableVector());
   if (ValueVT != BuiltVectorTy) {
 if (SDValue Widened = widenVectorToPartType(DAG, Val, DL, BuiltVectorTy))
   Val = Widened;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 6395980 - [Driver] Move GCC multilib/multiarch paths support from Linux.cpp to Gnu.cpp

[Fangrui Song via cfe-commits]

Author: Samuel Thibault
Date: 2020-04-24T09:33:19-07:00
New Revision: 63959803702c66cbd72f6526f43914039c1a027b

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

LOG: [Driver] Move GCC multilib/multiarch paths support from Linux.cpp to 
Gnu.cpp

The current code for GNU/Linux is actually completely generic, and can be moved 
to ToolChains/Gnu.cpp,
so that it can benefit GNU/Hurd and GNU/kFreeBSD.

Reviewed By: MaskRay, phosek

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/Gnu.h
clang/lib/Driver/ToolChains/Linux.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 0ea33fc20e86..315988faf40a 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -35,6 +35,7 @@ using namespace clang;
 using namespace llvm::opt;
 
 using tools::addMultilibFlag;
+using tools::addPathIfExists;
 
 void tools::GnuTool::anchor() {}
 
@@ -2670,6 +2671,140 @@ bool Generic_GCC::IsIntegratedAssemblerDefault() const {
   }
 }
 
+static void addMultilibsFilePaths(const Driver , const MultilibSet 
,
+  const Multilib ,
+  StringRef InstallPath,
+  ToolChain::path_list ) {
+  if (const auto  = Multilibs.filePathsCallback())
+for (const auto  : PathsCallback(Multilib))
+  addPathIfExists(D, InstallPath + Path, Paths);
+}
+
+void Generic_GCC::PushPPaths(ToolChain::path_list ) {
+  // Cross-compiling binutils and GCC installations (vanilla and openSUSE at
+  // least) put various tools in a triple-prefixed directory off of the parent
+  // of the GCC installation. We use the GCC triple here to ensure that we end
+  // up with tools that support the same amount of cross compiling as the
+  // detected GCC installation. For example, if we find a GCC installation
+  // targeting x86_64, but it is a bi-arch GCC installation, it can also be
+  // used to target i386.
+  if (GCCInstallation.isValid()) {
+PPaths.push_back(Twine(GCCInstallation.getParentLibPath() + "/../" +
+   GCCInstallation.getTriple().str() + "/bin")
+ .str());
+  }
+}
+
+void Generic_GCC::AddMultilibPaths(const Driver ,
+   const std::string ,
+   const std::string ,
+   const std::string ,
+   path_list ) {
+  // Add the multilib suffixed paths where they are available.
+  if (GCCInstallation.isValid()) {
+const llvm::Triple  = GCCInstallation.getTriple();
+const std::string  =
+std::string(GCCInstallation.getParentLibPath());
+
+// Add toolchain / multilib specific file paths.
+addMultilibsFilePaths(D, Multilibs, SelectedMultilib,
+  GCCInstallation.getInstallPath(), Paths);
+
+// Sourcery CodeBench MIPS toolchain holds some libraries under
+// a biarch-like suffix of the GCC installation.
+addPathIfExists(
+D, GCCInstallation.getInstallPath() + SelectedMultilib.gccSuffix(),
+Paths);
+
+// GCC cross compiling toolchains will install target libraries which ship
+// as part of the toolchain under // rather than as
+// any part of the GCC installation in
+// //gcc//. This decision is somewhat
+// debatable, but is the reality today. We need to search this tree even
+// when we have a sysroot somewhere else. It is the responsibility of
+// whomever is doing the cross build targeting a sysroot using a GCC
+// installation that is *not* within the system root to ensure two things:
+//
+//  1) Any DSOs that are linked in from this tree or from the install path
+// above must be present on the system root and found via an
+// appropriate rpath.
+//  2) There must not be libraries installed into
+// // unless they should be preferred over
+// those within the system root.
+//
+// Note that this matches the GCC behavior. See the below comment for where
+// Clang diverges from GCC's behavior.
+addPathIfExists(D,
+LibPath + "/../" + GCCTriple.str() + "/lib/../" + OSLibDir 
+
+SelectedMultilib.osSuffix(),
+Paths);
+
+// If the GCC installation we found is inside of the sysroot, we want to
+// prefer libraries installed in the parent prefix of the GCC installation.
+// It is important to *not* use these paths when the GCC installation is
+// outside of the system root as that can pick up unintended libraries.
+// This usually happens 

[PATCH] D77540: [PATCH] [ARM]: Armv8.6-a Matrix Mul Asm and Intrinsics Support

[Luke Geeson via Phabricator via cfe-commits]

LukeGeeson abandoned this revision.
LukeGeeson added a comment.

Sub-issues all closed


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

https://reviews.llvm.org/D77540



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

[PATCH] D78129: Add Marvell ThunderX3T110 support

[Wei Zhao via Phabricator via cfe-commits]

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



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:849-857
+// These pointer authentication instructions require armv8.3a
+let Predicates = [HasV8_3a, HasPA] in {
 let Uses = [LR], Defs = [LR] in {
   def PACIAZ   : SystemNoOperands<0b000, "hint\t#24">;
   def PACIBZ   : SystemNoOperands<0b010, "hint\t#26">;
   let isAuthenticated = 1 in {
 def AUTIAZ   : SystemNoOperands<0b100, "hint\t#28">;

ktkachov wrote:
> IIRC these instructions are deliberately allowed in pre-armv8.3 targets 
> because they are encoded in the NOP-space and can be deployed on pre-armv8.3 
> targets 
I will do some research on this.



Comment at: llvm/lib/Target/AArch64/AArch64SchedThunderX3T110.td:9
+//
+// This file defines the scheduling model for Marvell ThunderX3T101
+// family of processors.

ktkachov wrote:
> Typo in the processor name?
Sure, thanks for spotting it. I will have it fixed.


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

https://reviews.llvm.org/D78129



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

[PATCH] D78374: [Analyzer][StreamChecker] Added evaluation of fread and fwrite.

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

I gave a lot of thought to the high level logic, but I need some time to really 
internalize whats happening here.

In D78374#1993858 , @balazske wrote:

> Finally I had to make the decision to remove the `ErrorKindTy` enum and use 
> boolean flags instead for every possible error (including no error). This is 
> needed because we do not know always what error is possible if it is 
> "unknown". It could be determined from the last operation but now not any 
> more. The documentation for `fread` says that if 0 is passed as the size or 
> count argument the function returns zero and does not change the state. So 
> the error state before `fread` remains active. The new design is to have bool 
> values for every error kind (**feof** and **ferror** and a no-error state) so 
> multiple can be active in a state to indicate that more than one error state 
> is possible. If no-error or **feof** is possible these flags are turned on. 
> If we need to know in such a state if the stream is in **EOF** a state split 
> is needed to handle both cases (one with **EOF** and one with no-error). This 
> split must be done in the pre-call handler, for example if we want a warning 
> that the operation is not safe to use in **EOF** state. (But in this case 
> really no split is needed, only clear the EOF flag and make a warning.)


I guess one solution would be to have a history of last operations on the 
stream, but overall, it makes sense to have a make a shift to calculate the 
possible errors as we're evaluating the functions. Great idea!

> We can have another approach if we do not set return values of the functions 
> at all, instead save the symbol of the function and determine the returned 
> value later from the constraints actually applied on it. This may save state 
> splits, but only until a condition is encountered that checks for the 
> function's return value.

Or any stream modifying operation. If we don't have branches for the return 
value, that is almost a bug in itself. Also, digging the return value out of a 
branch condition may be difficult (see `ReturnValueChecker`). Lets stick with 
the state splits at the function call for now.




Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:222
 {StreamState::FEof, StreamState::FError, StreamState::NoError}}},
-  {{"ftell", 1}, {::preDefault, nullptr, 0, {}}},
+  // Note: ftell sets errno only.
+  {{"ftell", 1},

balazske wrote:
> Szelethus wrote:
> > Szelethus wrote:
> > > C'99 standard [[ 
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf | 
> > > §7.19.9.4.3]], about the `ftell function`:
> > > 
> > > > If successful, the `ftell` function returns the current value of the 
> > > > file position indicator for the stream. On failure, the `ftell` 
> > > > function returns `-1L` and stores an implementation-defined positive 
> > > > value in `errno`.
> > > 
> > > So we need an evalCall for this.
> > I mean, this function can only fail if the stream itself is an erroneous or 
> > closed state, right? So we can associate the -1 return value with the 
> > stream being in that, and the other with the stream being opened.
> The `ftell` is part of a later patch that is adding `ftell` (and probably 
> other functions). Only the "PossibleErrors" was updated in this patch because 
> its meaning was changed (it contains value even if only one error kind is 
> possible, before it was used only if at least two errors are possible).
> It is not sure how the file operations work, maybe the `ftell` needs access 
> to some data that is not available at the moment (and can fail even if the 
> stream was not OK). If the stream is already in failed state the question is: 
> Do ftell fail (then the we can make it return -1) or it does not fail but 
> gives an unusable value (then generate a checker warning and stop the 
> analysis).
In any case, this should be removed from the patch, because adding it seems to 
be an orthogonal change to this one.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:37
+/// Note: A stream has either FEOF or FERROR set but not both at the same time.
+struct StreamErrorState {
+  /// There is an execution path with none of the error flags set.

We're not describing the error state of a stream here, but rather //possible// 
error states, so the name should reflect that.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:207-210
+  {{"fread", 4},
+   {::preFread,
+std::bind(::evalFreadFwrite, _1, _2, _3, _4,
+  ErrorFEof | ErrorFError),

What does this mean? I guess not the possible states after an fread call, but 
rather the possible states after a **failed** fread call, but then...



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:225-228
   

[PATCH] D78129: Add Marvell ThunderX3T110 support

[Kyrill Tkachov via Phabricator via cfe-commits]

ktkachov added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:849-857
+// These pointer authentication instructions require armv8.3a
+let Predicates = [HasV8_3a, HasPA] in {
 let Uses = [LR], Defs = [LR] in {
   def PACIAZ   : SystemNoOperands<0b000, "hint\t#24">;
   def PACIBZ   : SystemNoOperands<0b010, "hint\t#26">;
   let isAuthenticated = 1 in {
 def AUTIAZ   : SystemNoOperands<0b100, "hint\t#28">;

IIRC these instructions are deliberately allowed in pre-armv8.3 targets because 
they are encoded in the NOP-space and can be deployed on pre-armv8.3 targets 



Comment at: llvm/lib/Target/AArch64/AArch64SchedThunderX3T110.td:9
+//
+// This file defines the scheduling model for Marvell ThunderX3T101
+// family of processors.

Typo in the processor name?


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

https://reviews.llvm.org/D78129



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

[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2871
+  // Overwrite the associated constraint of the Symbol.
+  Constraints = CF.remove(Constraints, Sym);
   Constraints = CF.add(Constraints, Sym, C.second);

martong wrote:
> martong wrote:
> > martong wrote:
> > > steakhal wrote:
> > > > How can we simplify this?
> > > Could we change the visitation logic to start with the `EndPathNode`? I 
> > > mean could we exercise `FalsePositiveRefutationBRVisitor` to start the 
> > > visitation from `EndPathNode`? If that was possible then this whole patch 
> > > would be way simpler.
> > > In BugReporter.cpp:
> > > ```
> > >   // Run visitors on all nodes starting from the node *before* the last 
> > > one.
> > >   // The last node is reserved for notes generated with {@code 
> > > getEndPath}.
> > >   const ExplodedNode *NextNode = ErrorNode->getFirstPred();
> > >   while (NextNode) {
> > > ```
> > > Why can't we have a different visitation order implemented specifically 
> > > for the refutation visitor? (@NoQ, @xazax.hun)
> > Hmm, to answer my own question, then we would visit the ErrorNode twice. So 
> > then perhaps we should not allow any constraints in the ErrorNodes, right? 
> > What if we'd split all such ErrorNodes into a PrevNode with the constraints 
> > and a simple ErrorNode without the constraints?
> @xazax.hun, and others: Any thoughts on my comments above? What do you think, 
> would it be possible to split the error node into two nodes? A PrevNode with 
> the constraints and a simple ErrorNode without the constraints?
I think this would make a lot of sense in the context of this visitor. But we 
would need to check if it also makes sense in the context of the other parts of 
the analyzer (other visitors and mechanisms like bug report generation). I'd 
prefer such a change to be a separate patch so we can assess it easier whether 
it makes things easier or more complicated. I think it might be worth to 
experiment with.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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

[PATCH] D77875: [ARM] Armv8.6-a Matrix Mul cmd line support

[Luke Geeson via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG740a1dd050ee: [ARM] Armv8.6-a Matrix Mul cmd line support 
(authored by LukeGeeson).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77875

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm-matrix-multiply.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/AArch64TargetParser.h
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.h
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -636,6 +636,7 @@
   {"maverick", "maverick", nullptr, nullptr},
   {"xscale", "noxscale", nullptr, nullptr},
   {"sb", "nosb", "+sb", "-sb"},
+  {"i8mm", "noi8mm", "+i8mm", "-i8mm"},
   {"mve", "nomve", "+mve", "-mve"},
   {"mve.fp", "nomve.fp", "+mve.fp", "-mve.fp"}};
 
@@ -1230,7 +1231,10 @@
   {"tme", "notme", "+tme", "-tme"},
   {"ssbs", "nossbs", "+ssbs", "-ssbs"},
   {"sb", "nosb", "+sb", "-sb"},
-  {"predres", "nopredres", "+predres", "-predres"}
+  {"predres", "nopredres", "+predres", "-predres"},
+  {"i8mm", "noi8mm", "+i8mm", "-i8mm"},
+  {"f32mm", "nof32mm", "+f32mm", "-f32mm"},
+  {"f64mm", "nof64mm", "+f64mm", "-f64mm"},
 };
 
   for (unsigned i = 0; i < array_lengthof(ArchExt); i++) {
Index: llvm/include/llvm/Support/ARMTargetParser.h
===
--- llvm/include/llvm/Support/ARMTargetParser.h
+++ llvm/include/llvm/Support/ARMTargetParser.h
@@ -47,14 +47,15 @@
   AEK_FP_DP   = 1 << 18,
   AEK_LOB = 1 << 19,
   AEK_BF16= 1 << 20,
-  AEK_CDECP0 =  1 << 21,
-  AEK_CDECP1 =  1 << 22,
-  AEK_CDECP2 =  1 << 23,
-  AEK_CDECP3 =  1 << 24,
-  AEK_CDECP4 =  1 << 25,
-  AEK_CDECP5 =  1 << 26,
-  AEK_CDECP6 =  1 << 27,
-  AEK_CDECP7 =  1 << 28,
+  AEK_I8MM= 1 << 21,
+  AEK_CDECP0 =  1 << 22,
+  AEK_CDECP1 =  1 << 23,
+  AEK_CDECP2 =  1 << 24,
+  AEK_CDECP3 =  1 << 25,
+  AEK_CDECP4 =  1 << 26,
+  AEK_CDECP5 =  1 << 27,
+  AEK_CDECP6 =  1 << 28,
+  AEK_CDECP7 =  1 << 29,
 
   // Unsupported extensions.
   AEK_OS   =1ULL << 59,
Index: llvm/include/llvm/Support/ARMTargetParser.def
===
--- llvm/include/llvm/Support/ARMTargetParser.def
+++ llvm/include/llvm/Support/ARMTargetParser.def
@@ -116,7 +116,8 @@
  ARMBuildAttrs::CPUArch::v8_A, FK_CRYPTO_NEON_FP_ARMV8,
  (ARM::AEK_SEC| ARM::AEK_MP   | ARM::AEK_VIRT | ARM::AEK_HWDIVARM |
   ARM::AEK_HWDIVTHUMB | ARM::AEK_DSP  | ARM::AEK_CRC  | ARM::AEK_RAS |
-  ARM::AEK_DOTPROD| ARM::AEK_BF16 | ARM::AEK_SHA2 | ARM::AEK_AES))
+  ARM::AEK_DOTPROD| ARM::AEK_BF16 | ARM::AEK_SHA2 | ARM::AEK_AES |
+  ARM::AEK_I8MM))
 ARM_ARCH("armv8-r", ARMV8R, "8-R", "v8r", ARMBuildAttrs::CPUArch::v8_R,
   FK_NEON_FP_ARMV8,
   (ARM::AEK_MP | ARM::AEK_VIRT | ARM::AEK_HWDIVARM | ARM::AEK_HWDIVTHUMB |
@@ -171,6 +172,7 @@
 ARM_ARCH_EXT_NAME("fp16fml",  ARM::AEK_FP16FML,  "+fp16fml", "-fp16fml")
 ARM_ARCH_EXT_NAME("bf16", ARM::AEK_BF16, "+bf16","-bf16")
 ARM_ARCH_EXT_NAME("sb",   ARM::AEK_SB,   "+sb",  "-sb")
+ARM_ARCH_EXT_NAME("i8mm", ARM::AEK_I8MM, "+i8mm","-i8mm")
 ARM_ARCH_EXT_NAME("lob",  ARM::AEK_LOB,  "+lob",   "-lob")
 ARM_ARCH_EXT_NAME("cdecp0",   ARM::AEK_CDECP0,   "+cdecp0",  "-cdecp0")
 ARM_ARCH_EXT_NAME("cdecp1",   ARM::AEK_CDECP1,   "+cdecp1",  "-cdecp1")
Index: llvm/include/llvm/Support/AArch64TargetParser.h
===
--- llvm/include/llvm/Support/AArch64TargetParser.h
+++ llvm/include/llvm/Support/AArch64TargetParser.h
@@ -24,7 +24,7 @@
 namespace AArch64 {
 
 // Arch extension modifiers for CPUs.
-enum ArchExtKind : unsigned {
+enum ArchExtKind : uint64_t {
   AEK_INVALID = 0,
   AEK_NONE =1,
   AEK_CRC = 1 << 1,
@@ -57,6 +57,8 @@
   AEK_TME = 1 << 28,
   AEK_BF16 =1 << 29,
   AEK_I8MM =1 << 30,
+  AEK_F32MM =   1ULL << 31,
+  AEK_F64MM =   1ULL << 32,
 };
 
 enum class ArchKind {
Index: llvm/include/llvm/Support/AArch64TargetParser.def

[PATCH] D77872: [AArch32] Armv8.6-a Matrix Mult Assembly + Intrinsics

[Luke Geeson via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
LukeGeeson marked an inline comment as done.
Closed by commit rG7da190512532: [AArch32] Armv8.6-a Matrix Mult Assembly + 
Intrinsics (authored by LukeGeeson).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77872

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/arm-v8.6a-neon-intrinsics.c
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMInstrNEON.td
  llvm/lib/Target/ARM/ARMPredicates.td
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/test/CodeGen/ARM/arm-matmul.ll

Index: llvm/test/CodeGen/ARM/arm-matmul.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/arm-matmul.ll
@@ -0,0 +1,83 @@
+; RUN: llc -mtriple=arm-none-linux-gnu -mattr=+neon,+i8mm -float-abi=hard < %s -o -| FileCheck %s
+
+define <4 x i32> @smmla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) {
+entry:
+; CHECK-LABEL: smmla.v4i32.v16i8
+; CHECK:vsmmla.s8   q0, q1, q2
+  %vmmla1.i = tail call <4 x i32> @llvm.arm.neon.smmla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) #3
+  ret <4 x i32> %vmmla1.i
+}
+
+define <4 x i32> @ummla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) {
+entry:
+; CHECK-LABEL: ummla.v4i32.v16i8
+; CHECK:vummla.u8   q0, q1, q2
+  %vmmla1.i = tail call <4 x i32> @llvm.arm.neon.ummla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) #3
+  ret <4 x i32> %vmmla1.i
+}
+
+define <4 x i32> @usmmla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) {
+entry:
+; CHECK-LABEL: usmmla.v4i32.v16i8
+; CHECK:vusmmla.s8   q0, q1, q2
+  %vusmmla1.i = tail call <4 x i32> @llvm.arm.neon.usmmla.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %b) #3
+  ret <4 x i32> %vusmmla1.i
+}
+
+define <2 x i32> @usdot.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: usdot.v2i32.v8i8
+; CHECK:vusdot.s8   d0, d1, d2
+  %vusdot1.i = tail call <2 x i32> @llvm.arm.neon.usdot.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %b) #3
+  ret <2 x i32> %vusdot1.i
+}
+
+define <2 x i32> @usdot_lane.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: usdot_lane.v2i32.v8i8
+; CHECK:vusdot.s8   d0, d1, d2[0]
+  %0 = bitcast <8 x i8> %b to <2 x i32>
+  %shuffle = shufflevector <2 x i32> %0, <2 x i32> undef, <2 x i32> zeroinitializer
+  %1 = bitcast <2 x i32> %shuffle to <8 x i8>
+  %vusdot1.i = tail call <2 x i32> @llvm.arm.neon.usdot.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %1) #3
+  ret <2 x i32> %vusdot1.i
+}
+
+define <2 x i32> @sudot_lane.v2i32.v8i8(<2 x i32> %r, <8 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: sudot_lane.v2i32.v8i8
+; CHECK:vsudot.u8   d0, d1, d2[0]
+  %0 = bitcast <8 x i8> %b to <2 x i32>
+  %shuffle = shufflevector <2 x i32> %0, <2 x i32> undef, <2 x i32> zeroinitializer
+  %1 = bitcast <2 x i32> %shuffle to <8 x i8>
+  %vusdot1.i = tail call <2 x i32> @llvm.arm.neon.usdot.v2i32.v8i8(<2 x i32> %r, <8 x i8> %1, <8 x i8> %a) #3
+  ret <2 x i32> %vusdot1.i
+}
+
+define <4 x i32> @usdotq_lane.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: usdotq_lane.v4i32.v16i8
+; CHECK:vusdot.s8   q0, q1, d4[0]
+  %0 = bitcast <8 x i8> %b to <2 x i32>
+  %shuffle = shufflevector <2 x i32> %0, <2 x i32> undef, <4 x i32> zeroinitializer
+  %1 = bitcast <4 x i32> %shuffle to <16 x i8>
+  %vusdot1.i = tail call <4 x i32> @llvm.arm.neon.usdot.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <16 x i8> %1) #3
+  ret <4 x i32> %vusdot1.i
+}
+
+define <4 x i32> @sudotq_lane.v4i32.v16i8(<4 x i32> %r, <16 x i8> %a, <8 x i8> %b) {
+entry:
+; CHECK-LABEL: sudotq_lane.v4i32.v16i8
+; CHECK:vsudot.u8   q0, q1, d4[0]
+  %0 = bitcast <8 x i8> %b to <2 x i32>
+  %shuffle = shufflevector <2 x i32> %0, <2 x i32> undef, <4 x i32> zeroinitializer
+  %1 = bitcast <4 x i32> %shuffle to <16 x i8>
+  %vusdot1.i = tail call <4 x i32> @llvm.arm.neon.usdot.v4i32.v16i8(<4 x i32> %r, <16 x i8> %1, <16 x i8> %a) #3
+  ret <4 x i32> %vusdot1.i
+}
+
+declare <4 x i32> @llvm.arm.neon.smmla.v4i32.v16i8(<4 x i32>, <16 x i8>, <16 x i8>) #2
+declare <4 x i32> @llvm.arm.neon.ummla.v4i32.v16i8(<4 x i32>, <16 x i8>, <16 x i8>) #2
+declare <4 x i32> @llvm.arm.neon.usmmla.v4i32.v16i8(<4 x i32>, <16 x i8>, <16 x i8>) #2
+declare <2 x i32> @llvm.arm.neon.usdot.v2i32.v8i8(<2 x i32>, <8 x i8>, <8 x i8>) #2
+declare <4 x i32> @llvm.arm.neon.usdot.v4i32.v16i8(<4 x i32>, <16 x i8>, <16 x i8>) #2
Index: llvm/lib/Target/ARM/ARMSubtarget.h
===
--- llvm/lib/Target/ARM/ARMSubtarget.h
+++ llvm/lib/Target/ARM/ARMSubtarget.h
@@ -260,6 +260,9 @@
   /// HasBF16 - True if subtarget supports BFloat16 floating point operations

[PATCH] D77871: [AArch64] Armv8.6-a Matrix Mult Assembly + Intrinsics

[Luke Geeson via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG832cd749131b: [AArch64] Armv8.6-a Matrix Mult Assembly + 
Intrinsics (authored by LukeGeeson).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77871

Files:
  clang/include/clang/Basic/arm_neon.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-matmul.cpp
  clang/test/CodeGen/aarch64-v8.6a-neon-intrinsics.c
  llvm/include/llvm/IR/IntrinsicsAArch64.td
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/test/CodeGen/AArch64/aarch64-matmul.ll
  llvm/test/MC/AArch64/armv8.6a-simd-matmul-error.s
  llvm/test/MC/AArch64/armv8.6a-simd-matmul.s
  llvm/test/MC/Disassembler/AArch64/armv8.6a-simd-matmul.txt

Index: llvm/test/MC/Disassembler/AArch64/armv8.6a-simd-matmul.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/AArch64/armv8.6a-simd-matmul.txt
@@ -0,0 +1,34 @@
+# RUN: llvm-mc -triple=aarch64  -mattr=+i8mm -disassemble < %s   | FileCheck %s
+# RUN: llvm-mc -triple=aarch64  -mattr=+v8.6a -disassemble < %s  | FileCheck %s
+# RUN: not llvm-mc -triple=aarch64  -mattr=+v8.5a -disassemble < %s 2>&1 | FileCheck %s --check-prefix=NOI8MM
+
+[0x01,0xa6,0x9f,0x4e]
+[0x01,0xa6,0x9f,0x6e]
+[0x01,0xae,0x9f,0x4e]
+# CHECK: smmla   v1.4s, v16.16b, v31.16b
+# CHECK: ummla   v1.4s, v16.16b, v31.16b
+# CHECK: usmmla  v1.4s, v16.16b, v31.16b
+# NOI8MM: [[@LINE-6]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-6]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-6]]:{{[0-9]+}}: warning: invalid instruction encoding
+
+[0xe3,0x9d,0x9e,0x0e]
+[0xe3,0x9d,0x9e,0x4e]
+# CHECK: usdot   v3.2s, v15.8b, v30.8b
+# CHECK: usdot   v3.4s, v15.16b, v30.16b
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+
+[0x3f,0xf8,0xa2,0x0f]
+[0x3f,0xf8,0xa2,0x4f]
+# CHECK: usdot   v31.2s, v1.8b, v2.4b[3]
+# CHECK: usdot   v31.4s, v1.16b, v2.4b[3]
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+
+[0x3f,0xf8,0x22,0x0f]
+[0x3f,0xf8,0x22,0x4f]
+# CHECK: sudot   v31.2s, v1.8b, v2.4b[3]
+# CHECK: sudot   v31.4s, v1.16b, v2.4b[3]
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
+# NOI8MM: [[@LINE-4]]:{{[0-9]+}}: warning: invalid instruction encoding
Index: llvm/test/MC/AArch64/armv8.6a-simd-matmul.s
===
--- /dev/null
+++ llvm/test/MC/AArch64/armv8.6a-simd-matmul.s
@@ -0,0 +1,43 @@
+// RUN: llvm-mc -triple aarch64 -show-encoding -mattr=+i8mm   < %s  | FileCheck %s
+// RUN: llvm-mc -triple aarch64 -show-encoding -mattr=+v8.6a  < %s  | FileCheck %s
+// RUN: not llvm-mc -triple aarch64 -show-encoding -mattr=+v8.6a-i8mm < %s 2>&1 | FileCheck %s --check-prefix=NOMATMUL
+
+smmla  v1.4s, v16.16b, v31.16b
+ummla  v1.4s, v16.16b, v31.16b
+usmmla v1.4s, v16.16b, v31.16b
+// CHECK: smmla   v1.4s, v16.16b, v31.16b // encoding: [0x01,0xa6,0x9f,0x4e]
+// CHECK: ummla   v1.4s, v16.16b, v31.16b // encoding: [0x01,0xa6,0x9f,0x6e]
+// CHECK: usmmla  v1.4s, v16.16b, v31.16b // encoding: [0x01,0xae,0x9f,0x4e]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: smmla  v1.4s, v16.16b, v31.16b
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: ummla  v1.4s, v16.16b, v31.16b
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usmmla  v1.4s, v16.16b, v31.16b
+
+usdot v3.2s, v15.8b, v30.8b
+usdot v3.4s, v15.16b, v30.16b
+// CHECK: usdot   v3.2s, v15.8b, v30.8b   // encoding: [0xe3,0x9d,0x9e,0x0e]
+// CHECK: usdot   v3.4s, v15.16b, v30.16b // encoding: [0xe3,0x9d,0x9e,0x4e]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usdot v3.2s, v15.8b, v30.8b
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usdot v3.4s, v15.16b, v30.16b
+
+usdot v31.2s, v1.8b,  v2.4b[3]
+usdot v31.4s, v1.16b, v2.4b[3]
+// CHECK: usdot   v31.2s, v1.8b, v2.4b[3] // encoding: [0x3f,0xf8,0xa2,0x0f]
+// CHECK: usdot   v31.4s, v1.16b, v2.4b[3] // encoding: [0x3f,0xf8,0xa2,0x4f]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usdot   v31.2s, v1.8b, v2.4b[3]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: usdot   v31.4s, v1.16b, v2.4b[3]
+
+sudot v31.2s, v1.8b,  v2.4b[3]
+sudot v31.4s, v1.16b, v2.4b[3]
+// CHECK: sudot   v31.2s, v1.8b, v2.4b[3] // encoding: [0x3f,0xf8,0x22,0x0f]
+// CHECK: sudot   v31.4s, v1.16b, v2.4b[3] // encoding: [0x3f,0xf8,0x22,0x4f]
+// NOMATMUL: instruction requires: i8mm
+// NOMATMUL-NEXT: sudot   v31.2s, v1.8b, 

[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2869
+  Constraints = CF.add(Constraints, Sym, C.second);
+} else if (!OnlyForNewSymbols) {
+  // Overwrite the associated constraint of the Symbol.

If there is really no other way (see my comments below) then perhaps 
`OverwriteConstraintsOnExistingSyms` would be a better naming than 
`OnlyForNewSymbols` because it expresses what exactly is happening.
In either case, could you add some documentation (comments) to 
`addConstraints`? What it does, and what is the exact meaning of the param?



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2871
+  // Overwrite the associated constraint of the Symbol.
+  Constraints = CF.remove(Constraints, Sym);
   Constraints = CF.add(Constraints, Sym, C.second);

martong wrote:
> martong wrote:
> > steakhal wrote:
> > > How can we simplify this?
> > Could we change the visitation logic to start with the `EndPathNode`? I 
> > mean could we exercise `FalsePositiveRefutationBRVisitor` to start the 
> > visitation from `EndPathNode`? If that was possible then this whole patch 
> > would be way simpler.
> > In BugReporter.cpp:
> > ```
> >   // Run visitors on all nodes starting from the node *before* the last one.
> >   // The last node is reserved for notes generated with {@code getEndPath}.
> >   const ExplodedNode *NextNode = ErrorNode->getFirstPred();
> >   while (NextNode) {
> > ```
> > Why can't we have a different visitation order implemented specifically for 
> > the refutation visitor? (@NoQ, @xazax.hun)
> Hmm, to answer my own question, then we would visit the ErrorNode twice. So 
> then perhaps we should not allow any constraints in the ErrorNodes, right? 
> What if we'd split all such ErrorNodes into a PrevNode with the constraints 
> and a simple ErrorNode without the constraints?
@xazax.hun, and others: Any thoughts on my comments above? What do you think, 
would it be possible to split the error node into two nodes? A PrevNode with 
the constraints and a simple ErrorNode without the constraints?



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:194
+  // This assumption is false!
+  // 'y' can not be 5 if the maximal value of both x and y is 2.
+  // This bugreport must be caught by the visitor, since the 
constraints

martong wrote:
> `x and y` -> `x and n`.
It's not done. It is still `x and y` but should be `x and n`, isn't it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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