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

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

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

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)

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-branch-commits] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

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 `M

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

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] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

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] [llvm] release/19.x: [MIPS] Optimize sortRelocs for o32 (PR #106008)

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

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

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 i

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

@@ -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/

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

@@ -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 diffe

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

@@ -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 tr

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

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)

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] [llvm] [AVR] Backport #118015 and #121498 (PR #125081)

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

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

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 m

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

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)

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 lis

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

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)

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)

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

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

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)

@@ -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'

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

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-

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

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)

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 ___