aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/MC/MCExpr.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-07-26MC: Generate relocation for a branch crossing linker-relaxable FT_Align fragmentFangrui Song1-14/+11
"Encode FT_Align in fragment's variable-size tail" or a neighbor change caused a regression that was similar to the root cause of ab0931b6389838cb5d7d11914063a1ddd84102f0 (See the new test (.text3 with a call at the start")) For a FT_Align fragment, the offset between location A (with offset <= FixedSize) and B (offset == FixedSize+VarSize) cannot be resolved. In addition, delete unneeded condition `F->isLinkerRelaxable()`. LoongArch linker relaxation is largely under-tested, but update it as well.
2025-07-20MC: Refactor FT_Align fragments when linker relaxation is enabledFangrui Song1-4/+1
Previously, two MCAsmBackend hooks were used, with shouldInsertFixupForCodeAlign calling getWriter().recordRelocation directly, bypassing generic code. This patch: * Introduces MCAsmBackend::relaxAlign to replace the two hooks. * Tracks padding size using VarContentEnd (content is ignored). * Move setLinkerRelaxable from MCObjectStreamer::emitCodeAlignment to the backends. Pull Request: https://github.com/llvm/llvm-project/pull/149465
2025-07-20MC: Encode FT_Align in fragment's variable-size tailFangrui Song1-4/+4
Follow-up to #148544 Pull Request: https://github.com/llvm/llvm-project/pull/149030
2025-07-15MC: Restructure MCFragment as a fixed part and a variable tailFangrui Song1-5/+5
Refactor the fragment representation of `push rax; jmp foo; nop; jmp foo`, previously encoded as `MCDataFragment(nop); MCRelaxableFragment(jmp foo); MCDataFragment(nop); MCRelaxableFragment(jmp foo)`, to ``` MCFragment(fixed: push rax, variable: jmp foo) MCFragment(fixed: nop, variable: jmp foo) ``` Changes: * Eliminate MCEncodedFragment, moving content and fixup storage to MCFragment. * The new MCFragment contains a fixed-size content (similar to previous MCDataFragment) and an optional variable-size tail. * The variable-size tail supports FT_Relaxable, FT_LEB, FT_Dwarf, and FT_DwarfFrame, with plans to extend to other fragment types. dyn_cast/isa should be avoided for the converted fragment subclasses. * In `setVarFixups`, source fixup offsets are relative to the variable part's start. Stored fixup (in `FixupStorage`) offsets are relative to the fixed part's start. A lot of code does `getFragmentOffset(Frag) + Fixup.getOffset()`, expecting the fixup offset to be relative to the fixed part's start. * HexagonAsmBackend::fixupNeedsRelaxationAdvanced needs to know the associated instruction for a fixup. We have to add a `const MCFragment &` parameter. * In MCObjectStreamer, extend `absoluteSymbolDiff` to apply to FT_Relaxable as otherwise there would be many more FT_DwarfFrame fragments in -g compilations. https://llvm-compile-time-tracker.com/compare.php?from=28e1473e8e523150914e8c7ea50b44fb0d2a8d65&to=778d68ad1d48e7f111ea853dd249912c601bee89&stat=instructions:u ``` stage2-O0-g instructins:u geomeon (-0.07%) stage1-ReleaseLTO-g (link only) max-rss geomean (-0.39%) ``` ``` % /t/clang-old -g -c sqlite3.i -w -mllvm -debug-only=mc-dump &| awk '/^[0-9]+/{s[$2]++;tot++} END{print "Total",tot; n=asorti(s, si); for(i=1;i<=n;i++) print si[i],s[si[i]]}' Total 59675 Align 2215 Data 29700 Dwarf 12044 DwarfCallFrame 4216 Fill 92 LEB 12 Relaxable 11396 % /t/clang-new -g -c sqlite3.i -w -mllvm -debug-only=mc-dump &| awk '/^[0-9]+/{s[$2]++;tot++} END{print "Total",tot; n=asorti(s, si); for(i=1;i<=n;i++) print si[i],s[si[i]]}' Total 32287 Align 2215 Data 2312 Dwarf 12044 DwarfCallFrame 4216 Fill 92 LEB 12 Relaxable 11396 ``` Pull Request: https://github.com/llvm/llvm-project/pull/148544
2025-07-12MCFragment: Refactor code for MCFragmentFangrui Song1-8/+8
To prepare for moving content and fixup member variables from MCEncodedFragment to MCFragment and removing MCDataFragment/MCRelaxableFragment classes, replace dyn_cast with getKind() tests.
2025-06-28MCSymbolRefExpr: Migrate away from deprecated VariantKindFangrui Song1-4/+4
2025-06-28MCExpr: Migrate away from operator<<Fangrui Song1-2/+4
Printing an expression is error-prone without a MCAsmInfo argument. Remove the operator<< overload and replace callers with MCAsmInfo::printExpr. Some callers are changed to MCExpr::print, with the goal of eventually making it private.
2025-06-27MC: Reduce MCSymbolRefExpr::VK_None usesFangrui Song1-6/+5
2025-06-16MCSpecifierExpr: Remove unused virtual functionsFangrui Song1-9/+0
... now that all targets using MCSpecifierExpr have migrated to XXXMCAsmInfo::printExpr/evaluateAsRelocatableImpl.
2025-06-15MC: Adjust -show-inst output for MCExprFangrui Song1-4/+9
This dump feature does not pass MCAsmInfo to the printer function. When we remove MCSpecifierExpr subclasses (and the printImpl overrides), we will not be able to print target-specific specifier strings. Just print a textual representation.
2025-06-15MC: Add MCAsmInfo::evaluateAsRelocatableImpl and replace VEMCExpr with ↵Fangrui Song1-1/+4
MCSpecifierExpr Expressions with specifier can only be folded during relocation generatin. At parse time the `MCAssembler *` argument might be null, and targets should not rely on the evaluateAsRelocatable result. Therefore, we can move evaluateAsRelocatableImpl from MCSpecifierExpr to MCAsmInfo, so that targets do not need to inherit from MCSpecifierExpr.
2025-06-15MC: Add MCSpecifierExpr::createFangrui Song1-0/+10
as a target-agnostic implementation to replace target-specific XXXMCExpr::create.
2025-06-13MC,SPARC: Replace SparcMCExpr with MCSpecifierExprFangrui Song1-0/+2
Add a hook printSpecifierExpr so that targets can implement relocation specifier printing without inheriting from MCSpecifierExpr.
2025-06-08MCExpr: Move isSymbolUsedInExpression workaround to AMDGPUFangrui Song1-32/+0
This function was a workaround used to detect cyclic dependency (properly resolved by 343428c666f9293ae260bbcf79130562b830b268). We do not want backends to use it. However, #112251 exposed it to MCExpr to be reused by AMDGPU. Keep the workaround within AMDGPU to prevent other backends from accidentally relying on it.
2025-06-07MCSpecifierExpr: Make dtor defaultedFangrui Song1-2/+0
2025-06-07MC: Add MCSpecifierExpr to unify target MCExprsFangrui Song1-0/+23
Many targets define MCTargetExpr subclasses just to encode an expression with a relocation specifier. Create a generic MCSpecifierExpr to be inherited instead. Migrate M68k and SPARC as examples.
2025-06-01MCExpr: Simplify and optimize equated symbol evaluationFangrui Song1-16/+14
Sym.isInSection() calls findAssociatedFragment, which traverses the expression tree. This can be replaced by calling evaluateAsRelocatableImpl first and then inspecting the MCValue result.
2025-05-26MC: Allow .set to reassign non-MCConstantExpr expressionsFangrui Song1-3/+0
GNU Assembler supports symbol reassignment via .set, .equ, or =. However, LLVM's integrated assembler only allows reassignment for MCConstantExpr cases, as it struggles with scenarios like: ``` .data .set x, 0 .long x // reference the first instance x = .-.data .long x // reference the second instance .set x,.-.data .long x // reference the third instance ``` Between two assignments binds, we cannot ensure that a reference binds to the earlier assignment. We use MCSymbol::IsUsed and other conditions to reject potentially unsafe reassignments, but certain MCConstantExpr uses could be unsafe as well. This patch enables reassignment by cloning the symbol upon reassignment and updating the symbol table. Existing references to the original symbol remain unchanged, and the original symbol is excluded from the emitted symbol table.
2025-05-26MC: Detect cyclic dependency for variable symbolsFangrui Song1-4/+24
We report cyclic dependency errors for variable symbols and rely on isSymbolUsedInExpression in parseAssignmentExpression at parse time, which does not catch all setVariableValue cases (e.g. cyclic .weakref). Instead, add a bit to MCSymbol and check it when walking the variable value MCExpr. When a cycle is detected when we have a final layout, report an error and set the variable to a constant to avoid duplicate errors. isSymbolUsedInExpression is considered deprecated, but it is still used by AMDGPU (#112251).
2025-05-26MC: Improve error reporting for equated symbols and undefined labelsFangrui Song1-0/+2
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.
2025-05-25llvm-ml: Rework the alias directive to not use ELF-intended VK_WEAKREFFangrui Song1-7/+1
Set `WeakExternal` to disable the the expansion in MCExpr.cpp:canExpand.
2025-05-25[llvm-ml] Restore VK_WEAKREF special case to fix alias.asmFangrui Song1-1/+7
2025-05-25MC: Rework .weakrefFangrui Song1-6/+1
Use a variable symbol without any specifier instead of VK_WEAKREF. Add code in ELFObjectWriter::executePostLayoutBinding to check whether the target should be made an undefined weak symbol. This change fixes several issues: * Unreferenced `.weakref alias, target` no longer creates an undefined `target`. * When `alias` is already defined, report an error instead of crashing. .weakref is specific to ELF. llvm-ml has reused the VK_WEAKREF name for a different concept. wasm incorrectly copied the ELF implementation. Remove it.
2025-05-24MC: Remove redundant relocations for label differencesFangrui Song1-5/+4
For the label difference A-B where A and B are in the same section, if the section contains no linker-relaxable instruction, we can disable the framnent walk code path (https://reviews.llvm.org/D155357), removing redundant relocations. This optimization is available since we now track per-section linker-relaxable instructions (#140692). lld/test/ELF/loongarch-reloc-leb128.s , introduced in #81133, has been updated in 9662a6039c0320eb4473d87b47f0ed891a0f111c to prevent coverage loss.
2025-05-24MCObjectwriter: Add member variable MCAssembler * and simplify codeFangrui Song1-1/+1
2025-05-24[MC] Remove unused includes (NFC) (#141321)Kazu Hirata1-1/+0
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
2025-05-23RISCV: Remove shouldForceRelocation and unneeded relocationsFangrui Song1-0/+6
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
2025-04-06MCSymbolRefExpr: Remove HasSubsectionsViaSymbolsBitFangrui Song1-4/+3
This information is only needed assembly time and we can get it with Asm->getContext().getAsmInfo()->hasSubsectionsViaSymbols().
2025-04-06MCExpr: Remove unused SectionAddrMap workaroundFangrui Song1-34/+17
Mach-O's ARM and X86 writers use MCExpr's `SectionAddrMap *Addrs` argument to compute label differences, which was a bit of a hack. The hack has been cleaned up by commit 1b7759de8e6979dda2d949b1ba1c742922e5c366.
2025-04-06MCValue: Replace getRefKind with getSpecifierFangrui Song1-2/+2
2025-04-05MCValue: Replace MCSymbolRefExpr members with MCSymbolFangrui Song1-26/+21
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).
2025-04-05MCValue: Store SymA specifier at SpecifierFangrui Song1-8/+11
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).
2025-04-05[MC] Replace getSymA()->getSymbol() with getAddSym. NFCFangrui Song1-1/+1
We will replace the MCSymbolRefExpr member in MCValue with MCSymbol. This change reduces dependence on MCSymbolRefExpr.
2025-04-05[MC] Replace getSymA()->getSymbol() with getAddSym. NFCFangrui Song1-5/+4
We will replace the MCSymbolRefExpr member in MCValue with MCSymbol. This change reduces dependence on MCSymbolRefExpr.
2025-04-05MCValue: Make getSymB private and improve documentationFangrui Song1-6/+6
2025-04-05[MC] Rework evaluateSymbolicAdd to eliminate MCValue::SymB relianceFangrui Song1-74/+69
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.
2025-04-01[MC] Add UseAtForSpecifierFangrui Song1-1/+1
Some ELF targets don't use @ for relocation specifiers. We should not report `error: invalid variant` when @ is used. Attempt to make expr@specifier parsing less hacky.
2025-03-30[MC] Simplify MCBinaryExpr/MCUnaryExpr printing by reducing parentheses ↵Fangrui Song1-20/+31
(#133674) The existing pretty printer generates excessive parentheses for MCBinaryExpr expressions. This update removes unnecessary parentheses of MCBinaryExpr with +/- operators and MCUnaryExpr. Since relocatable expressions only use + and -, this change improves readability in most cases. Examples: - (SymA - SymB) + C now prints as SymA - SymB + C. This updates the output of -fexperimental-relative-c++-abi-vtables for AArch64 and x86 to `.long _ZN1B3fooEv@PLT-_ZTV1B-8` - expr + (MCTargetExpr) now prints as expr + MCTargetExpr, with this change primarily affecting AMDGPUMCExpr.
2025-03-30[MC] Don't print () around $ namesFangrui Song1-12/+2
This MIPS behavior from edb9d84dcc4824865e86f963e52d67eb50dde7f5 (2010) is obsoleted and misleading. This caused confusion in https://reviews.llvm.org/D123702 ([NVPTX] Disable parens for identifiers starting with '$') Note: $tmp was rejected by AsmParser before https://reviews.llvm.org/D75111 (2020)
2025-03-25MCExpr: simplify evaluateAsRelocatableImpl after ↵Fangrui Song1-5/+1
https://reviews.llvm.org/D156505
2025-03-23MCValue: Simplify code with getSubSymFangrui Song1-3/+3
MCValue::SymB is a MCSymbolRefExpr *, which might become MCSymbol * in the future. Simplify some code that uses MCValue::SymB.
2025-03-20[MC] Rename some VariantKind functions to use SpecifierFangrui Song1-2/+2
Use the more appropriate term "relocation specifier" and avoid the variable name `Kind`, which conflicts with MCExpr and FixupKind.
2025-03-17[MC] Fix formatting of a commentFangrui Song1-2/+2
2025-03-15[MC] evaluateAsRelocatableImpl: remove the Fixup argumentFangrui Song1-10/+4
Follow-up to d6fbffa23c84e622735b3e880fd800985c1c0072 . This commit updates all call sites and removes the argument from the function.
2025-03-15[MC] evaluateAsAbsolute requires MCValue::RefKind==0Fangrui Song1-4/+4
In `.equ a, 3; .if a@plt`, a@plt does not evaluate to an absolute value (MCExpr::evaluateAsRelocatableImpl disables evaluation when the Kind != 0 at parse time). Similarly, when using MCTargetValue, evaluateAsAbsolute should return false when MCValue::RefKind==0. This allows us to remove `if (!Asm)` check from MipsMCExpr.cpp (%hi(0xdeadbeef) is not evaluated to a constant without RefKind) and make targets less error-prone.
2025-03-15[MC] evaluateAsRelocatable: remove the Fixup argumentFangrui Song1-12/+10
Commit 752b91bd821ad8a23e004b6cd631ae4f6984ae8b added the argument for PowerPC to evaluate @l/@ha as constant in 2014. However, this is not needed and has been cleaned up by commit 8560da28c69de481f3ad147722577e87b902facb. Mips also had an inappropriate use, which has been fixed by 79d84a878e83990c235da8710273a98bf835c915
2025-03-05[MC] Remove unneeded MCSymbolRefExpr::create overload and add commentsFangrui Song1-5/+0
The StringRef overload is often error-prone as users might forget to register the MCSymbol. Add comments to MCTargetExpr and MCSymbolRefExpr::VariantKind. In the distant future the VariantKind parameter might be removed.
2025-03-03Reapply [MCExpr] Remove generic getVariantKindName and getVariantKindForNameFangrui Song1-82/+7
They are error-prone as MCParser may parse a variant kind, which cannot be handled by the target. The replacement in MCAsmInfo should be used instead. Follow-up to f244b8eed37a12539fb11b76e19ec7a7eb41dccc
2025-03-03Revert "[MCExpr] Remove generic getVariantKindName and getVariantKindForName"Kazu Hirata1-2/+82
This reverts commit 04b49b11a8f70424263a3fc1f9c5bc69a9f46844. This patch breaks ThinLTO/X86/memprof-tailcall-nonunique.ll. Builtbot failures: https://lab.llvm.org/buildbot/#/builders/108/builds/9933 https://lab.llvm.org/buildbot/#/builders/25/builds/6868 https://lab.llvm.org/buildbot/#/builders/46/builds/12890
2025-03-02[MCExpr] Remove generic getVariantKindName and getVariantKindForNameFangrui Song1-82/+2
They are error-prone as MCParser may parse a variant kind, which cannot be handled by the target. The replacement in MCAsmInfo should be used instead. Follow-up to f244b8eed37a12539fb11b76e19ec7a7eb41dccc
generated by cgit v1.1 at 2025-10-15 12:02:51 +0000