MaskRay wrote:
The previous, uglified lld tests, and this, make me believe that we should
revisit the lit feature. I am not sure I agree with this test rewriting.
https://github.com/llvm/llvm-project/pull/157232
___
llvm-branch-commits mailing list
ll
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/157236
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
LGTM.
It's good to get rid of `$(($(cat %t.size.txt) + 5))`
https://github.com/llvm/llvm-project/pull/156537
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.l
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/156538
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,19 @@
+# REQUIRES: aarch64
+
+# RUN: llvm-mc -filetype=obj -triple=aarch64 %s -o %t.o
+# RUN: ld.lld %t.o -o %t
+# RUN: llvm-readelf -s -r %t | FileCheck %s
+# RUN: ld.lld %t.o -o %t -pie
+# RUN: llvm-readelf -s -r %t | FileCheck %s
+# RUN: not ld.lld %t.o -o %t -shared
@@ -0,0 +1,18 @@
+# REQUIRES: aarch64
+
+# RUN: llvm-mc -filetype=obj -triple=aarch64 %s -o %t.o
+# RUN: not ld.lld %t.o -o %t 2>&1 | FileCheck --check-prefix=ERR %s
+
+.rodata
+# ERR: relocation R_AARCH64_FUNCINIT64 cannot be used against local symbol
MaskRay wro
https://github.com/MaskRay commented:
The lld part should be extracted to a separate patch. The patch has a base
branch. Is it still used?
https://github.com/llvm/llvm-project/pull/133531
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/133531
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
The property, if we decide to introduce, does not need to be too extensible.
That is because within the section header type `Elf64_Shdr`, `sh_name,
sh_offset, sh_size, sh_link, sh_info` can already be controlled. This patch
makes sh_type/sh_entsize customiable. I wonder whether
@@ -330,6 +325,18 @@ bool MachineFunction::shouldSplitStack() const {
return getFunction().hasFnAttribute("split-stack");
}
+Align MachineFunction::getPreferredAlignment() const {
+ Align PrefAlignment = Align(1);
MaskRay wrote:
Instead of reassigning to t
MaskRay wrote:
This looks good regardless of the CFI jump table usage.
https://github.com/llvm/llvm-project/pull/155540
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/153670
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -361,6 +361,10 @@ static void attemptToFoldSymbolOffsetDifference(const
MCAssembler *Asm,
if (BBeforeRelax && AAfterRelax)
return;
}
+ const auto *RF = dyn_cast(F);
+ if (RF && RF->isLinkerRelaxable()) {
+return;
Ma
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/153670
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
Need an aarch64 maintainer's signoff on the llvm part.
https://github.com/llvm/llvm-project/pull/133534
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch
MaskRay wrote:
> The R_AARCH64_PATCHINST relocation type is to support deactivation symbols.
> For more information, see the RFC:
> [discourse.llvm.org/t/rfc-deactivation-symbols/85556](https://discourse.llvm.org/t/rfc-deactivation-symbols/85556)
>
> An AArch64 psABI extension proposal has bee
@@ -61,6 +61,7 @@ ELF_RELOC(R_AARCH64_LD64_GOT_LO12_NC,0x138)
ELF_RELOC(R_AARCH64_LD64_GOTPAGE_LO15, 0x139)
ELF_RELOC(R_AARCH64_PLT32, 0x13a)
ELF_RELOC(R_AARCH64_GOTPCREL32, 0x13b)
+ELF_RELOC(R_AARCH64
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/133534
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
The assembler part (BinaryFormat / Target/AArch64 changes) look good. The
linker change should be made separate. But thank for combining this in a single
PR, making the full picture clear:)
https://github.com/llvm/llvm-project/pull/133534
@@ -0,0 +1,87 @@
+# RUN: rm -rf %t && split-file %s %t
MaskRay wrote:
consider adding `&& cd %t` so that we can remove `%t/` below, which clutter up
the commands...
https://github.com/llvm/llvm-project/pull/133534
___
@@ -0,0 +1,7 @@
+// RUN: llvm-mc -triple aarch64-elf -filetype=obj %s -o - | llvm-objdump -r -
| FileCheck %s
+
+// Test that PATCHINST appears after JUMP26.
+// CHECK: R_AARCH64_JUMP26
+// CHECK-NEXT: R_AARCH64_PATCHINST
+.reloc ., R_AARCH64_PATCHINST, ds
+b f1
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/151886
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
> > @androm3da The hexagon-thunks-packets.s test added by this change is
> > failing on our s390x builds.
> > See
> > [download.copr.fedorainfracloud.org/results/@fedora-llvm-team/llvm21/fedora-rawhide-s390x/09365945-llvm/builder-live.log.gz](https://download.copr.fedorainfraclou
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/151674
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/150812
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/150797
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/150813
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
Is this the last change in the patch series? The use of booleans is a good move
to prevent the complexity of MIPS-style dynamic relocations (which I haven’t
fully analyzed). Thanks for tidying this up!
https://github.com/llvm/llvm-project/pull/150813
@@ -470,7 +461,6 @@ class DynamicReloc {
void computeRaw(Ctx &, SymbolTableBaseSection *symt);
Symbol *sym;
- const OutputSection *outputSec = nullptr;
MaskRay wrote:
Thanks for removing `outputSec`!
https://github.com/llvm/llvm-project/pull/150810
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/150810
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/150811
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/150799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
There are some discussions on a codegen patch #149444 that I did not follow.
Could you summarize the motivation in this patch's description?
https://github.com/llvm/llvm-project/pull/150151
___
llvm-branch-commits mailing list
llvm-bran
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/150730
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
> The current code is quite crusty and divergent from non-MIPS in API use, but
> fixing it up like this is quite high-risk, especially given how weird the
> MIPS GOT is when it comes to the required initial memory state. Is anyone
> using LLD for MIPS these days who can test thi
https://github.com/MaskRay approved this pull request.
When DynamicReloc::Kind was introduced, I was concerned of the many Kinds, but
that was still better than the previous state. Thanks for the simplification.
https://github.com/llvm/llvm-project/pull/150798
__
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/150183
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/150183
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/150172
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/150183
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/150183
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -26,19 +26,15 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
return static_cast(getAssembler().getWriter());
}
-// Make sure that all section are registered in the correct order.
-static void registerSectionHierarchy(MCAssembler &Asm, MCSectionGOFF *Section)
{
- if
https://github.com/MaskRay created
https://github.com/llvm/llvm-project/pull/150183
registerSection should only be called by
MCObjectStreamer::changeSection. This will be utilized by a pending
change to move initial fragment allocation from MCContext::createSection
to MCStreamer::changeSection,
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/149733
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/149756
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/149723
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
Next steps:
* Allocate the fixed content as trailing data of the MCFragment by utilizing a
special bump allocator (gnulib obstack)
* Delete MCFixup member variables from MCFragment. Instead, add a MCFragment
pointer to MCFixup.
https://github.com/llvm/llvm-project/pull/149465
_
@@ -992,7 +965,30 @@ void MCAssembler::layoutSection(MCSection &Sec) {
uint64_t Offset = 0;
for (MCFragment &F : Sec) {
F.Offset = Offset;
-Offset += computeFragmentSize(F);
+if (F.getKind() == MCFragment::FT_Align) {
+ Offset += F.getFixedSize();
+ un
@@ -433,42 +434,44 @@ static void writeFragment(raw_ostream &OS, const
MCAssembler &Asm,
const auto &EF = cast(F);
OS << StringRef(EF.getContents().data(), EF.getContents().size());
OS << StringRef(EF.getVarContents().data(), EF.getVarContents().size());
-if (F
@@ -230,22 +230,24 @@ uint64_t MCAssembler::computeFragmentSize(const
MCFragment &F) const {
case MCFragment::FT_Align: {
unsigned Offset = F.Offset + F.getFixedSize();
unsigned Size = offsetToAlignment(Offset, F.getAlignment());
-
-// Insert extra Nops for code
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/149578
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
Can use some description what is the correct behavior.
Perhaps
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-falign-functions
> If n is not specified or is zero, use a machine-dependent default.
https://github.com/llvm/llvm-project/pull/149445
_
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -53,3 +53,4 @@ LLVM_FIXED_MD_KIND(MD_DIAssignID, "DIAssignID", 38)
LLVM_FIXED_MD_KIND(MD_coro_outside_frame, "coro.outside.frame", 39)
LLVM_FIXED_MD_KIND(MD_mmra, "mmra", 40)
LLVM_FIXED_MD_KIND(MD_noalias_addrspace, "noalias.addrspace", 41)
+LLVM_FIXED_MD_KIND(MD_elf_section
@@ -230,22 +230,24 @@ uint64_t MCAssembler::computeFragmentSize(const
MCFragment &F) const {
case MCFragment::FT_Align: {
unsigned Offset = F.Offset + F.getFixedSize();
unsigned Size = offsetToAlignment(Offset, F.getAlignment());
-
-// Insert extra Nops for code
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/149465
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
I haven't had the chance to review this patch in detail, but I’m concerned
about the number of linker options required for the CFI feature. While I
recognize its benefits, the complexity seems excessive.
https://github.com/llvm/llvm-project/pull/149448
__
https://github.com/MaskRay created
https://github.com/llvm/llvm-project/pull/149465
Previously, two MCAsmBackend hooks were used, with
shouldInsertFixupForCodeAlign calling getWriter().recordRelocation
directly, bypassing generic code.
This patch:
* Introduces MCAsmBackend::relaxAlign to repla
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/147915
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/147916
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/147917
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
Author: Fangrui Song
Date: 2025-07-04T00:58:07-07:00
New Revision: 7e3e2e1b8c6ff21e68782a56164139cca334fcf3
URL:
https://github.com/llvm/llvm-project/commit/7e3e2e1b8c6ff21e68782a56164139cca334fcf3
DIFF:
https://github.com/llvm/llvm-project/commit/7e3e2e1b8c6ff21e68782a56164139cca334fcf3.diff
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/147227
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,67 @@
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-objdump %t -d --symbolize-operands --no-show-raw-insn
--no-leading-addr | \
+# RUN: FileCheck %s --match-full-lines -DABS_ADRP_VAL=0x6000
+# RUN: llvm-objdump %t -d --symbolize-operands --no-show-raw-insn
--no-leading-add
https://github.com/MaskRay commented:
Looks good, but I'd check whether @jh7370 has opinions on the test.
(We need an executable for testing. llvm/test cannot use lld, so we have to
resort to hexadecimal bytes...)
https://github.com/llvm/llvm-project/pull/145009
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/144633
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/144633
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -41,6 +44,61 @@ void MCGOFFStreamer::changeSection(MCSection *Section,
uint32_t Subsection) {
MCObjectStreamer::changeSection(Section, Subsection);
}
+void MCGOFFStreamer::emitLabel(MCSymbol *Symbol, SMLoc Loc) {
+ MCObjectStreamer::emitLabel(Symbol, Loc);
+ cast(Symbo
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/144437
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay commented:
LGTM! But I will delegated to a GOFF expert for approval...
https://github.com/llvm/llvm-project/pull/144437
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/MaskRay created
https://github.com/llvm/llvm-project/pull/144633
Rename these relocation specifier constants, aligning with the naming
convention used by other targets (`S_` instead of `VK_`).
* ELF/COFF: AArch64MCExpr::VK_ => AArch64::S_ (VK_ABS/VK_PAGE_ABS are
also used b
@@ -0,0 +1,92 @@
+//===- TargetImpl.h -*- C++
-*-===//
+//
+// 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: Apa
@@ -0,0 +1,94 @@
+//===- TargetImpl.h -*- C++
-*-===//
MaskRay wrote:
`//===--===//`
for new file per https://llvm.org/docs/CodingStandards.html#file
@@ -0,0 +1,98 @@
+# REQUIRES: x86
+
+## Test that the branch-to-branch optimization follows the links
+## from f1 -> f2 -> f3 and updates all references to point to f3.
+
+# RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
+# RUN: ld.lld %t.o -o %t --branch-to-branch
@@ -0,0 +1,94 @@
+//===- TargetImpl.h -*- C++
-*-===//
+//
+// 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: Apa
@@ -0,0 +1,94 @@
+//===- TargetImpl.h -*- C++
-*-===//
+//
+// 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: Apa
MaskRay wrote:
Perhaps you'll need to change the base branch to `main` and force push to
users/pcc/spr/elf-add-branch-to-branch-optimization?
https://github.com/llvm/llvm-project/pull/138366
___
llvm-branch-commits mailing list
llvm-branch-commits@lis
@@ -975,6 +977,62 @@ void AArch64::relocateAlloc(InputSectionBase &sec, uint8_t
*buf) const {
}
}
+static std::optional getControlTransferAddend(InputSection &is,
+Relocation &r) {
+ // Identify a control transfer rel
MaskRay wrote:
> [pcc](https://github.com/pcc) wants to merge 1 commit into
> [users/pcc/spr/main.elf-add-branch-to-branch-optimization](https://github.com/llvm/llvm-project/tree/users/pcc/spr/main.elf-add-branch-to-branch-optimization)
> from
> [users/pcc/spr/elf-add-branch-to-branch-optimiza
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/142311
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay requested changes to this pull request.
While at Google, I encountered this issue co-authored the glibc commit
b5c45e83753b27dc538dff2d55d4410c385cf3a4.
I don’t believe this is relevant for upstream LLD, so I haven’t pursued
submitting a linker patch.
The piece of LLD
@@ -0,0 +1,39 @@
+
MaskRay wrote:
Use `clang/test/CodeGen/debug-info-*.c`? We use `%clang_cc1` in almost all
non-driver tests
https://github.com/llvm/llvm-project/pull/134635
___
llvm-branch-commits mailing list
llvm-
@@ -50,26 +53,26 @@ class MCSectionGOFF final : public MCSection {
friend class MCContext;
friend class MCSymbolGOFF;
- MCSectionGOFF(StringRef Name, SectionKind K, GOFF::SDAttr SDAttributes,
-MCSectionGOFF *Parent)
- : MCSection(SV_GOFF, Name, K.isTe
MaskRay wrote:
> The alternative fix, which I think I'm now leaning towards, would be to
> change how the branch-to-branch optimization handles relocations to
> STT_SECTION symbols. A relocation pointing to the STT_SECTION for .text with
> addend 1 would be treated as a branch to .text+5 and i
MaskRay wrote:
> @MaskRay Sorry, your comment is basically empty. I guess a GitHub problem?
Sorry... Could be my accidentally pushing a comment to a wrong PR..
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm
MaskRay wrote:
The goal is to differentiate two scenarios when a symbol is referenced by a
potential R_X86_64_PLT32 relocation:
* `.4byte foo@plt - .` (LLVM assembly extension, not supported in GNU
assembler): No redirection to a thunk. References foo or its PLT entry.
* `jmp foo; .section .te
MaskRay wrote:
I've read
https://github.com/llvm/llvm-project/pull/138366#issuecomment-2855889424 but I
am still not following.
What is invalid?
Note that range extension thunks track both the symbol and the addend (e.g.
https://reviews.llvm.org/D70637 (AArch64)).
So we could add a thunk for
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/135867
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
MaskRay wrote:
3
之
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/MaskRay commented:
LGTM. As I'm not familiar with z/OS, my review focused on its compatibility
with the current MC infrastructure. (My internet access will be limited between
April 20th and May 4th, which may cause delays in my response time.)
Thanks for reimplementing the g
MaskRay wrote:
> Hey Amir,
>
> Thanks for the PR. Unfortunately, it is still failing. The trick below
> doesn't seem to work on my buildbot machine:
>
> > Link against a DSO to ensure PLT entries.
>
> So doing:
>
> ```shell
> nm --synthetic callcont-fallthru.s.tmp
> ```
>
> won't list a `pu
1 - 100 of 795 matches
Mail list logo
