Remove the redundant MCFixup::Loc member and instead use MCExpr::Loc to
determine the location for fixups. Previously, many target MCCodeEmitter would
use the beginning of an instruction for fixup locations, which often
resulted in inaccurate column information.
```
// RISCVMCCodeEmitter::getImmOpValue
Fixups.push_back(MCFixup::create(0, Expr, FixupKind, MI.getLoc()));
// X86MCCodeEmitter::emitImmediate
Fixups.push_back(MCFixup::create(static_cast<uint32_t>(CB.size() - StartByte), Expr, FixupKind, Loc));
```
While MCExpr::Loc generally provides more meaningful location data,
tests should avoid over-relying on it. For instance, MCBinaryExpr's
location refers to its operator, and for operands with sigils (like
`$foo`), the location often omits the sigils.
https://llvm-compile-time-tracker.com/compare.php?from=8740ff822d462844506134bb7c425e1778518b95&to=831a11f75d22d64982b13dba132d656ac8567612&stat=instructions%3Au
I've also considered removing MCExpr::Loc (revert
https://reviews.llvm.org/D28861), but we'd lose too much information.
It's also difficult to carry location information to improve location
tracking in target MCCodeEmitter.
This change utilizes previous MCExpr::Loc improvement like
7e3e2e1b8c6ff21e68782a56164139cca334fcf3
7b517cf743f112f980cf6a4d6e6190c2a5b3e451
Follow-up to #141333. Relocation generation called both addReloc and
applyFixup, with the default addReloc invoking shouldForceRelocation,
resulting in three virtual calls. This approach was also inflexible, as
targets needing additional data required extending
`shouldForceRelocation` (see #73721, resolved by #141311).
This change integrates relocation handling into applyFixup, eliminating
two virtual calls. The prior default addReloc is renamed to
maybeAddReloc. Targets overriding addReloc now call their customized
addReloc implementation.
... due to their close relationship. MCSection's inline functions (e.g.
iterator) access MCFragment, and we want MCFragment's inline functions
to access MCSection similarly (#146307).
Pull Request: https://github.com/llvm/llvm-project/pull/146315
* Make pre-layout to -debug-only=mc-dump-pre. This output is not useful
for most debugging needs.
* Print fragment-associated symbols. Make it easier to locate relevant
fragments.
* Print the LinkerRelaxable flag.
The "Symbol" stanza includes symbol names with all zero indexes. which
are not useful.
The "assembler backend - post-relaxation" part is not useful. Only
Hexagon (and X86 when x86-pad-for-align is set) might change the layout
between "post-relaxation" and "final-layout". From my experience
debugging the two passes requires more dumping code not served by the
output.
Remove unneeded details like "<" and ">". Reduce indentation.
Omit `this` address to simplify output comparison.
Add a -debug-only=mc-dump test.
While here, add fixup printing for MCRelaxableFragment.
This builds on top of commit 9d0754ada5dbbc0c009bcc2f7824488419cc5530
("[MC] Relax fragments eagerly") and relaxes fragments eagerly to
eliminate MCSection::HasLayout and `getFragmentOffset` overhead.
Relands 1a47f3f3db66589c11f8ddacfeaecc03fb80c510
Builds with many text sections (e.g. full LTO) shall observe a decrease
in compile time.
---
In addition, ensure `.fill` and `.space` directives with expressions are
re-evaluated during fragment relaxation, as their sizes may change.
Continue iteration to prevent stale, incorrect sizes.
This change has to be coupled with the fragment algorithm change
as otherwise the test test/MC/ELF/layout-interdependency.s would not
converge.
Fixes#123402 and resolves the root cause of #100283, building on error
postponing from commit 38b12d4a7c219b46d1cb52580cbacbdb931262f2.
For AArch64/label-arithmetic-diags-elf.s, the extra iteration
reports a .fill error early and suppresses the fixup/relocation errors.
Just split the tests.
The dummy fragment is primarily used by MCAsmStreamer::emitLabel to
track the defined state. We can replace it with an arbitrary fragment.
Remove MCDummyFragment introduced for https://github.com/llvm/llvm-project/issues/24860
Currently, the code path is likely only reachable with super edge-case scenario,
but will be more reachable with the upcoming parseAssignmentExpression improvement
to address a pile of hacks.
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
