[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

aengelke wrote:

> we can wrap them in some frontend plugin adapter and have some plugin 
> uniformity in clang.

Could you share some more details on how you envision this? Because loading the 
backend plugins has to happen somewhere in or under ExecuteCompilerInvocation 
before llvm::cl::ParseCommandLineOptions is called. So there're two options:

1. Call the backend plugin wrapper here and prepopualte the 
FrontendPluginRegistry with it. From the FrontendPluginRegistry, at this point 
only instantiate is called, where there's no access to the CompilerInstance. I 
don't see how this is viable.
2. Move llvm::cl::ParseCommandLineOptions down into CodeGenAction, which might 
cause some breakage due to changing options. -fpass-plugin would still need to 
be handled somewhere before that and this does need some extra code somewhere?


https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [LifetimeSafety] Track moved declarations to prevent false positives (PR #170007)

2025-12-15 Thread Yitzhak Mandelbaum via llvm-branch-commits 

https://github.com/ymand approved this pull request.


https://github.com/llvm/llvm-project/pull/170007
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [LifetimeSafety] Track moved declarations to prevent false positives (PR #170007)

2025-12-15 Thread Yitzhak Mandelbaum via llvm-branch-commits 


@@ -102,6 +102,11 @@ class FactsGenerator : public 
ConstStmtVisitor {
   // corresponding to the left-hand side is updated to be a "write", thereby
   // exempting it from the check.
   llvm::DenseMap UseFacts;
+
+  // Tracks declarations that have been moved via std::move. This is used to
+  // prevent false positives when the original owner is destroyed after the
+  // value has been moved. This tracking is flow-insensitive.

ymand wrote:

Consider moving the comments on lines 195-201 here, or at least mentioning 
them. But, that's a matter of taste :)

Also, whether in comments or test maybe highlight some example impacts? e.g. 
modifying your test below:

```
{
  MyObj a;
  v = a;
  b = std::move(a);

  refresh(a); // For types which can take on valid state after move.
  v = a;
}
```

Or, a branch?
```
{
  MyObj a;
  v = a;
  if (c) {
b = std::move(a);
  }
}
```



https://github.com/llvm/llvm-project/pull/170007
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] [libc] Add `IN6_IS_ADDR_LOOPBACK` (PR #172312)

2025-12-15 Thread via llvm-branch-commits 

llvmbot wrote:




@llvm/pr-subscribers-libc

Author: Connector Switch (c8ef)


Changes



---
Full diff: https://github.com/llvm/llvm-project/pull/172312.diff


2 Files Affected:

- (modified) libc/include/llvm-libc-macros/netinet-in-macros.h (+9) 
- (modified) libc/test/include/netinet_in_test.cpp (+5) 


``diff
diff --git a/libc/include/llvm-libc-macros/netinet-in-macros.h 
b/libc/include/llvm-libc-macros/netinet-in-macros.h
index f97a2dd0c3fda..3148aed6bb112 100644
--- a/libc/include/llvm-libc-macros/netinet-in-macros.h
+++ b/libc/include/llvm-libc-macros/netinet-in-macros.h
@@ -44,6 +44,15 @@
(__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[2]) == 0 &&  
\
(__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[3]) == 0)
 
+#define IN6_IS_ADDR_LOOPBACK(a)
\
+  ((__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[0]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[1]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[2]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[12]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[13]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[14]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[15]) == 1)
+
 #define IN6_IS_ADDR_LINKLOCAL(a)   
\
   ((__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[0]) == 0xfe &&
\
(__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[1] & 0xc0) == 0x80)
diff --git a/libc/test/include/netinet_in_test.cpp 
b/libc/test/include/netinet_in_test.cpp
index d70c780800858..15e57ccef7ac5 100644
--- a/libc/test/include/netinet_in_test.cpp
+++ b/libc/test/include/netinet_in_test.cpp
@@ -19,6 +19,11 @@ TEST(LlvmLibcNetinetInTest, IN6Macro) {
 buff[i] = 0;
   }
 
+  EXPECT_FALSE(IN6_IS_ADDR_LOOPBACK(buff));
+  buff[15] = 1;
+  EXPECT_TRUE(IN6_IS_ADDR_LOOPBACK(buff));
+  buff[15] = 0;
+
   buff[0] = 0xfe;
   buff[1] = 0x80;
   EXPECT_TRUE(IN6_IS_ADDR_LINKLOCAL(buff));

``




https://github.com/llvm/llvm-project/pull/172312
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] [libc] Add `IN6_IS_ADDR_LOOPBACK` (PR #172312)

2025-12-15 Thread Connector Switch via llvm-branch-commits 

https://github.com/c8ef ready_for_review 
https://github.com/llvm/llvm-project/pull/172312
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] [libc] Add `IN6_IS_ADDR_LOOPBACK` (PR #172312)

2025-12-15 Thread Connector Switch via llvm-branch-commits 

https://github.com/c8ef created https://github.com/llvm/llvm-project/pull/172312

None

>From 77c407bc401353723cc0a5d684c9e17102d0559b Mon Sep 17 00:00:00 2001
From: c8ef 
Date: Mon, 15 Dec 2025 23:01:04 +0800
Subject: [PATCH] [libc] Add `IN6_IS_ADDR_LOOPBACK`

---
 libc/include/llvm-libc-macros/netinet-in-macros.h | 9 +
 libc/test/include/netinet_in_test.cpp | 5 +
 2 files changed, 14 insertions(+)

diff --git a/libc/include/llvm-libc-macros/netinet-in-macros.h 
b/libc/include/llvm-libc-macros/netinet-in-macros.h
index f97a2dd0c3fda..3148aed6bb112 100644
--- a/libc/include/llvm-libc-macros/netinet-in-macros.h
+++ b/libc/include/llvm-libc-macros/netinet-in-macros.h
@@ -44,6 +44,15 @@
(__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[2]) == 0 &&  
\
(__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[3]) == 0)
 
+#define IN6_IS_ADDR_LOOPBACK(a)
\
+  ((__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[0]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[1]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint32_t *, a)[2]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[12]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[13]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[14]) == 0 &&  
\
+   (__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[15]) == 1)
+
 #define IN6_IS_ADDR_LINKLOCAL(a)   
\
   ((__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[0]) == 0xfe &&
\
(__LLVM_LIBC_CAST(reinterpret_cast, uint8_t *, a)[1] & 0xc0) == 0x80)
diff --git a/libc/test/include/netinet_in_test.cpp 
b/libc/test/include/netinet_in_test.cpp
index d70c780800858..15e57ccef7ac5 100644
--- a/libc/test/include/netinet_in_test.cpp
+++ b/libc/test/include/netinet_in_test.cpp
@@ -19,6 +19,11 @@ TEST(LlvmLibcNetinetInTest, IN6Macro) {
 buff[i] = 0;
   }
 
+  EXPECT_FALSE(IN6_IS_ADDR_LOOPBACK(buff));
+  buff[15] = 1;
+  EXPECT_TRUE(IN6_IS_ADDR_LOOPBACK(buff));
+  buff[15] = 0;
+
   buff[0] = 0xfe;
   buff[1] = 0x80;
   EXPECT_TRUE(IN6_IS_ADDR_LINKLOCAL(buff));

___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] [libc] Add `IN6_IS_ADDR_LOOPBACK` (PR #172312)

2025-12-15 Thread Connector Switch via llvm-branch-commits 

c8ef wrote:

> [!WARNING]
> This pull request is not mergeable via GitHub because a downstack PR is 
> open. Once all requirements are satisfied, merge this PR as a stack  href="https://app.graphite.com/github/pr/llvm/llvm-project/172312?utm_source=stack-comment-downstack-mergeability-warning";
>  >on Graphite.
> https://graphite.dev/docs/merge-pull-requests";>Learn more

* **#172312** https://app.graphite.com/github/pr/llvm/llvm-project/172312?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/> 👈 https://app.graphite.com/github/pr/llvm/llvm-project/172312?utm_source=stack-comment-view-in-graphite";
 target="_blank">(View in Graphite)
* **#172311** https://app.graphite.com/github/pr/llvm/llvm-project/172311?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/>
* `main`




This stack of pull requests is managed by https://graphite.dev?utm-source=stack-comment";>Graphite. Learn 
more about https://stacking.dev/?utm_source=stack-comment";>stacking.


https://github.com/llvm/llvm-project/pull/172312
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] AMDGPU: Introduce f64 rsq pattern in AMDGPUCodeGenPrepare (PR #172053)

2025-12-15 Thread Yingwei Zheng via llvm-branch-commits 


@@ -605,15 +608,117 @@ static Value *emitRsqIEEE1ULP(IRBuilder<> &Builder, 
Value *Src,
   return Builder.CreateFMul(Rsq, OutputScaleFactor);
 }
 
+/// Emit inverse sqrt expansion for f64 with a correction sequence on top of
+/// v_rsq_f64. This should give a 1ulp result.
+Value *AMDGPUCodeGenPrepareImpl::emitRsqF64(IRBuilder<> &Builder, Value *X,
+FastMathFlags SqrtFMF,
+FastMathFlags DivFMF,
+const Instruction *CtxI,
+bool IsNegative) const {
+  // rsq(x):
+  //   double y0 = BUILTIN_AMDGPU_RSQRT_F64(x);
+  //   double e = MATH_MAD(-y0 * (x == PINF_F64 || x == 0.0 ? y0 : x), y0, 
1.0);
+  //   return MATH_MAD(y0*e, MATH_MAD(e, 0.375, 0.5), y0);
+  //
+  // The rsq instruction handles the special cases correctly. We need to check
+  // for the edge case conditions to ensure the special case propagates through
+  // the later instructions.
+
+  Value *Y0 = Builder.CreateUnaryIntrinsic(Intrinsic::amdgcn_rsq, X);
+
+  // Try to elide the edge case check.
+  //
+  // Fast math flags imply:
+  //   sqrt ninf => !isinf(x)
+  //   sqrt nnan => not helpful
+  //   fdiv ninf => x != 0, !isinf(x)
+  //   fdiv nnan => x != 0
+  bool MaybePosInf = !SqrtFMF.noInfs() && !DivFMF.noInfs();
+  bool MaybeZero = !DivFMF.noInfs() && !DivFMF.noNaNs();
+
+  DenormalMode DenormMode;
+  FPClassTest Interested = fcNone;
+  if (MaybeZero)
+Interested = fcZero;
+  if (MaybePosInf)
+Interested = fcPosInf;
+
+  if (Interested != fcNone) {
+KnownFPClass KnownSrc = computeKnownFPClass(X, Interested, CtxI);
+if (KnownSrc.isKnownNeverPosInfinity())
+  MaybePosInf = false;
+
+DenormMode = F.getDenormalMode(X->getType()->getFltSemantics());
+if (KnownSrc.isKnownNeverLogicalZero(DenormMode))
+  MaybeZero = false;
+  }
+
+  Value *SpecialOrRsq = Y0;

dtcxzyw wrote:

Oops. I misread `-x*y0` as `-y0*y0`. So the implementation in rsqrtD.cl is 
correct.

For normal cases (`x == PINF_F64 || x == 0.0` evaluates to false), we should 
use x instead.
```suggestion
  Value *SpecialOrRsq = X;
```


https://github.com/llvm/llvm-project/pull/172053
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Add __builtin_allow_sanitize_check() (PR #172030)

2025-12-15 Thread Alexander Potapenko via llvm-branch-commits 


@@ -3549,6 +3549,38 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
 llvm::MetadataAsValue::get(Ctx, llvm::MDString::get(Ctx, Kind)));
 return RValue::get(Allow);
   }
+  case Builtin::BI__builtin_allow_sanitize_check: {
+Intrinsic::ID IntrID = Intrinsic::not_intrinsic;
+StringRef SanitizerName =
+cast(E->getArg(0)->IgnoreParenCasts())->getString();
+
+if (SanitizerName == "address" || SanitizerName == "kernel-address") {

ramosian-glider wrote:

Won't this provoke the users to use "address" and "kernel-address" 
interchangeably?
If we want this, maybe it should be reflected in the documentation?

https://github.com/llvm/llvm-project/pull/172030
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Add __builtin_allow_sanitize_check() (PR #172030)

2025-12-15 Thread Alexander Potapenko via llvm-branch-commits 

https://github.com/ramosian-glider approved this pull request.

Two nits.

https://github.com/llvm/llvm-project/pull/172030
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Add __builtin_allow_sanitize_check() (PR #172030)

2025-12-15 Thread Alexander Potapenko via llvm-branch-commits 

https://github.com/ramosian-glider edited 
https://github.com/llvm/llvm-project/pull/172030
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Add __builtin_allow_sanitize_check() (PR #172030)

2025-12-15 Thread Alexander Potapenko via llvm-branch-commits 


@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+void test_builtin_allow_sanitize_check() {
+  // Test with non-string literal argument

ramosian-glider wrote:

Shouldn't comments in this file end with a period?

https://github.com/llvm/llvm-project/pull/172030
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

aengelke wrote:

> Can we move this code in LoadRequestedPlugins to make it work with other 
> tools and actions?

I originally did that but moved away from that, because it would pull in 
CodeGen and large parts of LLVM (including all passes) into the clangFrontend 
library...

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 

https://github.com/aengelke edited 
https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 

https://github.com/aengelke updated 
https://github.com/llvm/llvm-project/pull/171868

>From 7169c9eef2da43c0e9d79dad32c55797ef31ac27 Mon Sep 17 00:00:00 2001
From: Alexis Engelke 
Date: Fri, 12 Dec 2025 10:57:24 +
Subject: [PATCH 1/2] load plugins in FrontendTool to avoid CodeGen
 dependencies in Frontend

Created using spr 1.3.5-bogner
---
 clang/include/clang/Basic/CodeGenOptions.h|  4 ++--
 clang/lib/CodeGen/BackendUtil.cpp |  4 ++--
 clang/lib/Frontend/CompilerInstance.cpp   |  9 -
 clang/lib/FrontendTool/CMakeLists.txt |  1 +
 .../FrontendTool/ExecuteCompilerInvocation.cpp| 15 +++
 5 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/clang/include/clang/Basic/CodeGenOptions.h 
b/clang/include/clang/Basic/CodeGenOptions.h
index 10808f3aba45c..149e7f46491f6 100644
--- a/clang/include/clang/Basic/CodeGenOptions.h
+++ b/clang/include/clang/Basic/CodeGenOptions.h
@@ -20,7 +20,6 @@
 #include "llvm/ADT/FloatingPointMode.h"
 #include "llvm/Frontend/Debug/Options.h"
 #include "llvm/Frontend/Driver/CodeGenOptions.h"
-#include "llvm/Passes/PassPlugin.h"
 #include "llvm/Support/CodeGen.h"
 #include "llvm/Support/Hash.h"
 #include "llvm/Support/Regex.h"
@@ -33,6 +32,7 @@
 
 namespace llvm {
 class PassBuilder;
+class PassPlugin;
 }
 namespace clang {
 
@@ -479,7 +479,7 @@ class CodeGenOptions : public CodeGenOptionsBase {
   std::vector PassPluginNames;
 
   /// List of loaded pass plugins.
-  std::vector PassPlugins;
+  std::vector PassPlugins;
 
   /// List of pass builder callbacks.
   std::vector> PassBuilderCallbacks;
diff --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index b39e303d13994..92e4d99ddea48 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -1018,8 +1018,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
 #endif
   }
   // Register plugin callbacks with PB.
-  for (auto &Plugin : CodeGenOpts.PassPlugins)
-Plugin.registerPassBuilderCallbacks(PB);
+  for (llvm::PassPlugin *Plugin : CodeGenOpts.PassPlugins)
+Plugin->registerPassBuilderCallbacks(PB);
   for (const auto &PassCallback : CodeGenOpts.PassBuilderCallbacks)
 PassCallback(PB);
 #define HANDLE_EXTENSION(Ext)  
\
diff --git a/clang/lib/Frontend/CompilerInstance.cpp 
b/clang/lib/Frontend/CompilerInstance.cpp
index c69be4fea232c..884e7b52483a1 100644
--- a/clang/lib/Frontend/CompilerInstance.cpp
+++ b/clang/lib/Frontend/CompilerInstance.cpp
@@ -1077,15 +1077,6 @@ void CompilerInstance::LoadRequestedPlugins() {
   << Path << Error;
   }
 
-  // Load and store pass plugins for back-end.
-  for (const std::string &Path : getCodeGenOpts().PassPluginNames) {
-if (auto PassPlugin = llvm::PassPlugin::Load(Path))
-  getCodeGenOpts().PassPlugins.push_back(*PassPlugin);
-else
-  getDiagnostics().Report(diag::err_fe_unable_to_load_plugin)
-  << Path << toString(PassPlugin.takeError());
-  }
-
   // Check if any of the loaded plugins replaces the main AST action
   for (const FrontendPluginRegistry::entry &Plugin :
FrontendPluginRegistry::entries()) {
diff --git a/clang/lib/FrontendTool/CMakeLists.txt 
b/clang/lib/FrontendTool/CMakeLists.txt
index 66213f76eb968..d851eba629926 100644
--- a/clang/lib/FrontendTool/CMakeLists.txt
+++ b/clang/lib/FrontendTool/CMakeLists.txt
@@ -1,5 +1,6 @@
 set(LLVM_LINK_COMPONENTS
   Option
+  Passes
   Support
   )
 
diff --git a/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp 
b/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
index 05f646b43e3c4..0779d7b683092 100644
--- a/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ b/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -26,6 +26,7 @@
 #include "clang/StaticAnalyzer/Frontend/AnalyzerHelpFlags.h"
 #include "clang/StaticAnalyzer/Frontend/FrontendActions.h"
 #include "llvm/Option/OptTable.h"
+#include "llvm/Passes/PassPlugin.h"
 #include "llvm/Support/BuryPointer.h"
 #include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Support/ErrorHandling.h"
@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {
+if (auto PassPlugin = llvm::PassPlugin::Load(Path)) {
+  
PassPlugins.emplace_back(std::make_unique(*PassPlugin));
+  Clang->getCodeGenOpts().PassPlugins.push_back(PassPlugins.back().get());
+} else {
+  Clang->getDiagnostics().Report(diag::err_fe_unable_to_load_plugin)
+  << Path << toString(PassPlugin.takeError());
+}
+  }
+
   // Honor -mllvm.
   //
   // FIXME: Remove this, one day.

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 


@@ -474,8 +475,11 @@ class CodeGenOptions : public CodeGenOptionsBase {
 
   std::vector DefaultFunctionAttrs;
 
-  /// List of dynamic shared object files to be loaded as pass plugins.
-  std::vector PassPlugins;
+  /// List of dynamic shared object file names to be loaded as pass plugins.
+  std::vector PassPluginNames;
+
+  /// List of loaded pass plugins.
+  std::vector PassPlugins;

aengelke wrote:

Moved to CompilerInstance. (I was taking the lead from PassBuilderCallbacks, 
which is also not a value type, but good to know that this is the outlier.)

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [DA] Remove ExtraGCD from GCD MIV (NFC) (PR #172004)

2025-12-15 Thread Michael Kruse via llvm-branch-commits 

https://github.com/Meinersbur approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/172004
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

aengelke wrote:

It seems the motivation was to add pass callbacks without loading a plugin 
shared library and without recompiling Clang. This PR also almost achieves 
this, the only missing part is the ability to create a PassPlugin without 
loading a DSO (this could be easily added). (So instead of adding to 
PassBuilderCallbacks, a user would create a new DSO-less PassPlugin and push 
that to the PassPlugins list introduced here.)

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/21.x: Build and ship OpenMP with LLVM releases (#160581) (PR #172303)

2025-12-15 Thread via llvm-branch-commits 

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Leandro Lupori (luporl)


Changes

Backport a93214c5828d64d699637221166870ae0a7e68ed

Fixes #135021

Suggested-by: Kawashima Takahiro 


---
Full diff: https://github.com/llvm/llvm-project/pull/172303.diff


1 Files Affected:

- (modified) clang/cmake/caches/Release.cmake (+4-1) 


``diff
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 9f7e906241106..eb490fd558df0 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -36,7 +36,7 @@ if (${CMAKE_HOST_SYSTEM_NAME} MATCHES "Linux")
   list(APPEND DEFAULT_PROJECTS "bolt")
 endif()
 
-set (DEFAULT_RUNTIMES "compiler-rt;libcxx")
+set (DEFAULT_RUNTIMES "compiler-rt;libcxx;openmp;flang-rt")
 if (NOT WIN32)
   list(APPEND DEFAULT_RUNTIMES "libcxxabi" "libunwind")
 endif()
@@ -158,6 +158,9 @@ endif()
 # Final Stage Config (stage2)
 set_final_stage_var(LLVM_ENABLE_RUNTIMES "${LLVM_RELEASE_ENABLE_RUNTIMES}" 
STRING)
 set_final_stage_var(LLVM_ENABLE_PROJECTS "${LLVM_RELEASE_ENABLE_PROJECTS}" 
STRING)
+# Don't build libarcher due to:
+# https://github.com/llvm/llvm-project/issues/170138
+set_final_stage_var(LIBOMP_ARCHER_SUPPORT "OFF" BOOL)
 if (${CMAKE_HOST_SYSTEM_NAME} MATCHES "Linux")
   set_final_stage_var(CLANG_BOLT "INSTRUMENT" STRING)
 endif()

``




https://github.com/llvm/llvm-project/pull/172303
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/21.x: Build and ship OpenMP with LLVM releases (#160581) (PR #172303)

2025-12-15 Thread Leandro Lupori via llvm-branch-commits 

https://github.com/luporl milestoned 
https://github.com/llvm/llvm-project/pull/172303
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/21.x: Build and ship OpenMP with LLVM releases (#160581) (PR #172303)

2025-12-15 Thread Leandro Lupori via llvm-branch-commits 

https://github.com/luporl created 
https://github.com/llvm/llvm-project/pull/172303

Backport a93214c5828d64d699637221166870ae0a7e68ed

Fixes #135021

Suggested-by: Kawashima Takahiro 


>From c42be077dd4cabf47fea07295a52b5f246d94ba6 Mon Sep 17 00:00:00 2001
From: Leandro Lupori 
Date: Mon, 15 Dec 2025 10:40:01 -0300
Subject: [PATCH] release/21.x: Build and ship OpenMP with LLVM releases
 (#160581)

Backport a93214c5828d64d699637221166870ae0a7e68ed

Fixes #135021

Suggested-by: Kawashima Takahiro 
---
 clang/cmake/caches/Release.cmake | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 9f7e906241106..eb490fd558df0 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -36,7 +36,7 @@ if (${CMAKE_HOST_SYSTEM_NAME} MATCHES "Linux")
   list(APPEND DEFAULT_PROJECTS "bolt")
 endif()
 
-set (DEFAULT_RUNTIMES "compiler-rt;libcxx")
+set (DEFAULT_RUNTIMES "compiler-rt;libcxx;openmp;flang-rt")
 if (NOT WIN32)
   list(APPEND DEFAULT_RUNTIMES "libcxxabi" "libunwind")
 endif()
@@ -158,6 +158,9 @@ endif()
 # Final Stage Config (stage2)
 set_final_stage_var(LLVM_ENABLE_RUNTIMES "${LLVM_RELEASE_ENABLE_RUNTIMES}" 
STRING)
 set_final_stage_var(LLVM_ENABLE_PROJECTS "${LLVM_RELEASE_ENABLE_PROJECTS}" 
STRING)
+# Don't build libarcher due to:
+# https://github.com/llvm/llvm-project/issues/170138
+set_final_stage_var(LIBOMP_ARCHER_SUPPORT "OFF" BOOL)
 if (${CMAKE_HOST_SYSTEM_NAME} MATCHES "Linux")
   set_final_stage_var(CLANG_BOLT "INSTRUMENT" STRING)
 endif()

___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Vassil Vassilev via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

vgvassilev wrote:

Ok, for some reason I thought this part was in CodeGen. Phew. Can we move this 
code in `LoadRequestedPlugins` to make it work with other tools and actions?

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread William Moses via llvm-branch-commits 


@@ -474,8 +475,11 @@ class CodeGenOptions : public CodeGenOptionsBase {
 
   std::vector DefaultFunctionAttrs;
 
-  /// List of dynamic shared object files to be loaded as pass plugins.
-  std::vector PassPlugins;
+  /// List of dynamic shared object file names to be loaded as pass plugins.
+  std::vector PassPluginNames;

wsmoses wrote:

Since this PR keeps the existing pass plugin name infrastructure, it is wise to 
not rename it and avoid churn.

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [flang] [mlir] [OpenMP][MLIR] Add thread_limit with dims modifier support (PR #171825)

2025-12-15 Thread Krzysztof Parzyszek via llvm-branch-commits 


@@ -1452,15 +1452,53 @@ class OpenMP_ThreadLimitClauseSkip<
   > : OpenMP_Clause {
   let arguments = (ins
+ConfinedAttr, [IntPositive]>:$thread_limit_num_dims,
+Variadic:$thread_limit_dims_values,
 Optional:$thread_limit

kparzysz wrote:

Can we just have a single list?  If there was no "dims" it would contain a 
single element.

https://github.com/llvm/llvm-project/pull/171825
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 


@@ -474,8 +475,11 @@ class CodeGenOptions : public CodeGenOptionsBase {
 
   std::vector DefaultFunctionAttrs;
 
-  /// List of dynamic shared object files to be loaded as pass plugins.
-  std::vector PassPlugins;
+  /// List of dynamic shared object file names to be loaded as pass plugins.
+  std::vector PassPluginNames;

aengelke wrote:

Hmm, not sure: PassPluginNames is now processed much earlier than it was 
before, which would cause the more subtle breakage of plugins being silently 
ignored. (E.g., if a Clang front-end plugin contains 
`PassPlugins.push_back(somestring)`, with this patch right now it will fail to 
compile, but without renaming, the new name would be ignored because the plugin 
is never loaded -- CodeGen/BackendUtil doesn't do this anymore.)

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Jan Svoboda via llvm-branch-commits 


@@ -474,8 +475,11 @@ class CodeGenOptions : public CodeGenOptionsBase {
 
   std::vector DefaultFunctionAttrs;
 
-  /// List of dynamic shared object files to be loaded as pass plugins.
-  std::vector PassPlugins;
+  /// List of dynamic shared object file names to be loaded as pass plugins.
+  std::vector PassPluginNames;
+
+  /// List of loaded pass plugins.
+  std::vector PassPlugins;

jansvoboda11 wrote:

`CodeGenOptions` is supposed to be a value type. Please store this somewhere 
else (e.g. `CompilerInstance`).

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 

https://github.com/aengelke edited 
https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

aengelke wrote:

I meant LLVM's CodeGen, not Clang CodeGen, sorry. This would be pulled in 
transitively.

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Vassil Vassilev via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPlugins) {
+if (auto PassPlugin = llvm::PassPlugin::Load(Path)) {
+  
PassPlugins.emplace_back(std::make_unique(*PassPlugin));
+  Clang->getPassPlugins().push_back(PassPlugins.back().get());
+} else {
+  Clang->getDiagnostics().Report(diag::err_fe_unable_to_load_plugin)
+  << Path << toString(PassPlugin.takeError());
+}
+  }
+

vgvassilev wrote:

Apologies for the misunderstanding. I meant moving this code in 
`LoadRequestedPlugins`, too.

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Vassil Vassilev via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

vgvassilev wrote:

What part of CodeGen is needed? I thought only the `getCodeGenOpts` but that is 
solvable by moving the relevant fields elsewhere.

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPlugins) {
+if (auto PassPlugin = llvm::PassPlugin::Load(Path)) {
+  
PassPlugins.emplace_back(std::make_unique(*PassPlugin));
+  Clang->getPassPlugins().push_back(PassPlugins.back().get());
+} else {
+  Clang->getDiagnostics().Report(diag::err_fe_unable_to_load_plugin)
+  << Path << toString(PassPlugin.takeError());
+}
+  }
+

aengelke wrote:

llvm::PassPlugin::Load pulls in the LLVM Passes library, which pulls in almost 
all passes. I can do that, but then the clangFrontend library would have many 
more dependencies. clangFrontendTool already pulls these in through CodeGen 
etc., but clangFrontend users might not want that?

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 

https://github.com/aengelke edited 
https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Stefan Gränitz via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

weliveindetail wrote:

Not a blocker for this PR, but since the question comes up: There is a test 
from https://github.com/llvm/llvm-project/pull/70171 that loads a LLVM plugin 
through a dummy `PluginASTAction`. The additional `PassBuilderCallbacks` member 
in `CodeGenOption` originates from this PR.

@wsmoses Is there a good reason for it not to use the LLVM plugin interface? If 
yes, can we represent that in the test? If no, can we drop it?

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [mlir] [Backport][MLIR] Properties.td fix from main commit 77f2560 (PR #165768)

2025-12-15 Thread Fabian Mora via llvm-branch-commits 

fabianmcg wrote:

> The bug that this is fixing, when was the bug introduced? Since this is the 
> very last release from the 21.x branch, we generally only want to accept 
> fixes for regressions or small fixes that have a wide impact. As a 
> consequence of this being the last release from the 21.x branch, if there are 
> any issues that may arise from this change, we would not be able to fix it 
> until the LLVM 22 release.
> 
> Given that, @fabianmcg, do you feel this change is very low risk and a fix 
> for a recent regression that would merit including in 21.x instead of just 
> waiting for LLVM 22?

Apologies, I missed the ping

The bug has been there since July 2024. The reason that it has gone unnoticed 
is that properties still have no wide adoption, and the bug triggers in very 
specific circumstances.

In the circumstances that it does trigger, it makes the IR non-roundtripable 
through bytecode (this is a basic feature, and one that it's usually tested in 
a lit suite), and it produces no error message making it hard to debug.

In terms of impact, without the fix, people might not be able to use 
OptionalProp. However, given that MLIR still doesn't recommend the usage of 
releases for dev (ie. we still recommend people to use main), that there are 
many unsolved issues around properties, and that a downstream can solve the 
issue without this fix. I would likely not included.

Nonetheless, @yu810226 is there a reason you needed to backport this patch?

https://github.com/llvm/llvm-project/pull/165768
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Stefan Gränitz via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

weliveindetail wrote:

> It seems the motivation was to add pass callbacks without loading a plugin 
> shared library and without recompiling Clang

Not sure. The LLVMPrintFunctionNames example builds a .so and the test loads it 
with `-load`. To me this looks like a parallel mechanism.

> Clang should not have multiple ways to deal with plugins

Clang should handle its own frontend plugins. And it should accept and forward 
LLVM pass plugins. Rust and Swift do that as well. (BTW this patch doesn't 
anything in that regard, it just moves things around to improve parameter 
handling.)

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Stefan Gränitz via llvm-branch-commits 

https://github.com/weliveindetail approved this pull request.

I think we should check that Clang loads the example plugin from the right 
location in standalone builds. Otherwise, this LGTM

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Vassil Vassilev via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

vgvassilev wrote:

Why we need separate infrastructure from what we have for the frontend plugins? 
Ideally the plugin should be able to register itself when loaded and I do not 
see why we need any special treatment here.

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Alexis Engelke via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

aengelke wrote:

llvm::PassPlugin works differently from front-end plugins in that they don't 
register themselves anywhere but just expose a function that returns 
information about the plugin (stored in llvm::PassPlugin). This information 
contains a function pointer, which is expected to be called when the pass 
pipeline is built.

However, pass plugins do register their llvm::cl options when loaded, but 
currently, they are only loaded in EmitAssemblyHelper::RunOptimizationPipeline, 
which is long after the LLVM options have been parsed (which is done here).

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [DA] Introduce OverflowSafeSignedAPInt to prevent potential overflow (PR #171991)

2025-12-15 Thread Sjoerd Meijer via llvm-branch-commits 

sjoerdmeijer wrote:

I am not sure this this belongs in DA. APInt has several routines that deal 
determine overflow, e.g. sadd_ov, ssub_ov, etc. So, as a very minimum, if we 
need a convenience wrapper, we should first use those routines?


https://github.com/llvm/llvm-project/pull/171991
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Stefan Gränitz via llvm-branch-commits 

https://github.com/weliveindetail edited 
https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Vassil Vassilev via llvm-branch-commits 


@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
 
   Clang->LoadRequestedPlugins();
 
+  // Load and store pass plugins for the back-end. Store the loaded pass 
plugins
+  // here and store references to these in CodeGenOpts to avoid pulling in the
+  // entire PassPlugin dependency chain in CodeGenOpts.
+  std::vector> PassPlugins;
+  for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {

vgvassilev wrote:

Clang should not have multiple ways to deal with plugins. For me that is a 
design issue and we will need to address it. 

It seems the merged pr was done because of the lack of proper backend plugin 
support which we are intending to fix. 

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Vassil Vassilev via llvm-branch-commits 

https://github.com/vgvassilev edited 
https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [CI] Make premerge advisor exit with code 0 if failures are explained (PR #172394)

2025-12-15 Thread Aiden Grossman via llvm-branch-commits 

https://github.com/boomanaiden154 updated 
https://github.com/llvm/llvm-project/pull/172394


___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [CI] Make premerge advisor exit with code 0 if failures are explained (PR #172394)

2025-12-15 Thread via llvm-branch-commits 

llvmbot wrote:




@llvm/pr-subscribers-infrastructure

Author: Aiden Grossman (boomanaiden154)


Changes

This will mark the CI as green if the premerge advisor is able to
explain all of the failures. We have seen many false negatives (failures
not explained that should be), but no false positives (failures
explained that should not be) so far.


---
Full diff: https://github.com/llvm/llvm-project/pull/172394.diff


3 Files Affected:

- (modified) .ci/generate_test_report_lib.py (+27-3) 
- (modified) .ci/generate_test_report_lib_test.py (+52-24) 
- (modified) .ci/premerge_advisor_explain.py (+13-14) 


``diff
diff --git a/.ci/generate_test_report_lib.py b/.ci/generate_test_report_lib.py
index 5edde254eb73d..734ce3a4f4316 100644
--- a/.ci/generate_test_report_lib.py
+++ b/.ci/generate_test_report_lib.py
@@ -158,6 +158,16 @@ def get_failures(junit_objects) -> dict[str, 
list[tuple[str, str]]]:
 return failures
 
 
+def are_all_failures_explained(
+failures: list[tuple[str, str]], failure_explanations: dict[str, 
FailureExplanation]
+) -> bool:
+for failure in failures:
+failed_action, _ = failure
+if failed_action not in failure_explanations:
+return False
+return True
+
+
 # Set size_limit to limit the byte size of the report. The default is 1MB as 
this
 # is the most that can be put into an annotation. If the generated report 
exceeds
 # this limit and failures are listed, it will be generated again without 
failures
@@ -172,7 +182,7 @@ def generate_report(
 size_limit=1024 * 1024,
 list_failures=True,
 failure_explanations_list: list[FailureExplanation] = [],
-):
+) -> tuple[str, bool]:
 failures = get_failures(junit_objects)
 tests_run = 0
 tests_skipped = 0
@@ -183,6 +193,12 @@ def generate_report(
 if not failure_explanation["explained"]:
 continue
 failure_explanations[failure_explanation["name"]] = failure_explanation
+all_failures_explained = True
+if failures:
+for _, failures_list in failures.items():
+all_failures_explained &= are_all_failures_explained(
+failures_list, failure_explanations
+)
 
 for results in junit_objects:
 for testsuite in results:
@@ -202,7 +218,11 @@ def generate_report(
 )
 else:
 ninja_failures = find_failure_in_ninja_logs(ninja_logs)
+all_failures_explained &= are_all_failures_explained(
+ninja_failures, failure_explanations
+)
 if not ninja_failures:
+all_failures_explained = False
 report.extend(
 [
 "The build failed before running any tests. Detailed "
@@ -229,7 +249,7 @@ def generate_report(
 UNRELATED_FAILURES_STR,
 ]
 )
-return "\n".join(report)
+return ("\n".join(report), all_failures_explained)
 
 tests_passed = tests_run - tests_skipped - tests_failed
 
@@ -263,7 +283,11 @@ def plural(num_tests):
 # No tests failed but the build was in a failed state. Bring this to 
the user's
 # attention.
 ninja_failures = find_failure_in_ninja_logs(ninja_logs)
+all_failures_explained &= are_all_failures_explained(
+ninja_failures, failure_explanations
+)
 if not ninja_failures:
+all_failures_explained = False
 report.extend(
 [
 "",
@@ -302,7 +326,7 @@ def plural(num_tests):
 list_failures=False,
 )
 
-return report
+return (report, all_failures_explained)
 
 
 def load_info_from_files(build_log_files):
diff --git a/.ci/generate_test_report_lib_test.py 
b/.ci/generate_test_report_lib_test.py
index 06279d672f3c3..bd72a7b2314d5 100644
--- a/.ci/generate_test_report_lib_test.py
+++ b/.ci/generate_test_report_lib_test.py
@@ -191,19 +191,23 @@ def test_ninja_log_mismatched_failed(self):
 def test_title_only(self):
 self.assertEqual(
 generate_test_report_lib.generate_report("Foo", 0, [], []),
-dedent(
-"""\
+(
+dedent(
+"""\
 # Foo
 
 :white_check_mark: The build succeeded and no tests ran. This 
is expected in some build configurations."""
+),
+True,
 ),
 )
 
 def test_title_only_failure(self):
 self.assertEqual(
 generate_test_report_lib.generate_report("Foo", 1, [], []),
-dedent(
-"""\
+(
+dedent(
+"""\
 # Foo
 
 The build failed before running any tests. Detailed information 
about the build failure could not be automatically obtained.
@@ -211,6 +215,8 @@ def test_title_only_failure(self):
 Download the build'

[llvm-branch-commits] [CI] Make premerge advisor exit with code 0 if failures are explained (PR #172394)

2025-12-15 Thread Aiden Grossman via llvm-branch-commits 

https://github.com/boomanaiden154 created 
https://github.com/llvm/llvm-project/pull/172394

This will mark the CI as green if the premerge advisor is able to
explain all of the failures. We have seen many false negatives (failures
not explained that should be), but no false positives (failures
explained that should not be) so far.



___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] InstCombine: Fold absorbing fmul of compared 0 into select (PR #172381)

2025-12-15 Thread via llvm-branch-commits 

llvmbot wrote:




@llvm/pr-subscribers-llvm-transforms

Author: Matt Arsenault (arsenm)


Changes

This is similar to the select-bin-op identity case, except
in this case we are looking for the absorbing value for the
binary operator.

If the compared value is a floating-point 0, and the fmul is
implied to return a +0, put the 0 directly into the select
operand. This pattern appears in scale-if-denormal sequences
after  optimizations assume denormals are treated as 0.

Fold:

```
%fabs.x = call float @llvm.fabs.f32(float %x)
%mul.fabs.x = fmul float %fabs.x, known_positive
%x.is.zero = fcmp oeq float %x, 0.0
%select = select i1 %x.is.zero, float %mul.fabs.x, float %fabs.x

```

To:

```
%fabs.x = call float @llvm.fabs.f32(float %x)
%mul.fabs.x = fmul float %fabs.x,known_positive
%x.is.zero = fcmp oeq float %x, 0.0
%select = select i1 %x.is.zero, float 0.0, float %fabs.x

```

https://alive2.llvm.org/ce/z/Qcy56Z

---
Full diff: https://github.com/llvm/llvm-project/pull/172381.diff


2 Files Affected:

- (modified) llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp (+39-19) 
- (modified) 
llvm/test/Transforms/InstCombine/select-fcmp-fmul-zero-absorbing-value.ll 
(+7-15) 


``diff
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp 
b/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
index f52bac5e600cb..5216c9ae1 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
@@ -83,40 +83,60 @@ static Instruction *foldSelectBinOpIdentity(SelectInst &Sel,
   if (!match(Sel.getOperand(IsEq ? 1 : 2), m_BinOp(BO)))
 return nullptr;
 
-  // The compare constant must be the identity constant for that binop.
-  // If this a floating-point compare with 0.0, any zero constant will do.
-  Type *Ty = BO->getType();
-  Constant *IdC = ConstantExpr::getBinOpIdentity(BO->getOpcode(), Ty, true);
-  if (IdC != C) {
-if (!IdC || !CmpInst::isFPPredicate(Pred))
-  return nullptr;
-if (!match(IdC, m_AnyZeroFP()) || !match(C, m_AnyZeroFP()))
-  return nullptr;
-  }
+  // For absorbing values, we can fold to the compared value.
+  bool IsAbsorbingValue = false;
 
   // Last, match the compare variable operand with a binop operand.
   Value *Y;
   if (BO->isCommutative()) {
-if (!match(BO, m_c_BinOp(m_Value(Y), m_Specific(X
+// Recognized 0 as an absorbing value for fmul, but we need to be careful
+// about the sign. This could be more aggressive, by handling arbitrary 
sign
+// bit operations as long as we know the fmul sign matches (and handling
+// arbitrary opcodes).
+if (match(BO, m_c_FMul(m_FAbs(m_Specific(X)), m_Value(Y))) &&
+match(C, m_AnyZeroFP()) &&
+IC.fmulByZeroIsZero(Y, BO->getFastMathFlags(), &Sel))
+  IsAbsorbingValue = true;
+else if (!match(BO, m_c_BinOp(m_Value(Y), m_Specific(X
   return nullptr;
   } else {
 if (!match(BO, m_BinOp(m_Value(Y), m_Specific(X
   return nullptr;
   }
 
-  // +0.0 compares equal to -0.0, and so it does not behave as required for 
this
-  // transform. Bail out if we can not exclude that possibility.
-  if (const auto *FPO = dyn_cast(BO))
-if (!FPO->hasNoSignedZeros() &&
-!cannotBeNegativeZero(Y,
-  IC.getSimplifyQuery().getWithInstruction(&Sel)))
-  return nullptr;
+  // The compare constant must be the identity constant for that binop.
+  // If this a floating-point compare with 0.0, any zero constant will do.
+  Type *Ty = BO->getType();
+
+  Value *FoldedVal;
+  if (IsAbsorbingValue) {
+FoldedVal = C;
+  } else {
+Constant *IdC = ConstantExpr::getBinOpIdentity(BO->getOpcode(), Ty, true);
+if (IdC != C) {
+  if (!IdC || !CmpInst::isFPPredicate(Pred))
+return nullptr;
+
+  if (!match(IdC, m_AnyZeroFP()) || !match(C, m_AnyZeroFP()))
+return nullptr;
+}
+
+// +0.0 compares equal to -0.0, and so it does not behave as required for
+// this transform. Bail out if we can not exclude that possibility.
+if (const auto *FPO = dyn_cast(BO))
+  if (!FPO->hasNoSignedZeros() &&
+  !cannotBeNegativeZero(Y,
+
IC.getSimplifyQuery().getWithInstruction(&Sel)))
+return nullptr;
+
+FoldedVal = Y;
+  }
 
   // BO = binop Y, X
   // S = { select (cmp eq X, C), BO, ? } or { select (cmp ne X, C), ?, BO }
   // =>
   // S = { select (cmp eq X, C),  Y, ? } or { select (cmp ne X, C), ?,  Y }
-  return IC.replaceOperand(Sel, IsEq ? 1 : 2, Y);
+  return IC.replaceOperand(Sel, IsEq ? 1 : 2, FoldedVal);
 }
 
 /// This folds:
diff --git 
a/llvm/test/Transforms/InstCombine/select-fcmp-fmul-zero-absorbing-value.ll 
b/llvm/test/Transforms/InstCombine/select-fcmp-fmul-zero-absorbing-value.ll
index 660d2a0c0784e..1390cef970abe 100644
--- a/llvm/test/Transforms/InstCombine/select-fcmp-fmul-zero-absorbing-value.ll
+++ b/llvm/test/Transforms/InstCombine/select-fcmp-fmul-zero-absorbing

[llvm-branch-commits] [llvm] InstCombine: Fold absorbing fmul of compared 0 into select (PR #172381)

2025-12-15 Thread Matt Arsenault via llvm-branch-commits 

https://github.com/arsenm edited 
https://github.com/llvm/llvm-project/pull/172381
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Clang] Load pass plugins before parsing LLVM options (PR #171868)

2025-12-15 Thread Stefan Gränitz via llvm-branch-commits 

weliveindetail wrote:

> Then there's no problem. %llvmshlibdir is also used for all other Clang 
> plugin tests.

Clang frontend plugins don't originate from LLVM

https://github.com/llvm/llvm-project/pull/171868
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits