[clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3804: lacking () for c… (PR #90391)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

PR should be named according to what they are actually achieving, I'm not sure 
why the GitHub issue title is relevant?

https://github.com/llvm/llvm-project/pull/90391
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] CTAD: Fix require-clause is not transformed. (PR #89378)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

This seems to have broken the bot: 
https://github.com/llvm/llvm-project/pull/89476 (you should have had an email?)

I reverted in https://github.com/llvm/llvm-project/pull/89476

https://github.com/llvm/llvm-project/pull/89378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revert "[clang] CTAD: Fix require-clause is not transformed." (PR #89476)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/89476
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revert "[clang] CTAD: Fix require-clause is not transformed." (PR #89476)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph created 
https://github.com/llvm/llvm-project/pull/89476

Reverts llvm/llvm-project#89378

Broke the windows premerge checks 
https://lab.llvm.org/buildbot/#/builders/271/builds/6788


>From 7897826aa7931ffc854a88b20e5ab8bf976ad093 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Sat, 20 Apr 2024 02:34:03 +0200
Subject: [PATCH] Revert "[clang] CTAD: Fix require-clause is not transformed.
 (#89378)"

This reverts commit c8e65e193d542464421ad4f9a9965d45b302ac0c.
---
 clang/lib/Sema/SemaTemplate.cpp  | 27 +--
 clang/lib/Sema/SemaTemplateInstantiate.cpp   |  5 +++-
 clang/test/SemaCXX/cxx20-ctad-type-alias.cpp | 18 -
 clang/test/SemaTemplate/deduction-guide.cpp  | 28 
 4 files changed, 17 insertions(+), 61 deletions(-)

diff --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index 4bda31ba67c02d..d4976f9d0d11d8 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -2962,6 +2962,19 @@ void DeclareImplicitDeductionGuidesForTypeAlias(
   Context.getCanonicalTemplateArgument(
   Context.getInjectedTemplateArg(NewParam));
 }
+// Substitute new template parameters into requires-clause if present.
+Expr *RequiresClause =
+transformRequireClause(SemaRef, F, TemplateArgsForBuildingFPrime);
+// FIXME: implement the is_deducible constraint per C++
+// [over.match.class.deduct]p3.3:
+//... and a constraint that is satisfied if and only if the arguments
+//of A are deducible (see below) from the return type.
+auto *FPrimeTemplateParamList = TemplateParameterList::Create(
+Context, AliasTemplate->getTemplateParameters()->getTemplateLoc(),
+AliasTemplate->getTemplateParameters()->getLAngleLoc(),
+FPrimeTemplateParams,
+AliasTemplate->getTemplateParameters()->getRAngleLoc(),
+/*RequiresClause=*/RequiresClause);
 
 // To form a deduction guide f' from f, we leverage clang's instantiation
 // mechanism, we construct a template argument list where the template
@@ -3007,20 +3020,6 @@ void DeclareImplicitDeductionGuidesForTypeAlias(
 F, TemplateArgListForBuildingFPrime, AliasTemplate->getLocation(),
 Sema::CodeSynthesisContext::BuildingDeductionGuides)) {
   auto *GG = cast(FPrime);
-  // Substitute new template parameters into requires-clause if present.
-  Expr *RequiresClause =
-  transformRequireClause(SemaRef, F, TemplateArgsForBuildingFPrime);
-  // FIXME: implement the is_deducible constraint per C++
-  // [over.match.class.deduct]p3.3:
-  //... and a constraint that is satisfied if and only if the arguments
-  //of A are deducible (see below) from the return type.
-  auto *FPrimeTemplateParamList = TemplateParameterList::Create(
-  Context, AliasTemplate->getTemplateParameters()->getTemplateLoc(),
-  AliasTemplate->getTemplateParameters()->getLAngleLoc(),
-  FPrimeTemplateParams,
-  AliasTemplate->getTemplateParameters()->getRAngleLoc(),
-  /*RequiresClause=*/RequiresClause);
-
   buildDeductionGuide(SemaRef, AliasTemplate, FPrimeTemplateParamList,
   GG->getCorrespondingConstructor(),
   GG->getExplicitSpecifier(), GG->getTypeSourceInfo(),
diff --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp 
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index 98d5c7cb3a8a80..3e6676f21c9be0 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -2502,7 +2502,10 @@ 
TemplateInstantiator::TransformTemplateTypeParmType(TypeLocBuilder ,
   assert(Arg.getKind() == TemplateArgument::Type &&
  "unexpected nontype template argument kind in template rewrite");
   QualType NewT = Arg.getAsType();
-  TLB.pushTrivial(SemaRef.Context, NewT, TL.getNameLoc());
+  assert(isa(NewT) &&
+ "type parm not rewritten to type parm");
+  auto NewTL = TLB.push(NewT);
+  NewTL.setNameLoc(TL.getNameLoc());
   return NewT;
 }
 
diff --git a/clang/test/SemaCXX/cxx20-ctad-type-alias.cpp 
b/clang/test/SemaCXX/cxx20-ctad-type-alias.cpp
index 508a3a5da76a91..6f04264a655ad5 100644
--- a/clang/test/SemaCXX/cxx20-ctad-type-alias.cpp
+++ b/clang/test/SemaCXX/cxx20-ctad-type-alias.cpp
@@ -289,21 +289,3 @@ using String = Array;
 // Verify no crash on constructing the aggregate deduction guides.
 String s("hello");
 } // namespace test21
-
-// GH89013
-namespace test22 {
-class Base {};
-template 
-class Derived final : public Base {};
-
-template 
-requires __is_base_of(Base, D)
-struct Foo {
-  explicit Foo(D) {}
-};
-
-template 
-using AFoo = Foo>;
-
-AFoo a(Derived{});
-} // namespace test22
diff --git a/clang/test/SemaTemplate/deduction-guide.cpp 
b/clang/test/SemaTemplate/deduction-guide.cpp
index 29cc5a9b996f95..58f08aa1eed650 100644
--- 

[clang] [llvm] [mlir] Fix warning about mismatches between function parameter and call-site args names (PR #89294)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph edited 
https://github.com/llvm/llvm-project/pull/89294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [mlir] Fix Definition Mismatches (PR #89294)

[Mehdi Amini via cfe-commits]

@@ -433,7 +433,7 @@ class LLVM_LIBRARY_VISIBILITY InstCombinerImpl final
   Value *foldAndOrOfICmpsOfAndWithPow2(ICmpInst *LHS, ICmpInst *RHS,
Instruction *CxtI, bool IsAnd,
bool IsLogical = false);
-  Value *matchSelectFromAndOr(Value *A, Value *B, Value *C, Value *D,

joker-eph wrote:

You could fix the warning by using vastly different names for the function 
parameters?

https://github.com/llvm/llvm-project/pull/89294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Mark alias/ifunc targets used and consider mangled names (PR #87130)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

This broke a bot, I reverted and it's back green here: 
https://lab.llvm.org/buildbot/#/builders/272/builds/14069

https://github.com/llvm/llvm-project/pull/87130
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Revert "[Sema] Mark alias/ifunc targets used and consider mangled names" (PR #88919)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/88919
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Revert "[Sema] Mark alias/ifunc targets used and consider mangled names" (PR #88919)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph created 
https://github.com/llvm/llvm-project/pull/88919

Reverts llvm/llvm-project#87130

Bot is broken with clang crash: 
https://lab.llvm.org/buildbot/#/builders/272/builds/14063/steps/6/logs/stdio



>From 271a8c2e5c8f57ab5d37f6056713dab530424470 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Tue, 16 Apr 2024 17:44:12 +0200
Subject: [PATCH] Revert "[Sema] Mark alias/ifunc targets used and consider
 mangled names"

This reverts commit 2ac562ab784c6bf04e6d3026c567d3552a735668.
---
 clang/lib/Sema/CMakeLists.txt |  1 -
 clang/lib/Sema/SemaDeclAttr.cpp   | 44 +--
 clang/test/AST/ast-dump-attr-json.cpp |  1 -
 clang/test/Sema/alias-unused-win.cpp  |  2 +-
 clang/test/Sema/alias-unused.cpp  | 16 +++
 .../llvm-project-overlay/clang/BUILD.bazel|  1 -
 6 files changed, 19 insertions(+), 46 deletions(-)

diff --git a/clang/lib/Sema/CMakeLists.txt b/clang/lib/Sema/CMakeLists.txt
index a96439df664228..ab3b813a9ccd97 100644
--- a/clang/lib/Sema/CMakeLists.txt
+++ b/clang/lib/Sema/CMakeLists.txt
@@ -1,6 +1,5 @@
 set(LLVM_LINK_COMPONENTS
   Core
-  Demangle
   FrontendHLSL
   FrontendOpenMP
   MC
diff --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index d26f130b5774ce..b7b1fbc625a150 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -45,7 +45,6 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/STLForwardCompat.h"
 #include "llvm/ADT/StringExtras.h"
-#include "llvm/Demangle/Demangle.h"
 #include "llvm/IR/Assumptions.h"
 #include "llvm/MC/MCSectionMachO.h"
 #include "llvm/Support/Error.h"
@@ -1984,36 +1983,6 @@ static void handleWeakRefAttr(Sema , Decl *D, const 
ParsedAttr ) {
   D->addAttr(::new (S.Context) WeakRefAttr(S.Context, AL));
 }
 
-// Mark alias/ifunc target as used. Due to name mangling, we look up the
-// demangled name ignoring parameters (not supported by microsoftDemangle
-// https://github.com/llvm/llvm-project/issues/88825). This should handle the
-// majority of use cases while leaving namespace scope names unmarked.
-static void markUsedForAliasOrIfunc(Sema , Decl *D, const ParsedAttr ,
-StringRef Str) {
-  std::unique_ptr Demangled;
-  if (S.getASTContext().getCXXABIKind() != TargetCXXABI::Microsoft)
-Demangled.reset(llvm::itaniumDemangle(Str, /*ParseParams=*/false));
-  std::unique_ptr MC(S.Context.createMangleContext());
-  SmallString<256> Name;
-
-  const DeclarationNameInfo Target(
-  (Demangled ? Demangled.get() : Str), AL.getLoc());
-  LookupResult LR(S, Target, Sema::LookupOrdinaryName);
-  if (S.LookupName(LR, S.TUScope)) {
-for (NamedDecl *ND : LR) {
-  if (MC->shouldMangleDeclName(ND)) {
-llvm::raw_svector_ostream Out(Name);
-Name.clear();
-MC->mangleName(GlobalDecl(ND), Out);
-  } else {
-Name = ND->getIdentifier()->getName();
-  }
-  if (Name == Str)
-ND->markUsed(S.Context);
-}
-  }
-}
-
 static void handleIFuncAttr(Sema , Decl *D, const ParsedAttr ) {
   StringRef Str;
   if (!S.checkStringLiteralArgumentAttr(AL, 0, Str))
@@ -2026,7 +1995,6 @@ static void handleIFuncAttr(Sema , Decl *D, const 
ParsedAttr ) {
 return;
   }
 
-  markUsedForAliasOrIfunc(S, D, AL, Str);
   D->addAttr(::new (S.Context) IFuncAttr(S.Context, AL, Str));
 }
 
@@ -2061,7 +2029,17 @@ static void handleAliasAttr(Sema , Decl *D, const 
ParsedAttr ) {
 }
   }
 
-  markUsedForAliasOrIfunc(S, D, AL, Str);
+  // Mark target used to prevent unneeded-internal-declaration warnings.
+  if (!S.LangOpts.CPlusPlus) {
+// FIXME: demangle Str for C++, as the attribute refers to the mangled
+// linkage name, not the pre-mangled identifier.
+const DeclarationNameInfo target((Str), AL.getLoc());
+LookupResult LR(S, target, Sema::LookupOrdinaryName);
+if (S.LookupQualifiedName(LR, S.getCurLexicalContext()))
+  for (NamedDecl *ND : LR)
+ND->markUsed(S.Context);
+  }
+
   D->addAttr(::new (S.Context) AliasAttr(S.Context, AL, Str));
 }
 
diff --git a/clang/test/AST/ast-dump-attr-json.cpp 
b/clang/test/AST/ast-dump-attr-json.cpp
index 883e584bfedf07..051c2956abfdf7 100644
--- a/clang/test/AST/ast-dump-attr-json.cpp
+++ b/clang/test/AST/ast-dump-attr-json.cpp
@@ -46,7 +46,6 @@ __thread __attribute__ ((tls_model ("local-exec"))) int 
tls_model_var;
 // CHECK-NEXT:"tokLen": 11
 // CHECK-NEXT:   }
 // CHECK-NEXT:  },
-// CHECK-NEXT:  "isUsed": true,
 // CHECK-NEXT:  "name": "global_decl",
 // CHECK-NEXT:  "mangledName": "global_decl",
 // CHECK-NEXT:  "type": {
diff --git a/clang/test/Sema/alias-unused-win.cpp 
b/clang/test/Sema/alias-unused-win.cpp
index 97d57a3bbd1e31..47c96d41175179 100644
--- a/clang/test/Sema/alias-unused-win.cpp
+++ b/clang/test/Sema/alias-unused-win.cpp
@@ -7,7 +7,7 @@ extern "C" {
 static int f(void) { return 42; } // cxx-warning{{unused function 'f'}}
 int g(void) 

[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

LGTM overall, but the CI failure looks real.

https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Add missing clang to the monolithic pre-merge build (PR #85354)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph created 
https://github.com/llvm/llvm-project/pull/85354

Clang has a custom separate pipeline integrated with libc++ that only runs in 
release mode. It means that changes which touches only clang won't run the 
clang tests in the configuration used by LLVM premerge and will break it 
unknowingly.

>From d4286b64b9e4eb7743edccbe3f1a3c117a8d0fc0 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Thu, 14 Mar 2024 19:49:29 -0700
Subject: [PATCH] Add missing clang to the monolithic pre-merge build

Clang has a custom separate pipeline integrated with libc++
that only runs in release mode. It means that changes which touches
only clang won't run the clang tests in the configuration used by
LLVM premerge and will break it unknowingly.
---
 .ci/generate-buildkite-pipeline-premerge | 2 +-
 clang/empty_trigger  | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 clang/empty_trigger

diff --git a/.ci/generate-buildkite-pipeline-premerge 
b/.ci/generate-buildkite-pipeline-premerge
index 4ebf304e23d587..b0a995dc8d7df4 100755
--- a/.ci/generate-buildkite-pipeline-premerge
+++ b/.ci/generate-buildkite-pipeline-premerge
@@ -224,7 +224,7 @@ fi
 # needs while letting them run on the infrastructure provided by LLVM.
 
 # Figure out which projects need to be built on each platform
-all_projects="bolt clang-tools-extra compiler-rt cross-project-tests flang 
libc libclc lld lldb llvm mlir openmp polly pstl"
+all_projects="bolt clang clang-tools-extra compiler-rt cross-project-tests 
flang libc libclc lld lldb llvm mlir openmp polly pstl"
 modified_projects="$(keep-modified-projects ${all_projects})"
 
 linux_projects_to_test=$(exclude-linux $(compute-projects-to-test 
${modified_projects}))
diff --git a/clang/empty_trigger b/clang/empty_trigger
new file mode 100644
index 00..e69de29bb2d1d6

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

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

@@ -104,7 +104,7 @@ static std::recursive_mutex *g_debugger_list_mutex_ptr =
 nullptr; // NOTE: intentional leak to avoid issues with C++ destructor 
chain
 static Debugger::DebuggerList *g_debugger_list_ptr =
 nullptr; // NOTE: intentional leak to avoid issues with C++ destructor 
chain
-static llvm::ThreadPool *g_thread_pool = nullptr;
+static llvm::DefaultThreadPoolThreadPool *g_thread_pool = nullptr;

joker-eph wrote:

Weirdly this issue wasn't caught in CI!

https://github.com/llvm/llvm-project/pull/83702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/83702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph updated 
https://github.com/llvm/llvm-project/pull/83702

>From d1dc1dfb1bb601fe90289bf29176c74a38ac5697 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Tue, 5 Mar 2024 10:38:41 -0800
Subject: [PATCH] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC)

The base class llvm::ThreadPoolInterface will be renamed llvm::ThreadPool
in a subsequent commit.
---
 bolt/lib/Core/ParallelUtilities.cpp   |  4 ++--
 bolt/tools/merge-fdata/merge-fdata.cpp|  2 +-
 .../clang-doc/tool/ClangDocMain.cpp   |  2 +-
 .../tool/FindAllSymbolsMain.cpp   |  2 +-
 clang/lib/Tooling/AllTUsExecution.cpp |  2 +-
 clang/tools/clang-scan-deps/ClangScanDeps.cpp |  2 +-
 lld/MachO/Writer.cpp  |  2 +-
 lldb/source/Core/Debugger.cpp |  4 ++--
 llvm/docs/ORCv2.rst   |  2 +-
 .../SpeculativeJIT/SpeculativeJIT.cpp |  2 +-
 llvm/include/llvm/ExecutionEngine/Orc/LLJIT.h |  2 +-
 llvm/include/llvm/Support/ThreadPool.h|  7 +++---
 llvm/lib/CodeGen/ParallelCG.cpp   |  2 +-
 llvm/lib/DWARFLinker/Classic/DWARFLinker.cpp  |  2 +-
 .../DWARFLinker/Parallel/DWARFLinkerImpl.cpp  |  2 +-
 llvm/lib/DebugInfo/GSYM/DwarfTransformer.cpp  |  2 +-
 llvm/lib/ExecutionEngine/Orc/LLJIT.cpp|  4 ++--
 llvm/lib/LTO/LTO.cpp  |  2 +-
 llvm/lib/LTO/LTOBackend.cpp   |  2 +-
 llvm/lib/LTO/ThinLTOCodeGenerator.cpp |  4 ++--
 llvm/lib/Support/BalancedPartitioning.cpp |  2 +-
 llvm/tools/dsymutil/dsymutil.cpp  |  2 +-
 llvm/tools/llvm-cov/CodeCoverage.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageExporterJson.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageReport.cpp|  4 ++--
 .../tools/llvm-debuginfod/llvm-debuginfod.cpp |  2 +-
 llvm/tools/llvm-profdata/llvm-profdata.cpp|  2 +-
 llvm/tools/llvm-reduce/deltas/Delta.cpp   |  2 +-
 llvm/unittests/ADT/LazyAtomicPointerTest.cpp  |  4 ++--
 llvm/unittests/Debuginfod/HTTPServerTests.cpp | 16 +++---
 llvm/unittests/Support/ParallelTest.cpp   |  2 +-
 llvm/unittests/Support/ThreadPool.cpp | 22 +--
 .../Support/ThreadSafeAllocatorTest.cpp   |  6 ++---
 mlir/include/mlir/IR/MLIRContext.h|  2 +-
 mlir/lib/CAPI/IR/Support.cpp  |  2 +-
 mlir/lib/ExecutionEngine/AsyncRuntime.cpp |  2 +-
 mlir/lib/IR/MLIRContext.cpp   |  4 ++--
 37 files changed, 65 insertions(+), 66 deletions(-)

diff --git a/bolt/lib/Core/ParallelUtilities.cpp 
b/bolt/lib/Core/ParallelUtilities.cpp
index 88d9444a6a2ba7..5f5e96e0e7881c 100644
--- a/bolt/lib/Core/ParallelUtilities.cpp
+++ b/bolt/lib/Core/ParallelUtilities.cpp
@@ -49,7 +49,7 @@ namespace ParallelUtilities {
 
 namespace {
 /// A single thread pool that is used to run parallel tasks
-std::unique_ptr ThreadPoolPtr;
+std::unique_ptr ThreadPoolPtr;
 
 unsigned computeCostFor(const BinaryFunction ,
 const PredicateTy ,
@@ -106,7 +106,7 @@ ThreadPoolInterface () {
   if (ThreadPoolPtr.get())
 return *ThreadPoolPtr;
 
-  ThreadPoolPtr = std::make_unique(
+  ThreadPoolPtr = std::make_unique(
   llvm::hardware_concurrency(opts::ThreadCount));
   return *ThreadPoolPtr;
 }
diff --git a/bolt/tools/merge-fdata/merge-fdata.cpp 
b/bolt/tools/merge-fdata/merge-fdata.cpp
index c6dfd3cfdc56de..f2ac5ad4492ee5 100644
--- a/bolt/tools/merge-fdata/merge-fdata.cpp
+++ b/bolt/tools/merge-fdata/merge-fdata.cpp
@@ -316,7 +316,7 @@ void mergeLegacyProfiles(const SmallVectorImpl 
) {
   // least 4 tasks.
   ThreadPoolStrategy S = optimal_concurrency(
   std::max(Filenames.size() / 4, static_cast(1)));
-  ThreadPool Pool(S);
+  DefaultThreadPool Pool(S);
   DenseMap ParsedProfiles(
   Pool.getMaxConcurrency());
   for (const auto  : Filenames)
diff --git a/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp 
b/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
index 22bdb5de22d871..21b581fa6df2e1 100644
--- a/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
+++ b/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
@@ -238,7 +238,7 @@ Example usage for a project using a compile commands 
database:
   Error = false;
   llvm::sys::Mutex IndexMutex;
   // ExecutorConcurrency is a flag exposed by AllTUsExecution.h
-  llvm::ThreadPool Pool(llvm::hardware_concurrency(ExecutorConcurrency));
+  llvm::DefaultThreadPool 
Pool(llvm::hardware_concurrency(ExecutorConcurrency));
   for (auto  : USRToBitcode) {
 Pool.async([&]() {
   std::vector> Infos;
diff --git 
a/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
 
b/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
index b2d0efecc20692..298b02e77cb0aa 100644
--- 
a/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
+++ 
b/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
@@ -89,7 +89,7 

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph updated 
https://github.com/llvm/llvm-project/pull/83702

>From ea79b6037497230b23caf36024a9e6883d3cac04 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Tue, 5 Mar 2024 10:38:41 -0800
Subject: [PATCH] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC)

The base class llvm::ThreadPoolInterface will be renamed llvm::ThreadPool
in a subsequent commit.
---
 bolt/lib/Core/ParallelUtilities.cpp   |  4 ++--
 bolt/tools/merge-fdata/merge-fdata.cpp|  2 +-
 .../clang-doc/tool/ClangDocMain.cpp   |  2 +-
 .../tool/FindAllSymbolsMain.cpp   |  2 +-
 clang/lib/Tooling/AllTUsExecution.cpp |  2 +-
 clang/tools/clang-scan-deps/ClangScanDeps.cpp |  2 +-
 lld/MachO/Writer.cpp  |  2 +-
 lldb/source/Core/Debugger.cpp |  4 ++--
 llvm/docs/ORCv2.rst   |  2 +-
 .../SpeculativeJIT/SpeculativeJIT.cpp |  2 +-
 llvm/include/llvm/ExecutionEngine/Orc/LLJIT.h |  2 +-
 llvm/include/llvm/Support/ThreadPool.h|  7 +++---
 llvm/lib/CodeGen/ParallelCG.cpp   |  2 +-
 llvm/lib/DWARFLinker/Classic/DWARFLinker.cpp  |  2 +-
 .../DWARFLinker/Parallel/DWARFLinkerImpl.cpp  |  2 +-
 llvm/lib/DebugInfo/GSYM/DwarfTransformer.cpp  |  2 +-
 llvm/lib/ExecutionEngine/Orc/LLJIT.cpp|  4 ++--
 llvm/lib/LTO/LTO.cpp  |  2 +-
 llvm/lib/LTO/LTOBackend.cpp   |  2 +-
 llvm/lib/LTO/ThinLTOCodeGenerator.cpp |  4 ++--
 llvm/lib/Support/BalancedPartitioning.cpp |  2 +-
 llvm/tools/dsymutil/dsymutil.cpp  |  2 +-
 llvm/tools/llvm-cov/CodeCoverage.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageExporterJson.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageReport.cpp|  4 ++--
 .../tools/llvm-debuginfod/llvm-debuginfod.cpp |  2 +-
 llvm/tools/llvm-profdata/llvm-profdata.cpp|  2 +-
 llvm/tools/llvm-reduce/deltas/Delta.cpp   |  2 +-
 llvm/unittests/ADT/LazyAtomicPointerTest.cpp  |  4 ++--
 llvm/unittests/Debuginfod/HTTPServerTests.cpp | 16 +++---
 llvm/unittests/Support/ParallelTest.cpp   |  2 +-
 llvm/unittests/Support/ThreadPool.cpp | 22 +--
 .../Support/ThreadSafeAllocatorTest.cpp   |  6 ++---
 mlir/include/mlir/IR/MLIRContext.h|  2 +-
 mlir/lib/CAPI/IR/Support.cpp  |  2 +-
 mlir/lib/ExecutionEngine/AsyncRuntime.cpp |  2 +-
 mlir/lib/IR/MLIRContext.cpp   |  4 ++--
 37 files changed, 65 insertions(+), 66 deletions(-)

diff --git a/bolt/lib/Core/ParallelUtilities.cpp 
b/bolt/lib/Core/ParallelUtilities.cpp
index 88d9444a6a2ba7..5f5e96e0e7881c 100644
--- a/bolt/lib/Core/ParallelUtilities.cpp
+++ b/bolt/lib/Core/ParallelUtilities.cpp
@@ -49,7 +49,7 @@ namespace ParallelUtilities {
 
 namespace {
 /// A single thread pool that is used to run parallel tasks
-std::unique_ptr ThreadPoolPtr;
+std::unique_ptr ThreadPoolPtr;
 
 unsigned computeCostFor(const BinaryFunction ,
 const PredicateTy ,
@@ -106,7 +106,7 @@ ThreadPoolInterface () {
   if (ThreadPoolPtr.get())
 return *ThreadPoolPtr;
 
-  ThreadPoolPtr = std::make_unique(
+  ThreadPoolPtr = std::make_unique(
   llvm::hardware_concurrency(opts::ThreadCount));
   return *ThreadPoolPtr;
 }
diff --git a/bolt/tools/merge-fdata/merge-fdata.cpp 
b/bolt/tools/merge-fdata/merge-fdata.cpp
index c6dfd3cfdc56de..f2ac5ad4492ee5 100644
--- a/bolt/tools/merge-fdata/merge-fdata.cpp
+++ b/bolt/tools/merge-fdata/merge-fdata.cpp
@@ -316,7 +316,7 @@ void mergeLegacyProfiles(const SmallVectorImpl 
) {
   // least 4 tasks.
   ThreadPoolStrategy S = optimal_concurrency(
   std::max(Filenames.size() / 4, static_cast(1)));
-  ThreadPool Pool(S);
+  DefaultThreadPool Pool(S);
   DenseMap ParsedProfiles(
   Pool.getMaxConcurrency());
   for (const auto  : Filenames)
diff --git a/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp 
b/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
index 22bdb5de22d871..21b581fa6df2e1 100644
--- a/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
+++ b/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
@@ -238,7 +238,7 @@ Example usage for a project using a compile commands 
database:
   Error = false;
   llvm::sys::Mutex IndexMutex;
   // ExecutorConcurrency is a flag exposed by AllTUsExecution.h
-  llvm::ThreadPool Pool(llvm::hardware_concurrency(ExecutorConcurrency));
+  llvm::DefaultThreadPool 
Pool(llvm::hardware_concurrency(ExecutorConcurrency));
   for (auto  : USRToBitcode) {
 Pool.async([&]() {
   std::vector> Infos;
diff --git 
a/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
 
b/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
index b2d0efecc20692..298b02e77cb0aa 100644
--- 
a/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
+++ 
b/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
@@ -89,7 +89,7 

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph updated 
https://github.com/llvm/llvm-project/pull/83702

>From 1b407d9d5abc9a1cf58afaf7f32ed40446d55f52 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Tue, 5 Mar 2024 10:38:41 -0800
Subject: [PATCH] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC)

The base class llvm::ThreadPoolInterface will be renamed llvm::ThreadPool
in a subsequent commit.
---
 bolt/lib/Core/ParallelUtilities.cpp   |  4 ++--
 bolt/tools/merge-fdata/merge-fdata.cpp|  2 +-
 .../clang-doc/tool/ClangDocMain.cpp   |  2 +-
 .../tool/FindAllSymbolsMain.cpp   |  2 +-
 clang/lib/Tooling/AllTUsExecution.cpp |  2 +-
 clang/tools/clang-scan-deps/ClangScanDeps.cpp |  2 +-
 lld/MachO/Writer.cpp  |  2 +-
 lldb/source/Core/Debugger.cpp |  4 ++--
 llvm/docs/ORCv2.rst   |  2 +-
 .../SpeculativeJIT/SpeculativeJIT.cpp |  2 +-
 llvm/include/llvm/ExecutionEngine/Orc/LLJIT.h |  2 +-
 llvm/include/llvm/Support/ThreadPool.h|  7 +++---
 llvm/lib/CodeGen/ParallelCG.cpp   |  2 +-
 llvm/lib/DWARFLinker/Classic/DWARFLinker.cpp  |  2 +-
 .../DWARFLinker/Parallel/DWARFLinkerImpl.cpp  |  2 +-
 llvm/lib/DebugInfo/GSYM/DwarfTransformer.cpp  |  2 +-
 llvm/lib/ExecutionEngine/Orc/LLJIT.cpp|  4 ++--
 llvm/lib/LTO/LTO.cpp  |  2 +-
 llvm/lib/LTO/LTOBackend.cpp   |  2 +-
 llvm/lib/LTO/ThinLTOCodeGenerator.cpp |  4 ++--
 llvm/lib/Support/BalancedPartitioning.cpp |  2 +-
 llvm/tools/dsymutil/dsymutil.cpp  |  2 +-
 llvm/tools/llvm-cov/CodeCoverage.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageExporterJson.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageReport.cpp|  4 ++--
 .../tools/llvm-debuginfod/llvm-debuginfod.cpp |  2 +-
 llvm/tools/llvm-profdata/llvm-profdata.cpp|  2 +-
 llvm/tools/llvm-reduce/deltas/Delta.cpp   |  2 +-
 llvm/unittests/ADT/LazyAtomicPointerTest.cpp  |  4 ++--
 llvm/unittests/Debuginfod/HTTPServerTests.cpp | 16 +++---
 llvm/unittests/Support/ParallelTest.cpp   |  2 +-
 llvm/unittests/Support/ThreadPool.cpp | 22 +--
 .../Support/ThreadSafeAllocatorTest.cpp   |  6 ++---
 mlir/include/mlir/IR/MLIRContext.h|  2 +-
 mlir/lib/CAPI/IR/Support.cpp  |  2 +-
 mlir/lib/ExecutionEngine/AsyncRuntime.cpp |  2 +-
 mlir/lib/IR/MLIRContext.cpp   |  4 ++--
 37 files changed, 65 insertions(+), 66 deletions(-)

diff --git a/bolt/lib/Core/ParallelUtilities.cpp 
b/bolt/lib/Core/ParallelUtilities.cpp
index 88d9444a6a2ba7..5f5e96e0e7881c 100644
--- a/bolt/lib/Core/ParallelUtilities.cpp
+++ b/bolt/lib/Core/ParallelUtilities.cpp
@@ -49,7 +49,7 @@ namespace ParallelUtilities {
 
 namespace {
 /// A single thread pool that is used to run parallel tasks
-std::unique_ptr ThreadPoolPtr;
+std::unique_ptr ThreadPoolPtr;
 
 unsigned computeCostFor(const BinaryFunction ,
 const PredicateTy ,
@@ -106,7 +106,7 @@ ThreadPoolInterface () {
   if (ThreadPoolPtr.get())
 return *ThreadPoolPtr;
 
-  ThreadPoolPtr = std::make_unique(
+  ThreadPoolPtr = std::make_unique(
   llvm::hardware_concurrency(opts::ThreadCount));
   return *ThreadPoolPtr;
 }
diff --git a/bolt/tools/merge-fdata/merge-fdata.cpp 
b/bolt/tools/merge-fdata/merge-fdata.cpp
index c6dfd3cfdc56de..f2ac5ad4492ee5 100644
--- a/bolt/tools/merge-fdata/merge-fdata.cpp
+++ b/bolt/tools/merge-fdata/merge-fdata.cpp
@@ -316,7 +316,7 @@ void mergeLegacyProfiles(const SmallVectorImpl 
) {
   // least 4 tasks.
   ThreadPoolStrategy S = optimal_concurrency(
   std::max(Filenames.size() / 4, static_cast(1)));
-  ThreadPool Pool(S);
+  DefaultThreadPool Pool(S);
   DenseMap ParsedProfiles(
   Pool.getMaxConcurrency());
   for (const auto  : Filenames)
diff --git a/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp 
b/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
index 22bdb5de22d871..21b581fa6df2e1 100644
--- a/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
+++ b/clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
@@ -238,7 +238,7 @@ Example usage for a project using a compile commands 
database:
   Error = false;
   llvm::sys::Mutex IndexMutex;
   // ExecutorConcurrency is a flag exposed by AllTUsExecution.h
-  llvm::ThreadPool Pool(llvm::hardware_concurrency(ExecutorConcurrency));
+  llvm::DefaultThreadPool 
Pool(llvm::hardware_concurrency(ExecutorConcurrency));
   for (auto  : USRToBitcode) {
 Pool.async([&]() {
   std::vector> Infos;
diff --git 
a/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
 
b/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
index b2d0efecc20692..298b02e77cb0aa 100644
--- 
a/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
+++ 
b/clang-tools-extra/clang-include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
@@ -89,7 +89,7 

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph edited 
https://github.com/llvm/llvm-project/pull/83702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

Actually no: the first patch landed already, so `ThreadPoolInterface` is now 
the base class in the codebase. I have some mixup here in that when renaming 
ThreadPool -> DefaultThreadPool, I used the base class ThreadPoolInterface when 
updating some of the uses.

I will push these ahead as a NFC change and rebase, that'll reduce the diff 
here.

https://github.com/llvm/llvm-project/pull/83702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

I did the first part of the renaming @dwblaikie : looks good?

https://github.com/llvm/llvm-project/pull/83702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph updated 
https://github.com/llvm/llvm-project/pull/83702

>From f961f22a3643673c1f3a040715dcfa2887ee1dca Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Mon, 4 Mar 2024 23:21:04 -0800
Subject: [PATCH] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC)

The base class llvm::ThreadPoolInterface will be renamed llvm::ThreadPool
in a subsequent commit.
---
 bolt/include/bolt/Core/ParallelUtilities.h|  4 ++--
 bolt/lib/Core/ParallelUtilities.cpp   | 10 -
 bolt/lib/Passes/IdenticalCodeFolding.cpp  |  2 +-
 bolt/lib/Rewrite/DWARFRewriter.cpp|  2 +-
 bolt/tools/merge-fdata/merge-fdata.cpp|  2 +-
 .../clang-doc/tool/ClangDocMain.cpp   |  2 +-
 .../tool/FindAllSymbolsMain.cpp   |  2 +-
 clang/lib/Tooling/AllTUsExecution.cpp |  2 +-
 clang/tools/clang-scan-deps/ClangScanDeps.cpp |  2 +-
 lld/MachO/Writer.cpp  |  2 +-
 lldb/source/Core/Debugger.cpp |  4 ++--
 llvm/docs/ORCv2.rst   |  2 +-
 .../SpeculativeJIT/SpeculativeJIT.cpp |  2 +-
 llvm/include/llvm/ExecutionEngine/Orc/LLJIT.h |  2 +-
 llvm/include/llvm/Support/ThreadPool.h|  7 +++---
 llvm/lib/CodeGen/ParallelCG.cpp   |  2 +-
 llvm/lib/DWARFLinker/Classic/DWARFLinker.cpp  |  2 +-
 .../DWARFLinker/Parallel/DWARFLinkerImpl.cpp  |  2 +-
 llvm/lib/DebugInfo/GSYM/DwarfTransformer.cpp  |  2 +-
 llvm/lib/ExecutionEngine/Orc/LLJIT.cpp|  4 ++--
 llvm/lib/LTO/LTO.cpp  |  2 +-
 llvm/lib/LTO/LTOBackend.cpp   |  2 +-
 llvm/lib/LTO/ThinLTOCodeGenerator.cpp |  4 ++--
 llvm/lib/Support/BalancedPartitioning.cpp |  2 +-
 llvm/tools/dsymutil/dsymutil.cpp  |  2 +-
 llvm/tools/llvm-cov/CodeCoverage.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageExporterJson.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageReport.cpp|  4 ++--
 .../tools/llvm-debuginfod/llvm-debuginfod.cpp |  2 +-
 llvm/tools/llvm-profdata/llvm-profdata.cpp|  2 +-
 llvm/tools/llvm-reduce/deltas/Delta.cpp   |  6 ++---
 llvm/unittests/ADT/LazyAtomicPointerTest.cpp  |  4 ++--
 llvm/unittests/Debuginfod/HTTPServerTests.cpp | 16 +++---
 llvm/unittests/Support/ParallelTest.cpp   |  2 +-
 llvm/unittests/Support/ThreadPool.cpp | 22 +--
 .../Support/ThreadSafeAllocatorTest.cpp   |  6 ++---
 mlir/include/mlir/IR/MLIRContext.h|  2 +-
 mlir/lib/CAPI/IR/Support.cpp  |  2 +-
 mlir/lib/ExecutionEngine/AsyncRuntime.cpp |  4 ++--
 mlir/lib/IR/MLIRContext.cpp   |  4 ++--
 40 files changed, 75 insertions(+), 76 deletions(-)

diff --git a/bolt/include/bolt/Core/ParallelUtilities.h 
b/bolt/include/bolt/Core/ParallelUtilities.h
index e510525bc51d00..e7b35a79acc78c 100644
--- a/bolt/include/bolt/Core/ParallelUtilities.h
+++ b/bolt/include/bolt/Core/ParallelUtilities.h
@@ -49,8 +49,8 @@ enum SchedulingPolicy {
   SP_BB_QUADRATIC,   /// cost is estimated by the square of the BB count
 };
 
-/// Return the managed thread pool and initialize it if not initiliazed.
-ThreadPool ();
+/// Return the managed thread pool and initialize it if not initialized.
+ThreadPoolInterface ();
 
 /// Perform the work on each BinaryFunction except those that are accepted
 /// by SkipPredicate, scheduling heuristic is based on SchedPolicy.
diff --git a/bolt/lib/Core/ParallelUtilities.cpp 
b/bolt/lib/Core/ParallelUtilities.cpp
index 1a28bc4346ecd5..5f5e96e0e7881c 100644
--- a/bolt/lib/Core/ParallelUtilities.cpp
+++ b/bolt/lib/Core/ParallelUtilities.cpp
@@ -49,7 +49,7 @@ namespace ParallelUtilities {
 
 namespace {
 /// A single thread pool that is used to run parallel tasks
-std::unique_ptr ThreadPoolPtr;
+std::unique_ptr ThreadPoolPtr;
 
 unsigned computeCostFor(const BinaryFunction ,
 const PredicateTy ,
@@ -102,11 +102,11 @@ inline unsigned estimateTotalCost(const BinaryContext ,
 
 } // namespace
 
-ThreadPool () {
+ThreadPoolInterface () {
   if (ThreadPoolPtr.get())
 return *ThreadPoolPtr;
 
-  ThreadPoolPtr = std::make_unique(
+  ThreadPoolPtr = std::make_unique(
   llvm::hardware_concurrency(opts::ThreadCount));
   return *ThreadPoolPtr;
 }
@@ -145,7 +145,7 @@ void runOnEachFunction(BinaryContext , SchedulingPolicy 
SchedPolicy,
   TotalCost > BlocksCount ? TotalCost / BlocksCount : 1;
 
   // Divide work into blocks of equal cost
-  ThreadPool  = getThreadPool();
+  ThreadPoolInterface  = getThreadPool();
   auto BlockBegin = BC.getBinaryFunctions().begin();
   unsigned CurrentCost = 0;
 
@@ -202,7 +202,7 @@ void runOnEachFunctionWithUniqueAllocId(
   TotalCost > BlocksCount ? TotalCost / BlocksCount : 1;
 
   // Divide work into blocks of equal cost
-  ThreadPool  = getThreadPool();
+  ThreadPoolInterface  = getThreadPool();
   auto BlockBegin = BC.getBinaryFunctions().begin();
   unsigned CurrentCost = 0;
   unsigned AllocId = 1;
diff --git 

[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph updated 
https://github.com/llvm/llvm-project/pull/83702

>From 41e5c286c29a4fea65f6116f6844b44a3847f9db Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Mon, 4 Mar 2024 23:21:04 -0800
Subject: [PATCH] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC)

The base class llvm::ThreadPoolInterface will be renamed llvm::ThreadPool
in a subsequent commit.
---
 bolt/include/bolt/Core/ParallelUtilities.h|  4 ++--
 bolt/lib/Core/ParallelUtilities.cpp   | 10 -
 bolt/lib/Passes/IdenticalCodeFolding.cpp  |  2 +-
 bolt/lib/Rewrite/DWARFRewriter.cpp|  2 +-
 bolt/tools/merge-fdata/merge-fdata.cpp|  2 +-
 .../clang-doc/tool/ClangDocMain.cpp   |  2 +-
 .../tool/FindAllSymbolsMain.cpp   |  2 +-
 clang/lib/Tooling/AllTUsExecution.cpp |  2 +-
 lld/MachO/Writer.cpp  |  2 +-
 lldb/source/Core/Debugger.cpp |  2 +-
 llvm/docs/ORCv2.rst   |  2 +-
 .../SpeculativeJIT/SpeculativeJIT.cpp |  2 +-
 llvm/include/llvm/ExecutionEngine/Orc/LLJIT.h |  2 +-
 llvm/include/llvm/Support/ThreadPool.h|  7 +++---
 llvm/lib/CodeGen/ParallelCG.cpp   |  2 +-
 llvm/lib/DWARFLinker/Classic/DWARFLinker.cpp  |  2 +-
 .../DWARFLinker/Parallel/DWARFLinkerImpl.cpp  |  2 +-
 llvm/lib/DebugInfo/GSYM/DwarfTransformer.cpp  |  2 +-
 llvm/lib/ExecutionEngine/Orc/LLJIT.cpp|  4 ++--
 llvm/lib/LTO/LTO.cpp  |  2 +-
 llvm/lib/LTO/LTOBackend.cpp   |  2 +-
 llvm/lib/LTO/ThinLTOCodeGenerator.cpp |  4 ++--
 llvm/lib/Support/BalancedPartitioning.cpp |  2 +-
 llvm/tools/dsymutil/dsymutil.cpp  |  2 +-
 llvm/tools/llvm-cov/CodeCoverage.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageExporterJson.cpp  |  2 +-
 llvm/tools/llvm-cov/CoverageReport.cpp|  4 ++--
 .../tools/llvm-debuginfod/llvm-debuginfod.cpp |  2 +-
 llvm/tools/llvm-profdata/llvm-profdata.cpp|  2 +-
 llvm/tools/llvm-reduce/deltas/Delta.cpp   |  6 ++---
 llvm/unittests/ADT/LazyAtomicPointerTest.cpp  |  4 ++--
 llvm/unittests/Debuginfod/HTTPServerTests.cpp | 16 +++---
 llvm/unittests/Support/ParallelTest.cpp   |  2 +-
 llvm/unittests/Support/ThreadPool.cpp | 22 +--
 .../Support/ThreadSafeAllocatorTest.cpp   |  6 ++---
 mlir/lib/CAPI/IR/Support.cpp  |  2 +-
 mlir/lib/ExecutionEngine/AsyncRuntime.cpp |  4 ++--
 mlir/lib/IR/MLIRContext.cpp   |  4 ++--
 38 files changed, 72 insertions(+), 73 deletions(-)

diff --git a/bolt/include/bolt/Core/ParallelUtilities.h 
b/bolt/include/bolt/Core/ParallelUtilities.h
index e510525bc51d00..e7b35a79acc78c 100644
--- a/bolt/include/bolt/Core/ParallelUtilities.h
+++ b/bolt/include/bolt/Core/ParallelUtilities.h
@@ -49,8 +49,8 @@ enum SchedulingPolicy {
   SP_BB_QUADRATIC,   /// cost is estimated by the square of the BB count
 };
 
-/// Return the managed thread pool and initialize it if not initiliazed.
-ThreadPool ();
+/// Return the managed thread pool and initialize it if not initialized.
+ThreadPoolInterface ();
 
 /// Perform the work on each BinaryFunction except those that are accepted
 /// by SkipPredicate, scheduling heuristic is based on SchedPolicy.
diff --git a/bolt/lib/Core/ParallelUtilities.cpp 
b/bolt/lib/Core/ParallelUtilities.cpp
index 1a28bc4346ecd5..5f5e96e0e7881c 100644
--- a/bolt/lib/Core/ParallelUtilities.cpp
+++ b/bolt/lib/Core/ParallelUtilities.cpp
@@ -49,7 +49,7 @@ namespace ParallelUtilities {
 
 namespace {
 /// A single thread pool that is used to run parallel tasks
-std::unique_ptr ThreadPoolPtr;
+std::unique_ptr ThreadPoolPtr;
 
 unsigned computeCostFor(const BinaryFunction ,
 const PredicateTy ,
@@ -102,11 +102,11 @@ inline unsigned estimateTotalCost(const BinaryContext ,
 
 } // namespace
 
-ThreadPool () {
+ThreadPoolInterface () {
   if (ThreadPoolPtr.get())
 return *ThreadPoolPtr;
 
-  ThreadPoolPtr = std::make_unique(
+  ThreadPoolPtr = std::make_unique(
   llvm::hardware_concurrency(opts::ThreadCount));
   return *ThreadPoolPtr;
 }
@@ -145,7 +145,7 @@ void runOnEachFunction(BinaryContext , SchedulingPolicy 
SchedPolicy,
   TotalCost > BlocksCount ? TotalCost / BlocksCount : 1;
 
   // Divide work into blocks of equal cost
-  ThreadPool  = getThreadPool();
+  ThreadPoolInterface  = getThreadPool();
   auto BlockBegin = BC.getBinaryFunctions().begin();
   unsigned CurrentCost = 0;
 
@@ -202,7 +202,7 @@ void runOnEachFunctionWithUniqueAllocId(
   TotalCost > BlocksCount ? TotalCost / BlocksCount : 1;
 
   // Divide work into blocks of equal cost
-  ThreadPool  = getThreadPool();
+  ThreadPoolInterface  = getThreadPool();
   auto BlockBegin = BC.getBinaryFunctions().begin();
   unsigned CurrentCost = 0;
   unsigned AllocId = 1;
diff --git a/bolt/lib/Passes/IdenticalCodeFolding.cpp 
b/bolt/lib/Passes/IdenticalCodeFolding.cpp
index 

[clang] c462160 - More fix BUILD_SHARED_LIBS=ON build for platforms which require explicit link of -lpthread (NFC)

[Mehdi Amini via cfe-commits]

Author: Mehdi Amini
Date: 2024-03-02T19:54:35-08:00
New Revision: c4621607245a5feed42cf9f748ff796728ef579a

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

LOG: More fix BUILD_SHARED_LIBS=ON build for platforms which require explicit 
link of -lpthread (NFC)

Some systems requires explictly providing -lpthread when linking, I don't
have such system so it is hard to find all the missing cases.

Added: 


Modified: 
clang/lib/Tooling/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/Tooling/CMakeLists.txt 
b/clang/lib/Tooling/CMakeLists.txt
index aff39e4de13c0b..91e6cbdcbc44f7 100644
--- a/clang/lib/Tooling/CMakeLists.txt
+++ b/clang/lib/Tooling/CMakeLists.txt
@@ -135,4 +135,5 @@ add_clang_library(clangTooling
   clangRewrite
   clangSerialization
   clangToolingCore
+  ${LLVM_PTHREAD_LIB}
   )



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

[clang] [clang-tools-extra] [compiler-rt] [flang] [libclc] [libcxx] [lld] [lldb] [llvm] [NFC] Remove trailing whitespace across all non-test related files (PR #82838)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

Fine with me if we want to land this as is, but per-top-level subproject may be 
a better granularity.

https://github.com/llvm/llvm-project/pull/82838
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [mlir] Rename `ThreadPool::getThreadCount()` to `getMaxConcurrency()` (NFC) (PR #82296)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/82296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [mlir] Rename `ThreadPool::getThreadCount()` to `getMaxConcurrency()` (NFC) (PR #82296)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph updated 
https://github.com/llvm/llvm-project/pull/82296

>From 8c236920e5eb5703a64cd89a45f2cc89607b96fd Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Mon, 19 Feb 2024 17:34:33 -0800
Subject: [PATCH] Rename `ThreadPool::getThreadCount()` to
 `getMaxConcurrency()` (NFC)

This is addressing a long-time TODO to rename this misleading API.
The old one is preserved for now but marked deprecated.
---
 bolt/tools/merge-fdata/merge-fdata.cpp| 3 ++-
 clang/tools/clang-scan-deps/ClangScanDeps.cpp | 6 +++---
 llvm/include/llvm/Support/ThreadPool.h| 5 -
 llvm/lib/Debuginfod/Debuginfod.cpp| 2 +-
 llvm/lib/LTO/LTO.cpp  | 2 +-
 mlir/include/mlir/IR/Threading.h  | 2 +-
 mlir/lib/ExecutionEngine/AsyncRuntime.cpp | 2 +-
 mlir/lib/IR/MLIRContext.cpp   | 2 +-
 mlir/lib/Pass/Pass.cpp| 2 +-
 9 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/bolt/tools/merge-fdata/merge-fdata.cpp 
b/bolt/tools/merge-fdata/merge-fdata.cpp
index 104991dabc5f07..c6dfd3cfdc56de 100644
--- a/bolt/tools/merge-fdata/merge-fdata.cpp
+++ b/bolt/tools/merge-fdata/merge-fdata.cpp
@@ -317,7 +317,8 @@ void mergeLegacyProfiles(const SmallVectorImpl 
) {
   ThreadPoolStrategy S = optimal_concurrency(
   std::max(Filenames.size() / 4, static_cast(1)));
   ThreadPool Pool(S);
-  DenseMap ParsedProfiles(Pool.getThreadCount());
+  DenseMap ParsedProfiles(
+  Pool.getMaxConcurrency());
   for (const auto  : Filenames)
 Pool.async(ParseProfile, std::cref(Filename), std::ref(ParsedProfiles));
   Pool.wait();
diff --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index e45ea700d87b94..0458a4b3ecec39 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -870,7 +870,7 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
 EagerLoadModules);
   llvm::ThreadPool Pool(llvm::hardware_concurrency(NumThreads));
   std::vector> WorkerTools;
-  for (unsigned I = 0; I < Pool.getThreadCount(); ++I)
+  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I)
 WorkerTools.push_back(std::make_unique(Service));
 
   std::vector Inputs =
@@ -894,13 +894,13 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
 
   if (Verbose) {
 llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getThreadCount() << " workers\n";
+ << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
   }
 
   llvm::Timer T;
   T.startTimer();
 
-  for (unsigned I = 0; I < Pool.getThreadCount(); ++I) {
+  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
 Pool.async([&, I]() {
   llvm::DenseSet AlreadySeenModules;
   while (auto MaybeInputIndex = GetNextInputIndex()) {
diff --git a/llvm/include/llvm/Support/ThreadPool.h 
b/llvm/include/llvm/Support/ThreadPool.h
index 5e67a312d5c7b5..03ebd35aa46dc4 100644
--- a/llvm/include/llvm/Support/ThreadPool.h
+++ b/llvm/include/llvm/Support/ThreadPool.h
@@ -104,9 +104,12 @@ class ThreadPool {
   /// not to waste the thread.
   void wait(ThreadPoolTaskGroup );
 
-  // TODO: misleading legacy name warning!
   // Returns the maximum number of worker threads in the pool, not the current
   // number of threads!
+  unsigned getMaxConcurrency() const { return MaxThreadCount; }
+
+  // TODO: misleading legacy name warning!
+  LLVM_DEPRECATED("Use getMaxConcurrency instead", "getMaxConcurrency")
   unsigned getThreadCount() const { return MaxThreadCount; }
 
   /// Returns true if the current thread is a worker thread of this thread 
pool.
diff --git a/llvm/lib/Debuginfod/Debuginfod.cpp 
b/llvm/lib/Debuginfod/Debuginfod.cpp
index 4928fcb3b3f879..1cf550721000eb 100644
--- a/llvm/lib/Debuginfod/Debuginfod.cpp
+++ b/llvm/lib/Debuginfod/Debuginfod.cpp
@@ -414,7 +414,7 @@ Error DebuginfodCollection::findBinaries(StringRef Path) {
   sys::fs::recursive_directory_iterator I(Twine(Path), EC), E;
   std::mutex IteratorMutex;
   ThreadPoolTaskGroup IteratorGroup(Pool);
-  for (unsigned WorkerIndex = 0; WorkerIndex < Pool.getThreadCount();
+  for (unsigned WorkerIndex = 0; WorkerIndex < Pool.getMaxConcurrency();
WorkerIndex++) {
 IteratorGroup.async([&, this]() -> void {
   std::string FilePath;
diff --git a/llvm/lib/LTO/LTO.cpp b/llvm/lib/LTO/LTO.cpp
index b38c568d10cd09..b5062580169da3 100644
--- a/llvm/lib/LTO/LTO.cpp
+++ b/llvm/lib/LTO/LTO.cpp
@@ -1537,7 +1537,7 @@ class InProcessThinBackend : public ThinBackendProc {
   }
 
   unsigned getThreadCount() override {
-return BackendThreadPool.getThreadCount();
+return BackendThreadPool.getMaxConcurrency();
   }
 };
 } // end anonymous namespace
diff --git a/mlir/include/mlir/IR/Threading.h b/mlir/include/mlir/IR/Threading.h
index 

[clang] [llvm] [mlir] Rename `ThreadPool::getThreadCount()` to `getMaxConcurrency()` (NFC) (PR #82296)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph created 
https://github.com/llvm/llvm-project/pull/82296

This is addressing a long-time TODO to rename this misleading API. The old one 
is preserved for now but marked deprecated.

>From d381cf98345ff6a817958519a5aa456fbfdea1d2 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Mon, 19 Feb 2024 17:34:33 -0800
Subject: [PATCH] Rename `ThreadPool::getThreadCount()` to
 `getMaxConcurrency()` (NFC)

This is addressing a long-time TODO to rename this misleading API.
The old one is preserved for now but marked deprecated.
---
 bolt/tools/merge-fdata/merge-fdata.cpp| 2 +-
 clang/tools/clang-scan-deps/ClangScanDeps.cpp | 6 +++---
 llvm/include/llvm/Support/ThreadPool.h| 5 -
 llvm/lib/Debuginfod/Debuginfod.cpp| 2 +-
 llvm/lib/LTO/LTO.cpp  | 2 +-
 mlir/include/mlir/IR/Threading.h  | 2 +-
 mlir/lib/ExecutionEngine/AsyncRuntime.cpp | 2 +-
 mlir/lib/IR/MLIRContext.cpp   | 2 +-
 mlir/lib/Pass/Pass.cpp| 2 +-
 9 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/bolt/tools/merge-fdata/merge-fdata.cpp 
b/bolt/tools/merge-fdata/merge-fdata.cpp
index 104991dabc5f07..6e64604e7309a2 100644
--- a/bolt/tools/merge-fdata/merge-fdata.cpp
+++ b/bolt/tools/merge-fdata/merge-fdata.cpp
@@ -317,7 +317,7 @@ void mergeLegacyProfiles(const SmallVectorImpl 
) {
   ThreadPoolStrategy S = optimal_concurrency(
   std::max(Filenames.size() / 4, static_cast(1)));
   ThreadPool Pool(S);
-  DenseMap ParsedProfiles(Pool.getThreadCount());
+  DenseMap 
ParsedProfiles(Pool.getMaxConcurrency());
   for (const auto  : Filenames)
 Pool.async(ParseProfile, std::cref(Filename), std::ref(ParsedProfiles));
   Pool.wait();
diff --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index e45ea700d87b94..0458a4b3ecec39 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -870,7 +870,7 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
 EagerLoadModules);
   llvm::ThreadPool Pool(llvm::hardware_concurrency(NumThreads));
   std::vector> WorkerTools;
-  for (unsigned I = 0; I < Pool.getThreadCount(); ++I)
+  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I)
 WorkerTools.push_back(std::make_unique(Service));
 
   std::vector Inputs =
@@ -894,13 +894,13 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
 
   if (Verbose) {
 llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getThreadCount() << " workers\n";
+ << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
   }
 
   llvm::Timer T;
   T.startTimer();
 
-  for (unsigned I = 0; I < Pool.getThreadCount(); ++I) {
+  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
 Pool.async([&, I]() {
   llvm::DenseSet AlreadySeenModules;
   while (auto MaybeInputIndex = GetNextInputIndex()) {
diff --git a/llvm/include/llvm/Support/ThreadPool.h 
b/llvm/include/llvm/Support/ThreadPool.h
index 5e67a312d5c7b5..897657b00d354e 100644
--- a/llvm/include/llvm/Support/ThreadPool.h
+++ b/llvm/include/llvm/Support/ThreadPool.h
@@ -104,9 +104,12 @@ class ThreadPool {
   /// not to waste the thread.
   void wait(ThreadPoolTaskGroup );
 
-  // TODO: misleading legacy name warning!
   // Returns the maximum number of worker threads in the pool, not the current
   // number of threads!
+  unsigned getMaxConcurrency() const {return MaxThreadCount;}
+  
+  // TODO: misleading legacy name warning!
+  LLVM_DEPRECATED("Use getMaxConcurrency instead", "getMaxConcurrency")
   unsigned getThreadCount() const { return MaxThreadCount; }
 
   /// Returns true if the current thread is a worker thread of this thread 
pool.
diff --git a/llvm/lib/Debuginfod/Debuginfod.cpp 
b/llvm/lib/Debuginfod/Debuginfod.cpp
index 4928fcb3b3f879..1cf550721000eb 100644
--- a/llvm/lib/Debuginfod/Debuginfod.cpp
+++ b/llvm/lib/Debuginfod/Debuginfod.cpp
@@ -414,7 +414,7 @@ Error DebuginfodCollection::findBinaries(StringRef Path) {
   sys::fs::recursive_directory_iterator I(Twine(Path), EC), E;
   std::mutex IteratorMutex;
   ThreadPoolTaskGroup IteratorGroup(Pool);
-  for (unsigned WorkerIndex = 0; WorkerIndex < Pool.getThreadCount();
+  for (unsigned WorkerIndex = 0; WorkerIndex < Pool.getMaxConcurrency();
WorkerIndex++) {
 IteratorGroup.async([&, this]() -> void {
   std::string FilePath;
diff --git a/llvm/lib/LTO/LTO.cpp b/llvm/lib/LTO/LTO.cpp
index b38c568d10cd09..b5062580169da3 100644
--- a/llvm/lib/LTO/LTO.cpp
+++ b/llvm/lib/LTO/LTO.cpp
@@ -1537,7 +1537,7 @@ class InProcessThinBackend : public ThinBackendProc {
   }
 
   unsigned getThreadCount() override {
-return BackendThreadPool.getThreadCount();
+return BackendThreadPool.getMaxConcurrency();
   }
 };
 } // end 

[flang] [libcxx] [libc] [clang] [lldb] [llvm] [mlir] [mlir] Skip invalid test on big endian platform (s390x) (PR #80246)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/80246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[compiler-rt] [llvm] [mlir] [clang-tools-extra] [clang] [flang] [mlir][tosa] Add dialect version. (PR #79514)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

> I think you are assuming guarantees here that doesn't exist. 

I'm just going by you're writing :)
You wrote: "To be able to flag incompatible bytecode files rather than have it 
fail later in mysterious ways"
But my take is that you're not actually providing the ability to flag 
incompatible bytecode, instead I believe what you're providing is the ability 
to explicitly invalidate every existing serialized bytecode at some arbitrary 
points in time by bumping the version. In between these even where the version 
is bumped: you haven't changed anything and we can't flag incompatible bytecode.

> So this is a mechanism with policy TBD.

Right, and I'd like a better story around how we'd handle this policy before 
landing this kind of code in-tree actually: this is a bit too much "YOLO" to me 
right now.



https://github.com/llvm/llvm-project/pull/79514
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang] [llvm] [mlir] [mlir][docs] Clarified Dialect creation tutorial + fixed typos (PR #77820)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph edited 
https://github.com/llvm/llvm-project/pull/77820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang-tools-extra] [mlir] [clang] [mlir][docs] Clarified Dialect creation tutorial + fixed typos (PR #77820)

[Mehdi Amini via cfe-commits]

@@ -106,6 +106,12 @@ the LINK_COMPONENTS descriptor.  This allows cmake 
infrastructure to
 generate new library targets with correct linkage, in particular, when
 BUILD_SHARED_LIBS=on or LLVM_LINK_LLVM_DYLIB=on are specified.
 
+Registration of the dialect can be performed globally by editing the
+file include/mlir/InitAllDialects.h.  In this example, we can add

joker-eph wrote:

This is framed as if it is a possibility: I believe this isn't optional, all 
dialects should be there.

https://github.com/llvm/llvm-project/pull/77820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[compiler-rt] [clang] [flang] [llvm] [clang-tools-extra] [mlir] [mlir][tosa] Add dialect version. (PR #79514)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

> To be able to flag incompatible bytecode files rather than have it fail later 
> in mysterious ways. E.g., allows for a more strict failure.

That would require some sort of principles and policy around the changes that 
affect the serialization of this and the maintenance of this version number, I 
haven't seen a discussion about this: did I miss it?

Also, TOSA isn't a hermetic dialect: it includes other IR entities from other 
dialects, and changing these would impact this story as well.

https://github.com/llvm/llvm-project/pull/79514
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [flang] [clang] [mlir] [compiler-rt] [clang-tools-extra] [mlir][tosa] Add dialect version. (PR #79514)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph requested changes to this pull request.

This lack some information to me:

- What is the purpose of this?
- What kind of compatibility is this supposed to provide?
- What is the versioning scheme?

https://github.com/llvm/llvm-project/pull/79514
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Revert "[RISCV] Relax march string order constraint" (PR #79976)

[Mehdi Amini via cfe-commits]

joker-eph wrote:


- Reverting a change that way costs me 3 clicks: it is the lowest cost on me to 
fix the CI.
- We likely want people to be able to use the pre-merge checks independently of 
the reviews: you're way of tying "opening a PR" to some expectations (that 
aren't clear to me) seems to go against this. 




https://github.com/llvm/llvm-project/pull/79976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [RISCV] Relax march string order constraint (PR #78120)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

Sorry, had to revert because this broke a buildbot:

```
llvm/lib/Support/RISCVISAInfo.cpp:910:18: error: call to deleted constructor of 
'llvm::Error'
return E;
^
```
https://lab.llvm.org/buildbot/#/builders/61/builds/53704

https://github.com/llvm/llvm-project/pull/78120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] Revert "[RISCV] Relax march string order constraint" (PR #79976)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/79976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] Revert "[RISCV] Relax march string order constraint" (PR #79976)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph created 
https://github.com/llvm/llvm-project/pull/79976

Reverts llvm/llvm-project#78120

Buildbot is broken:

llvm/lib/Support/RISCVISAInfo.cpp:910:18: error: call to deleted constructor of 
'llvm::Error'
  return E;
 ^


>From 193b711e4e1596c9db045e1e2afbc3077adccad3 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Tue, 30 Jan 2024 02:32:24 -0800
Subject: [PATCH] Revert "[RISCV] Relax march string order constraint"

---
 clang/test/Driver/riscv-arch.c  |  14 +-
 llvm/lib/Support/RISCVISAInfo.cpp   | 302 ++--
 llvm/unittests/Support/RISCVISAInfoTest.cpp | 103 ++-
 3 files changed, 173 insertions(+), 246 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index c9e984e07cbea..0ac81ea982f1b 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -156,8 +156,9 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32L %s
 // RV32L: error: invalid arch name 'rv32l'
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32imadf -### %s \
-// RUN:   -fsyntax-only 2>&1 | FileCheck %s
+// RUN: not %clang --target=riscv32-unknown-elf -march=rv32imadf -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32IMADF %s
+// RV32IMADF: error: invalid arch name 'rv32imadf'
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32imm -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32IMM %s
@@ -183,8 +184,9 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64L %s
 // RV64L: error: invalid arch name 'rv64l'
 
-// RUN: %clang --target=riscv64-unknown-elf -march=rv64imadf -### %s \
-// RUN:   -fsyntax-only 2>&1 | FileCheck %s
+// RUN: not %clang --target=riscv64-unknown-elf -march=rv64imadf -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64IMADF %s
+// RV64IMADF: error: invalid arch name 'rv64imadf'
 
 // RUN: not %clang --target=riscv64-unknown-elf -march=rv64imm -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64IMM %s
@@ -214,7 +216,7 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32imcq -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ORDER %s
 // RV32-ORDER: error: invalid arch name 'rv32imcq',
-// RV32-ORDER: unsupported standard user-level extension 'q'
+// RV32-ORDER: standard user-level extension not given in canonical order 'q'
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izvl64b -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVL64B-ER %s
@@ -316,7 +318,7 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32ixabc_a -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-PREFIX %s
 // RV32-PREFIX: error: invalid arch name 'rv32ixabc_a',
-// RV32-PREFIX: unsupported non-standard user-level extension 'xabc'
+// RV32-PREFIX: invalid extension prefix 'a'
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32ixdef_sabc -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-X-ORDER %s
diff --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 050253f78399e..c46d76da962c6 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -7,7 +7,6 @@
 
//===--===//
 
 #include "llvm/Support/RISCVISAInfo.h"
-#include "llvm/ADT/MapVector.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/StringExtras.h"
@@ -704,106 +703,6 @@ RISCVISAInfo::parseNormalizedArchString(StringRef Arch) {
   return std::move(ISAInfo);
 }
 
-static Error splitExtsByUnderscore(StringRef Exts,
-   std::vector ) {
-  SmallVector Split;
-  if (Exts.empty())
-return Error::success();
-
-  Exts.split(Split, "_");
-
-  for (auto Ext : Split) {
-if (Ext.empty())
-  return createStringError(errc::invalid_argument,
-   "extension name missing after separator '_'");
-
-SplitExts.push_back(Ext.str());
-  }
-  return Error::success();
-}
-
-static Error processMultiLetterExtension(
-StringRef RawExt,
-MapVector> ,
-bool IgnoreUnknown, bool EnableExperimentalExtension,
-bool ExperimentalExtensionVersionCheck) {
-  StringRef Type = getExtensionType(RawExt);
-  StringRef Desc = getExtensionTypeDesc(RawExt);
-  auto Pos = findLastNonVersionCharacter(RawExt) + 1;
-  StringRef Name(RawExt.substr(0, Pos));
-  StringRef Vers(RawExt.substr(Pos));
-
-  if (Type.empty()) {
-if (IgnoreUnknown)
-  return Error::success();
-return createStringError(errc::invalid_argument,
- "invalid extension prefix '" + RawExt + "'");
-  }
-
-  if (!IgnoreUnknown && Name.size() == Type.size())
-return createStringError(errc::invalid_argument,
- "%s name missing after '%s'", Desc.str().c_str(),
-   

[mlir] [libc] [lldb] [flang] [libcxxabi] [lld] [libcxx] [clang-tools-extra] [compiler-rt] [llvm] [clang] [mlir][complex] Prevent underflow in complex.abs (PR #76316)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

I had to revert because this broke a bot: 
https://lab.llvm.org/buildbot/#/builders/264/builds/6131

```
# RUN: at line 1
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.obj/bin/mlir-opt 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.src/mlir/test/Integration/Dialect/Complex/CPU/correctness.mlir
-func-bufferize -tensor-bufferize -arith-bufferize --canonicalize
-convert-scf-to-cf --convert-complex-to-standard-finalize-memref-to-llvm 
-convert-math-to-llvm -convert-math-to-libm-convert-vector-to-llvm 
-convert-complex-to-llvm-convert-func-to-llvm -reconcile-unrealized-casts | 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.obj/bin/mlir-cpu-runner   -e 
entry -entry-point-result=void
-shared-libs=/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.obj/lib/libmlir_c_runner_utils.so
 | /vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.obj/bin/FileCheck 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.src/mlir/test/Integration/Dialect/Complex/CPU/correctness.mlir
# executed command: 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.obj/bin/mlir-opt 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.src/mlir/test/Integration/Dialect/Complex/CPU/correctness.mlir
 -func-bufferize -tensor-bufferize -arith-bufferize --canonicalize 
-convert-scf-to-cf --convert-complex-to-standard -finalize-memref-to-llvm 
-convert-math-to-llvm -convert-math-to-libm -convert-vector-to-llvm 
-convert-complex-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts
# executed command: 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.obj/bin/mlir-cpu-runner -e entry 
-entry-point-result=void 
-shared-libs=/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.obj/lib/libmlir_c_runner_utils.so
# executed command: 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.obj/bin/FileCheck 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.src/mlir/test/Integration/Dialect/Complex/CPU/correctness.mlir
# .---command stderr
# | 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.src/mlir/test/Integration/Dialect/Complex/CPU/correctness.mlir:135:17:
 error: CHECK-NEXT: expected string not found in input
# |  // CHECK-NEXT: -1.098
# | ^
# | :3:6: note: scanning from here
# | 0.45509
# |  ^
# | :4:1: note: possible intended match here
# | 1.09868
# | ^
# | 
# | Input file: 
# | Check file: 
/vol/worker/mlir-nvidia/mlir-nvidia-gcc7/llvm.src/mlir/test/Integration/Dialect/Complex/CPU/correctness.mlir
# | 
# | -dump-input=help explains the following input dump.
# | 
# | Input was:
# | <<
# | 1: nan 
# | 2: nan 
# | 3: 0.45509 
# | next:135'0  X~~ error: no match found
# | 4: 1.09868 
# | next:135'0 
# | next:135'1 ?possible intended match
# | 5: 0 
# | next:135'0 ~~
# | 6: 0 
# | next:135'0 ~~
# | 7: 0.707107 
# | next:135'0 ~
# | 8: 0.707107 
# | next:135'0 ~
# | 9: 1.09868 
# | next:135'0 
# | .
# | .
# | .
# | >>
# `-
# error: command failed with exit status: 1
```

https://github.com/llvm/llvm-project/pull/76316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[lldb] [polly] [libcxx] [openmp] [libcxxabi] [mlir] [compiler-rt] [clang] [llvm] [clang-tools-extra] [libc] [flang] [mlir][vector] Fix invalid `LoadOp` indices being created (PR #76292)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.


https://github.com/llvm/llvm-project/pull/76292
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [libcxxabi] [lldb] [libcxx] [polly] [openmp] [compiler-rt] [flang] [libc] [mlir] [clang-tools-extra] [clang] [mlir][vector] Fix invalid `LoadOp` indices being created (PR #76292)

[Mehdi Amini via cfe-commits]

@@ -897,7 +921,8 @@ struct TransferOpConversion : public 
VectorToSCFPattern {
   } else {
 // It's safe to assume the mask buffer can be unpacked if the data
 // buffer was unpacked.
-auto castedMaskType = *unpackOneDim(maskBufferType);
+auto maskBufferType = dyn_cast(maskBuffer.getType());

joker-eph wrote:

OK, but we're not checking the result: if this can't fail here by construction 
it should be a cast instead.

https://github.com/llvm/llvm-project/pull/76292
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[flang] [clang-tools-extra] [clang] [mlir] [llvm] [compiler-rt] [mlir][vector] Fix invalid `LoadOp` indices being created (PR #76292)

[Mehdi Amini via cfe-commits]

@@ -866,16 +866,41 @@ struct TransferOpConversion : public 
VectorToSCFPattern {
 this->setHasBoundedRewriteRecursion();
   }
 
+  static void getMaskBufferLoadIndices(OpTy xferOp, Value castedMaskBuffer,
+   SmallVector ,
+   Value iv) {
+assert(xferOp.getMask() && "Expected transfer op to have mask");
+
+// Add load indices from the previous iteration.
+// The mask buffer depends on the permutation map, which makes determining
+// the indices quite complex, so this is why we need to "look back" to the
+// previous iteration to find the right indices.
+Value maskBuffer = getMaskBuffer(xferOp);
+for (OpOperand  : maskBuffer.getUses()) {
+  // If there is no previous load op, then the indices are empty.
+  if (auto loadOp = dyn_cast(use.getOwner())) {

joker-eph wrote:

```suggestion
for (Operation *user : maskBuffer.getUsers()) {
  // If there is no previous load op, then the indices are empty.
  if (auto loadOp = dyn_cast(user)) {
```

https://github.com/llvm/llvm-project/pull/76292
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[mlir] [flang] [clang-tools-extra] [llvm] [compiler-rt] [clang] [mlir][vector] Fix invalid `LoadOp` indices being created (PR #76292)

[Mehdi Amini via cfe-commits]

@@ -897,7 +921,8 @@ struct TransferOpConversion : public 
VectorToSCFPattern {
   } else {
 // It's safe to assume the mask buffer can be unpacked if the data
 // buffer was unpacked.
-auto castedMaskType = *unpackOneDim(maskBufferType);
+auto maskBufferType = dyn_cast(maskBuffer.getType());

joker-eph wrote:

Why are you introducing a `dyn_cast` here?

https://github.com/llvm/llvm-project/pull/76292
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [mlir] [llvm] [compiler-rt] [flang] [mlir][vector] Fix invalid `LoadOp` indices being created (PR #76292)

[Mehdi Amini via cfe-commits]

@@ -866,16 +866,41 @@ struct TransferOpConversion : public 
VectorToSCFPattern {
 this->setHasBoundedRewriteRecursion();
   }
 
+  static void getMaskBufferLoadIndices(OpTy xferOp, Value castedMaskBuffer,
+   SmallVector ,

joker-eph wrote:

```suggestion
   SmallVectorImpl ,
```

https://github.com/llvm/llvm-project/pull/76292
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[flang] [mlir] [llvm] [compiler-rt] [libcxx] [clang-tools-extra] [clang] [libc] [mlir][gpu] Support dynamic_shared_memory Op with vector dialect (PR #74475)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.


https://github.com/llvm/llvm-project/pull/74475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[compiler-rt] [lld] [openmp] [libcxx] [mlir] [clang] [lldb] [llvm] [flang] [libc] [clang-tools-extra] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph edited 
https://github.com/llvm/llvm-project/pull/71430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[compiler-rt] [lld] [openmp] [libcxx] [mlir] [clang] [lldb] [llvm] [flang] [libc] [clang-tools-extra] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

[Mehdi Amini via cfe-commits]

@@ -61,6 +63,7 @@ registerAllGPUToLLVMIRTranslations(DialectRegistry ) 
{
   registerLLVMDialectTranslation(registry);
   registerNVVMDialectTranslation(registry);
   registerROCDLDialectTranslation(registry);
+  registerSPIRVDialectTranslation(registry);

joker-eph wrote:

> The PR has been open for a while and blocking other work that depends on it. 
> Would be great if you can approve soon.

Well, we were waiting on the test that you just added today!

https://github.com/llvm/llvm-project/pull/71430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[compiler-rt] [lld] [openmp] [libcxx] [mlir] [clang] [lldb] [llvm] [flang] [libc] [clang-tools-extra] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

[Mehdi Amini via cfe-commits]

@@ -0,0 +1,31 @@
+//===- SPIRVToLLVMIRTranslation.cpp - Translate SPIRV to LLVM IR 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements a translation between the MLIR SPIRV dialect and
+// LLVM IR.
+//
+//===--===//
+
+#include "mlir/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVDialect.h"
+#include "mlir/IR/BuiltinAttributes.h"
+#include "mlir/IR/Operation.h"
+#include "mlir/Target/LLVMIR/ModuleTranslation.h"
+
+using namespace mlir;
+using namespace mlir::LLVM;
+
+void mlir::registerSPIRVDialectTranslation(DialectRegistry ) {
+  registry.insert();

joker-eph wrote:

It does not make sense to me to have an API called 
"registerSPIRVDialectTranslation" that itself registers a dialect and no 
translation actually.

https://github.com/llvm/llvm-project/pull/71430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[compiler-rt] [libcxx] [mlir] [clang] [llvm] [flang] [clang-tools-extra] [mlir] Fix a zero stride canonicalizer crash (PR #74200)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.

Thanks!

https://github.com/llvm/llvm-project/pull/74200
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [libc] [mlir] [clang-tools-extra] [clang] [libcxx] [compiler-rt] [flang] [mlir][llvm] Fix verifier for const int and dense (PR #74340)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.


https://github.com/llvm/llvm-project/pull/74340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang-tools-extra] [libcxx] [compiler-rt] [mlir] [clang] [flang] [mlir] Fix a zero stride canonicalizer crash (PR #74200)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

> Is it possible to add the test case (or minimal similar example) with 
> `--inline` option so that we can confirm the original issue is resolved.
> 
> #73383

It is common that the person filing the issue does not reduce the IR or the 
pipeline that causes the bug. 
In particular this particular reporter (are you associated with them @Lewuathe 
?) seems like automated fuzzer. Here the only thing that the inliner does is 
running the canonicalizer.
I updated the issue instead.

https://github.com/llvm/llvm-project/pull/74200
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [mlir] [compiler-rt] [llvm] [libcxx] [clang-tools-extra] [flang] [mlir] Fix a zero stride canonicalizer crash (PR #74200)

[Mehdi Amini via cfe-commits]

@@ -0,0 +1,14 @@
+// RUN: mlir-opt %s -inline -split-input-file | FileCheck %s
+
+// CHECK-LABEL: func @inline_negative_stride
+func.func @inline_negative_stride(%arg0 : memref<10xf32>) -> memref<1xf32, 
strided<[?], offset: 1>> {
+  cf.br ^bb1(%arg0 : memref<10xf32>)
+^bb1(%m: memref<10xf32>):
+  %c0 = arith.constant 0 : index
+  %c1 = arith.constant 1 : index
+  %1 = memref.subview %m[1] [1] [%c0] : memref<10xf32> to memref<1xf32, 
strided<[?], offset: 1>>
+  return %1 : memref<1xf32, strided<[?], offset: 1>>
+}
+// CHECK-NEXT: arith.constant 0 : index
+// CHECK-NEXT: %[[SUBVIEW:.*]] = memref.subview
+// CHECK-NEXT: return %[[SUBVIEW]] : memref<1xf32, strided<[?], offset: 1>>

joker-eph wrote:

This is a canonicalized crash, we don't need to run the inliner.

https://github.com/llvm/llvm-project/pull/74200
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[flang] [clang] [libcxx] [lld] [lldb] [compiler-rt] [mlir] [llvm] [mlir][async] Avoid crash when not using `func.func` (PR #72801)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

FYI the build is failing (maybe re-running would be enough though)

https://github.com/llvm/llvm-project/pull/72801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[lldb] [compiler-rt] [llvm] [clang] [lld] [mlir] [flang] [libcxx] [mlir][async] Avoid crash when not using `func.func` (PR #72801)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.


https://github.com/llvm/llvm-project/pull/72801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libc] [clang-tools-extra] [mlir] [compiler-rt] [lld] [libcxx] [clang] [flang] [lldb] [llvm] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph edited 
https://github.com/llvm/llvm-project/pull/71430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libc] [clang-tools-extra] [mlir] [compiler-rt] [lld] [libcxx] [clang] [flang] [lldb] [llvm] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

[Mehdi Amini via cfe-commits]

@@ -61,6 +63,7 @@ registerAllGPUToLLVMIRTranslations(DialectRegistry ) 
{
   registerLLVMDialectTranslation(registry);
   registerNVVMDialectTranslation(registry);
   registerROCDLDialectTranslation(registry);
+  registerSPIRVDialectTranslation(registry);

joker-eph wrote:

Which muir-translate test requires that? I don't find it by skimming the patch.

https://github.com/llvm/llvm-project/pull/71430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libc] [clang-tools-extra] [flang] [clang] [llvm] [compiler-rt] [libcxx] [lld] [mlir] [lldb] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

[Mehdi Amini via cfe-commits]

@@ -0,0 +1,31 @@
+//===- SPIRVToLLVMIRTranslation.cpp - Translate SPIRV to LLVM IR 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements a translation between the MLIR SPIRV dialect and
+// LLVM IR.
+//
+//===--===//
+
+#include "mlir/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVDialect.h"
+#include "mlir/IR/BuiltinAttributes.h"
+#include "mlir/IR/Operation.h"
+#include "mlir/Target/LLVMIR/ModuleTranslation.h"
+
+using namespace mlir;
+using namespace mlir::LLVM;
+
+void mlir::registerSPIRVDialectTranslation(DialectRegistry ) {
+  registry.insert();

joker-eph wrote:

I'm confused here: there is no translation interface.

https://github.com/llvm/llvm-project/pull/71430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libc] [clang-tools-extra] [flang] [clang] [llvm] [compiler-rt] [libcxx] [lld] [mlir] [lldb] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

[Mehdi Amini via cfe-commits]

@@ -61,6 +63,7 @@ registerAllGPUToLLVMIRTranslations(DialectRegistry ) 
{
   registerLLVMDialectTranslation(registry);
   registerNVVMDialectTranslation(registry);
   registerROCDLDialectTranslation(registry);
+  registerSPIRVDialectTranslation(registry);

joker-eph wrote:

Trying to understand...
What is the unit test that requires this?

https://github.com/llvm/llvm-project/pull/71430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [compiler-rt] [llvm] [clang] [flang] [mlir] [mlir] Verify non-negative `offset` and `size` (PR #72059)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.

Nice, thanks!

https://github.com/llvm/llvm-project/pull/72059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[mlir] [llvm] [clang] [llvm] Improve implementation of StringRef::find_last_of and cie (PR #71865)

[Mehdi Amini via cfe-commits]

@@ -274,6 +278,23 @@ StringRef::size_type 
StringRef::find_first_not_of(StringRef Chars,
 /// Note: O(size() + Chars.size())
 StringRef::size_type StringRef::find_last_of(StringRef Chars,
  size_t From) const {
+#ifdef __SSE2__
+  if (Chars.size() == 2) {
+__m128i Needle0 = _mm_set1_epi8(Chars[0]);
+__m128i Needle1 = _mm_set1_epi8(Chars[1]);
+size_type Sz = std::min(From, Length);
+do {
+  Sz = Sz < 16 ? 0 : Sz - 16;
+  __m128i Buffer = _mm_loadu_si128((const __m128i *)(Data + Sz));
+  unsigned Mask = _mm_movemask_epi8(_mm_or_si128(
+  _mm_cmpeq_epi8(Buffer, Needle0), _mm_cmpeq_epi8(Buffer, Needle1)));
+  if (Mask != 0) {
+return Sz + sizeof(Mask) * CHAR_BIT - llvm::countl_zero(Mask);
+  }
+} while (Sz);
+return npos;
+  }
+#endif

joker-eph wrote:

Can this be abstracted or made out-of-line?
I'm wondering about the scalability of HW-specific intrinsics in-line 
(anticipating for the incoming `#elif defined(ARM64)`...)

https://github.com/llvm/llvm-project/pull/71865
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[compiler-rt] [clang] [llvm] [mlir] [clang-tools-extra] [mlir][tensor] Document `dest` operand (PR #71726)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.

LG (with one edit)

https://github.com/llvm/llvm-project/pull/71726
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[compiler-rt] [clang] [llvm] [mlir] [clang-tools-extra] [mlir][tensor] Document `dest` operand (PR #71726)

[Mehdi Amini via cfe-commits]

@@ -18,31 +18,34 @@ def Tensor_Dialect : Dialect {
   let description = [{
 The `tensor` dialect is intended to hold core tensor creation and
 manipulation ops, which are not strongly associated with any particular
-other dialect or domain abstraction. The primary smoke test of this is ops
-that make sense for any tensor element type.
-
-We leave it to other dialects to hold the vast swath of possible
-computations one might want to do on a tensor.
-
-The `tensor` type is (for better or for worse) used to represent all kinds
-of things, and supports an open-ended set of element types. Examples:
+other dialect or domain abstraction. The aim for ops in this dialect is
+that they make sense for any tensor element type. When this is not the
+case, the op is left to live in other dialects. Examples of element types
+that could be supported by the `tensor` dialect include:
 
 - representing large, dense aggregations of primitive types, suitable for
   high-performance numerical computing.
-- representing shapes in the `shape` dialect, which consist of small
-  1D tensors of `index` data type.
+- representing shapes in the `shape` dialect, which consist of small 1D
+  tensors of `index` data type.
 - representing aggregations of strings or “variant” types.
-- representing large, sparse aggregations of primitive types, suitable
-  for high-performance numerical computing.
-
-Thus, for the `tensor` dialect, we prefer for now to constrain the
-scope as much as possible. The expectation is that at some point
-in the future, the `tensor` dialect’s scope may be broadened through a
-careful discussion of the tradeoffs.
-
-The `tensor` type is actually a builtin type (it lives in the builtin
-dialect), and does not live in this dialect.
+- representing large, sparse aggregations of primitive types, suitable for
+  high-performance numerical computing.
 
+Because of this broad element type support and because of the existence of
+more dedicated dialects, such as the `sparse_tensor` and `linalg` dialects,
+we prefer for now to keep the `tensor` dialect as small as possible. The
+expectation is that at some point in the future, the `tensor` dialect’s
+scope may be broadened through a careful discussion of the tradeoffs.
+
+On the `tensor` type itself, note that it is actually a builtin type (it
+lives in the builtin dialect), and does not live in this dialect.
+Furthermore, a `tensor` is an immutable object. For example, this means
+that a copy will always be made of the `tensor` object when it is passed to
+the `dest` operand used by some ops in this dialect. The storage to which
+the `tensor` object refers may be mutated, see the [Destination-Passing
+Style](

joker-eph wrote:

```suggestion
the `dest` operand used by some ops in this dialect. As an optimization,
an implementation can eliminate these copies during lowering when they
are redundant and perform in-place mutation, see the [Destination-Passing
Style](
```


https://github.com/llvm/llvm-project/pull/71726
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[flang] [clang] [clang-tools-extra] [mlir] [compiler-rt] [llvm] [mlir] Verify non-negative `offset` and `size` (PR #72059)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

> > This looks like a good fix for the verifier, but we should also fix the 
> > canonicalization to **not** create invalid IR!
> 
> Then I think that I'll implement the suggestions from Matthias in this PR and 
> leave the canonicalization for a future PR. For that future PR, could you 
> tell me what the preferred result would be? What would be the valid IR here 
> that the canonicalization should return?

It is related to this PR in the sense that we can’t create invalid IR: so if 
you make it illegal in the verifier then the canonicalizer can’t fold to this 
form and must check before doing so.
If we want to leave the canonicalizer folding, then the verifier should accept 
it instead.

Both options are correct, but they should be consistent. Not folding negative 
dimension seems like a straightforward thing I think?

https://github.com/llvm/llvm-project/pull/72059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang][NFC] Refactor `CXXNewExpr::InitializationStyle` (PR #71322)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

>  tests will fail locally but pass everywhere else (for example, people 
> working on slightly out-of-norm configurations will sometimes have persistent 
> local failures that are unrelated to changes in the patch).

It never happened to me, in a way that can't be root caused and fixed (that is 
for example cases like that would be the name of my directory interfere with a 
CHECK somehow), what do you have in mind?

>  When precommit CI comes back green or with only false positives

The point of my message was that the CI wasn't a false positive: the CI didn't 
run. A false positive would be seeing a "Passed" for the test that you see 
failing locally.

> speculative commits to see whether an issue "is real" or not do happen on 
> occasion and are appropriate 

The cases I have seen for "speculative commits" are the opposite of what you're 
describing: iterating on issues that only happens on a bot and not reproducible 
locally. That is you **have** to push a commit because this is the only way to 
iterate on debugging an issue.
Pushing a commit when you have a local failure seems backward to me, I don't 
quite follow actually.


https://github.com/llvm/llvm-project/pull/71322
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang][NFC] Refactor `CXXNewExpr::InitializationStyle` (PR #71322)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

> I've seen those exact test failures locally, but since precommit CI was fine, 
> I landed this PR and kept a close eye on the bots.

If you see failures locally, it's best to understand where they coming from: 
even if it passes on bots it just means we have a hole in our test coverage.  
For the pre-commit CI, one thing to look for is a "positive signal" instead of 
the absence of "negative signal": that is checking in the log for a "success" 
for a given tests (depending on the config, tests can be marked "unsupported" 
or not executed for various reasons).
Thanks @zmodem for reporting the issue: we need to fix the premerge config!


https://github.com/llvm/llvm-project/pull/71322
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] [flang] [libc] [clang-tools-extra] [llvm] [clang] [compiler-rt] [mlir] Make SmallVectorImpl destructor protected (PR #71439)

[Mehdi Amini via cfe-commits]

@@ -95,7 +95,7 @@ class SerializeToHsacoPass
   std::unique_ptr>
   serializeISA(const std::string ) override;
 
-  std::unique_ptr> assembleIsa(const std::string );
+  std::unique_ptr> assembleIsa(const std::string );

joker-eph wrote:

@krzysz00 can you change this ahead of the current PR?

https://github.com/llvm/llvm-project/pull/71439
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxxabi] [flang] [libcxx] [llvm] [clang] [mlir] [clang-tools-extra] [lldb] [lld] [compiler-rt] Refactor ModuleToObject to offer more flexibility to subclass (NFC) (PR #71165)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/71165
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxxabi] [flang] [libcxx] [llvm] [clang] [mlir] [clang-tools-extra] [lldb] [lld] [compiler-rt] Refactor ModuleToObject to offer more flexibility to subclass (NFC) (PR #71165)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph edited 
https://github.com/llvm/llvm-project/pull/71165
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 3289ecf - [혀헽헿] changes introduced through rebase

[Mehdi Amini via cfe-commits]

Author: Mehdi Amini
Date: 2023-11-03T03:23:43-07:00
New Revision: 3289ecff8e8f5022cb6a40777392c98f1bcf5780

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

LOG: [혀헽헿] changes introduced through rebase

Created using spr 1.3.4

[skip ci]

Added: 


Modified: 
clang/test/OpenMP/cancel_codegen.cpp
clang/test/OpenMP/parallel_codegen.cpp
llvm/lib/IR/ConstantFold.cpp
mlir/include/mlir/Conversion/Passes.td
mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp
mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVMPass.cpp
mlir/test/Conversion/VectorToLLVM/vector-mask-to-llvm.mlir
mlir/test/Conversion/VectorToLLVM/vector-reduction-to-llvm.mlir
mlir/test/Conversion/VectorToLLVM/vector-scalable-memcpy.mlir
mlir/test/Conversion/VectorToLLVM/vector-to-llvm.mlir

Removed: 
mlir/test/Conversion/VectorToLLVM/typed-pointers.mlir



diff  --git a/clang/test/OpenMP/cancel_codegen.cpp 
b/clang/test/OpenMP/cancel_codegen.cpp
index 53580e0c2b0293f..03024cf331b2717 100644
--- a/clang/test/OpenMP/cancel_codegen.cpp
+++ b/clang/test/OpenMP/cancel_codegen.cpp
@@ -1026,25 +1026,25 @@ for (int i = 0; i < argc; ++i) {
 // CHECK3-NEXT:call void @llvm.experimental.noalias.scope.decl(metadata 
[[META8:![0-9]+]])
 // CHECK3-NEXT:call void @llvm.experimental.noalias.scope.decl(metadata 
[[META10:![0-9]+]])
 // CHECK3-NEXT:call void @llvm.experimental.noalias.scope.decl(metadata 
[[META12:![0-9]+]])
-// CHECK3-NEXT:store i32 [[TMP2]], ptr [[DOTGLOBAL_TID__ADDR_I]], align 4, 
!noalias !14
-// CHECK3-NEXT:store ptr [[TMP5]], ptr [[DOTPART_ID__ADDR_I]], align 8, 
!noalias !14
-// CHECK3-NEXT:store ptr null, ptr [[DOTPRIVATES__ADDR_I]], align 8, 
!noalias !14
-// CHECK3-NEXT:store ptr null, ptr [[DOTCOPY_FN__ADDR_I]], align 8, 
!noalias !14
-// CHECK3-NEXT:store ptr [[TMP3]], ptr [[DOTTASK_T__ADDR_I]], align 8, 
!noalias !14
-// CHECK3-NEXT:store ptr [[TMP7]], ptr [[__CONTEXT_ADDR_I]], align 8, 
!noalias !14
-// CHECK3-NEXT:[[TMP8:%.*]] = load ptr, ptr [[__CONTEXT_ADDR_I]], align 8, 
!noalias !14
+// CHECK3-NEXT:store i32 [[TMP2]], ptr [[DOTGLOBAL_TID__ADDR_I]], align 4, 
!noalias ![[NOALIAS0:[0-9]+]]
+// CHECK3-NEXT:store ptr [[TMP5]], ptr [[DOTPART_ID__ADDR_I]], align 8, 
!noalias ![[NOALIAS0]]
+// CHECK3-NEXT:store ptr null, ptr [[DOTPRIVATES__ADDR_I]], align 8, 
!noalias ![[NOALIAS0]]
+// CHECK3-NEXT:store ptr null, ptr [[DOTCOPY_FN__ADDR_I]], align 8, 
!noalias ![[NOALIAS0]]
+// CHECK3-NEXT:store ptr [[TMP3]], ptr [[DOTTASK_T__ADDR_I]], align 8, 
!noalias ![[NOALIAS0]]
+// CHECK3-NEXT:store ptr [[TMP7]], ptr [[__CONTEXT_ADDR_I]], align 8, 
!noalias ![[NOALIAS0]]
+// CHECK3-NEXT:[[TMP8:%.*]] = load ptr, ptr [[__CONTEXT_ADDR_I]], align 8, 
!noalias ![[NOALIAS0]]
 // CHECK3-NEXT:[[OMP_GLOBAL_THREAD_NUM_I:%.*]] = call i32 
@__kmpc_global_thread_num(ptr @[[GLOB12:[0-9]+]])
 // CHECK3-NEXT:[[TMP9:%.*]] = call i32 @__kmpc_cancel(ptr @[[GLOB1]], i32 
[[OMP_GLOBAL_THREAD_NUM_I]], i32 4)
 // CHECK3-NEXT:[[TMP10:%.*]] = icmp ne i32 [[TMP9]], 0
 // CHECK3-NEXT:br i1 [[TMP10]], label [[DOTCANCEL_EXIT_I:%.*]], label 
[[DOTCANCEL_CONTINUE_I:%.*]]
 // CHECK3:   .cancel.exit.i:
-// CHECK3-NEXT:store i32 1, ptr [[CLEANUP_DEST_SLOT_I]], align 4, !noalias 
!14
+// CHECK3-NEXT:store i32 1, ptr [[CLEANUP_DEST_SLOT_I]], align 4, !noalias 
![[NOALIAS1:[0-9]+]]
 // CHECK3-NEXT:br label [[DOTOMP_OUTLINED__EXIT:%.*]]
 // CHECK3:   .cancel.continue.i:
-// CHECK3-NEXT:store i32 0, ptr [[CLEANUP_DEST_SLOT_I]], align 4, !noalias 
!14
+// CHECK3-NEXT:store i32 0, ptr [[CLEANUP_DEST_SLOT_I]], align 4, !noalias 
![[NOALIAS1]]
 // CHECK3-NEXT:br label [[DOTOMP_OUTLINED__EXIT]]
 // CHECK3:   .omp_outlined..exit:
-// CHECK3-NEXT:[[CLEANUP_DEST_I:%.*]] = load i32, ptr 
[[CLEANUP_DEST_SLOT_I]], align 4, !noalias !14
+// CHECK3-NEXT:[[CLEANUP_DEST_I:%.*]] = load i32, ptr 
[[CLEANUP_DEST_SLOT_I]], align 4, !noalias ![[NOALIAS1]]
 // CHECK3-NEXT:ret i32 0
 //
 //

diff  --git a/clang/test/OpenMP/parallel_codegen.cpp 
b/clang/test/OpenMP/parallel_codegen.cpp
index 5c98761be0808ef..d545b4a9d9fa887 100644
--- a/clang/test/OpenMP/parallel_codegen.cpp
+++ b/clang/test/OpenMP/parallel_codegen.cpp
@@ -812,7 +812,7 @@ int main (int argc, char **argv) {
 //
 //
 // CHECK3-LABEL: define {{[^@]+}}@_Z5tmainIPPcEiT_..omp_par
-// CHECK3-SAME: (ptr noalias [[TID_ADDR:%.*]], ptr noalias [[ZERO_ADDR:%.*]], 
ptr [[TMP0:%.*]]) #[[ATTR1]] {
+// CHECK3-SAME: (ptr noalias [[TID_ADDR:%.*]], ptr noalias [[ZERO_ADDR:%.*]], 
ptr [[TMP0:%.*]]) #[[ATTR2:[0-9]+]]
 // CHECK3-NEXT:  omp.par.entry:
 // CHECK3-NEXT:[[GEP__RELOADED:%.*]] = getelementptr { ptr, ptr }, ptr 
[[TMP0]], i32 0, i32 0
 // CHECK3-NEXT:

[clang] [mlir] Add config for PDL (PR #69927)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

Need to iterate a bit more on framing the problem:

> MLIR is a general infrastructure and as far as possible no dialect is 
> intended to be special or privileged

Yes, and you can use MLIR without PDL, it's not a mandatory component. I 
believe that the minimal examples `mlir-cat` and `mlir-minimal-opt` don't have 
PDL linked in (so you can already have your *-opt tool without it!

> Users should be able to use MLIR and the parts they need to customize for 
> their solution (e.g., one doesn't have to include any dialect except the ones 
> one uses). 

I don't see PDL as "just a dialect": I see it more as an infrastructure 
component. 
That is no one will have PDL used within their IR! 
It isn't comparable to any other dialect and completely unique from this point 
of view (do we have other dialects that aren't targeting user-written 
compilers? The transform dialect might be in-between)

> Many parts are elided when not referenced (LTO DCE'd etc), but this is not 
> possible with PDL given how its integrated with the common rewrite drivers. 
> This results in it always being included even when not used.

Now that seems more accurate to me: the dependency on PDL is only from the 
rewrite drivers, which is a "bring your own" thing by the way.
So the underlying question for motivating this here would be better framed IMO 
as "should we have an option to build the GreedyPatternRewriter without PDL?" 
I see it less as a strong need here (because again, bring your own driver if 
you don't like it).

Without a stronger case, this seems like something I would be supportive if we 
can make it minimally intrusive: that is localize the changes to a maximum and 
not spread through the codebase.
There are far too many #ifdef  to me right now, this may need some more 
refactoring first to avoid this and make PDL a more proper "separate component" 
inside libMLIRRewrite so that is can be enabled/disabled more naturally.

https://github.com/llvm/llvm-project/pull/69927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [mlir][doc] Improve Destination-passing-style documentation (PR #70283)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/70283
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [mlir][doc] Improve Destination-passing-style documentation (PR #70283)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph updated 
https://github.com/llvm/llvm-project/pull/70283

>From 0bdf7a0bc1c1e3b5fc3280e9ba5f5cacfeeb5f7f Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Wed, 25 Oct 2023 19:17:32 -0700
Subject: [PATCH 1/3] Update Bufferization.md

---
 mlir/docs/Bufferization.md | 39 --
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/mlir/docs/Bufferization.md b/mlir/docs/Bufferization.md
index d9d0751cae8c9dd..ea3593549ca1563 100644
--- a/mlir/docs/Bufferization.md
+++ b/mlir/docs/Bufferization.md
@@ -101,10 +101,28 @@ bufferization strategy would be unacceptable for 
high-performance codegen. When
 choosing an already existing buffer, we must be careful not to accidentally
 overwrite data that is still needed later in the program.
 
-To simplify this problem, One-Shot Bufferize was designed for ops that are in
-*destination-passing style*. For every tensor result, such ops have a tensor
-operand, whose buffer could be utilized for storing the result of the op in the
-absence of other conflicts. We call such tensor operands the *destination*.
+To simplify this problem, One-Shot Bufferize was designed to take advantage of
+*destination-passing style*. This form exists in itself independently of
+bufferization and is tied to SSA semantics: many ops are “updating” part of
+their input SSA variable. For example the LLVM instruction
+[`insertelement`](https://llvm.org/docs/LangRef.html#insertelement-instruction)
+is inserting an element inside a vector. Since SSA values are immutable, the
+operation returns a copy of the input vector with the element inserted.
+Another example in MLIR is `linalg.generic`, which always has an extra `outs`
+operand which provides the initial values to update (for example when the
+operation is doing a reduction). 
+
+This input is referred to as "destination" in the following (quotes are
+important are this operand isn't modified in place but copied) and come into
+place in the context of bufferization as a possible "anchor" for the
+bufferization algorithm. This allows the user to shape the input in a form that
+guarantees close to optimal bufferization result when carefully choosing the
+SSA value used as "destination".
+
+For every tensor result, a "destination-passing" style op has a corresponding
+tensor operand. If there aren't any other uses of this tensor, the 
bufferization
+can alias it with the op result and perform the operation "in-place" by reusing
+the buffer allocated for this "destination" input.
 
 As an example, consider the following op: `%0 = tensor.insert %cst into
 %t[%idx] : tensor`
@@ -112,15 +130,16 @@ As an example, consider the following op: `%0 = 
tensor.insert %cst into
 `%t` is the destination in this example. When choosing a buffer for the result
 `%0`, One-Shot Bufferize considers only two options:
 
-1.  buffer(`%0`) = buffer(`%t`).
-2.  buffer(`%0`) is a newly allocated buffer.
+1.  buffer(`%0`) = buffer(`%t`): alias the destination tensor with the
+result and perform the operation in-place.
+3.  buffer(`%0`) is a newly allocated buffer.
 
 There may be other buffers in the same function that could potentially be used
 for buffer(`%0`), but those are not considered by One-Shot Bufferize to keep 
the
 bufferization simple. One-Shot Bufferize could be extended to consider such
 buffers in the future to achieve a better quality of bufferization.
 
-Tensor ops that are not in destination-passing style always bufferize to a
+Tensor ops that are not in destination-passing style always bufferized to a
 memory allocation. E.g.:
 
 ```mlir
@@ -159,9 +178,9 @@ slice of a tensor:
 ```
 
 The above example bufferizes to a `memref.subview`, followed by a
-"`linalg.generic` on memrefs" that overwrites the memory of the subview. The
-`tensor.insert_slice` bufferizes to a no-op (in the absence of RaW conflicts
-such as a subsequent read of `%s`).
+"`linalg.generic` on memrefs" that overwrites the memory of the subview, 
assuming
+that the slice `%t` has no other user. The `tensor.insert_slice` then 
bufferizes
+to a no-op (in the absence of RaW conflicts such as a subsequent read of `%s`).
 
 RaW conflicts are detected with an analysis of SSA use-def chains (details
 later). One-Shot Bufferize works best if there is a single SSA use-def chain,

>From a06bcdde0c75dbab260d7d31d4dcaf0b169d8811 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Wed, 25 Oct 2023 20:42:41 -0700
Subject: [PATCH 2/3] Update Bufferization.md

---
 mlir/docs/Bufferization.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mlir/docs/Bufferization.md b/mlir/docs/Bufferization.md
index ea3593549ca1563..88a2e50e85d938d 100644
--- a/mlir/docs/Bufferization.md
+++ b/mlir/docs/Bufferization.md
@@ -113,7 +113,7 @@ operand which provides the initial values to update (for 
example when the
 operation is doing a reduction). 
 
 This input is referred to as "destination" in the following (quotes are

[clang] [mlir][doc] Improve Destination-passing-style documentation (PR #70283)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph updated 
https://github.com/llvm/llvm-project/pull/70283

>From 0bdf7a0bc1c1e3b5fc3280e9ba5f5cacfeeb5f7f Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Wed, 25 Oct 2023 19:17:32 -0700
Subject: [PATCH 1/2] Update Bufferization.md

---
 mlir/docs/Bufferization.md | 39 --
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/mlir/docs/Bufferization.md b/mlir/docs/Bufferization.md
index d9d0751cae8c9dd..ea3593549ca1563 100644
--- a/mlir/docs/Bufferization.md
+++ b/mlir/docs/Bufferization.md
@@ -101,10 +101,28 @@ bufferization strategy would be unacceptable for 
high-performance codegen. When
 choosing an already existing buffer, we must be careful not to accidentally
 overwrite data that is still needed later in the program.
 
-To simplify this problem, One-Shot Bufferize was designed for ops that are in
-*destination-passing style*. For every tensor result, such ops have a tensor
-operand, whose buffer could be utilized for storing the result of the op in the
-absence of other conflicts. We call such tensor operands the *destination*.
+To simplify this problem, One-Shot Bufferize was designed to take advantage of
+*destination-passing style*. This form exists in itself independently of
+bufferization and is tied to SSA semantics: many ops are “updating” part of
+their input SSA variable. For example the LLVM instruction
+[`insertelement`](https://llvm.org/docs/LangRef.html#insertelement-instruction)
+is inserting an element inside a vector. Since SSA values are immutable, the
+operation returns a copy of the input vector with the element inserted.
+Another example in MLIR is `linalg.generic`, which always has an extra `outs`
+operand which provides the initial values to update (for example when the
+operation is doing a reduction). 
+
+This input is referred to as "destination" in the following (quotes are
+important are this operand isn't modified in place but copied) and come into
+place in the context of bufferization as a possible "anchor" for the
+bufferization algorithm. This allows the user to shape the input in a form that
+guarantees close to optimal bufferization result when carefully choosing the
+SSA value used as "destination".
+
+For every tensor result, a "destination-passing" style op has a corresponding
+tensor operand. If there aren't any other uses of this tensor, the 
bufferization
+can alias it with the op result and perform the operation "in-place" by reusing
+the buffer allocated for this "destination" input.
 
 As an example, consider the following op: `%0 = tensor.insert %cst into
 %t[%idx] : tensor`
@@ -112,15 +130,16 @@ As an example, consider the following op: `%0 = 
tensor.insert %cst into
 `%t` is the destination in this example. When choosing a buffer for the result
 `%0`, One-Shot Bufferize considers only two options:
 
-1.  buffer(`%0`) = buffer(`%t`).
-2.  buffer(`%0`) is a newly allocated buffer.
+1.  buffer(`%0`) = buffer(`%t`): alias the destination tensor with the
+result and perform the operation in-place.
+3.  buffer(`%0`) is a newly allocated buffer.
 
 There may be other buffers in the same function that could potentially be used
 for buffer(`%0`), but those are not considered by One-Shot Bufferize to keep 
the
 bufferization simple. One-Shot Bufferize could be extended to consider such
 buffers in the future to achieve a better quality of bufferization.
 
-Tensor ops that are not in destination-passing style always bufferize to a
+Tensor ops that are not in destination-passing style always bufferized to a
 memory allocation. E.g.:
 
 ```mlir
@@ -159,9 +178,9 @@ slice of a tensor:
 ```
 
 The above example bufferizes to a `memref.subview`, followed by a
-"`linalg.generic` on memrefs" that overwrites the memory of the subview. The
-`tensor.insert_slice` bufferizes to a no-op (in the absence of RaW conflicts
-such as a subsequent read of `%s`).
+"`linalg.generic` on memrefs" that overwrites the memory of the subview, 
assuming
+that the slice `%t` has no other user. The `tensor.insert_slice` then 
bufferizes
+to a no-op (in the absence of RaW conflicts such as a subsequent read of `%s`).
 
 RaW conflicts are detected with an analysis of SSA use-def chains (details
 later). One-Shot Bufferize works best if there is a single SSA use-def chain,

>From a06bcdde0c75dbab260d7d31d4dcaf0b169d8811 Mon Sep 17 00:00:00 2001
From: Mehdi Amini 
Date: Wed, 25 Oct 2023 20:42:41 -0700
Subject: [PATCH 2/2] Update Bufferization.md

---
 mlir/docs/Bufferization.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mlir/docs/Bufferization.md b/mlir/docs/Bufferization.md
index ea3593549ca1563..88a2e50e85d938d 100644
--- a/mlir/docs/Bufferization.md
+++ b/mlir/docs/Bufferization.md
@@ -113,7 +113,7 @@ operand which provides the initial values to update (for 
example when the
 operation is doing a reduction). 
 
 This input is referred to as "destination" in the following (quotes are

[clang-tools-extra] [mlir] Add config for PDL (PR #69927)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

Can you expand on the motivation? Why is it a problem that PDL is always 
included? Your description isn’t very explicit on the impact.

https://github.com/llvm/llvm-project/pull/69927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [mlir] Verify TestBuiltinAttributeInterfaces eltype (PR #69878)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.


https://github.com/llvm/llvm-project/pull/69878
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [mlir] Verify TestBuiltinAttributeInterfaces eltype (PR #69878)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.


https://github.com/llvm/llvm-project/pull/69878
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LLVM] Add new attribute `optdebug` to optimize for debugging (PR #66632)

[Mehdi Amini via cfe-commits]

@@ -1872,7 +1872,8 @@ example:
 passes make choices that keep the code size of this function as small
 as possible and perform optimizations that may sacrifice runtime
 performance in order to minimize the size of the generated code.
-This attribute is incompatible with the ``optnone`` attribute.
+This attribute is incompatible with the ``optdebug`` and ``optnone``
+attributes.

joker-eph wrote:

It seems that you're missing the Verifier change to enforce this?

https://github.com/llvm/llvm-project/pull/66632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [mlir][llvm] Fix elem type passing into `getelementptr` (PR #68136)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

Reverted, the bots have been broken all day.

https://github.com/llvm/llvm-project/pull/68136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [MLIR] Pass hostShared flag in gpu.alloc op to runtime wrappers (PR #66401)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/66401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [MLIR] Pass hostShared flag in gpu.alloc op to runtime wrappers (PR #66401)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph closed 
https://github.com/llvm/llvm-project/pull/66401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Replace llvm.memcpy et al's i1 isVolatile with i8 VolFlags (PR #65748)

[Mehdi Amini via cfe-commits]

@@ -214,14 +214,14 @@ class LLVM_MemcpyIntrOpBase :
 /*requiresAccessGroup=*/1, /*requiresAliasAnalysis=*/1> {
   dag args = (ins Arg:$dst,
   Arg:$src,
-  AnySignlessInteger:$len, I1Attr:$isVolatile);

joker-eph wrote:

Seems to me that should handle this as we do with the FastMathFlags: that is a 
enum attribute modeling the bitfields.

https://github.com/llvm/llvm-project/pull/65748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Fix some typos in comments: evalute -> evaluate (NFC) (PR #65906)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.


https://github.com/llvm/llvm-project/pull/65906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Update GoogleTest to v1.14.0 (PR #65823)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph approved this pull request.

Agree with @MaskRay for the style: we should minimize the diff with upstream as 
much as possible!

https://github.com/llvm/llvm-project/pull/65823
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [MLIR] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -0,0 +1,223 @@
+//===- SyclRuntimeWrappers.cpp - MLIR SYCL wrapper library ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Implements C wrappers around the sycl runtime library.
+//
+//===--===//
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef _WIN32
+#define SYCL_RUNTIME_EXPORT __declspec(dllexport)
+#else
+#define SYCL_RUNTIME_EXPORT
+#endif // _WIN32
+
+namespace {
+
+template 
+auto catchAll(F &) {
+  try {
+return func();
+  } catch (const std::exception ) {
+fprintf(stdout, "An exception was thrown: %s\n", e.what());
+fflush(stdout);
+abort();
+  } catch (...) {
+fprintf(stdout, "An unknown exception was thrown\n");
+fflush(stdout);
+abort();
+  }
+}
+
+#define L0_SAFE_CALL(call) 
\
+  {
\
+ze_result_t status = (call);   
\
+if (status != ZE_RESULT_SUCCESS) { 
\
+  fprintf(stdout, "L0 error %d\n", status);
\
+  fflush(stdout);  
\
+  abort(); 
\
+}  
\
+  }
+
+} // namespace
+
+static sycl::device getDefaultDevice() {
+  auto platformList = sycl::platform::get_platforms();
+  for (const auto  : platformList) {
+auto platformName = platform.get_info();
+bool isLevelZero = platformName.find("Level-Zero") != std::string::npos;
+if (!isLevelZero)
+  continue;
+
+return platform.get_devices()[0];
+  }
+  throw std::runtime_error("getDefaultDevice failed");
+}
+
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wglobal-constructors"

joker-eph wrote:

I don't think we have this anywhere in the codebase right now, can you remove 
it and use lazy initialization instead?

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Reland "[CUDA][HIP] Fix overloading resolution in global variable ini… (PR #65606)

[Mehdi Amini via cfe-commits]

joker-eph wrote:

Please reflow the title to avoid the `` and line wrap.

https://github.com/llvm/llvm-project/pull/65606
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -0,0 +1,70 @@
+//===- SerializeToSPIRV.cpp - Convert GPU kernel to SPIRV blob 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// This pass iterates all the SPIR-V modules in the top module and serializes
+/// each SPIR-V module to SPIR-V binary and then attachs the binary blob as a
+/// string attribute to the corresponding gpu module.
+///
+//===--===//
+
+#include "mlir/Dialect/GPU/Transforms/Passes.h"
+
+#include "mlir/Dialect/GPU/IR/GPUDialect.h"
+#include "mlir/Dialect/GPU/Transforms/Passes.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVDialect.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVOps.h"
+#include "mlir/Target/SPIRV/Serialization.h"
+
+namespace mlir {
+#define GEN_PASS_DEF_GPUSERIALIZETOSPIRVPASS
+#include "mlir/Dialect/GPU/Transforms/Passes.h.inc"
+} // namespace mlir
+
+using namespace mlir;
+
+struct GpuSerializeToSPIRVPass : public 
mlir::impl::GpuSerializeToSPIRVPassBase {
+public:
+  void runOnOperation() override {
+auto mod = getOperation();
+llvm::SmallVector spvBinary;
+for (mlir::gpu::GPUModuleOp gpuMod : mod.getOps()) {
+  auto name = gpuMod.getName();
+  // check that the spv module has the same name with gpu module except the
+  // prefix "__spv__"
+  auto isSameMod = [&](spirv::ModuleOp spvMod) -> bool {
+auto spvModName = spvMod.getName();
+return spvModName->consume_front("__spv__") && spvModName == name;
+  };
+  auto spvMods = mod.getOps();
+  auto it = llvm::find_if(spvMods, isSameMod);
+  if (it == spvMods.end()) {
+gpuMod.emitError() << "Unable to find corresponding SPIR-V module";
+signalPassFailure();
+return;
+  }
+  auto spvMod = *it;
+
+  spvBinary.clear();
+  // serialize the spv module to spv binary
+  if (mlir::failed(spirv::serialize(spvMod, spvBinary))) {
+spvMod.emitError() << "Failed to serialize SPIR-V module";
+signalPassFailure();
+return;
+  }
+
+  // attach the spv binary to the gpu module
+  auto spvData =
+  llvm::StringRef(reinterpret_cast(spvBinary.data()),
+  spvBinary.size() * sizeof(uint32_t));
+  auto spvAttr = mlir::StringAttr::get((), spvData);
+  gpuMod->setAttr(gpu::getDefaultGpuBinaryAnnotation(), spvAttr);
+  spvMod->erase();
+}
+  }
+};

joker-eph wrote:

@fabianmcg : how would that fit in the new serialization flow?

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -811,8 +812,13 @@ LogicalResult 
ConvertAllocOpToGpuRuntimeCallPattern::matchAndRewrite(
   // descriptor.
   Type elementPtrType = this->getElementPtrType(memRefType);
   auto stream = adaptor.getAsyncDependencies().front();
+
+  auto isHostShared = rewriter.create(
+  loc, llvmInt64Type, rewriter.getI64IntegerAttr(isShared));
+
   Value allocatedPtr =
-  allocCallBuilder.create(loc, rewriter, {sizeBytes, stream}).getResult();
+  allocCallBuilder.create(loc, rewriter, {sizeBytes, stream, isHostShared})
+  .getResult();

joker-eph wrote:

I see a unit-test for this: but can you send everything related to 
`isHostShared` in a separate PR?


https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -0,0 +1,70 @@
+//===- SerializeToSPIRV.cpp - Convert GPU kernel to SPIRV blob 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// This pass iterates all the SPIR-V modules in the top module and serializes
+/// each SPIR-V module to SPIR-V binary and then attachs the binary blob as a
+/// string attribute to the corresponding gpu module.
+///
+//===--===//
+
+#include "mlir/Dialect/GPU/Transforms/Passes.h"
+
+#include "mlir/Dialect/GPU/IR/GPUDialect.h"
+#include "mlir/Dialect/GPU/Transforms/Passes.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVDialect.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVOps.h"
+#include "mlir/Target/SPIRV/Serialization.h"
+
+namespace mlir {
+#define GEN_PASS_DEF_GPUSERIALIZETOSPIRVPASS
+#include "mlir/Dialect/GPU/Transforms/Passes.h.inc"
+} // namespace mlir
+
+using namespace mlir;
+
+struct GpuSerializeToSPIRVPass : public 
mlir::impl::GpuSerializeToSPIRVPassBase {
+public:
+  void runOnOperation() override {
+auto mod = getOperation();
+llvm::SmallVector spvBinary;
+for (mlir::gpu::GPUModuleOp gpuMod : mod.getOps()) {
+  auto name = gpuMod.getName();
+  // check that the spv module has the same name with gpu module except the
+  // prefix "__spv__"
+  auto isSameMod = [&](spirv::ModuleOp spvMod) -> bool {
+auto spvModName = spvMod.getName();
+return spvModName->consume_front("__spv__") && spvModName == name;
+  };
+  auto spvMods = mod.getOps();
+  auto it = llvm::find_if(spvMods, isSameMod);

joker-eph wrote:

This is really costly, can you build a symbol table once at the beginning of 
the function and use it for the queries instead?

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -811,8 +812,13 @@ LogicalResult 
ConvertAllocOpToGpuRuntimeCallPattern::matchAndRewrite(
   // descriptor.
   Type elementPtrType = this->getElementPtrType(memRefType);
   auto stream = adaptor.getAsyncDependencies().front();
+
+  auto isHostShared = rewriter.create(
+  loc, llvmInt64Type, rewriter.getI64IntegerAttr(isShared));
+
   Value allocatedPtr =
-  allocCallBuilder.create(loc, rewriter, {sizeBytes, stream}).getResult();
+  allocCallBuilder.create(loc, rewriter, {sizeBytes, stream, isHostShared})
+  .getResult();

joker-eph wrote:

I see a unit-test for this: but can you send everything related to 
`isHostShared` in a separate PR?


https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -0,0 +1,70 @@
+//===- SerializeToSPIRV.cpp - Convert GPU kernel to SPIRV blob 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// This pass iterates all the SPIR-V modules in the top module and serializes
+/// each SPIR-V module to SPIR-V binary and then attachs the binary blob as a
+/// string attribute to the corresponding gpu module.
+///
+//===--===//
+
+#include "mlir/Dialect/GPU/Transforms/Passes.h"
+
+#include "mlir/Dialect/GPU/IR/GPUDialect.h"
+#include "mlir/Dialect/GPU/Transforms/Passes.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVDialect.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVOps.h"
+#include "mlir/Target/SPIRV/Serialization.h"
+
+namespace mlir {
+#define GEN_PASS_DEF_GPUSERIALIZETOSPIRVPASS
+#include "mlir/Dialect/GPU/Transforms/Passes.h.inc"
+} // namespace mlir
+
+using namespace mlir;
+
+struct GpuSerializeToSPIRVPass : public 
mlir::impl::GpuSerializeToSPIRVPassBase {
+public:
+  void runOnOperation() override {
+auto mod = getOperation();
+llvm::SmallVector spvBinary;
+for (mlir::gpu::GPUModuleOp gpuMod : mod.getOps()) {
+  auto name = gpuMod.getName();
+  // check that the spv module has the same name with gpu module except the
+  // prefix "__spv__"
+  auto isSameMod = [&](spirv::ModuleOp spvMod) -> bool {
+auto spvModName = spvMod.getName();
+return spvModName->consume_front("__spv__") && spvModName == name;
+  };
+  auto spvMods = mod.getOps();
+  auto it = llvm::find_if(spvMods, isSameMod);

joker-eph wrote:

This is really costly, can you build a symbol table once at the beginning of 
the function and use it for the queries instead?

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph commented:

LGTM overall, this should likely get reviewed by @antiagainst / @kuhar ; and 
it's be great if you can split the independent changes and send them ahead of 
the e2e integration.

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -1158,7 +1178,7 @@ LogicalResult 
ConvertLaunchFuncOpToGpuRuntimeCallPattern::matchAndRewrite(
   {function.getResult(), adaptor.getGridSizeX(), adaptor.getGridSizeY(),
adaptor.getGridSizeZ(), adaptor.getBlockSizeX(), 
adaptor.getBlockSizeY(),
adaptor.getBlockSizeZ(), dynamicSharedMemorySize, stream, kernelParams,
-   /*extra=*/nullpointer});
+   /*extra=*/nullpointer, paramsCount});

joker-eph wrote:

I see a unit-test for this: but can you send everything related, but can you 
send everything related to paramsCount in a separate PR?

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -71,7 +71,8 @@ void GPUToSPIRVPass::runOnOperation() {
   std::unique_ptr target =
   spirv::getMemorySpaceToStorageClassTarget(*context);
   spirv::MemorySpaceToStorageClassMap memorySpaceMap =
-  spirv::mapMemorySpaceToVulkanStorageClass;
+  this->useOpenCL ? spirv::mapMemorySpaceToOpenCLStorageClass :
+  spirv::mapMemorySpaceToVulkanStorageClass;

joker-eph wrote:

Can you point out which unit-test is covering this? Can you send this in a 
separate PR?

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

https://github.com/joker-eph commented:

LGTM overall, this should likely get reviewed by @antiagainst / @kuhar ; and 
it's be great if you can split the independent changes and send them ahead of 
the e2e integration.

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Enabling Intel GPU Integration. (PR #65539)

[Mehdi Amini via cfe-commits]

@@ -71,7 +71,8 @@ void GPUToSPIRVPass::runOnOperation() {
   std::unique_ptr target =
   spirv::getMemorySpaceToStorageClassTarget(*context);
   spirv::MemorySpaceToStorageClassMap memorySpaceMap =
-  spirv::mapMemorySpaceToVulkanStorageClass;
+  this->useOpenCL ? spirv::mapMemorySpaceToOpenCLStorageClass :
+  spirv::mapMemorySpaceToVulkanStorageClass;

joker-eph wrote:

Can you point out which unit-test is covering this? Can you send this in a 
separate PR?

https://github.com/llvm/llvm-project/pull/65539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] c49142e - Fix truncated __OPENMP_NVPTX__ preprocessor condition

[Mehdi Amini via cfe-commits]

Author: Ryan Burns
Date: 2023-08-15T14:12:34-07:00
New Revision: c49142e4f5c8645a4d741d233f0cb55ef1ef87a2

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

LOG: Fix truncated __OPENMP_NVPTX__ preprocessor condition

I don't have a test case for this but noticed this warning when including 
system headers with `-I` rather than `-isystem`.

```
In file included from :1:
In file included from 
/nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_runtime_wrapper.h:157:
/nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_math.h:39:25:
 warning: extra tokens at end of #ifdef directive [-Wextra-tokens]
^
```

Reviewed By: tra

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

Added: 


Modified: 
clang/lib/Headers/__clang_cuda_math.h

Removed: 




diff  --git a/clang/lib/Headers/__clang_cuda_math.h 
b/clang/lib/Headers/__clang_cuda_math.h
index c06da2713fd8ce..04019165068668 100644
--- a/clang/lib/Headers/__clang_cuda_math.h
+++ b/clang/lib/Headers/__clang_cuda_math.h
@@ -36,7 +36,7 @@
 // because the OpenMP overlay requires constexpr functions here but prior to
 // c++14 void return functions could not be constexpr.
 #pragma push_macro("__DEVICE_VOID__")
-#ifdef __OPENMP_NVPTX__ && defined(__cplusplus) && __cplusplus < 201402L
+#if defined(__OPENMP_NVPTX__) && defined(__cplusplus) && __cplusplus < 201402L
 #define __DEVICE_VOID__ static __attribute__((always_inline, nothrow))
 #else
 #define __DEVICE_VOID__ __DEVICE__



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

[clang] 55c2211 - [APFloat] Add APFloat semantic support for TF32

[Mehdi Amini via cfe-commits]

Author: Jeremy Furtek
Date: 2023-06-23T10:54:49+02:00
New Revision: 55c2211a233e11179048cf58778f40e5a62f444a

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

LOG: [APFloat] Add APFloat semantic support for TF32

This diff adds APFloat support for a semantic that matches the TF32 data type
used by some accelerators (most notably GPUs from both NVIDIA and AMD).

For more information on the TF32 data type, see 
https://blogs.nvidia.com/blog/2020/05/14/tensorfloat-32-precision-format/.
Some intrinsics that support the TF32 data type were added in 
https://reviews.llvm.org/D122044.

For some discussion on supporting common semantics in `APFloat`, see similar
efforts for 8-bit formats at https://reviews.llvm.org/D146441, as well as
https://discourse.llvm.org/t/rfc-adding-the-amd-graphcore-maybe-others-float8-formats-to-apfloat/67969.

A subsequent diff will extend MLIR to use this data type. (Those changes are
not part of this diff to simplify the review process.)

Reviewed By: mehdi_amini

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

Added: 


Modified: 
clang/lib/AST/MicrosoftMangle.cpp
llvm/include/llvm/ADT/APFloat.h
llvm/lib/Support/APFloat.cpp
llvm/unittests/ADT/APFloatTest.cpp

Removed: 




diff  --git a/clang/lib/AST/MicrosoftMangle.cpp 
b/clang/lib/AST/MicrosoftMangle.cpp
index 9fede7bbad323..430a57d7b4ec0 100644
--- a/clang/lib/AST/MicrosoftMangle.cpp
+++ b/clang/lib/AST/MicrosoftMangle.cpp
@@ -898,6 +898,7 @@ void MicrosoftCXXNameMangler::mangleFloat(llvm::APFloat 
Number) {
   case APFloat::S_Float8E5M2FNUZ:
   case APFloat::S_Float8E4M3FNUZ:
   case APFloat::S_Float8E4M3B11FNUZ:
+  case APFloat::S_FloatTF32:
 llvm_unreachable("Tried to mangle unexpected APFloat semantics");
   }
 

diff  --git a/llvm/include/llvm/ADT/APFloat.h b/llvm/include/llvm/ADT/APFloat.h
index 1875706362f79..64caa5a765456 100644
--- a/llvm/include/llvm/ADT/APFloat.h
+++ b/llvm/include/llvm/ADT/APFloat.h
@@ -184,6 +184,10 @@ struct APFloatBase {
 // This format's exponent bias is 11, instead of the 7 (2 ** (4 - 1) - 1)
 // that IEEE precedent would imply.
 S_Float8E4M3B11FNUZ,
+// Floating point number that occupies 32 bits or less of storage, 
providing
+// improved range compared to half (16-bit) formats, at (potentially)
+// greater throughput than single precision (32-bit) formats.
+S_FloatTF32,
 
 S_x87DoubleExtended,
 S_MaxSemantics = S_x87DoubleExtended,
@@ -203,6 +207,7 @@ struct APFloatBase {
   static const fltSemantics () LLVM_READNONE;
   static const fltSemantics () LLVM_READNONE;
   static const fltSemantics () LLVM_READNONE;
+  static const fltSemantics () LLVM_READNONE;
   static const fltSemantics () LLVM_READNONE;
 
   /// A Pseudo fltsemantic used to construct APFloats that cannot conflict with
@@ -605,6 +610,7 @@ class IEEEFloat final : public APFloatBase {
   APInt convertFloat8E4M3FNAPFloatToAPInt() const;
   APInt convertFloat8E4M3FNUZAPFloatToAPInt() const;
   APInt convertFloat8E4M3B11FNUZAPFloatToAPInt() const;
+  APInt convertFloatTF32APFloatToAPInt() const;
   void initFromAPInt(const fltSemantics *Sem, const APInt );
   template  void initFromIEEEAPInt(const APInt );
   void initFromHalfAPInt(const APInt );
@@ -619,6 +625,7 @@ class IEEEFloat final : public APFloatBase {
   void initFromFloat8E4M3FNAPInt(const APInt );
   void initFromFloat8E4M3FNUZAPInt(const APInt );
   void initFromFloat8E4M3B11FNUZAPInt(const APInt );
+  void initFromFloatTF32APInt(const APInt );
 
   void assign(const IEEEFloat &);
   void copySignificand(const IEEEFloat &);

diff  --git a/llvm/lib/Support/APFloat.cpp b/llvm/lib/Support/APFloat.cpp
index c882c08b256e7..4a73739b5282a 100644
--- a/llvm/lib/Support/APFloat.cpp
+++ b/llvm/lib/Support/APFloat.cpp
@@ -138,6 +138,7 @@ static constexpr fltSemantics semFloat8E4M3FNUZ = {
 7, -7, 4, 8, fltNonfiniteBehavior::NanOnly, fltNanEncoding::NegativeZero};
 static constexpr fltSemantics semFloat8E4M3B11FNUZ = {
 4, -10, 4, 8, fltNonfiniteBehavior::NanOnly, fltNanEncoding::NegativeZero};
+static constexpr fltSemantics semFloatTF32 = {127, -126, 11, 19};
 static constexpr fltSemantics semX87DoubleExtended = {16383, -16382, 64, 80};
 static constexpr fltSemantics semBogus = {0, 0, 0, 0};
 
@@ -203,6 +204,8 @@ const llvm::fltSemantics 
::EnumToSemantics(Semantics S) {
 return Float8E4M3FNUZ();
   case S_Float8E4M3B11FNUZ:
 return Float8E4M3B11FNUZ();
+  case S_FloatTF32:
+return FloatTF32();
   case S_x87DoubleExtended:
 return x87DoubleExtended();
   }
@@ -233,6 +236,8 @@ APFloatBase::SemanticsToEnum(const llvm::fltSemantics ) 
{
 return S_Float8E4M3FNUZ;
   else if ( == ::APFloat::Float8E4M3B11FNUZ())
 return S_Float8E4M3B11FNUZ;
+  else if ( == 

[clang] 26eec9e - Revert "[clang] Implement Change scope of lambda trailing-return-type"

[Mehdi Amini via cfe-commits]

Author: Mehdi Amini
Date: 2022-04-13T19:35:13Z
New Revision: 26eec9e9dbc20186f6b810fe01d3a01aac8ae6f4

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

LOG: Revert "[clang] Implement Change scope of lambda trailing-return-type"

This reverts commit adff142dc253d65b6560e420bba6b858d88d4a98.
This broke clang bootstrap: it made existing C++ code in LLVM invalid:

llvm/include/llvm/CodeGen/LiveInterval.h:630:53: error: captured variable 'Idx' 
cannot appear here
  [=](std::remove_reference_t V,
^

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/AST/DeclCXX.h
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Scope.h
clang/include/clang/Sema/ScopeInfo.h
clang/include/clang/Sema/Sema.h
clang/lib/Parse/ParseExprCXX.cpp
clang/lib/Sema/Scope.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaCXXScopeSpec.cpp
clang/lib/Sema/SemaExpr.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/lib/Sema/SemaLambda.cpp
clang/lib/Sema/TreeTransform.h
clang/test/CXX/expr/expr.prim/expr.prim.lambda/p11-1y.cpp
clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
clang/www/cxx_status.html

Removed: 
clang/test/SemaCXX/lambda-capture-type-deduction.cpp



diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 016aafee016c2..91fc57dfac595 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -247,9 +247,6 @@ C++2b Feature Support
 - Implemented `P2128R6: Multidimensional subscript operator 
`_.
 - Implemented `P0849R8: auto(x): decay-copy in the language 
`_.
 - Implemented `P2242R3: Non-literal variables (and labels and gotos) in 
constexpr functions`_.
-- Implemented `P2036R3: Change scope of lambda trailing-return-type 
`_.
-  This proposal modifies how variables captured in lambdas can appear in 
trailing return type
-  expressions and how their types are deduced therein, in all C++ language 
versions.
 
 CUDA Language Changes in Clang
 --

diff  --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index c640f7f7ba63f..04a9daa14e05e 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1799,20 +1799,6 @@ class CXXRecordDecl : public RecordDecl {
 return getLambdaData().MethodTyInfo;
   }
 
-  void setLambdaTypeInfo(TypeSourceInfo *TS) {
-auto *DD = DefinitionData;
-assert(DD && DD->IsLambda && "setting lambda property of non-lambda 
class");
-auto  = static_cast(*DD);
-DL.MethodTyInfo = TS;
-  }
-
-  void setLambdaIsGeneric(bool IsGeneric) {
-auto *DD = DefinitionData;
-assert(DD && DD->IsLambda && "setting lambda property of non-lambda 
class");
-auto  = static_cast(*DD);
-DL.IsGenericLambda = IsGeneric;
-  }
-
   // Determine whether this type is an Interface Like type for
   // __interface inheritance purposes.
   bool isInterfaceLike() const;

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index e154925538f3a..3213163ee7876 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -7704,8 +7704,6 @@ let CategoryName = "Lambda Issue" in {
   def err_lambda_impcap : Error<
 "variable %0 cannot be implicitly captured in a lambda with no "
 "capture-default specified">;
-  def err_lambda_used_before_capture: Error<
-"captured variable %0 cannot appear here">;
   def note_lambda_variable_capture_fixit : Note<
 "capture %0 by %select{value|reference}1">;
   def note_lambda_default_capture_fixit : Note<

diff  --git a/clang/include/clang/Sema/Scope.h 
b/clang/include/clang/Sema/Scope.h
index 5a2d51b63d909..872951a0829b4 100644
--- a/clang/include/clang/Sema/Scope.h
+++ b/clang/include/clang/Sema/Scope.h
@@ -44,11 +44,11 @@ class Scope {
   enum ScopeFlags {
 /// This indicates that the scope corresponds to a function, which
 /// means that labels are set here.
-FnScope = 0x01,
+FnScope   = 0x01,
 
 /// This is a while, do, switch, for, etc that can have break
 /// statements embedded into it.
-BreakScope = 0x02,
+BreakScope= 0x02,
 
 /// This is a while, do, for, which can have continue statements
 /// embedded into it.
@@ -140,12 +140,6 @@ class Scope {
 /// parsed. If such a scope is a ContinueScope, it's invalid to jump to the
 /// continue block from here.
 ConditionVarScope = 0x200,
-
-/// This is the scope for a lambda, after the lambda introducer.
-/// 

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

[Mehdi AMINI via cfe-commits]

On Thu, Sep 30, 2021 at 8:05 PM Hubert Tong
 wrote:
>
> On Thu, Sep 30, 2021 at 6:56 PM Mehdi AMINI via cfe-commits 
>  wrote:
>>
>> We talked about this with the IWG (Infrastructure Working Group) just
>> last week coincidentally.
>> Two major blocking tracks that were identified at the roundtable
>> during the LLVM Dev Meeting exactly 2 years ago are still an issue
>> today:
>>
>> 1) Replacement for Herald rules. This is what allows us to subscribe
>> and track new revisions or commits based on paths in the repo or other
>> criteria. We could build a replacement based on GitHub action or any
>> other kind of service, but this is a bit tricky (how do you store
>> emails privately? etc.). I have looked around online but I didn't find
>> another OSS project (or external company) providing a similar service
>> for GitHub unfortunately, does anyone know of any?
>>
>> 2) Support for stacked commits. I can see how to structure this
>> somehow assuming we would push pull-request branches in the main repo
>> (with one new commit per branch and cascading the pull-requests from
>> one branch to the other), otherwise this will be a major regression
>> compared to the current workflow.
>>
>> What remains unknown to me is the current state of GitHub management
>> of comments across `git commit --amend` and force push to update a
>> branch.
>
>
> Force pushing to a PR branch does make it harder for reviewers to see how 
> review comments were addressed or what was done since they last looked at the 
> PR. Are your use cases addressed if the workflow consists of pushing 
> additional commits to address comments or pushing a merge commit to refresh 
> the PR branch? When the PR is approved, the "squash and merge" option can be 
> used to commit the patch as a single commit.

This isn't compatible with stacked commits / stacked PR unfortunately.
Also while merging main back into a branch of commits is "OK",
rebasing multiple commits is much less friendly (the same conflict may
have to be fixed over and over in each commit).

> I find the code review experience in GitHub to be a productivity drain 
> compared to Phabricator.
>
> Older inline comments are much harder to find in GitHub.
> Much more clicking needed in GitHub to actually load everything (blocks of 
> comments folded away, comments collapsed not because you want them collapsed 
> but because someone else or maybe just GitHub thought it should be collapsed, 
> source files not loaded).
> GitHub does not allow inline comments further away than a few lines from a 
> change.

Thanks! I have the same feeling, but I didn't have anything specific
to point to and figured that this is in the scope of "I'll get used to
it", but you mention some good points here.

Best,

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

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

[Mehdi AMINI via cfe-commits]

On Thu, Sep 30, 2021 at 4:09 PM Brian Cain  wrote:
>
>
>
> On Thu, Sep 30, 2021, 6:04 PM Brian Cain  wrote:
>>
>> Does something like Rust's "bors" bot satisfy the herald rules need?
>
>
>
> sorry, maybe I was thinking of the high-five bot. And it looks like that's 
> not quite a match for herald.

Actually high-five may be a good starting point!
In practice it may still be a bit limited by the GitHub integration:
for example I suspect you may not be able to "subscribe" someone to a
pull-request?
Also what the user will receive as an email may be quite unhelpful
(you have been subscribed to "" instead of the
current more comprehensive emails).


>
>
>>
>> re: #2 I have done this on GHE and it's mildly awkward but it does work.
>>
>> And yes normalizing force pushes is the unfortunate state of GitHub PRs. 
>> Comments are preserved. Code-anchored comments like review comments are 
>> marked as referring to out-of-date code, IIRC.
>>
>> On Thu, Sep 30, 2021, 5:56 PM Mehdi AMINI  wrote:
>>>
>>> We talked about this with the IWG (Infrastructure Working Group) just
>>> last week coincidentally.
>>> Two major blocking tracks that were identified at the roundtable
>>> during the LLVM Dev Meeting exactly 2 years ago are still an issue
>>> today:
>>>
>>> 1) Replacement for Herald rules. This is what allows us to subscribe
>>> and track new revisions or commits based on paths in the repo or other
>>> criteria. We could build a replacement based on GitHub action or any
>>> other kind of service, but this is a bit tricky (how do you store
>>> emails privately? etc.). I have looked around online but I didn't find
>>> another OSS project (or external company) providing a similar service
>>> for GitHub unfortunately, does anyone know of any?
>>>
>>> 2) Support for stacked commits. I can see how to structure this
>>> somehow assuming we would push pull-request branches in the main repo
>>> (with one new commit per branch and cascading the pull-requests from
>>> one branch to the other), otherwise this will be a major regression
>>> compared to the current workflow.
>>>
>>> What remains unknown to me is the current state of GitHub management
>>> of comments across `git commit --amend` and force push to update a
>>> branch.
>>>
>>> Others may have other items to add!
>>>
>>> --
>>> Mehdi
>>>
>>> On Thu, Sep 30, 2021 at 3:39 PM Brian Cain via llvm-dev
>>>  wrote:
>>> >
>>> > How far are we from a workflow that leverages Github's Pull Requests?  Is 
>>> > there some consensus that it's a desired end goal, but some features are 
>>> > missing?  Or do we prefer to use a workflow like this for the long term?
>>> >
>>> > On Thu, Sep 30, 2021, 4:54 PM Chris Tetreault via llvm-dev 
>>> >  wrote:
>>> >>
>>> >> As I, and others have noticed, it seems that as of today, there’s some 
>>> >> certificate issue with arcanist. (See: 
>>> >> https://lists.llvm.org/pipermail/llvm-dev/2021-September/153019.html) 
>>> >> The fix seems simple, and a PR is up, but looking through the PR 
>>> >> activity, it seems that the PR will not be accepted because Phabricator 
>>> >> is no longer being maintained. It seems that arc has become the first 
>>> >> casualty of the discontinuation of maintenance of phabricator.
>>> >>
>>> >>
>>> >>
>>> >> I know that arc is not universally used, but I think it’s a serious blow 
>>> >> to many people’s workflows. I think that MyDeveloperDay’s question might 
>>> >> have just become a bit more urgent.
>>> >>
>>> >>
>>> >>
>>> >> I suppose in the short-term, we could fork the phabricator repos in 
>>> >> order to fix little issues like this. Alternately, we should probably 
>>> >> stop recommending arcanist (unless we want to provide instructions on 
>>> >> how to fix any breakages that come along).
>>> >>
>>> >>
>>> >>
>>> >> Thanks,
>>> >>
>>> >>Chris Tetreault
>>> >>
>>> >>
>>> >>
>>> >> From: llvm-dev  On Behalf Of 
>>> >> MyDeveloper Day via llvm-dev
>>> >> Sent: Wednesday, August 18, 2021 10:17 AM
>>> >> To: llvm-dev ; cfe-commits 
>>> >> 
>>> >> Subject: [llvm-dev] Phabricator Creator Pulling the Plug
>>> >>
>>> >>
>>> >>
>>> >> WARNING: This email originated from outside of Qualcomm. Please be wary 
>>> >> of any links or attachments, and do not enable macros.
>>> >>
>>> >> All
>>> >>
>>> >>
>>> >>
>>> >> I'm a massive fan of Phabricator, and I know there is often lots of 
>>> >> contentious discussion about its relative merits vs github,
>>> >>
>>> >>
>>> >>
>>> >> But unless I missed this, was there any discussion regarding the recent 
>>> >> "Winding Down" announcement of Phabricator? and what it might mean for 
>>> >> us in LLVM
>>> >>
>>> >>
>>> >>
>>> >> See:
>>> >>
>>> >> https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/
>>> >>
>>> >> https://www.phacility.com/phabricator/
>>> >>
>>> >>
>>> >>
>>> >> Personally I'm excited by the concept of a community driven replacement 
>>> >> ( https://we.phorge.it/) .
>>> >>
>>> >> epriestley did a truly amazing job, it 

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

[Mehdi AMINI via cfe-commits]

We talked about this with the IWG (Infrastructure Working Group) just
last week coincidentally.
Two major blocking tracks that were identified at the roundtable
during the LLVM Dev Meeting exactly 2 years ago are still an issue
today:

1) Replacement for Herald rules. This is what allows us to subscribe
and track new revisions or commits based on paths in the repo or other
criteria. We could build a replacement based on GitHub action or any
other kind of service, but this is a bit tricky (how do you store
emails privately? etc.). I have looked around online but I didn't find
another OSS project (or external company) providing a similar service
for GitHub unfortunately, does anyone know of any?

2) Support for stacked commits. I can see how to structure this
somehow assuming we would push pull-request branches in the main repo
(with one new commit per branch and cascading the pull-requests from
one branch to the other), otherwise this will be a major regression
compared to the current workflow.

What remains unknown to me is the current state of GitHub management
of comments across `git commit --amend` and force push to update a
branch.

Others may have other items to add!

-- 
Mehdi

On Thu, Sep 30, 2021 at 3:39 PM Brian Cain via llvm-dev
 wrote:
>
> How far are we from a workflow that leverages Github's Pull Requests?  Is 
> there some consensus that it's a desired end goal, but some features are 
> missing?  Or do we prefer to use a workflow like this for the long term?
>
> On Thu, Sep 30, 2021, 4:54 PM Chris Tetreault via llvm-dev 
>  wrote:
>>
>> As I, and others have noticed, it seems that as of today, there’s some 
>> certificate issue with arcanist. (See: 
>> https://lists.llvm.org/pipermail/llvm-dev/2021-September/153019.html) The 
>> fix seems simple, and a PR is up, but looking through the PR activity, it 
>> seems that the PR will not be accepted because Phabricator is no longer 
>> being maintained. It seems that arc has become the first casualty of the 
>> discontinuation of maintenance of phabricator.
>>
>>
>>
>> I know that arc is not universally used, but I think it’s a serious blow to 
>> many people’s workflows. I think that MyDeveloperDay’s question might have 
>> just become a bit more urgent.
>>
>>
>>
>> I suppose in the short-term, we could fork the phabricator repos in order to 
>> fix little issues like this. Alternately, we should probably stop 
>> recommending arcanist (unless we want to provide instructions on how to fix 
>> any breakages that come along).
>>
>>
>>
>> Thanks,
>>
>>Chris Tetreault
>>
>>
>>
>> From: llvm-dev  On Behalf Of MyDeveloper 
>> Day via llvm-dev
>> Sent: Wednesday, August 18, 2021 10:17 AM
>> To: llvm-dev ; cfe-commits 
>> 
>> Subject: [llvm-dev] Phabricator Creator Pulling the Plug
>>
>>
>>
>> WARNING: This email originated from outside of Qualcomm. Please be wary of 
>> any links or attachments, and do not enable macros.
>>
>> All
>>
>>
>>
>> I'm a massive fan of Phabricator, and I know there is often lots of 
>> contentious discussion about its relative merits vs github,
>>
>>
>>
>> But unless I missed this, was there any discussion regarding the recent 
>> "Winding Down" announcement of Phabricator? and what it might mean for us in 
>> LLVM
>>
>>
>>
>> See:
>>
>> https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/
>>
>> https://www.phacility.com/phabricator/
>>
>>
>>
>> Personally I'm excited by the concept of a community driven replacement ( 
>> https://we.phorge.it/) .
>>
>> epriestley did a truly amazing job, it wasn't open to public contributions. 
>> Perhaps more open development could lead to closing some of the github gaps 
>> that were of concern.
>>
>>
>>
>> MyDeveloperDay
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 28c0479 - Revert "[Matrix] Overload stride arg in matrix.columnwise.load/store."

[Mehdi Amini via cfe-commits]

Author: Mehdi Amini
Date: 2021-08-12T11:57:19Z
New Revision: 28c04794df74ad3c38155a244729d1f8d57b9400

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

LOG: Revert "[Matrix] Overload stride arg in matrix.columnwise.load/store."

This reverts commit a1ef81de35a4bac6d3b22e9d7186d880124d7a55.

Broke the MLIR buildbot.

Added: 


Modified: 
clang/test/CodeGen/matrix-type-builtins.c
clang/test/CodeGenCXX/matrix-type-builtins.cpp
clang/test/CodeGenObjC/matrix-type-builtins.m
llvm/docs/LangRef.rst
llvm/include/llvm/IR/Intrinsics.td
llvm/include/llvm/IR/MatrixBuilder.h
llvm/lib/Transforms/Scalar/LowerMatrixIntrinsics.cpp
llvm/test/Transforms/LowerMatrixIntrinsics/strided-load-double.ll
llvm/test/Transforms/LowerMatrixIntrinsics/strided-store-double.ll
llvm/test/Verifier/matrix-intrinsics.ll

Removed: 




diff  --git a/clang/test/CodeGen/matrix-type-builtins.c 
b/clang/test/CodeGen/matrix-type-builtins.c
index ec0be85b7151e..67f5c78196878 100644
--- a/clang/test/CodeGen/matrix-type-builtins.c
+++ b/clang/test/CodeGen/matrix-type-builtins.c
@@ -1,5 +1,4 @@
-// RUN: %clang_cc1 -fenable-matrix -triple x86_64-apple-darwin %s -emit-llvm 
-disable-llvm-passes -o - | FileCheck --check-prefixes=COMMON,CHECK64 %s
-// RUN: %clang_cc1 -fenable-matrix -triple i386-apple-darwin %s -emit-llvm 
-disable-llvm-passes -o - | FileCheck --check-prefixes=COMMON,CHECK32 %s
+// RUN: %clang_cc1 -fenable-matrix -triple x86_64-apple-darwin %s -emit-llvm 
-disable-llvm-passes -o - | FileCheck %s
 
 // Also check we do not crash when running some middle-end passes. Most
 // importantly this includes the IR verifier, to ensure we emit valid IR.
@@ -16,33 +15,30 @@ typedef unsigned ux1x6_t __attribute__((matrix_type(1, 6)));
 typedef unsigned ux6x1_t __attribute__((matrix_type(6, 1)));
 
 void transpose_double_5x5(dx5x5_t *a) {
-  // COMMON-LABEL: define{{.*}} void @transpose_double_5x5(
-  // CHECK32:   [[A:%.*]] = load <25 x double>, <25 x double>* {{.*}}, 
align 4
-  // CHECK64:   [[A:%.*]] = load <25 x double>, <25 x double>* {{.*}}, 
align 8
-  // COMMON-NEXT:   [[TRANS:%.*]] = call <25 x double> 
@llvm.matrix.transpose.v25f64(<25 x double> [[A]], i32 5, i32 5)
-  // COMMON-NEXT:   [[AT_ADDR:%.*]] = bitcast [25 x double]* %a_t to <25 x 
double>*
-  // CHECK32-NEXT:  store <25 x double> [[TRANS]], <25 x double>* [[AT_ADDR]], 
align 4
-  // CHECK64-NEXT:  store <25 x double> [[TRANS]], <25 x double>* [[AT_ADDR]], 
align 8
-
+  // CHECK-LABEL: define{{.*}} void @transpose_double_5x5(
+  // CHECK:[[A:%.*]] = load <25 x double>, <25 x double>* {{.*}}, 
align 8
+  // CHECK-NEXT:   [[TRANS:%.*]] = call <25 x double> 
@llvm.matrix.transpose.v25f64(<25 x double> [[A]], i32 5, i32 5)
+  // CHECK-NEXT:   [[AT_ADDR:%.*]] = bitcast [25 x double]* %a_t to <25 x 
double>*
+  // CHECK-NEXT:   store <25 x double> [[TRANS]], <25 x double>* [[AT_ADDR]], 
align 8
   dx5x5_t a_t = __builtin_matrix_transpose(*a);
 }
 
 void transpose_float_3x2(fx3x2_t *a) {
-  // COMMON-LABEL: define{{.*}} void @transpose_float_3x2(
-  // COMMON:[[A:%.*]] = load <6 x float>, <6 x float>* {{.*}}, align 4
-  // COMMON-NEXT:   [[TRANS:%.*]] = call <6 x float> 
@llvm.matrix.transpose.v6f32(<6 x float> [[A]], i32 3, i32 2)
-  // COMMON-NEXT:   [[AT_ADDR:%.*]] = bitcast [6 x float]* %a_t to <6 x float>*
-  // COMMON-NEXT:   store <6 x float> [[TRANS]], <6 x float>* [[AT_ADDR]], 
align 4
+  // CHECK-LABEL: define{{.*}} void @transpose_float_3x2(
+  // CHECK:[[A:%.*]] = load <6 x float>, <6 x float>* {{.*}}, align 4
+  // CHECK-NEXT:   [[TRANS:%.*]] = call <6 x float> 
@llvm.matrix.transpose.v6f32(<6 x float> [[A]], i32 3, i32 2)
+  // CHECK-NEXT:   [[AT_ADDR:%.*]] = bitcast [6 x float]* %a_t to <6 x float>*
+  // CHECK-NEXT:   store <6 x float> [[TRANS]], <6 x float>* [[AT_ADDR]], 
align 4
 
   fx2x3_t a_t = __builtin_matrix_transpose(*a);
 }
 
 void transpose_int_20x4(ix20x4_t *a) {
-  // COMMON-LABEL: define{{.*}} void @transpose_int_20x4(
-  // COMMON: [[A:%.*]] = load <80 x i32>, <80 x i32>* {{.*}}, align 4
-  // COMMON-NEXT:[[TRANS:%.*]] = call <80 x i32> 
@llvm.matrix.transpose.v80i32(<80 x i32> [[A]], i32 20, i32 4)
-  // COMMON-NEXT:[[AT_ADDR:%.*]] = bitcast [80 x i32]* %a_t to <80 x i32>*
-  // COMMON-NEXT:store <80 x i32> [[TRANS]], <80 x i32>* [[AT_ADDR]], 
align 4
+  // CHECK-LABEL: define{{.*}} void @transpose_int_20x4(
+  // CHECK: [[A:%.*]] = load <80 x i32>, <80 x i32>* {{.*}}, align 4
+  // CHECK-NEXT:[[TRANS:%.*]] = call <80 x i32> 
@llvm.matrix.transpose.v80i32(<80 x i32> [[A]], i32 20, i32 4)
+  // CHECK-NEXT:[[AT_ADDR:%.*]] = bitcast [80 x i32]* %a_t to <80 x i32>*
+  // CHECK-NEXT:store <80 x i32> [[TRANS]], <80 x i32>*