Repository: llvm/llvm-project
Pull request #133352: [X86Backend][M68KBackend] Make Ctx in X86MCInstLower (M68KInstLower) the same as AsmPrinter.OutContext 
Author: login: weiweichen
Labels: name: backend:X86
name: backend:m68k
Created: 2025-03-28T02:15:08Z | Merged: 2025-04-05T02:44:07Z

In `X86MCInstLower::LowerMachineOperand`, a new `MCSymbol` can be created in `GetSymbolFromOperand(MO)` where `MO.getType()` is `MachineOperand::MO_ExternalSymbol` 
```
  case MachineOperand::MO_ExternalSymbol:
    return LowerSymbolOperand(MO, GetSymbolFromOperand(MO));
```
at https://github.com/llvm/llvm-project/blob/725a7b664b92cd2e884806de5a08900b43d43cce/llvm/lib/Target/X86/X86MCInstLower.cpp#L196

However, this newly created symbol will not be marked properly with its `IsExternal` field since `Ctx.getOrCreateSymbol(Name)` doesn't know if the newly created `MCSymbol` is for `MachineOperand::MO_ExternalSymbol`.



Looking at other backends, for example `Arch64MCInstLower` is doing for handling `MC_ExternalSymbol`

https://github.com/llvm/llvm-project/blob/14c36db16fc090ef494ff6d8207562c414b40e30/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L366-L367

https://github.com/llvm/llvm-project/blob/14c36db16fc090ef494ff6d8207562c414b40e30/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L145-L148

It creates/gets the MCSymbol from `AsmPrinter.OutContext` instead of from `Ctx`. Moreover, `Ctx` for `AArch64MCLower` is the same as `AsmPrinter.OutContext`. https://github.com/llvm/llvm-project/blob/8e7d6baf0e013408be932758b4a5334c14a34086/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp#L100. This applies to almost all the other backends except X86 and M68k.

```
$git grep "MCInstLowering("
lib/Target/AArch64/AArch64AsmPrinter.cpp:100:      : AsmPrinter(TM, std::move(Streamer)), MCInstLowering(OutContext, *this),
lib/Target/AMDGPU/AMDGPUMCInstLower.cpp:223:  AMDGPUMCInstLower MCInstLowering(OutContext, STI, *this);
lib/Target/AMDGPU/AMDGPUMCInstLower.cpp:257:  AMDGPUMCInstLower MCInstLowering(OutContext, STI, *this);
lib/Target/AMDGPU/R600MCInstLower.cpp:52:  R600MCInstLower MCInstLowering(OutContext, STI, *this);
lib/Target/ARC/ARCAsmPrinter.cpp:41:        MCInstLowering(&OutContext, *this) {}
lib/Target/AVR/AVRAsmPrinter.cpp:196:  AVRMCInstLower MCInstLowering(OutContext, *this);
lib/Target/BPF/BPFAsmPrinter.cpp:144:    BPFMCInstLower MCInstLowering(OutContext, *this);
lib/Target/CSKY/CSKYAsmPrinter.cpp:41:    : AsmPrinter(TM, std::move(Streamer)), MCInstLowering(OutContext, *this) {}
lib/Target/Lanai/LanaiAsmPrinter.cpp:147:  LanaiMCInstLower MCInstLowering(OutContext, *this);
lib/Target/Lanai/LanaiAsmPrinter.cpp:184:  LanaiMCInstLower MCInstLowering(OutContext, *this);
lib/Target/MSP430/MSP430AsmPrinter.cpp:149:  MSP430MCInstLower MCInstLowering(OutContext, *this);
lib/Target/Mips/MipsAsmPrinter.h:126:      : AsmPrinter(TM, std::move(Streamer)), MCInstLowering(*this) {}
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:695:    WebAssemblyMCInstLower MCInstLowering(OutContext, *this);
lib/Target/X86/X86MCInstLower.cpp:2200:  X86MCInstLower MCInstLowering(*MF, *this);
```

This patch makes `X86MCInstLower` and `M68KInstLower` to have their `Ctx` from `AsmPrinter.OutContext` instead of getting it from `MF.getContext()` to be consistent with all the other backends.  

I think since normal use case (probably anything other than our un-conventional case) only handles one llvm module all the way through in the codegen pipeline till the end of code emission (AsmPrint), `AsmPrinter.OutContext` is the same as MachineFunction's MCContext,  so this change is an NFC.

----

This fixes an error while running the generated code in ORC JIT for our use case with [MCLinker](https://youtu.be/yuSBEXkjfEA?si=HjgjkxJ9hLfnSvBj&t=813) (see more details below):
https://github.com/llvm/llvm-project/pull/133291#issuecomment-2759200983

We (Mojo) are trying to do a MC level linking so that we break llvm module into multiple submodules to compile and codegen in parallel (technically into *.o files with symbol linkage type change), but instead of archive all of them into one `.a` file, we want to fix the symbol linkage type and still produce one *.o file. The parallel codegen pipeline generates the codegen data structures in their own `MCContext` (which is `Ctx` here). So if function `f` and `g` got split into different submodules, they will have different `Ctx`. And when we try to create an external symbol with the same name for each of them with `Ctx.getOrCreate(SymName)`, we will get two different `MCSymbol*` because `f` and `g`'s `MCContext` are different and they can't see each other. This is unfortunately not what we want for external symbols. Using `AsmPrinter.OutContext` helps, since it is shared, if we try to get or create the `MCSymbol` there, we'll be able to deduplicate.




Diff:
diff --git a/llvm/lib/Target/M68k/M68kMCInstLower.cpp b/llvm/lib/Target/M68k/M68kMCInstLower.cpp
index 957c0f9d3da82..8698fc0de4710 100644
--- a/llvm/lib/Target/M68k/M68kMCInstLower.cpp
+++ b/llvm/lib/Target/M68k/M68kMCInstLower.cpp
@@ -33,7 +33,7 @@ using namespace llvm;
 #define DEBUG_TYPE "m68k-mc-inst-lower"
 
 M68kMCInstLower::M68kMCInstLower(MachineFunction &MF, M68kAsmPrinter &AP)
-    : Ctx(MF.getContext()), MF(MF), TM(MF.getTarget()), MAI(*TM.getMCAsmInfo()),
+    : Ctx(AP.OutContext), MF(MF), TM(MF.getTarget()), MAI(*TM.getMCAsmInfo()),
       AsmPrinter(AP) {}
 
 MCSymbol *
diff --git a/llvm/lib/Target/X86/X86MCInstLower.cpp b/llvm/lib/Target/X86/X86MCInstLower.cpp
index 52332c46851c2..d9945bdf2db60 100644
--- a/llvm/lib/Target/X86/X86MCInstLower.cpp
+++ b/llvm/lib/Target/X86/X86MCInstLower.cpp
@@ -142,8 +142,8 @@ void X86AsmPrinter::EmitAndCountInstruction(MCInst &Inst) {
 
 X86MCInstLower::X86MCInstLower(const MachineFunction &mf,
                                X86AsmPrinter &asmprinter)
-    : Ctx(mf.getContext()), MF(mf), TM(mf.getTarget()), MAI(*TM.getMCAsmInfo()),
-      AsmPrinter(asmprinter) {}
+    : Ctx(asmprinter.OutContext), MF(mf), TM(mf.getTarget()),
+      MAI(*TM.getMCAsmInfo()), AsmPrinter(asmprinter) {}
 
 MachineModuleInfoMachO &X86MCInstLower::getMachOMMI() const {
   return AsmPrinter.MMI->getObjFileInfo<MachineModuleInfoMachO>();
diff --git a/llvm/unittests/CodeGen/CMakeLists.txt b/llvm/unittests/CodeGen/CMakeLists.txt
index 4f580e7539f4d..a972dc32c40a2 100644
--- a/llvm/unittests/CodeGen/CMakeLists.txt
+++ b/llvm/unittests/CodeGen/CMakeLists.txt
@@ -47,6 +47,7 @@ add_llvm_unittest(CodeGenTests
   TargetOptionsTest.cpp
   TestAsmPrinter.cpp
   MLRegAllocDevelopmentFeatures.cpp
+  X86MCInstLowerTest.cpp
   )
 
 add_subdirectory(GlobalISel)
diff --git a/llvm/unittests/CodeGen/X86MCInstLowerTest.cpp b/llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
new file mode 100644
index 0000000000000..f5a59b16b4487
--- /dev/null
+++ b/llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
@@ -0,0 +1,174 @@
+//===- llvm/unittest/CodeGen/X86MCInstLowerTest.cpp
+//-------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "TestAsmPrinter.h"
+#include "llvm/AsmParser/Parser.h"
+#include "llvm/CodeGen/AsmPrinter.h"
+#include "llvm/CodeGen/MachineModuleInfo.h"
+#include "llvm/CodeGen/TargetLowering.h"
+#include "llvm/CodeGen/TargetPassConfig.h"
+#include "llvm/IR/LegacyPassManager.h"
+#include "llvm/IR/MDBuilder.h"
+#include "llvm/IR/Module.h"
+#include "llvm/MC/MCStreamer.h"
+#include "llvm/MC/TargetRegistry.h"
+#include "llvm/Support/SourceMgr.h"
+#include "llvm/Support/TargetSelect.h"
+#include "llvm/Target/TargetLoweringObjectFile.h"
+#include "llvm/Target/TargetMachine.h"
+#include "gtest/gtest.h"
+
+namespace llvm {
+
+class X86MCInstLowerTest : public testing::Test {
+protected:
+  static void SetUpTestCase() {
+    InitializeAllTargetMCs();
+    InitializeAllTargetInfos();
+    InitializeAllTargets();
+    InitializeAllAsmPrinters();
+  }
+
+  // Function to setup codegen pipeline and returns the AsmPrinter.
+  AsmPrinter *addPassesToEmitFile(llvm::legacy::PassManagerBase &PM,
+                                  llvm::raw_pwrite_stream &Out,
+                                  llvm::CodeGenFileType FileType,
+                                  llvm::MachineModuleInfoWrapperPass *MMIWP) {
+    TargetPassConfig *PassConfig = TM->createPassConfig(PM);
+
+    PassConfig->setDisableVerify(true);
+    PM.add(PassConfig);
+    PM.add(MMIWP);
+
+    if (PassConfig->addISelPasses())
+      return nullptr;
+
+    PassConfig->addMachinePasses();
+    PassConfig->setInitialized();
+
+    MC.reset(new MCContext(TM->getTargetTriple(), TM->getMCAsmInfo(),
+                           TM->getMCRegisterInfo(), TM->getMCSubtargetInfo()));
+    MC->setObjectFileInfo(TM->getObjFileLowering());
+    TM->getObjFileLowering()->Initialize(*MC, *TM);
+    MC->setObjectFileInfo(TM->getObjFileLowering());
+
+    // Use a new MCContext for AsmPrinter for testing.
+    // AsmPrinter.OutContext will be different from
+    // MachineFunction's MCContext in MMIWP.
+    Expected<std::unique_ptr<MCStreamer>> MCStreamerOrErr =
+        TM->createMCStreamer(Out, nullptr, FileType, *MC);
+
+    if (auto Err = MCStreamerOrErr.takeError())
+      return nullptr;
+
+    AsmPrinter *Printer =
+        TM->getTarget().createAsmPrinter(*TM, std::move(*MCStreamerOrErr));
+
+    if (!Printer)
+      return nullptr;
+
+    PM.add(Printer);
+
+    return Printer;
+  }
+
+  void SetUp() override {
+    // Module to compile.
+    const char *FooStr = R""""(
+        @G = external global i32
+
+        define i32 @foo() {
+          %1 = load i32, i32* @G; load the global variable
+          %2 = call i32 @f()
+          %3 = mul i32 %1, %2
+          ret i32 %3
+        }
+
+        declare i32 @f() #0
+      )"""";
+    StringRef AssemblyF(FooStr);
+
+    // Get target triple for X86_64
+    Triple TargetTriple("x86_64--");
+    std::string Error;
+    const Target *T = TargetRegistry::lookupTarget("", TargetTriple, Error);
+    // Skip the test if target is not built.
+    if (!T)
+      GTEST_SKIP();
+
+    // Get TargetMachine.
+    // Use Reloc::Model::PIC_ and CodeModel::Model::Large
+    // to get GOT during codegen as MO_ExternalSymbol.
+    TargetOptions Options;
+    TM = std::unique_ptr<TargetMachine>(T->createTargetMachine(
+        TargetTriple, "", "", Options, Reloc::Model::PIC_,
+        CodeModel::Model::Large, CodeGenOptLevel::Default));
+    if (!TM)
+      GTEST_SKIP();
+
+    SMDiagnostic SMError;
+
+    // Parse the module.
+    M = parseAssemblyString(AssemblyF, SMError, Context);
+    if (!M)
+      report_fatal_error(SMError.getMessage());
+    M->setDataLayout(TM->createDataLayout());
+
+    // Get llvm::Function from M
+    Foo = M->getFunction("foo");
+    if (!Foo)
+      report_fatal_error("foo?");
+
+    // Prepare the MCContext for codegen M.
+    // MachineFunction for Foo will have this MCContext.
+    MCFoo.reset(new MCContext(TargetTriple, TM->getMCAsmInfo(),
+                              TM->getMCRegisterInfo(),
+                              TM->getMCSubtargetInfo()));
+    MCFoo->setObjectFileInfo(TM->getObjFileLowering());
+    TM->getObjFileLowering()->Initialize(*MCFoo, *TM);
+    MCFoo->setObjectFileInfo(TM->getObjFileLowering());
+  }
+
+  LLVMContext Context;
+  std::unique_ptr<TargetMachine> TM;
+  std::unique_ptr<Module> M;
+
+  std::unique_ptr<MCContext> MC;
+  std::unique_ptr<MCContext> MCFoo;
+
+  Function *Foo;
+  std::unique_ptr<MachineFunction> MFFoo;
+};
+
+TEST_F(X86MCInstLowerTest, moExternalSymbol_MCSYMBOL) {
+
+  MachineModuleInfoWrapperPass *MMIWP =
+      new MachineModuleInfoWrapperPass(TM.get(), &*MCFoo);
+
+  legacy::PassManager PassMgrF;
+  SmallString<1024> Buf;
+  llvm::raw_svector_ostream OS(Buf);
+  AsmPrinter *Printer =
+      addPassesToEmitFile(PassMgrF, OS, CodeGenFileType::AssemblyFile, MMIWP);
+  PassMgrF.run(*M);
+
+  // Check GOT MCSymbol is from Printer.OutContext.
+  MCSymbol *GOTPrinterPtr =
+      Printer->OutContext.lookupSymbol("_GLOBAL_OFFSET_TABLE_");
+
+  // Check GOT MCSymbol is NOT from MachineFunction's MCContext.
+  MCSymbol *GOTMFCtxPtr =
+      MMIWP->getMMI().getMachineFunction(*Foo)->getContext().lookupSymbol(
+          "_GLOBAL_OFFSET_TABLE_");
+
+  EXPECT_NE(GOTPrinterPtr, nullptr);
+  EXPECT_EQ(GOTMFCtxPtr, nullptr);
+}
+
+} // end namespace llvm


Reviews:
user: login: efriedma-quic
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-31T20:54:34Z
user: login: weiweichen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-31T21:43:18Z
user: login: weiweichen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-31T21:45:47Z
user: login: efriedma-quic
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-31T22:13:30Z
user: login: weiweichen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-31T22:52:21Z
user: login: weiweichen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-01T15:00:56Z
user: login: npanchen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-02T14:22:56Z
user: login: efriedma-quic
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T21:43:14Z
user: login: topperc
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-04T00:30:43Z
user: login: topperc
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-04T02:46:18Z
user: login: weiweichen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-04T03:09:59Z
user: login: weiweichen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-04T03:10:08Z
user: login: weiweichen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-04T03:10:21Z
user: login: weiweichen
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-04T04:05:04Z
user: login: topperc
body: LGTM. This avoids creating a distinction between the 2 different sources of MCContexts in LLVM. As long as this happens to work for your use case that seems fine, but it seems fragile and could be broken in some other way in the future.
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-04-05T01:24:10Z

Review comments:
diff_hunk: @@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
path: llvm/lib/Target/X86/X86MCInstLower.cpp
user: login: efriedma-quic
body: Oh.  This is starting to make more sense, now.  Normally, there's only one MCContext, but because you're doing this "parallel codegen" thing, you're passing a different MCContext to construct the MachineFunction... and the coupling between a symbol and its context is loose enough that you can pass a symbol from the wrong MCContext to the AsmPrinter, and sort of get away with it.

If preventing that is the goal, why not change X86MCInstLower::X86MCInstLower instead?  Just change `Ctx(mf.getContext())` to `Ctx(asmprinter.OutContext)`.

That said, more generally, if you want everything to work reliably, you'll probably need to completely eliminate the MCContext reference from MachineFunction.  Otherwise, you'll continue to run into issues where the MCSymbol is from the wrong context.  Maybe doable, but involves a significant amount of refactoring to avoid constructing MCSymbols early... and I'm not sure if there are any other weird interactions here.
created_at: 2025-03-31T20:54:34Z
author_association: COLLABORATOR
diff_hunk: @@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
path: llvm/lib/Target/X86/X86MCInstLower.cpp
user: login: weiweichen
body: > If preventing that is the goal, why not change X86MCInstLower::X86MCInstLower instead? Just change `Ctx(mf.getContext())` to `Ctx(asmprinter.OutContext)`.

Hmmm, this probably won't work (I mean it will work for MO_ExternalSymbol to get a unique MCSymbol, but) because we do still need `mf.getContext()` to do most of the codegen here for this function pass to run on the corresponding `MachineFunction`. `Ctx` has to be `mf.getContext()` as most of  the codegen for this MachineFunction is in this MCContext. AsmPrinter's OutContext is just for the output here.

Yeah, for most cases, `AsmPrinter.OutContext` is the same as `mf.getContext` because there is just one `MCContext` in the whole pipeline. I'm not sure what is the motivation for other backends to also use `AsmPrinter.OutContext` for the same case here, but the change does make them look more consistent with each other 😀 



created_at: 2025-03-31T21:43:17Z
author_association: CONTRIBUTOR
diff_hunk: @@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
path: llvm/lib/Target/X86/X86MCInstLower.cpp
user: login: weiweichen
body: > said, more generally, if you want everything to work reliably, you'll probably need to completely eliminate the MCContext reference from MachineFunction. Otherwise, you'll continue to run into issues where the MCSymbol is from the wrong context. Maybe doable, but involves a significant amount of refactoring to avoid constructing MCSymbols early... and I'm not sure if there are any other weird interactions here.

Interesting idea, but I do need to think more about what does this entails, and as you said, it will probably be a significant amount of refactoring, so maybe as follow-ups with more concrete considerations on a larger scale refactoring? 

(Also very selfishly speaking, this PR will help significantly with our MCLinker to function correctly, otherwise, half of tests are failing now 😢, so would be great to get something in first so that we can keep upgrading weekly 🙏 . )
created_at: 2025-03-31T21:45:47Z
author_association: CONTRIBUTOR
diff_hunk: @@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
path: llvm/lib/Target/X86/X86MCInstLower.cpp
user: login: efriedma-quic
body: > Ctx has to be mf.getContext() as most of the codegen for this MachineFunction is in this MCContext.

I'm not really understanding what this means... I guess you've sort of informally partitioned things so that "local" symbols are created in the function's MCContext, and "global" symbols are created in the global MCContext?  I don't think that's really sustainable... if we're going to consistently partition symbols, the two kinds of symbols can't both just be `MCSymbol*`, or you'll inevitably trip over issues in more obscure cases where we use the wrong MCContext.

-----

I don't think the patch in its current form will cause any immediate issues, but I don't want to commit to a design that hasn't really been reviewed by LLVM community, and probably won't be approved in its current form because it's very confusing.
created_at: 2025-03-31T22:13:30Z
author_association: COLLABORATOR
diff_hunk: @@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
path: llvm/lib/Target/X86/X86MCInstLower.cpp
user: login: weiweichen
body: > > Ctx has to be mf.getContext() as most of the codegen for this MachineFunction is in this MCContext.
> 
> I'm not really understanding what this means... I guess you've sort of informally partitioned things so that "local" symbols are created in the function's MCContext, and "global" symbols are created in the global MCContext? I don't think that's really sustainable... if we're going to consistently partition symbols, the two kinds of symbols can't both just be `MCSymbol*`, or you'll inevitably trip over issues in more obscure cases where we use the wrong MCContext.
> 

This is valid concern, but we are willing to take the risk for potentially running into issues (since we don't have substantial example right now to show this will be a big problem and worrying about "what-if-sm" is hard 😞) in the future at this point to unblock all of our tests. I'm definitely open to suggestion on how to make the MCLinker more solid (maybe after/during [my talk](https://llvm.swoogo.com/2025eurollvm/agenda) next month?).

> I don't think the patch in its current form will cause any immediate issues, but I don't want to commit to a design that hasn't really been reviewed by LLVM community, and probably won't be approved in its current form because it's very confusing.

I understand your reservation and being careful, thank you for being thorough here! Though I want to point out that this change has [already been applied to most of other backends](https://github.com/llvm/llvm-project/pull/133352#issuecomment-2763396033) (and I imagine those changes were being reviewed and approved by the community?). So I'd push back a bit on the assumption that this is "a design that hasn't really been reviewed by LLVM community"?

> and probably won't be approved in its current form because it's very confusing.

Do you have any suggestion on which part is confusing and what can be added to make it less so? 🙏 


created_at: 2025-03-31T22:52:20Z
author_association: CONTRIBUTOR
diff_hunk: @@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
path: llvm/lib/Target/X86/X86MCInstLower.cpp
user: login: weiweichen
body: >  I don't think that's really sustainable... if we're going to consistently partition symbols, the two kinds of symbols can't both just be MCSymbol*, or you'll inevitably trip over issues in more obscure cases where we use the wrong MCContext.

Why can't the two kinds be both "MCSymbo*" just because their scopes are different (local vs global)? What's wrong with `MCSymbo' wrt scoping? Also, I don't quite get "inevitably trip over issues in more obscure cases" part, I'm afraid it's a bit vague statement. Could you be more specific on what cases that may be? And since most of other backends are already doing this, do you think they are also doing something unsustainable? 
created_at: 2025-04-01T15:00:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
path: llvm/lib/Target/X86/X86MCInstLower.cpp
user: login: npanchen
body: @efriedma-quic the absence of a fix blocks our pulldown as 50% of tests are failing due to reverted https://github.com/llvm/llvm-project/pull/133291#issuecomment-2759200983 change.

Even though I agree that there might be a better "bulletproof" solution, but is it ok to move forward with Weiwei's fix first and then consider much better solution ? My rationale here is that Weiwei's proposed fix is aligned with what most of the targets are doing now and also there was an interest in community to open source parallel MCLinker. So when it comes to open sourcing there will be more use-cases and we will come back to that topic again.
created_at: 2025-04-02T14:22:56Z
author_association: CONTRIBUTOR
diff_hunk: @@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
path: llvm/lib/Target/X86/X86MCInstLower.cpp
user: login: efriedma-quic
body: > this change has already been applied to most of other backends 

The other backends work in your model by accident.  They're not intentionally using one context or the other, they're just not using MachineFunction::getContext() at all in the AsmPrinter.

> Could you be more specific on what cases that may be?
> Do you have any suggestion on which part is confusing and what can be added to make it less so? 🙏

Basically, if MF.getContext().getOrCreateSymbol() means something different from AsmPrinter.OutContext.getOrCreateSymbol(), it's a lot harder to understand what's going on.  You have two APIs that look the same on the surface, and return a value of the same type, but actually mean something subtly different. Anything that creates an MCSymbol would need to be aware that both APIs exist, and pick the correct one.  Some existing code probably isn't consistent with your model, and anyone writing new code gets zero guidance from the API names or type system to help pick the correct one.

And the "local" one is never really right: MCSymbols passed to an MCStreamer are supposed to be part of the same MCContext as the MCStreamer.

To make things consistent, there needs to be *one* correct way to construct an MCSymbol.  Either we need a "MachineFunctionSymbol" type to represent symbols that haven't been emitted yet, or you need to stop sharing MCStreamers between different compilation units.  This patch isn't making any progress towards either of those models, or anything similar.

----

I don't think this patch will cause any immediate issues, because it's basically a no-op if there's only one MCContext, but this isn't the right long-term solution.  And I don't want to commit to merging an unbounded number of temporary hacks while you work out how to implement the right solution.
created_at: 2025-04-02T21:43:13Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,180 @@
+//===- llvm/unittest/CodeGen/AArch64SelectionDAGTest.cpp
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: topperc
body: File name is incorrect
created_at: 2025-04-04T00:28:22Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,180 @@
+//===- llvm/unittest/CodeGen/AArch64SelectionDAGTest.cpp
+//-------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "../lib/Target/X86/X86ISelLowering.h"
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: topperc
body: Is the header used?
created_at: 2025-04-04T00:29:47Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,180 @@
+//===- llvm/unittest/CodeGen/AArch64SelectionDAGTest.cpp
+//-------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "../lib/Target/X86/X86ISelLowering.h"
+#include "TestAsmPrinter.h"
+#include "llvm/Analysis/MemoryLocation.h"
+#include "llvm/Analysis/OptimizationRemarkEmitter.h"
+#include "llvm/AsmParser/Parser.h"
+#include "llvm/CodeGen/AsmPrinter.h"
+#include "llvm/CodeGen/MachineModuleInfo.h"
+#include "llvm/CodeGen/SelectionDAG.h"
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: topperc
body: I doubt this test uses anything from SelectionDAG.h
created_at: 2025-04-04T00:30:07Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,180 @@
+//===- llvm/unittest/CodeGen/AArch64SelectionDAGTest.cpp
+//-------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "../lib/Target/X86/X86ISelLowering.h"
+#include "TestAsmPrinter.h"
+#include "llvm/Analysis/MemoryLocation.h"
+#include "llvm/Analysis/OptimizationRemarkEmitter.h"
+#include "llvm/AsmParser/Parser.h"
+#include "llvm/CodeGen/AsmPrinter.h"
+#include "llvm/CodeGen/MachineModuleInfo.h"
+#include "llvm/CodeGen/SelectionDAG.h"
+#include "llvm/CodeGen/TargetLowering.h"
+#include "llvm/CodeGen/TargetPassConfig.h"
+#include "llvm/IR/LegacyPassManager.h"
+#include "llvm/IR/MDBuilder.h"
+#include "llvm/IR/Module.h"
+#include "llvm/MC/MCStreamer.h"
+#include "llvm/MC/TargetRegistry.h"
+#include "llvm/Support/KnownBits.h"
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: topperc
body: I doubt this file uses KnownBits.h
created_at: 2025-04-04T00:30:19Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,173 @@
+//===- llvm/unittest/CodeGen/X86MCInstLowerTest.cpp
+//-------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "TestAsmPrinter.h"
+#include "llvm/AsmParser/Parser.h"
+#include "llvm/CodeGen/AsmPrinter.h"
+#include "llvm/CodeGen/MachineModuleInfo.h"
+#include "llvm/CodeGen/TargetLowering.h"
+#include "llvm/CodeGen/TargetPassConfig.h"
+#include "llvm/IR/LegacyPassManager.h"
+#include "llvm/IR/MDBuilder.h"
+#include "llvm/IR/Module.h"
+#include "llvm/MC/MCStreamer.h"
+#include "llvm/MC/TargetRegistry.h"
+#include "llvm/Support/SourceMgr.h"
+#include "llvm/Support/TargetSelect.h"
+#include "llvm/Target/TargetLoweringObjectFile.h"
+#include "llvm/Target/TargetMachine.h"
+#include "gtest/gtest.h"
+
+namespace llvm {
+
+class X86MCInstLowerTest : public testing::Test {
+protected:
+  static void SetUpTestCase() {
+    LLVMInitializeX86TargetInfo();
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: topperc
body: If the X86 target isn't built, can you still call these funtions or do they not exist?
created_at: 2025-04-04T02:46:17Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,180 @@
+//===- llvm/unittest/CodeGen/AArch64SelectionDAGTest.cpp
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: weiweichen
body: yes, oops, fixed!
created_at: 2025-04-04T03:09:59Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,180 @@
+//===- llvm/unittest/CodeGen/AArch64SelectionDAGTest.cpp
+//-------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "../lib/Target/X86/X86ISelLowering.h"
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: weiweichen
body: nope, removed
created_at: 2025-04-04T03:10:08Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,180 @@
+//===- llvm/unittest/CodeGen/AArch64SelectionDAGTest.cpp
+//-------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "../lib/Target/X86/X86ISelLowering.h"
+#include "TestAsmPrinter.h"
+#include "llvm/Analysis/MemoryLocation.h"
+#include "llvm/Analysis/OptimizationRemarkEmitter.h"
+#include "llvm/AsmParser/Parser.h"
+#include "llvm/CodeGen/AsmPrinter.h"
+#include "llvm/CodeGen/MachineModuleInfo.h"
+#include "llvm/CodeGen/SelectionDAG.h"
+#include "llvm/CodeGen/TargetLowering.h"
+#include "llvm/CodeGen/TargetPassConfig.h"
+#include "llvm/IR/LegacyPassManager.h"
+#include "llvm/IR/MDBuilder.h"
+#include "llvm/IR/Module.h"
+#include "llvm/MC/MCStreamer.h"
+#include "llvm/MC/TargetRegistry.h"
+#include "llvm/Support/KnownBits.h"
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: weiweichen
body: you are right, removed
created_at: 2025-04-04T03:10:21Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,173 @@
+//===- llvm/unittest/CodeGen/X86MCInstLowerTest.cpp
+//-------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "TestAsmPrinter.h"
+#include "llvm/AsmParser/Parser.h"
+#include "llvm/CodeGen/AsmPrinter.h"
+#include "llvm/CodeGen/MachineModuleInfo.h"
+#include "llvm/CodeGen/TargetLowering.h"
+#include "llvm/CodeGen/TargetPassConfig.h"
+#include "llvm/IR/LegacyPassManager.h"
+#include "llvm/IR/MDBuilder.h"
+#include "llvm/IR/Module.h"
+#include "llvm/MC/MCStreamer.h"
+#include "llvm/MC/TargetRegistry.h"
+#include "llvm/Support/SourceMgr.h"
+#include "llvm/Support/TargetSelect.h"
+#include "llvm/Target/TargetLoweringObjectFile.h"
+#include "llvm/Target/TargetMachine.h"
+#include "gtest/gtest.h"
+
+namespace llvm {
+
+class X86MCInstLowerTest : public testing::Test {
+protected:
+  static void SetUpTestCase() {
+    LLVMInitializeX86TargetInfo();
path: llvm/unittests/CodeGen/X86MCInstLowerTest.cpp
user: login: weiweichen
body: Looks like compilation will fail if I'm not building X86 backend. Changing this to 
```
    InitializeAllTargetMCs();
    InitializeAllTargetInfos();
    InitializeAllTargets();
    InitializeAllAsmPrinters();
```

Tested with only building AArch64 backend, this test gets skipped.

```
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL
/Users/weiwei.chen/research/modularml/modular/third-party/llvm-project/llvm/unittests/CodeGen/X86MCInstLowerTest.cpp:107: Skipped


[  SKIPPED ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL (1 ms)
[----------] 1 test from X86MCInstLowerTest (1 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (2 ms total)
[  PASSED  ] 0 tests.
[  SKIPPED ] 1 test, listed below:
[  SKIPPED ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL
```
created_at: 2025-04-04T04:05:04Z
author_association: CONTRIBUTOR

PR comments:
user: login: github-actions[bot]
created_at: 2025-03-28T02:18:46Z
body: <!--LLVM CODE FORMAT COMMENT: {clang-format}-->

:white_check_mark: With the latest revision this PR passed the C/C++ code formatter.
author_association: NONE
user: login: weiweichen
created_at: 2025-03-28T03:30:32Z
body: Verified that this change won't negatively impact this issue https://github.com/llvm/llvm-project/issues/132055#issue-2932396176


```
source_filename = "text"
target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.14.0-macho"

declare i16 @julia_float_to_half(float)

define internal i16 @__truncsfhf2(float %0) {
  %2 = call i16 @julia_float_to_half(float %0)
  ret i16 %2
}

define hidden swiftcc half @julia_fp(float %0) {
  %2 = fptrunc float %0 to half
  ret half %2
}

@llvm.compiler.used = appending global [1 x ptr] [ptr @__truncsfhf2], section "llvm.metadata"
```

```
$ llc lala.ll -filetype=obj -o llvm20.o
$ llvm-objdump llvm20.o -t

llvm20.o:       file format mach-o 64-bit x86-64

SYMBOL TABLE:
0000000000000000 l     F __TEXT,__text ___truncsfhf2
0000000000000010 g     F __TEXT,__text .hidden _julia_fp
0000000000000000         *UND* _julia_float_to_half
```

`__truncsfhf2` is still `l`.
author_association: CONTRIBUTOR
user: login: MaskRay
created_at: 2025-03-28T07:25:18Z
body: This solution appears to potentially mask an underlying issue.

Can you state the motivation behind the change?  

The first few paragraphs only describe "what" the scenario is, but doesn't really state your end goal, and how this helps your MC Linker effort.

> In X86MCInstLower::LowerMachineOperand, a new MCSymbol can be created in GetSymbolFromOperand(MO) where MO.getType() is MachineOperand::MO_ExternalSymbol

It would be beneficial to broaden the review process, especially when the reviewer selected is closely associated and neither of you has prior experience with this specific code area. (https://github.com/llvm/llvm-project/pull/108880 landed quickly within four hours. Considering the reviewer's close association, a wider review might offer additional perspectives.)
author_association: MEMBER
user: login: weiweichen
created_at: 2025-03-28T14:35:34Z
body: > This solution appears to potentially mask an underlying issue.
> 
> Can you state the motivation behind the change?
> 
> The first few paragraphs only describe "what" the scenario is, but doesn't really state your end goal, and how this helps your MC Linker effort.
> 
> > In X86MCInstLower::LowerMachineOperand, a new MCSymbol can be created in GetSymbolFromOperand(MO) where MO.getType() is MachineOperand::MO_ExternalSymbol
> 

So for MC Linker, the main difference from normal codegen flow is that we are trying to AsmPrint functions that are initially in one llvm module, then being split into submodules for parallel codegen, and now use one AsmPrinter to generate the output. The parallel codegen pipeline generates the codegen data structures in their own `MCContext` (which is `Ctx` here). So if function `f` and `g` got split into different submodules, they will have different `Ctx`. If we try to create an external symbol with the same name for each of them with ` Ctx.getOrCreate(SymName)`, we will get two different `MCSymbol*` because `f` and `g`'s MCContext are different. This is not what we want for external symbols. Using `AsmPrinter.OutContext` helps, since it is shared, if we try to get or create the MCSymbol there, we'll be able to deduplicate.

I think since normal use case (probably anything other than our un-conventional case) only handles one llvm module all the way through in the whole codegen pipeline, there is no need to deduplicate, and this change is probably just an NFC.

Let me add this to the PR description as well!

> It would be beneficial to broaden the review process, especially when the reviewer selected is closely associated and neither of you has prior experience with this specific code area. (#108880 landed quickly within four hours. Considering the reviewer's close association, a wider review might offer additional perspectives.)

Totally agree. The PR  is "draft" now so that I can put out the code to discuss with @npanchen about the solution, but not incur too much noises to others. Once it is "Ready for review", I'll add folks who have given us feedbacks on the previous PR+issue as reviewers. 

(sorry for being pedantic here) But to my defense, #108880 took 4 days to land instead of 4 hours (it was 4 hours after approval). The PR notified core maintainers like `llvm/pr-subscribers-backend-x86` and requested review from folks who are not close to our org based on GitHub suggestion, but I didn't get any comments from anyone other than a post merge one about adding a test. Sorry that I probably missed/forgot that comment. Fully agree that I should have added a test to #108880 to indicate our intention for the change+verify the change. On the other hand, there are numerous x86 backend tests existing and none is broken by the change is a way of testing, no?


author_association: CONTRIBUTOR
user: login: llvmbot
created_at: 2025-03-28T14:47:47Z
body: 
<!--LLVM PR SUMMARY COMMENT-->
@llvm/pr-subscribers-backend-m68k

@llvm/pr-subscribers-backend-x86

Author: weiwei chen (weiweichen)

<details>
<summary>Changes</summary>

In `X86MCInstLower::LowerMachineOperand`, a new `MCSymbol` can be created in `GetSymbolFromOperand(MO)` where `MO.getType()` is `MachineOperand::MO_ExternalSymbol` 
```
  case MachineOperand::MO_ExternalSymbol:
    return LowerSymbolOperand(MO, GetSymbolFromOperand(MO));
```
at https://github.com/llvm/llvm-project/blob/725a7b664b92cd2e884806de5a08900b43d43cce/llvm/lib/Target/X86/X86MCInstLower.cpp#L196

However, this newly created symbol will not be marked properly with its `IsExternal` field since `Ctx.getOrCreateSymbol(Name)` doesn't know if the newly created `MCSymbol` is for `MachineOperand::MO_ExternalSymbol`.

Use `AsmPrinter.GetExternalSymbolSymbol(Name)` instead for this case so that we actually create a proper MCSymbol that is external. This is similar to what `Arch64MCInstLower` is doing for handling `MC_ExternalSymbol`

https://github.com/llvm/llvm-project/blob/14c36db16fc090ef494ff6d8207562c414b40e30/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L366-L367

https://github.com/llvm/llvm-project/blob/14c36db16fc090ef494ff6d8207562c414b40e30/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L145-L148

Note that the critical point here is that `MO_ExternalSymbol` is not created/get from `AsmPrinter.OutContext` instead of from `Ctx`.

This fixes an error while running the generated code in ORC JIT for our use case with [MCLinker](https://youtu.be/yuSBEXkjfEA?si=HjgjkxJ9hLfnSvBj&amp;t=813) (see more details below):
https://github.com/llvm/llvm-project/pull/133291#issuecomment-2759200983

We (Mojo) are trying to do a MC level linking so that we break llvm module into multiple submodules to compile and codegen in parallel (technically into *.o files with symbol linkage type change), but instead of archive all of them into one `.a` file, we want to fix the symbol linkage type and still produce one *.o file. The parallel codegen pipeline generates the codegen data structures in their own `MCContext` (which is `Ctx` here). So if function `f` and `g` got split into different submodules, they will have different `Ctx`. And when we try to create an external symbol with the same name for each of them with `Ctx.getOrCreate(SymName)`, we will get two different `MCSymbol*` because `f` and `g`'s `MCContext` are different and they can't see each other. This is unfortunately not what we want for external symbols. Using `AsmPrinter.OutContext` helps, since it is shared, if we try to get or create the `MCSymbol` there, we'll be able to deduplicate.

I think since normal use case (probably anything other than our un-conventional case) only handles one llvm module all the way through in the whole codegen pipeline, there is no need to deduplicate, and this change is probably just an NFC.

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


1 Files Affected:

- (modified) llvm/lib/Target/X86/X86MCInstLower.cpp (+9-2) 


``````````diff
diff --git a/llvm/lib/Target/X86/X86MCInstLower.cpp b/llvm/lib/Target/X86/X86MCInstLower.cpp
index 3f6cd55618666..c93a2879a057f 100644
--- a/llvm/lib/Target/X86/X86MCInstLower.cpp
+++ b/llvm/lib/Target/X86/X86MCInstLower.cpp
@@ -192,8 +192,15 @@ MCSymbol *X86MCInstLower::GetSymbolFromOperand(const MachineOperand &MO) const {
   }
 
   Name += Suffix;
-  if (!Sym)
-    Sym = Ctx.getOrCreateSymbol(Name);
+  if (!Sym) {
+    // If new MCSymbol needs to be created for
+    // MachineOperand::MO_ExternalSymbol, create it as a symbol
+    // in AsmPrinter's OutContext.
+    if (MO.isSymbol())
+      Sym = AsmPrinter.OutContext.getOrCreateSymbol(Name);
+    else
+      Sym = Ctx.getOrCreateSymbol(Name);
+  }
 
   // If the target flags on the operand changes the name of the symbol, do that
   // before we return the symbol.

``````````

</details>

author_association: MEMBER
user: login: weiweichen
created_at: 2025-03-28T14:48:49Z
body: This is another attempt to address the issue what was poorly addressed in https://github.com/llvm/llvm-project/pull/108880 🤦‍♀️ . Adding more explanation on the motivation/problem to address and the rationale on the change. Appreciate suggestions on how to add a test in addition to existing tests not being broken this change 🙏 

(update) working on adding a c++ unitttest.
author_association: CONTRIBUTOR
user: login: efriedma-quic
created_at: 2025-03-28T20:50:46Z
body: > (sorry for being pedantic here) But to my defense, https://github.com/llvm/llvm-project/pull/108880 took 4 days to land instead of 4 hours (it was 4 hours after approval). The PR notified core maintainers like llvm/pr-subscribers-backend-x86 and requested review from folks who are not close to our org based on GitHub suggestion, but I didn't get any comments from anyone other than a post merge one about adding a test. Sorry that I probably missed/forgot that comment. Fully agree that I should have added a test to https://github.com/llvm/llvm-project/pull/108880 to indicate our intention for the change+verify the change.

I don't want to blame anyone here.  The review process for patches to LLVM relies, to a large extent, on code authors exercising good judgement, and other people catching mistakes.  And new contributors often get tripped up here.

So, the patch probably shouldn't have been merged, but it's not a big deal.  Reverts are easy enough.  And we'll make sure everyone is on the same page going forward.

------------

If we are going to make changes here, I'd like to try to ensure consistency across targets.  And that whatever API usage rule you want to impose for the sake of your out-of-tree code actually makes sense; if there's a general rule we should follow for creating MCSymbols from the AsmPrinter, we should document it and make sure we consistently follow it.
author_association: COLLABORATOR
user: login: weiweichen
created_at: 2025-03-29T14:41:51Z
body: > If we are going to make changes here, I'd like to try to ensure consistency across targets. And that whatever API usage rule you want to impose for the sake of your out-of-tree code actually makes sense; if there's a general rule we should follow for creating MCSymbols from the AsmPrinter, we should document it and make sure we consistently follow it.

This is very good point!

I did some "grep" and found out that actually most backends are already using `AsmPrinter` to create `MCSymbol` for `MO_ExternalSymbol`. `GetExternalSymbolSymbol` creates the MCSymbol from `AsmPrinter.OutContext`.

https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L366-L367

https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/ARC/ARCMCInstLower.cpp#L47-L48

https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/BPF/BPFMCInstLower.cpp#L71-L72

https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/Lanai/LanaiMCInstLower.cpp#L118-L119

https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/Mips/MipsMCInstLower.cpp#L146-L147

https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/PowerPC/PPCMCInstLower.cpp#L49-L50

https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/XCore/XCoreMCInstLower.cpp#L49-L50

https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/Xtensa/XtensaAsmPrinter.cpp#L244-L245

With only one except (in addition to X86) for M68k backend. Adding the change for M68k backend as well. 

Is there another place to document this other than comments in the code?
author_association: CONTRIBUTOR
user: login: weiweichen
created_at: 2025-03-29T14:44:16Z
body: Added a C++ unit test as well. 
author_association: CONTRIBUTOR
user: login: weiweichen
created_at: 2025-03-29T14:44:36Z
body: Ready for review for real now 🙏 !
author_association: CONTRIBUTOR
user: login: weiweichen
created_at: 2025-04-01T15:52:06Z
body: @efriedma-quic, would you be open to a short zoom/google meeting to talk about this? (maybe easier if we can talk than typing here?) 
author_association: CONTRIBUTOR
user: login: npanchen
created_at: 2025-04-01T16:01:51Z
body: CC @RKSimon @phoebewang 
author_association: CONTRIBUTOR
user: login: weiweichen
created_at: 2025-04-03T21:09:16Z
body: @efriedma-quic, I really appreciate you putting time into this! It sounds like you don't think this is a big problem to take this patch, and it would help unblock my work. Are you ok with first making an incremental change, to make the x86 backend have the same behavior as other back-ends, and we can continue discussing the long-term solution?

Addressing your detailed comments below.  Thanks!


> The other backends work in your model by accident. They're not intentionally using one context or the other, they're just not using MachineFunction::getContext() at all in the AsmPrinter.

Respectfully, I do not agree that this works by accident. Separating the AsmPrinter output context (global) from the current MachineFunction's MCContext is very reasonable idea to address situations when the two contexts are not the same.

I looked through other backends to understand the logic. They actually all use both `AsmPrinter.OutContext` and `MachineFunction::getContext()` to disambiguate between the extern and non-extern symbols (see links below).  It is hard to say what exactly their intent is, but that use lines up exactly with what my suggested change for x86 is.

- AArch64 (where `Ctx is MachineFunction::getContext()`)
https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L76https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L118https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L130
- ARC
https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/ARC/ARCMCInstLower.cpp#L37
where `MO.getMBB()->getSymbol()` gets the `MCSymbol` from `Ctx` and `MCContext &Ctx = MF->getContext();`
https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/CodeGen/MachineBasicBlock.cpp#L83
- BPF uses `MO.getMBB()->getSymbol()` which creates `MCSymbol` from `Ctx` instead of `Printer.OunContext`
https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/BPF/BPFMCInstLower.cpp#L67
- Lanai
https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/Lanai/LanaiMCInstLower.cpp#L108
- Mips
https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/Mips/MipsMCInstLower.cpp#L137
- PPC
https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/PowerPC/PPCMCInstLower.cpp#L209
- XCore
https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/XCore/XCoreMCInstLower.cpp#L39
- Xtensa
https://github.com/llvm/llvm-project/blob/3e742b517a0606bfed329dfcb8c34c614ed73ea7/llvm/lib/Target/Xtensa/XtensaAsmPrinter.cpp#L238 

> Basically, if MF.getContext().getOrCreateSymbol() means something different from AsmPrinter.OutContext.getOrCreateSymbol(), it's a lot harder to understand what's going on.

There is a local context for the MachineFunctions and there is a global context for the AsmPrinter. We’d like to make it easy for the code to chose the right one when they are different. 

Moreover, this is actually the same API from `MCContext`. The difference here is the ownership of the MCSymbol and where to deduplicate them since `getOrCreateSymbol()` basically is a hashmap checking if the Symbol is already created, return the existing one; otherwise, create a new one. `MCSymbol` itself is just a collection of values and don’t refer/point back to the MCContext. It doesn't really matter who the owner of the MCSymbol is AFAICT.

Adding more comments in the code.

> And the "local" one is never really right: MCSymbols passed to an MCStreamer are supposed to be part of the same MCContext as the MCStreamer.

That’s exactly the new thing. We’ve been using two different contexts, intentionally, to create parallel compilation. Help me understand your reasoning, why the contexts should match? What invariants would be broken otherwise?

> To make things consistent, there needs to be one correct way to construct an MCSymbol. Either we need a "MachineFunctionSymbol" type to represent symbols that haven't been emitted yet, or you need to stop sharing MCStreamers between different compilation units. This patch isn't making any progress towards either of those models, or anything similar.

There is actually no sharing MCStreamers here (and on our side) since MCStreamer is part of AsmPrinter, and we only use one AsmPrinter. The difference is that the owner of the MCSymbol memory can be different which is also what the other backends are doing.

> And I don't want to commit to merging an unbounded number of temporary hacks while you work out how to implement the right solution.

I fully agree with this in principal that we should avoid piling on tech debt. However, I’m afraid "unbounded number of temporary hacks" is a bit unfair generalization for PR  since 1) there is only one change (not unbounded) 2) this is not really a hack, because it is actually making things more consistent with other backend's usage in the bigger llvm community.

> I don't think this patch will cause any immediate issues, because it's basically a no-op if there's only one MCContext, but this isn't the right long-term solution.

Thank you for understanding that there is no harm done here now! We are unfortunately fully blocked from llvm upgrade without this change. If there should be a better long-term solution, I’m wondering if it is the right time to seek it where no one (including us) needs and which will inevitably impact all backends and should get a proper design review? Any chance we can do this incrementally?

author_association: CONTRIBUTOR
user: login: topperc
created_at: 2025-04-04T00:42:52Z
body: > * AArch64 (where `Ctx is MachineFunction::getContext()`)
>   https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L76https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L118https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L130

Unless I'm misreadying, `Ctx` at all 3 of those locations came from a member variable of `AArch64MCInstLower`. `AArch64MCInstLower` is a member of `AArch64AsmPrinter` and the `Ctx` was initialized from `OutStreamer` not `MachineFunction::getContext()`.
author_association: COLLABORATOR
user: login: weiweichen
created_at: 2025-04-04T03:17:31Z
body: > > * AArch64 (where `Ctx is MachineFunction::getContext()`)
> >   https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L76https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L118https://github.com/llvm/llvm-project/blob/3f7ca8826776f32526e948b89816db492435f2e2/llvm/lib/Target/AArch64/AArch64MCInstLower.cpp#L130
> 
> Unless I'm misreadying, `Ctx` at all 3 of those locations came from a member variable of `AArch64MCInstLower`. `AArch64MCInstLower` is a member of `AArch64AsmPrinter` and the `Ctx` was initialized from `OutStreamer` not `MachineFunction::getContext()`.

Oh, good catch!! Looks like all the other backends are doing the same thing as AARch64 here that `Ctx` was initialized from `OutStreamer` not `MachineFunction::getContext()`, and X86 is the only exception.

```
(autovenv) (autovenv) weiwei.chen@Weiweis-MacBook-Pro ~/research/modularml/modular/third-party/llvm-project/llvm 🍔 git grep "MCInstLowering("
lib/Target/AArch64/AArch64AsmPrinter.cpp:99:      : AsmPrinter(TM, std::move(Streamer)), MCInstLowering(OutContext, *this),
lib/Target/AMDGPU/AMDGPUMCInstLower.cpp:222:  AMDGPUMCInstLower MCInstLowering(OutContext, STI, *this);
lib/Target/AMDGPU/AMDGPUMCInstLower.cpp:253:  AMDGPUMCInstLower MCInstLowering(OutContext, STI, *this);
lib/Target/AMDGPU/R600MCInstLower.cpp:52:  R600MCInstLower MCInstLowering(OutContext, STI, *this);
lib/Target/ARC/ARCAsmPrinter.cpp:41:        MCInstLowering(&OutContext, *this) {}
lib/Target/AVR/AVRAsmPrinter.cpp:195:  AVRMCInstLower MCInstLowering(OutContext, *this);
lib/Target/BPF/BPFAsmPrinter.cpp:144:    BPFMCInstLower MCInstLowering(OutContext, *this);
lib/Target/CSKY/CSKYAsmPrinter.cpp:41:    : AsmPrinter(TM, std::move(Streamer)), MCInstLowering(OutContext, *this) {}
lib/Target/Lanai/LanaiAsmPrinter.cpp:147:  LanaiMCInstLower MCInstLowering(OutContext, *this);
lib/Target/Lanai/LanaiAsmPrinter.cpp:184:  LanaiMCInstLower MCInstLowering(OutContext, *this);
lib/Target/MSP430/MSP430AsmPrinter.cpp:149:  MSP430MCInstLower MCInstLowering(OutContext, *this);
lib/Target/Mips/MipsAsmPrinter.h:126:      : AsmPrinter(TM, std::move(Streamer)), MCInstLowering(*this) {}
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:695:    WebAssemblyMCInstLower MCInstLowering(OutContext, *this);
lib/Target/X86/X86MCInstLower.cpp:2204:  X86MCInstLower MCInstLowering(*MF, *this);
```

@topperc, do you by any chance know if this exception is a must to have or X86 can also switch to use OutContext for `X86MCInstLower.Ctx`? I checked that `Ctx` in `X86MCInstLower` are mostly used for two things:
- `getOrCreateSymbol()` to create an MCSymbol.
- Use as an allocator to create different `MCExpr`s.

It looks like it's probably fine to switch here to be consistent with all the other backends unless there is something critical I'm missing here?

I pushed a new commit to reflect that change, [buildkite/github-pull-requests/linux-linux-x64](https://buildkite.com/llvm-project/github-pull-requests/builds/165124#0195feaa-a7ef-437e-9b61-24fd09824573) is passed. I also tested on our side that this fixes our issue as well. I'm wondering if this change is more acceptable now?


author_association: CONTRIBUTOR
user: login: weiweichen
created_at: 2025-04-05T02:44:02Z
body: > LGTM. This avoids creating a distinction between the 2 different sources of MCContexts in LLVM. As long as this happens to work for your use case that seems fine, but it seems fragile and could be broken in some other way in the future.

Thank you! Will definitely keep an eye on this part and follow up on more solid design if this turns out to be an issue down the road 🙏.
author_association: CONTRIBUTOR
user: login: llvm-ci
created_at: 2025-04-05T03:31:13Z
body: LLVM Buildbot has detected a new failure on builder `sanitizer-aarch64-linux-bootstrap-hwasan` running on `sanitizer-buildbot11` while building `llvm` at step 2 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/55/builds/9441

<details>
<summary>Here is the relevant piece of the build log for the reference</summary>

```
Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87461 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/23/76 (79618 of 87461)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/23/76' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-115745-23-76.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=76 GTEST_SHARD_INDEX=23 /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 24 of 76.
[==========] Running 4 tests from 4 test suites.
[----------] Global test environment set-up.
[----------] 1 test from AArch64SelectionDAGTest
[ RUN      ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT
[       OK ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT (4 ms)
[----------] 1 test from AArch64SelectionDAGTest (4 ms total)

[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MTransferSubregSpills
[       OK ] InstrRefLDVTest.MTransferSubregSpills (40 ms)
[----------] 1 test from InstrRefLDVTest (40 ms total)

[----------] 1 test from RegAllocScoreTest
[ RUN      ] RegAllocScoreTest.Counts
[       OK ] RegAllocScoreTest.Counts (1 ms)
[----------] 1 test from RegAllocScoreTest (1 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: -6
--
shard JSON output does not exist: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-115745-23-76.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
56.42s: Clang :: Driver/fsanitize.c
40.96s: Clang :: Preprocessor/riscv-target-features.c
38.15s: Clang :: Driver/arm-cortex-cpus-2.c
Step 11 (stage2/hwasan check) failure: stage2/hwasan check (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87461 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/23/76 (79618 of 87461)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/23/76' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-115745-23-76.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=76 GTEST_SHARD_INDEX=23 /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 24 of 76.
[==========] Running 4 tests from 4 test suites.
[----------] Global test environment set-up.
[----------] 1 test from AArch64SelectionDAGTest
[ RUN      ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT
[       OK ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT (4 ms)
[----------] 1 test from AArch64SelectionDAGTest (4 ms total)

[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MTransferSubregSpills
[       OK ] InstrRefLDVTest.MTransferSubregSpills (40 ms)
[----------] 1 test from InstrRefLDVTest (40 ms total)

[----------] 1 test from RegAllocScoreTest
[ RUN      ] RegAllocScoreTest.Counts
[       OK ] RegAllocScoreTest.Counts (1 ms)
[----------] 1 test from RegAllocScoreTest (1 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: -6
--
shard JSON output does not exist: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-115745-23-76.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
56.42s: Clang :: Driver/fsanitize.c
40.96s: Clang :: Preprocessor/riscv-target-features.c
38.15s: Clang :: Driver/arm-cortex-cpus-2.c

```

</details>
author_association: NONE
user: login: llvm-ci
created_at: 2025-04-05T03:34:16Z
body: LLVM Buildbot has detected a new failure on builder `clang-x64-windows-msvc` running on `windows-gcebot2` while building `llvm` at step 4 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/63/builds/4983

<details>
<summary>Here is the relevant piece of the build log for the reference</summary>

```
Step 4 (annotate) failure: 'python ../llvm-zorg/zorg/buildbot/builders/annotated/clang-windows.py ...' (failure)
...
  Passed           : 46417 (99.12%)
  Expectedly Failed:    37 (0.08%)
[97/98] Running the LLVM regression tests
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:57: note: using lit tools: C:\Program Files\Git\usr\bin
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using ld.lld: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\ld.lld.exe
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using lld-link: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\lld-link.exe
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using ld64.lld: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\ld64.lld.exe
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using wasm-ld: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\wasm-ld.exe
-- Testing: 58003 tests, 32 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70..
FAIL: LLVM :: tools/llvm-exegesis/RISCV/rvv/filter.test (25440 of 58003)
******************** TEST 'LLVM :: tools/llvm-exegesis/RISCV/rvv/filter.test' FAILED ********************
Exit Code: 2

Command Output (stdout):
--
# RUN: at line 1
c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\llvm-exegesis.exe -mtriple=riscv64 -mcpu=sifive-x280 -benchmark-phase=assemble-measured-code --mode=inverse_throughput --opcode-name=PseudoVNCLIPU_WX_M1_MASK     --riscv-filter-config='vtype = {VXRM: rod, AVL: VLMAX, SEW: e(8|16), Policy: ta/mu}' --max-configs-per-opcode=1000 --min-instructions=10 | c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\filecheck.exe C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\test\tools\llvm-exegesis\RISCV\rvv\filter.test
# executed command: 'c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\llvm-exegesis.exe' -mtriple=riscv64 -mcpu=sifive-x280 -benchmark-phase=assemble-measured-code --mode=inverse_throughput --opcode-name=PseudoVNCLIPU_WX_M1_MASK '--riscv-filter-config=vtype = {VXRM: rod, AVL: VLMAX, SEW: e(8|16), Policy: ta/mu}' --max-configs-per-opcode=1000 --min-instructions=10
# .---command stderr------------
# | PseudoVNCLIPU_WX_M1_MASK: Failed to produce any snippet via: instruction has tied variables, avoiding Read-After-Write issue, picking random def and use registers not aliasing each other, for uses, one unique register for each position
# `-----------------------------
# executed command: 'c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\filecheck.exe' 'C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\test\tools\llvm-exegesis\RISCV\rvv\filter.test'
# .---command stderr------------
# | FileCheck error: '<stdin>' is empty.
# | FileCheck command line:  c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\filecheck.exe C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\test\tools\llvm-exegesis\RISCV\rvv\filter.test
# `-----------------------------
# error: command failed with exit status: 2

--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
********************
Failed Tests (1):
  LLVM :: tools/llvm-exegesis/RISCV/rvv/filter.test


Testing Time: 344.55s

Total Discovered Tests: 64944
  Skipped          :    26 (0.04%)
  Unsupported      :  2420 (3.73%)
  Passed           : 62309 (95.94%)
  Expectedly Failed:   188 (0.29%)
  Failed           :     1 (0.00%)
FAILED: test/CMakeFiles/check-llvm C:/b/slave/clang-x64-windows-msvc/build/stage1/test/CMakeFiles/check-llvm 
cmd.exe /C "cd /D C:\b\slave\clang-x64-windows-msvc\build\stage1\test && C:\Python39\python.exe C:/b/slave/clang-x64-windows-msvc/build/stage1/./bin/llvm-lit.py -sv -j 32 C:/b/slave/clang-x64-windows-msvc/build/stage1/test"
ninja: build stopped: subcommand failed.
Step 8 (stage 1 check) failure: stage 1 check (failure)
...
  Passed           : 46417 (99.12%)
  Expectedly Failed:    37 (0.08%)
[97/98] Running the LLVM regression tests
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:57: note: using lit tools: C:\Program Files\Git\usr\bin
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using ld.lld: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\ld.lld.exe
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using lld-link: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\lld-link.exe
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using ld64.lld: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\ld64.lld.exe
llvm-lit.py: C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using wasm-ld: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\wasm-ld.exe
-- Testing: 58003 tests, 32 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70..
FAIL: LLVM :: tools/llvm-exegesis/RISCV/rvv/filter.test (25440 of 58003)
******************** TEST 'LLVM :: tools/llvm-exegesis/RISCV/rvv/filter.test' FAILED ********************
Exit Code: 2

Command Output (stdout):
--
# RUN: at line 1
c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\llvm-exegesis.exe -mtriple=riscv64 -mcpu=sifive-x280 -benchmark-phase=assemble-measured-code --mode=inverse_throughput --opcode-name=PseudoVNCLIPU_WX_M1_MASK     --riscv-filter-config='vtype = {VXRM: rod, AVL: VLMAX, SEW: e(8|16), Policy: ta/mu}' --max-configs-per-opcode=1000 --min-instructions=10 | c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\filecheck.exe C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\test\tools\llvm-exegesis\RISCV\rvv\filter.test
# executed command: 'c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\llvm-exegesis.exe' -mtriple=riscv64 -mcpu=sifive-x280 -benchmark-phase=assemble-measured-code --mode=inverse_throughput --opcode-name=PseudoVNCLIPU_WX_M1_MASK '--riscv-filter-config=vtype = {VXRM: rod, AVL: VLMAX, SEW: e(8|16), Policy: ta/mu}' --max-configs-per-opcode=1000 --min-instructions=10
# .---command stderr------------
# | PseudoVNCLIPU_WX_M1_MASK: Failed to produce any snippet via: instruction has tied variables, avoiding Read-After-Write issue, picking random def and use registers not aliasing each other, for uses, one unique register for each position
# `-----------------------------
# executed command: 'c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\filecheck.exe' 'C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\test\tools\llvm-exegesis\RISCV\rvv\filter.test'
# .---command stderr------------
# | FileCheck error: '<stdin>' is empty.
# | FileCheck command line:  c:\b\slave\clang-x64-windows-msvc\build\stage1\bin\filecheck.exe C:\b\slave\clang-x64-windows-msvc\llvm-project\llvm\test\tools\llvm-exegesis\RISCV\rvv\filter.test
# `-----------------------------
# error: command failed with exit status: 2

--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
********************
Failed Tests (1):
  LLVM :: tools/llvm-exegesis/RISCV/rvv/filter.test


Testing Time: 344.55s

Total Discovered Tests: 64944
  Skipped          :    26 (0.04%)
  Unsupported      :  2420 (3.73%)
  Passed           : 62309 (95.94%)
  Expectedly Failed:   188 (0.29%)
  Failed           :     1 (0.00%)
FAILED: test/CMakeFiles/check-llvm C:/b/slave/clang-x64-windows-msvc/build/stage1/test/CMakeFiles/check-llvm 
cmd.exe /C "cd /D C:\b\slave\clang-x64-windows-msvc\build\stage1\test && C:\Python39\python.exe C:/b/slave/clang-x64-windows-msvc/build/stage1/./bin/llvm-lit.py -sv -j 32 C:/b/slave/clang-x64-windows-msvc/build/stage1/test"
ninja: build stopped: subcommand failed.

```

</details>
author_association: NONE
user: login: llvm-ci
created_at: 2025-04-05T03:58:36Z
body: LLVM Buildbot has detected a new failure on builder `sanitizer-aarch64-linux-bootstrap-asan` running on `sanitizer-buildbot8` while building `llvm` at step 2 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/24/builds/7040

<details>
<summary>Here is the relevant piece of the build log for the reference</summary>

```
Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87462 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/23/76 (78973 of 87462)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/23/76' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-2549900-23-76.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=76 GTEST_SHARD_INDEX=23 /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 24 of 76.
[==========] Running 4 tests from 4 test suites.
[----------] Global test environment set-up.
[----------] 1 test from AArch64SelectionDAGTest
[ RUN      ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT
[       OK ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT (15 ms)
[----------] 1 test from AArch64SelectionDAGTest (15 ms total)

[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MTransferSubregSpills
[       OK ] InstrRefLDVTest.MTransferSubregSpills (148 ms)
[----------] 1 test from InstrRefLDVTest (148 ms total)

[----------] 1 test from RegAllocScoreTest
[ RUN      ] RegAllocScoreTest.Counts
[       OK ] RegAllocScoreTest.Counts (1 ms)
[----------] 1 test from RegAllocScoreTest (1 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: 1
--
shard JSON output does not exist: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-2549900-23-76.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
233.30s: Clang :: Driver/fsanitize.c
179.96s: Clang :: Preprocessor/riscv-target-features.c
163.85s: Clang :: Driver/arm-cortex-cpus-2.c
Step 11 (stage2/asan check) failure: stage2/asan check (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87462 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/23/76 (78973 of 87462)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/23/76' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-2549900-23-76.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=76 GTEST_SHARD_INDEX=23 /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 24 of 76.
[==========] Running 4 tests from 4 test suites.
[----------] Global test environment set-up.
[----------] 1 test from AArch64SelectionDAGTest
[ RUN      ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT
[       OK ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT (15 ms)
[----------] 1 test from AArch64SelectionDAGTest (15 ms total)

[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MTransferSubregSpills
[       OK ] InstrRefLDVTest.MTransferSubregSpills (148 ms)
[----------] 1 test from InstrRefLDVTest (148 ms total)

[----------] 1 test from RegAllocScoreTest
[ RUN      ] RegAllocScoreTest.Counts
[       OK ] RegAllocScoreTest.Counts (1 ms)
[----------] 1 test from RegAllocScoreTest (1 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: 1
--
shard JSON output does not exist: /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-2549900-23-76.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
233.30s: Clang :: Driver/fsanitize.c
179.96s: Clang :: Preprocessor/riscv-target-features.c
163.85s: Clang :: Driver/arm-cortex-cpus-2.c

```

</details>
author_association: NONE
user: login: llvm-ci
created_at: 2025-04-05T04:38:34Z
body: LLVM Buildbot has detected a new failure on builder `sanitizer-x86_64-linux-bootstrap-asan` running on `sanitizer-buildbot2` while building `llvm` at step 2 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/52/builds/7340

<details>
<summary>Here is the relevant piece of the build log for the reference</summary>

```
Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure)
...
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/lld-link
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld.lld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/lld-link
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 89957 tests, 88 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80..
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/100/151 (80893 of 89957)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/100/151' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-322859-100-151.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=151 GTEST_SHARD_INDEX=100 /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 101 of 151.
[==========] Running 2 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MLocSingleBlock
[       OK ] InstrRefLDVTest.MLocSingleBlock (3 ms)
[----------] 1 test from InstrRefLDVTest (3 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: 1
--
shard JSON output does not exist: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-322859-100-151.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
307.52s: LLVM :: CodeGen/AMDGPU/sched-group-barrier-pipeline-solver.mir
132.71s: Clang :: Driver/fsanitize.c
114.50s: Clang :: Preprocessor/riscv-target-features.c
113.21s: LLVM :: CodeGen/RISCV/attributes.ll
99.03s: Clang :: OpenMP/target_update_codegen.cpp
95.37s: Clang :: OpenMP/target_defaultmap_codegen_01.cpp
92.84s: Clang :: Driver/arm-cortex-cpus-2.c
90.46s: Clang :: Driver/arm-cortex-cpus-1.c
79.57s: Clang :: Preprocessor/aarch64-target-features.c
79.16s: Clang :: Preprocessor/arm-target-features.c
69.66s: LLVM :: CodeGen/RISCV/atomic-rmw.ll
65.81s: Clang :: Preprocessor/predefined-arch-macros.c
65.58s: Clang :: Driver/linux-ld.c
Step 11 (stage2/asan check) failure: stage2/asan check (failure)
...
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/lld-link
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld.lld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/lld-link
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 89957 tests, 88 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80..
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/100/151 (80893 of 89957)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/100/151' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-322859-100-151.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=151 GTEST_SHARD_INDEX=100 /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 101 of 151.
[==========] Running 2 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MLocSingleBlock
[       OK ] InstrRefLDVTest.MLocSingleBlock (3 ms)
[----------] 1 test from InstrRefLDVTest (3 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: 1
--
shard JSON output does not exist: /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-322859-100-151.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
307.52s: LLVM :: CodeGen/AMDGPU/sched-group-barrier-pipeline-solver.mir
132.71s: Clang :: Driver/fsanitize.c
114.50s: Clang :: Preprocessor/riscv-target-features.c
113.21s: LLVM :: CodeGen/RISCV/attributes.ll
99.03s: Clang :: OpenMP/target_update_codegen.cpp
95.37s: Clang :: OpenMP/target_defaultmap_codegen_01.cpp
92.84s: Clang :: Driver/arm-cortex-cpus-2.c
90.46s: Clang :: Driver/arm-cortex-cpus-1.c
79.57s: Clang :: Preprocessor/aarch64-target-features.c
79.16s: Clang :: Preprocessor/arm-target-features.c
69.66s: LLVM :: CodeGen/RISCV/atomic-rmw.ll
65.81s: Clang :: Preprocessor/predefined-arch-macros.c
65.58s: Clang :: Driver/linux-ld.c

```

</details>
author_association: NONE
user: login: llvm-ci
created_at: 2025-04-05T04:57:33Z
body: LLVM Buildbot has detected a new failure on builder `sanitizer-aarch64-linux-bootstrap-msan` running on `sanitizer-buildbot9` while building `llvm` at step 2 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/94/builds/5918

<details>
<summary>Here is the relevant piece of the build log for the reference</summary>

```
Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87460 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/23/76 (79255 of 87460)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/23/76' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-3200700-23-76.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=76 GTEST_SHARD_INDEX=23 /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 24 of 76.
[==========] Running 4 tests from 4 test suites.
[----------] Global test environment set-up.
[----------] 1 test from AArch64SelectionDAGTest
[ RUN      ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT
[       OK ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT (8 ms)
[----------] 1 test from AArch64SelectionDAGTest (8 ms total)

[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MTransferSubregSpills
[       OK ] InstrRefLDVTest.MTransferSubregSpills (64 ms)
[----------] 1 test from InstrRefLDVTest (64 ms total)

[----------] 1 test from RegAllocScoreTest
[ RUN      ] RegAllocScoreTest.Counts
[       OK ] RegAllocScoreTest.Counts (0 ms)
[----------] 1 test from RegAllocScoreTest (4 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: -6
--
shard JSON output does not exist: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-3200700-23-76.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
74.45s: LLVM :: CodeGen/AMDGPU/memintrinsic-unroll.ll
64.76s: LLVM :: CodeGen/AMDGPU/sched-group-barrier-pipeline-solver.mir
60.02s: Clang :: Driver/fsanitize.c
Step 11 (stage2/msan check) failure: stage2/msan check (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87460 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/23/76 (79255 of 87460)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/23/76' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-3200700-23-76.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=76 GTEST_SHARD_INDEX=23 /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 24 of 76.
[==========] Running 4 tests from 4 test suites.
[----------] Global test environment set-up.
[----------] 1 test from AArch64SelectionDAGTest
[ RUN      ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT
[       OK ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT (8 ms)
[----------] 1 test from AArch64SelectionDAGTest (8 ms total)

[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MTransferSubregSpills
[       OK ] InstrRefLDVTest.MTransferSubregSpills (64 ms)
[----------] 1 test from InstrRefLDVTest (64 ms total)

[----------] 1 test from RegAllocScoreTest
[ RUN      ] RegAllocScoreTest.Counts
[       OK ] RegAllocScoreTest.Counts (0 ms)
[----------] 1 test from RegAllocScoreTest (4 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: -6
--
shard JSON output does not exist: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/unittests/CodeGen/./CodeGenTests-LLVM-Unit-3200700-23-76.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
74.45s: LLVM :: CodeGen/AMDGPU/memintrinsic-unroll.ll
64.76s: LLVM :: CodeGen/AMDGPU/sched-group-barrier-pipeline-solver.mir
60.02s: Clang :: Driver/fsanitize.c
Step 16 (stage2/msan_track_origins check) failure: stage2/msan_track_origins check (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:520: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87460 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: LLVM-Unit :: CodeGen/./CodeGenTests/23/76 (78970 of 87460)
******************** TEST 'LLVM-Unit :: CodeGen/./CodeGenTests/23/76' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/unittests/CodeGen/./CodeGenTests-LLVM-Unit-3286472-23-76.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=76 GTEST_SHARD_INDEX=23 /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/unittests/CodeGen/./CodeGenTests
--

Note: This is test shard 24 of 76.
[==========] Running 4 tests from 4 test suites.
[----------] Global test environment set-up.
[----------] 1 test from AArch64SelectionDAGTest
[ RUN      ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT
[       OK ] AArch64SelectionDAGTest.getTypeConversion_SplitScalableMVT (22 ms)
[----------] 1 test from AArch64SelectionDAGTest (22 ms total)

[----------] 1 test from InstrRefLDVTest
[ RUN      ] InstrRefLDVTest.MTransferSubregSpills
[       OK ] InstrRefLDVTest.MTransferSubregSpills (91 ms)
[----------] 1 test from InstrRefLDVTest (91 ms total)

[----------] 1 test from RegAllocScoreTest
[ RUN      ] RegAllocScoreTest.Counts
[       OK ] RegAllocScoreTest.Counts (1 ms)
[----------] 1 test from RegAllocScoreTest (1 ms total)

[----------] 1 test from X86MCInstLowerTest
[ RUN      ] X86MCInstLowerTest.moExternalSymbol_MCSYMBOL

--
exit: -6
--
shard JSON output does not exist: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan_track_origins/unittests/CodeGen/./CodeGenTests-LLVM-Unit-3286472-23-76.json
********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Slowest Tests:
--------------------------------------------------------------------------
423.09s: LLVM :: CodeGen/AMDGPU/sched-group-barrier-pipeline-solver.mir
223.78s: Clang :: Analysis/runtime-regression.c
152.78s: LLVM :: CodeGen/AMDGPU/memintrinsic-unroll.ll

```

</details>
author_association: NONE
user: login: weiweichen
created_at: 2025-04-05T05:12:19Z
body: Sending this PR https://github.com/llvm/llvm-project/pull/134481 which should probably help to fix all the sanitizer failures here for `X86MCInstLowerTest.cpp`.
author_association: CONTRIBUTOR
user: login: llvm-ci
created_at: 2025-04-05T06:41:46Z
body: LLVM Buildbot has detected a new failure on builder `lld-x86_64-win` running on `as-worker-93` while building `llvm` at step 7 "test-build-unified-tree-check-all".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/146/builds/2646

<details>
<summary>Here is the relevant piece of the build log for the reference</summary>

```
Step 7 (test-build-unified-tree-check-all) failure: test (failure)
******************** TEST 'LLVM-Unit :: Support/./SupportTests.exe/82/95' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe-LLVM-Unit-10736-82-95.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=95 GTEST_SHARD_INDEX=82 C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe
--

Script:
--
C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe --gtest_filter=ProgramEnvTest.CreateProcessLongPath
--
C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp(160): error: Expected equality of these values:
  0
  RC
    Which is: -2

C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp(163): error: fs::remove(Twine(LongPath)): did not return errc::success.
error number: 13
error message: permission denied



C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp:160
Expected equality of these values:
  0
  RC
    Which is: -2

C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp:163
fs::remove(Twine(LongPath)): did not return errc::success.
error number: 13
error message: permission denied




********************


```

</details>
author_association: NONE