[llvm-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

2024-08-25 Thread Alex Rønne Petersen via llvm-branch-commits 

https://github.com/alexrp created 
https://github.com/llvm/llvm-project/pull/106008

Manual backport of #104723.

From 9a72d8b12202d27c4229ff9ccab0f0cdb6b6f583 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Sun, 18 Aug 2024 11:24:44 -0700
Subject: [PATCH 1/3] [MIPS] Remove expensive LLVM_DEBUG relocation dump

The input is usually ordered by offset, so inspecting the output is
sufficient. The super expensive relocation dump is not conventional.
---
 .../Mips/MCTargetDesc/MipsELFObjectWriter.cpp | 32 ++-
 1 file changed, 2 insertions(+), 30 deletions(-)

diff --git a/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp 
b/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp
index 4d6a00c14a3575..1f047020d96c80 100644
--- a/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp
+++ b/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp
@@ -47,13 +47,6 @@ struct MipsRelocationEntry {
   }
 };
 
-#ifndef NDEBUG
-raw_ostream &operator<<(raw_ostream &OS, const MipsRelocationEntry &RHS) {
-  RHS.print(OS);
-  return OS;
-}
-#endif
-
 class MipsELFObjectWriter : public MCELFObjectTargetWriter {
 public:
   MipsELFObjectWriter(uint8_t OSABI, bool HasRelocationAddend, bool Is64);
@@ -115,17 +108,11 @@ static InputIt find_best(InputIt First, InputIt Last, 
UnaryPredicate Predicate,
   for (InputIt I = First; I != Last; ++I) {
 unsigned Matched = Predicate(*I);
 if (Matched != FindBest_NoMatch) {
-  LLVM_DEBUG(dbgs() << std::distance(First, I) << " is a match (";
- I->print(dbgs()); dbgs() << ")\n");
-  if (Best == Last || BetterThan(*I, *Best)) {
-LLVM_DEBUG(dbgs() << ".. and it beats the last one\n");
+  if (Best == Last || BetterThan(*I, *Best))
 Best = I;
-  }
 }
-if (Matched == FindBest_PerfectMatch) {
-  LLVM_DEBUG(dbgs() << ".. and it is unbeatable\n");
+if (Matched == FindBest_PerfectMatch)
   break;
-}
   }
 
   return Best;
@@ -201,15 +188,6 @@ static bool compareMatchingRelocs(const 
MipsRelocationEntry &Candidate,
   return PreviousBest.Matched && !Candidate.Matched;
 }
 
-#ifndef NDEBUG
-/// Print all the relocations.
-template 
-static void dumpRelocs(const char *Prefix, const Container &Relocs) {
-  for (const auto &R : Relocs)
-dbgs() << Prefix << R << "\n";
-}
-#endif
-
 MipsELFObjectWriter::MipsELFObjectWriter(uint8_t OSABI,
  bool HasRelocationAddend, bool Is64)
 : MCELFObjectTargetWriter(Is64, OSABI, ELF::EM_MIPS, HasRelocationAddend) 
{}
@@ -448,8 +426,6 @@ void MipsELFObjectWriter::sortRelocs(const MCAssembler &Asm,
   std::list Sorted;
   std::list Remainder;
 
-  LLVM_DEBUG(dumpRelocs("R: ", Relocs));
-
   // Separate the movable relocations (AHL relocations using the high bits) 
from
   // the immobile relocations (everything else). This does not preserve 
high/low
   // matches that already existed in the input.
@@ -459,8 +435,6 @@ void MipsELFObjectWriter::sortRelocs(const MCAssembler &Asm,
});
 
   for (auto &R : Remainder) {
-LLVM_DEBUG(dbgs() << "Matching: " << R << "\n");
-
 unsigned MatchingType = getMatchingLoType(R);
 assert(MatchingType != ELF::R_MIPS_NONE &&
"Wrong list for reloc that doesn't need a match");
@@ -494,8 +468,6 @@ void MipsELFObjectWriter::sortRelocs(const MCAssembler &Asm,
 Sorted.insert(InsertionPoint, R)->Matched = true;
   }
 
-  LLVM_DEBUG(dumpRelocs("S: ", Sorted));
-
   assert(Relocs.size() == Sorted.size() && "Some relocs were not consumed");
 
   // Overwrite the original vector with the sorted elements.

From f139a3296123eb567c158fd1219b33e2263cc5f7 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Sun, 18 Aug 2024 15:47:38 -0700
Subject: [PATCH 2/3] [MC] Remove ELFRelocationEntry::OriginalAddend

For MIPS's o32 ABI (REL), https://reviews.llvm.org/D19718 introduced
`OriginalAddend` to find the matching R_MIPS_LO16 relocation for
R_MIPS_GOT16 when STT_SECTION conversion is applicable.

lw $2, %lo(local1)
lui $2, %got(local1)

However, we could just store the original `Addend` in
`ELFRelocationEntry` and remove `OriginalAddend`.

Note: The relocation ordering algorithm in
https://reviews.llvm.org/D19718 is inefficient (#104562), which will be
addressed by another patch.
---
 llvm/include/llvm/MC/MCELFObjectWriter.h|  9 +++--
 llvm/lib/MC/ELFObjectWriter.cpp | 17 ++---
 .../Mips/MCTargetDesc/MipsELFObjectWriter.cpp   |  9 -
 3 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/llvm/include/llvm/MC/MCELFObjectWriter.h 
b/llvm/include/llvm/MC/MCELFObjectWriter.h
index 9b74cbc3d3a520..d48840c0f89877 100644
--- a/llvm/include/llvm/MC/MCELFObjectWriter.h
+++ b/llvm/include/llvm/MC/MCELFObjectWriter.h
@@ -38,18 +38,15 @@ struct ELFRelocationEntry {
   unsigned Type;   // The type of the relocation.
   uint64_t Addend; // The addend to use.
   const MCSymbolELF *OriginalSymbol; // The original

[llvm-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

2024-08-25 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

cc @MaskRay @brad0

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

[llvm-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

2024-08-26 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

@tru please see the numbers in 
https://github.com/llvm/llvm-project/issues/104562#issue-2469758971. The Zig 
project has no choice but to keep all MIPS32 testing (both local and in CI) 
disabled until this fix is in effect. So I'd say it's reasonably important.

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

[llvm-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

2024-08-26 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

Yeah, this has been an issue for a while AIUI.

I don't think it affects C/C++ projects in general because of separate 
compilation. Zig, OTOH, uses a compilation model that's more like a "unity 
build", which results in tons of relocations in the single module that goes 
through `MipsELFObjectWriter`, so we're really badly affected by this. It's 
only recently that we've started getting our MIPS port up to a high standard of 
quality, so it's hurting us quite a bit now that we actually want to do regular 
testing for it.

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

[llvm-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

2024-08-31 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

Has a decision been reached on this? (Not familiar with how exactly the process 
works.)

Also, even if this doesn't make it for 19.1.0-final, can it be considered for a 
subsequent bug fix release?

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

[llvm-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

2024-09-02 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

@MaskRay @topperc @wzssyqa @yingopq sorry for the pings, but I assume today is 
the last chance to get this in, so I would love to hear your thoughts on 
whether you think that's a good idea. :slightly_smiling_face:

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

[llvm-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

2024-09-03 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

Definitely agree it's not a regression, but I think I would quibble a bit with 
the idea that taking ~1h6min to compile something that normally takes ~3min is 
not a bug in some sense. :slightly_smiling_face:

But ok, philosophical debates aside: Would it be reasonable to at least 
consider it a [critical performance issue for the purposes of a bug fix 
release](https://github.com/llvm/llvm-project/blob/main/llvm/docs/HowToReleaseLLVM.rst#release-patch-rules)?
 I acknowledge that there'd still need to be an assessment as to whether the 
patch is safe, but it *seems* like it should at least fit one of the criteria 
on its face. In regards to safety, perhaps confidence in the patch would 
increase in the time between 19.1.0-final and the subsequent bug fix releases?

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

[llvm-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

2024-09-07 Thread Alex Rønne Petersen via llvm-branch-commits 

https://github.com/alexrp updated 
https://github.com/llvm/llvm-project/pull/106008

From 20583f07954e2dadf2a9fceaee005a0a730c31e6 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Sun, 18 Aug 2024 11:24:44 -0700
Subject: [PATCH 1/3] [MIPS] Remove expensive LLVM_DEBUG relocation dump

The input is usually ordered by offset, so inspecting the output is
sufficient. The super expensive relocation dump is not conventional.
---
 .../Mips/MCTargetDesc/MipsELFObjectWriter.cpp | 32 ++-
 1 file changed, 2 insertions(+), 30 deletions(-)

diff --git a/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp 
b/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp
index 4d6a00c14a3575..1f047020d96c80 100644
--- a/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp
+++ b/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp
@@ -47,13 +47,6 @@ struct MipsRelocationEntry {
   }
 };
 
-#ifndef NDEBUG
-raw_ostream &operator<<(raw_ostream &OS, const MipsRelocationEntry &RHS) {
-  RHS.print(OS);
-  return OS;
-}
-#endif
-
 class MipsELFObjectWriter : public MCELFObjectTargetWriter {
 public:
   MipsELFObjectWriter(uint8_t OSABI, bool HasRelocationAddend, bool Is64);
@@ -115,17 +108,11 @@ static InputIt find_best(InputIt First, InputIt Last, 
UnaryPredicate Predicate,
   for (InputIt I = First; I != Last; ++I) {
 unsigned Matched = Predicate(*I);
 if (Matched != FindBest_NoMatch) {
-  LLVM_DEBUG(dbgs() << std::distance(First, I) << " is a match (";
- I->print(dbgs()); dbgs() << ")\n");
-  if (Best == Last || BetterThan(*I, *Best)) {
-LLVM_DEBUG(dbgs() << ".. and it beats the last one\n");
+  if (Best == Last || BetterThan(*I, *Best))
 Best = I;
-  }
 }
-if (Matched == FindBest_PerfectMatch) {
-  LLVM_DEBUG(dbgs() << ".. and it is unbeatable\n");
+if (Matched == FindBest_PerfectMatch)
   break;
-}
   }
 
   return Best;
@@ -201,15 +188,6 @@ static bool compareMatchingRelocs(const 
MipsRelocationEntry &Candidate,
   return PreviousBest.Matched && !Candidate.Matched;
 }
 
-#ifndef NDEBUG
-/// Print all the relocations.
-template 
-static void dumpRelocs(const char *Prefix, const Container &Relocs) {
-  for (const auto &R : Relocs)
-dbgs() << Prefix << R << "\n";
-}
-#endif
-
 MipsELFObjectWriter::MipsELFObjectWriter(uint8_t OSABI,
  bool HasRelocationAddend, bool Is64)
 : MCELFObjectTargetWriter(Is64, OSABI, ELF::EM_MIPS, HasRelocationAddend) 
{}
@@ -448,8 +426,6 @@ void MipsELFObjectWriter::sortRelocs(const MCAssembler &Asm,
   std::list Sorted;
   std::list Remainder;
 
-  LLVM_DEBUG(dumpRelocs("R: ", Relocs));
-
   // Separate the movable relocations (AHL relocations using the high bits) 
from
   // the immobile relocations (everything else). This does not preserve 
high/low
   // matches that already existed in the input.
@@ -459,8 +435,6 @@ void MipsELFObjectWriter::sortRelocs(const MCAssembler &Asm,
});
 
   for (auto &R : Remainder) {
-LLVM_DEBUG(dbgs() << "Matching: " << R << "\n");
-
 unsigned MatchingType = getMatchingLoType(R);
 assert(MatchingType != ELF::R_MIPS_NONE &&
"Wrong list for reloc that doesn't need a match");
@@ -494,8 +468,6 @@ void MipsELFObjectWriter::sortRelocs(const MCAssembler &Asm,
 Sorted.insert(InsertionPoint, R)->Matched = true;
   }
 
-  LLVM_DEBUG(dumpRelocs("S: ", Sorted));
-
   assert(Relocs.size() == Sorted.size() && "Some relocs were not consumed");
 
   // Overwrite the original vector with the sorted elements.

From 99fe6d1feee427cc06e561facb80a4eda2ada583 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Sun, 18 Aug 2024 15:47:38 -0700
Subject: [PATCH 2/3] [MC] Remove ELFRelocationEntry::OriginalAddend

For MIPS's o32 ABI (REL), https://reviews.llvm.org/D19718 introduced
`OriginalAddend` to find the matching R_MIPS_LO16 relocation for
R_MIPS_GOT16 when STT_SECTION conversion is applicable.

lw $2, %lo(local1)
lui $2, %got(local1)

However, we could just store the original `Addend` in
`ELFRelocationEntry` and remove `OriginalAddend`.

Note: The relocation ordering algorithm in
https://reviews.llvm.org/D19718 is inefficient (#104562), which will be
addressed by another patch.
---
 llvm/include/llvm/MC/MCELFObjectWriter.h|  9 +++--
 llvm/lib/MC/ELFObjectWriter.cpp | 17 ++---
 .../Mips/MCTargetDesc/MipsELFObjectWriter.cpp   |  9 -
 3 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/llvm/include/llvm/MC/MCELFObjectWriter.h 
b/llvm/include/llvm/MC/MCELFObjectWriter.h
index 9b74cbc3d3a520..d48840c0f89877 100644
--- a/llvm/include/llvm/MC/MCELFObjectWriter.h
+++ b/llvm/include/llvm/MC/MCELFObjectWriter.h
@@ -38,18 +38,15 @@ struct ELFRelocationEntry {
   unsigned Type;   // The type of the relocation.
   uint64_t Addend; // The addend to use.
   const MCSymbolELF *OriginalSymbol; // The original value of Symbol if we 
change

[llvm-branch-commits] [clang] [llvm] [LLVM] [Clang] Backport "Support for Gentoo `*t64` triples (64-bit time_t ABIs)" (PR #112364)

2024-10-30 Thread Alex Rønne Petersen via llvm-branch-commits 


@@ -294,7 +294,11 @@ class Triple {
 
 PAuthTest,
 
-LastEnvironmentType = PAuthTest
+GNUT64,
+GNUEABIT64,
+GNUEABIHFT64,
+
+LastEnvironmentType = GNUEABIHFT64

alexrp wrote:

Also, ABI aside, quoting [Release Patch 
Rules](https://llvm.org/docs/HowToReleaseLLVM.html#release-patch-rules):

> Bug fix releases Patches should be limited to bug fixes or very safe and 
> critical performance improvements. Patches must maintain **both API and ABI 
> compatibility** with the previous major release.

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

[llvm-branch-commits] [clang] [llvm] [LLVM] [Clang] Backport "Support for Gentoo `*t64` triples (64-bit time_t ABIs)" (PR #112364)

2024-10-30 Thread Alex Rønne Petersen via llvm-branch-commits 


@@ -294,7 +294,11 @@ class Triple {
 
 PAuthTest,
 
-LastEnvironmentType = PAuthTest
+GNUT64,
+GNUEABIT64,
+GNUEABIHFT64,
+
+LastEnvironmentType = GNUEABIHFT64

alexrp wrote:

I don't *think* a revert at this stage would make much of a difference since 
the break has already shipped in a release anyway. We'll have to deal with it 
in Zig regardless.

We just need to be a bit more careful with enum changes like this going forward.

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

[llvm-branch-commits] [clang] [llvm] [LLVM] [Clang] Backport "Support for Gentoo `*t64` triples (64-bit time_t ABIs)" (PR #112364)

2024-10-30 Thread Alex Rønne Petersen via llvm-branch-commits 


@@ -294,7 +294,11 @@ class Triple {
 
 PAuthTest,
 
-LastEnvironmentType = PAuthTest
+GNUT64,
+GNUEABIT64,
+GNUEABIHFT64,
+
+LastEnvironmentType = GNUEABIHFT64

alexrp wrote:

We don't mandate a particular patch version of LLVM because we try to support 
building Zig with a distro-provided LLVM. Distro packages aren't necessarily 
going to be on the latest LLVM patch release.

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

[llvm-branch-commits] [clang] [llvm] [LLVM] [Clang] Backport "Support for Gentoo `*t64` triples (64-bit time_t ABIs)" (PR #112364)

2024-10-30 Thread Alex Rønne Petersen via llvm-branch-commits 

https://github.com/alexrp edited 
https://github.com/llvm/llvm-project/pull/112364
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AVR] Backport #118015 and #121498 (PR #125081)

2025-01-30 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

FWIW, the issue this addresses is a hard blocker for building even basic AVR 
programs with Zig as well, so definitely +1 for a backport from our side.

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

[llvm-branch-commits] [llvm] [AVR] Backport #118015 and #121498 (PR #125081)

2025-01-31 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

> Also, @alexrp - is Zig planning on upgrading soon as well? If not, I can try 
> to prepare a different backport, one that doesn't require modifying 
> `shouldForceRelocation()` (not 100% sure that's possible, but I can at least 
> look into that).

The situation on our end is that Zig 0.14.0 will release on February 17th with 
LLVM 19. (We're not planning on upgrading to 20 until 0.15.0.) So if an LLVM 
patch release can happen before the 17th, then a backport would definitely be 
appreciated, if possible.

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

[llvm-branch-commits] [llvm] release/19.x: [llvm][Mips] Bail on underaligned loads/stores in FastISel. (#106231) (PR #126693)

2025-02-10 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

Fine by me, but I was under the impression that [there won't be any more 19.x 
releases](https://github.com/llvm/llvm-project/pull/125081#issuecomment-2646389290)?

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

[llvm-branch-commits] [llvm] release/20.x: [PowerPC] Support conversion between f16 and f128 (#130158) (PR #132049)

2025-03-20 Thread Alex Rønne Petersen via llvm-branch-commits 

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


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

[llvm-branch-commits] [clang] [llvm] release/20.x: [Hexagon] Set the default compilation target to V68 (#125239) (PR #128597)

2025-03-19 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

Given 20.1.1 was just released, is the plan still to get this one into 20.x? 
(Just asking to know whether we should make a corresponding change in Zig.)

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

[llvm-branch-commits] [llvm] [PowerPC] Support conversion between f16 and f128 (#130158) (PR #133279)

2025-03-27 Thread Alex Rønne Petersen via llvm-branch-commits 

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


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

[llvm-branch-commits] [llvm] release/20x: Revert "[ARM][ConstantIslands] Correct MinNoSplitDisp calculation (#114590)" (PR #135850)

2025-04-15 Thread Alex Rønne Petersen via llvm-branch-commits 

https://github.com/alexrp milestoned 
https://github.com/llvm/llvm-project/pull/135850
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/20x: Revert "[ARM][ConstantIslands] Correct MinNoSplitDisp calculation (#114590)" (PR #135850)

2025-04-15 Thread Alex Rønne Petersen via llvm-branch-commits 

https://github.com/alexrp created 
https://github.com/llvm/llvm-project/pull/135850

This reverts commit e48916f615e0ad2b994b2b785d4fe1b8a98bc322.

From fc9b72b1fc60dc0c556f6e146d735791df5c6581 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Alex=20R=C3=B8nne=20Petersen?= 
Date: Tue, 15 Apr 2025 22:32:34 +0200
Subject: [PATCH] Revert "[ARM][ConstantIslands] Correct MinNoSplitDisp
 calculation (#114590)"

This reverts commit e48916f615e0ad2b994b2b785d4fe1b8a98bc322.
---
 llvm/lib/Target/ARM/ARMConstantIslandPass.cpp |   3 +-
 .../Thumb2/constant-islands-no-split.mir  | 165 --
 2 files changed, 1 insertion(+), 167 deletions(-)
 delete mode 100644 llvm/test/CodeGen/Thumb2/constant-islands-no-split.mir

diff --git a/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp 
b/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
index e41e02a560db0..89eb49ed416ae 100644
--- a/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
+++ b/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
@@ -1323,8 +1323,7 @@ bool ARMConstantIslands::findAvailableWater(CPUser &U, 
unsigned UserOffset,
   MachineBasicBlock *UserBB = U.MI->getParent();
   BBInfoVector &BBInfo = BBUtils->getBBInfo();
   const Align CPEAlign = getCPEAlign(U.CPEMI);
-  unsigned MinNoSplitDisp =
-  BBInfo[UserBB->getNumber()].postOffset(CPEAlign) - UserOffset;
+  unsigned MinNoSplitDisp = BBInfo[UserBB->getNumber()].postOffset(CPEAlign);
   if (CloserWater && MinNoSplitDisp > U.getMaxDisp() / 2)
 return false;
   for (water_iterator IP = std::prev(WaterList.end()), B = WaterList.begin();;
diff --git a/llvm/test/CodeGen/Thumb2/constant-islands-no-split.mir 
b/llvm/test/CodeGen/Thumb2/constant-islands-no-split.mir
deleted file mode 100644
index 9283ef14ca6cb..0
--- a/llvm/test/CodeGen/Thumb2/constant-islands-no-split.mir
+++ /dev/null
@@ -1,165 +0,0 @@
-# RUN: llc -mtriple=thumbv7-linux-gnueabihf -run-pass=arm-cp-islands 
-arm-constant-island-max-iteration=1 %s -o - | FileCheck %s
 |
-  ; ModuleID = 'constant-islands-new-island.ll'
-  source_filename = "constant-islands-new-island.ll"
-  target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
-  target triple = "thumbv7-unknown-linux-gnueabihf"
-  
-  define void @test(i1 %tst) {
-  entry:
-%0 = call i32 @llvm.arm.space(i32 2000, i32 undef)
-br label %smallbb
-  
-  smallbb:  ; preds = %entry
-br i1 %tst, label %true, label %false
-  
-  true: ; preds = %false, %smallbb
-%val = phi float [ 1.234500e+04, %smallbb ], [ undef, %false ]
-%1 = call i32 @llvm.arm.space(i32 2000, i32 undef)
-call void @bar(float %val)
-ret void
-  
-  false:; preds = %smallbb
-br label %true
-  }
-  
-  declare void @bar(float)
-  
-  ; Function Attrs: nounwind
-  declare i32 @llvm.arm.space(i32 immarg, i32) #0
-  
-  attributes #0 = { nounwind }
-
-...

-name:test
-alignment:   2
-exposesReturnsTwice: false
-legalized:   false
-regBankSelected: false
-selected:false
-failedISel:  false
-tracksRegLiveness: true
-hasWinCFI:   false
-noPhis:  true
-isSSA:   false
-noVRegs: true
-hasFakeUses: false
-callsEHReturn:   false
-callsUnwindInit: false
-hasEHCatchret:   false
-hasEHScopes: false
-hasEHFunclets:   false
-isOutlined:  false
-debugInstrRef:   false
-failsVerification: false
-tracksDebugUserValues: false
-registers:   []
-liveins:
-  - { reg: '$r0', virtual-reg: '' }
-frameInfo:
-  isFrameAddressTaken: false
-  isReturnAddressTaken: false
-  hasStackMap: false
-  hasPatchPoint:   false
-  stackSize:   16
-  offsetAdjustment: 0
-  maxAlignment:4
-  adjustsStack:true
-  hasCalls:true
-  stackProtector:  ''
-  functionContext: ''
-  maxCallFrameSize: 0
-  cvBytesOfCalleeSavedRegisters: 0
-  hasOpaqueSPAdjustment: false
-  hasVAStart:  false
-  hasMustTailInVarArgFunc: false
-  hasTailCall: false
-  isCalleeSavedInfoValid: true
-  localFrameSize:  0
-  savePoint:   ''
-  restorePoint:''
-fixedStack:  []
-stack:
-  - { id: 0, name: '', type: spill-slot, offset: -12, size: 4, alignment: 4, 
-  stack-id: default, callee-saved-register: '', callee-saved-restored: 
true, 
-  debug-info-variable: '', debug-info-expression: '', debug-info-location: 
'' }
-  - { id: 1, name: '', type: spill-slot, offset: -16, size: 4, alignment: 4, 
-  stack-id: default, callee-saved-register: '', callee-saved-restored: 
true, 
-  debug-info-variable: '', debug-info-expression: '', debug-info-location: 
'' }
-  - { id: 2, name: '', type: spill-slot, offset: -4, size: 4, alignment: 4, 
-  stack-id: default, callee-saved-register: '$lr', callee-saved-restored: 
false, 
-  debug-info-variable: '', debug-info-expression: '', debug-info-location: 
'' }
-  - { id: 3, name: '', type: spill-slot, offset: -8, size: 4, alignment: 4, 
-

[llvm-branch-commits] [llvm] release/20x: Revert "[ARM][ConstantIslands] Correct MinNoSplitDisp calculation (#114590)" (PR #135850)

2025-04-15 Thread Alex Rønne Petersen via llvm-branch-commits 

https://github.com/alexrp edited 
https://github.com/llvm/llvm-project/pull/135850
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [SPARC][IAS] Add definitions for OSA 2011 instructions (PR #138403)

2025-05-03 Thread Alex Rønne Petersen via llvm-branch-commits 


@@ -87,3 +87,4 @@ ELF_RELOC(R_SPARC_GOTDATA_LOX10,  81)
 ELF_RELOC(R_SPARC_GOTDATA_OP_HIX22,  82)
 ELF_RELOC(R_SPARC_GOTDATA_OP_LOX10,  83)
 ELF_RELOC(R_SPARC_GOTDATA_OP, 84)
+ELF_RELOC(R_SPARC_WDISP10, 88)

alexrp wrote:

Don't worry too much about it FWIW, I'll just resolve the conflicts if this one 
happens to be merged first.

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

[llvm-branch-commits] [llvm] release/20.x: [Hexagon] Handle Call Operand vxi1 in Hexagon Backend (#128027) (PR #129311)

2025-03-01 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

Strictly speaking this represents an ABI change, so per the LLVM release 
policy, I don't see how it *could* be included in a post-20.1.0 release?

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

[llvm-branch-commits] [llvm] release/20.x: [AArch64] Fix BE popcount casts. (#129879) (PR #129996)

2025-03-08 Thread Alex Rønne Petersen via llvm-branch-commits 

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


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

[llvm-branch-commits] [llvm] release/20.x: [PowerPC] Support conversion between f16 and f128 (#130158) (PR #132049)

2025-03-25 Thread Alex Rønne Petersen via llvm-branch-commits 

alexrp wrote:

Seems like the tests are failing because #126880 hasn't been backported. 
Probably should just adjust the tests accordingly.

What's standard practice here? Should someone with commit access just push a 
fix to the PR branch?

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