Remove the MCSubtargetInfo argument from applyFixup, introduced in
https://reviews.llvm.org/D45962 , as it's only required by ARM. Instead,
add const MCFragment & so that ARMAsmBackend can retrieve
MCSubtargetInfo via a static member function.
Additionally, remove the MCAssembler argument, which is also only
required by ARM.
Additionally, make applyReloc non-const. Its arguments now fully cover
addReloc's functionality.
After #141311 removed the MCSubtargetInfo argument from
shouldForceRelocation, addReloc does not need this argument, either.
In a rare scenario that the information is needed, the target should
check the MCFragment subclass and get it from
MCDataFragment/MCRelaxableFragment.
This reverts the code change in commit
e87f33d9ce785668223c3bcc4e06956985cccda1 (#73721) but keeps its test.
There have been many changes to lib/MC and AsmBackend.cpp files, so this
is not a pure revert.
#73721, a workaround to generate necessary relocations in mixed
non-relax/relax code,
is no longer necessary after #140692 fixed the root issue (whether two
locations are separated by a fragment with indeterminate size due to
linker relaxation).
Follow-up to #140494
`shouldForceRelocation` is conservative and produces redundant
relocations.
For example, RISCVAsmBackend::ForceRelocs (introduced to support mixed
relax/norelax code) leads to redundant relocations in the following
example adapted from #77436
```
.option norelax
j label
// For assembly input, RISCVAsmParser::ParseInstruction sets ForceRelocs (https://reviews.llvm.org/D46423).
// For direct object emission, RISCVELFStreamer sets ForceRelocs (#77436)
.option relax
call foo // linker-relaxable
.option norelax
j label // redundant relocation due to ForceRelocs
.option relax
label:
```
Root problem: The `isSymbolRefDifferenceFullyResolvedImpl` condition in
MCAssembler::evaluateFixup does not check whether two locations are
separated by a fragment whose size can be indeterminate due to linker
instruction (e.g. MCDataFragment with relaxation, or MCAlignFragment
due to indeterminate start offst).
This patch
* Updates the fragment walk code in
`attemptToFoldSymbolOffsetDifference` to treat MCRelaxableFragment
(for --riscv-asm-relax-branches) as fixed size after finishLayout.
* Adds a condition in `addReloc` to complement
`isSymbolRefDifferenceFullyResolvedImpl`.
* Removes the no longer needed `shouldForceRelocation`.
This fragment walk code path handles nicely handles
mixed relax/norelax case from
https://discourse.llvm.org/t/possible-problem-related-to-subtarget-usage/75283
and allows us to remove `MCSubtargetInfo` argument (#73721) as a follow-up.
This fragment walk code should be avoided in the absence of
linker-relaxable fragments within the current section.
Adjust two bolt/test/RISCV tests (#141310)
Pull Request: https://github.com/llvm/llvm-project/pull/140692
Introduce MCAsmBackend::addReloc to manage relocation appending.
The default implementation uses shouldForceRelocation to check
unresolved fixups and calls recordRelocation to append a relocation when
needed.
RISCV and LoongArch override addReloc to handle ADD/SUB relocations,
with potential support for RELAX relocations in the future.
AVR overrides addReloc to customize shouldForceRelocation behavior
(#121498).
applyFixup is moved into evaluateFixup.
The simm13 format OR instruction should use one single fixup kind, while
it currently uses a lot more, including %m44/%l44.
This change refactors R_SPARC_H44/R_SPARC_M44/R_SPARC_M44 handling to
remove fixup kinds and specifiers. We utilize the [0,
FirstLiteralRelocationKind) MCFixupKind range to encode raw relocation
types that may be resolved (see the MCAssembler.cpp change).
The `evaluateAsRelocatableImpl` implementation resembles
PPCMCExpr::evaluateAsRelocatableImpl.
For RELA targets, fixup kinds that force relocations (GOT, TLS, ALIGN,
RELAX, etc) can bypass `applyFixup` and be encoded as
`FirstRelocationKind+i`, as seen in LoongArch. This patch removes
redundant fixup kinds and adopts the `FirstRelocationKind+i` encoding.
The `llvm-mc -show-encoding` output no longer displays descriptive fixup
names, as this information is removed from
`RISCVAsmBackend::getFixupKindInfo`. While a backend hook could be added
to call `llvm::object::getELFRelocationTypeName`, it's unnecessary since
the relocation in `-filetype=obj` output is what truly matters.
Pull Request: https://github.com/llvm/llvm-project/pull/136088
Among fixupNeedsRelaxationAdvanced (introduced by
https://reviews.llvm.org/D8217) targets, only Hexagon needs the
`MCRelaxableFragment` parameter (commit
86f218e7ec5d941b7785eaebcb8f4cad76db8a64) to get the instruction packet
(MCInst with sub-instruction operands).
As fixupNeedsRelaxationAdvanced follows mayNeedRelaxation, we can store
the MCInst in mayNeedRelaxation and eliminate the MCRelaxableFragment
parameter.
Follow-up to 7c83b7ef1796210451b839f4c58f2815f4aedfe5 that eliminates
the MCRelaxableFragment parameter from fixupNeedsRelaxation.
Follow-up to commits 5710759eb390c0d5274c2a4d43967282d7df1993
and 634f9a981571eae000c1adc311014c5c64486187
- Integrate `evaluateFixup` into `recordRelocation` and inline code
within `MCAssembler::layout`, removing `handleFixup`.
- Update `fixupNeedsRelaxation` to bypass `shouldForceRelocation` when
calling `evaluateFixup`, eliminating the `WasForced` workaround for
RISC-V linker relaxation (https://reviews.llvm.org/D46350 ).
This parameter eliminates a redundant computation for VK_ABS8 in X86 and
reduces reliance on shouldForceRelocation in relaxation decisions.
Note: `local: jmp local@plt` relaxes JMP. This behavior depends on
fixupNeedsRelaxation calling shouldForceRelocation, which might change
in the future.
Commit 52eb11f925ddeba4e1b3840fd636ee87387f3ada temporarily introduced
getSymSpecifier to prepare for "MCValue: Replace MCSymbolRefExpr members
with MCSymbol" (d5893fc2a7e1191afdb4940469ec9371a319b114). The
refactoring is now complete.
Commit 0999cbd0b9ed8aa893cce10d681dec6d54b200ad (2014) introduced
`MCValue::RefKind` for AArch64 ELF as a clean approach to encode the
relocation specifier.
Following numerous migration commits, direct references to getSymA and
getSymB have been eliminated. This allows us to seamlessly update SymA
and SymB, replacing MCSymbolRefExpr with MCSymbol.
Removeing reliance on a MCAssembler::evaluateFixup hack
(`if (Target.SymSpecifier || SA.isUndefined()) {` (previosuly
`if (A->getKind() != MCSymbolRefExpr::VK_None || SA.isUndefined()) {`))
requires 38c3ad36be1facbe6db2dede7e93c0f12fb4e1dc and 4182d2dcb5ecbfc34d41a6cd11810cd36844eddb
Revert the temporary RISCV/LoongArch workaround
(7e62715e0cd433ed97749549c6582c4e1aa689a3) during migration.
MCAssembler::evaluateFixup needs an extra `!Add->isAbsolute()` case
to support `movq abs@GOTPCREL(%rip), %rax; abs = 42` in llvm/test/MC/ELF/relocation-alias.s
(ELFObjectWriter::isSymbolRefDifferenceFullyResolvedImpl asserts if
called on an absolute symbol).
The relocation specifier should be accessed via MCValue::Specifier.
However, some targets encode the relocation specifier within SymA using
MCSymbolRefExpr::SubclassData and access it via getAccessVariant(), though
this method is now deprecated.
This change stores the SymA specifier at Specifier as well, unifying the
two code paths.
* CSKY: GOT- and PLT- relocations now suppress the STT_SECTION
conversion.
* AArch64: https://reviews.llvm.org/D156505 added `getRefkind` check to
prevent folding. This is a hack and is now removed.
MCValue: Unify relocation specifier storage by storing SymA specifier at Specifier
The relocation specifier is accessed via MCValue::Specifier, but some
targets encoded it within SymA using MCSymbolRefExpr::SubclassData and
retrieved it through the now-deprecated getAccessVariant() method. This
commit unifies the two approaches by storing the SymA specifier at
`Specifier` as well.
Additional changes:
- CSKY: GOT- and PLT- relocations now suppress STT_SECTION conversion.
- AArch64: Removed the `getRefkind` check hack (introduced in https://reviews.llvm.org/D156505) that prevented folding.
Removed the assertion from `getRelocType`.
- RISCV: Removed the assertion from `getRelocType`.
Future plans:
- Replace MCSymbolRefExpr members with MCSymbol within MCValue.
- Remove `getSymSpecifier` (added for migration).
Reworked evaluateSymbolicAdd and isSymbolRefDifferenceFullyResolved to
remove their reliance on MCValue::SymB, which previously used the
MCSymbolRefExpr member when folding two symbolic expressions. This
dependency prevented replacing MCValue::SymB with a MCSymbol. By
refactoring, we enable this replacement, which is a more significant
improvement.
Note that this change eliminates the rare "unsupported subtraction of
qualified symbol" diagnostic, resulting in a minor loss of information.
However, the benefit of enabling MCValue::SymB replacement with MCSymbol
outweighs this slight regression.
clang -fexperimental-relative-c++-abi-vtables might generate `@plt` and
`@gotpcrel` specifiers in data directives. The syntax is not used in
humand-written assembly code, and is not supported by GNU assembler.
Note: the `@plt` in `.word foo@plt` is different from
the legacy `call func@plt` (where `@plt` is simply ignored).
The `@plt` syntax was selected was simply due to a quirk of AsmParser:
the syntax was supported by all targets until I updated it
to be an opt-in feature in a0671758eb6e52a758bd1b096a9b421eec60204c
RISC-V favors the `%specifier(expr)` syntax following MIPS and Sparc,
and we should follow this convention.
This PR adds support for `.word %pltpcrel(foo+offset)` and
`.word %gotpcrel(foo)`, and drops `@plt` and `@gotpcrel`.
* MCValue::SymA can no longer have a SymbolVariant. Add an assert
similar to that of AArch64ELFObjectWriter.cpp before
https://reviews.llvm.org/D81446 (see my analysis at
https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers
if intrigued)
* `jump foo@plt, x31` now has a different diagnostic.
Pull Request: https://github.com/llvm/llvm-project/pull/132569
Target shouldForceRelocation checks `FirstLiteralRelocationKind` to
determine whether a relocation is forced due to the .reloc directive. We
should move the code to evaluateFixup so that many targets don't need to
override shouldForceRelocation.
Due to 8728e097dfbec3630a1dd907431c0f14274a1ae8
(`std::unique_ptr<MCAsmBackend> Backend`), the compiler doesn't know
that `Backend` will not be modified across function calls.
This reverts commit be5a845e4c29aadb513ae6e5e2879dccf37efdbb.
This causes large code size regressions, which were not present
in the initial version of this change.
This builds on top of commit 9d0754ada5dbbc0c009bcc2f7824488419cc5530
("[MC] Relax fragments eagerly") and relaxes fragments eagerly to
eliminate MCSection::HasLayout and `getFragmentOffset` overhead. The
approach is slightly different from
1a47f3f3db66589c11f8ddacfeaecc03fb80c510 and has less performance
benefit.
The new layout algorithm also addresses the following problems:
* Size change of MCFillFragment/MCOrgFragment did not influence the
fixed-point iteration, which could be problematic for contrived cases.
* The `invalid number of bytes` error was reported too early. Since
`.zero A-B` might have temporary negative values in the first few
iterations.
* X86AsmBackend::finishLayout performed only one iteration, which might
not converge. In addition, the removed `#ifndef NDEBUG` code (disabled
by default) in X86AsmBackend::finishLayout was problematic, as !NDEBUG
and NDEBUG builds evaluated fragment offsets at different times before
this patch.
* The computed layout for relax-recompute-align.s is optimal now.
Builds with many text sections (e.g. full LTO) shall observe a decrease
in compile time while the new algorithm could be slightly slower for
some -O0 -g projects.
Aligned bundling from the deprecated PNaCl placed constraints how we can
perform iteration.
This reverts commit 1a47f3f3db66589c11f8ddacfeaecc03fb80c510.
Fix#100283
This commit is actually a trigger of other preexisting problems:
* Size change of fill fragments does not influence the fixed-point iteration.
* The `invalid number of bytes` error is reported too early. Since
`.zero A-B` might have temporary negative values in the first few
iterations.
However, the problems appeared at least "benign" (did not affect the
Linux kernel builds) before this commit.
Commit 8728e097dfbec3630a1dd907431c0f14274a1ae8 (2018) introduced
getWriterPtr, which might be nullptr for MCAsmStreamer. This lured call
sites to use getWriterPtr when it's guaranteed to be non-null for
MCObjectstreamer. Remove this misleading API.
This builds on top of commit 9d0754ada5dbbc0c009bcc2f7824488419cc5530
("[MC] Relax fragments eagerly") and relaxes fragments eagerly to
eliminate MCSection::HasLayout and `getFragmentOffset` overhead.
Note: The removed `#ifndef NDEBUG` code (disabled by default) in
X86AsmBackend::finishLayout was problematic, as (a) !NDEBUG and NDEBUG
builds evaluated fragment offsets at different times before this patch
(b) one iteration might not be sufficient to converge. There might be
some edge cases that it did not handle. Anyhow, this patch probably
makes it work for more cases.
