aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/MC/MCAssembler.cpp
AgeCommit message (Collapse)AuthorFilesLines
10 days[SFrames] reland Emit and relax FREs #158154 (#159643)Sterling-Augustine1-0/+24
[Previously reverted due to msan failures on two uninitialized padding bits.] This PR emits and relaxes the FREs generated in the previous PR. After this change llvm emits usable sframe sections that can be linked with the gnu linker. There are a few remaining cfi directives to handle before they are generally usable, however. The output isn't identical with gnu-gas in every case (this code produces fewer identical FREs in a row than gas), but I'm reasonably sure that they are correct regardless. There are even more size optimizations that can be done later. Also, while working on the tests, I found a few bugs in older portions and cleaned those up. This is a fairly big commit, but I'm not sure how to make it smaller.
11 daysRevert "[SFrames] Emit and relax FREs (#158154)" (#159436)Sterling-Augustine1-24/+0
Breaks some buildbots This reverts commit c9285166214db4236f26312f68bba91f6437bd6f.
11 days[SFrames] Emit and relax FREs (#158154)Sterling-Augustine1-0/+24
This PR emits and relaxes the FREs generated in the previous PR. After this change llvm emits usable sframe sections that can be linked with the gnu linker. There are a few remaining cfi directives to handle before they are generally usable, however. The output isn't identical with gnu-gas in every case (this code produces fewer identical FREs in a row than gas), but I'm reasonably sure that they are correct regardless. There are even more size optimizations that can be done later. Also, while working on the tests, I found a few bugs in older portions and cleaned those up. This is a fairly big commit, but I'm not sure how to make it smaller.
2025-08-23MCAssembler: Simplify relaxation of FT_Fill and FT_OrgFangrui Song1-15/+4
2025-08-23MCAssembler: Simplify fragment relaxationFangrui Song1-67/+50
* FT_Data: skip relaxFragment * Others: Call relaxFragment, which computes the old size, calls the relevant relaxXXX function, then compares the size.
2025-08-23MCAssembler: Simplify getSectionAddressSizeFangrui Song1-3/+2
The tail fragment must be of type FT_Data. Reduce a computeFragmentSize use.
2025-08-04MC: Evaluate .org during fragment relaxationFangrui Song1-0/+10
Similar to 742ecfc13e8aa34cfff2900e31838f657fcafe30 for MCFillFragment, ensure `.org` directives with expressions are re-evaluated during fragment relaxation, as their sizes may change. Continue iteration to prevent stale, incorrect sizes. While I knew MCOrgFragment likely needed to be re-evaluated at all, I did not have a motivation to add it;-) This fixes the root cause of https://github.com/ClangBuiltLinux/linux/issues/2116 (writeSectionData assertion failure when building the Linux kernel for arm64) The issue cannot be reliably replicated. The specific test case would not replicate if any of the following condition was not satisfied: * .org was not re-evaluated. Fixed by this commit. * clang -cc1as has a redundant `initSections` call, leading to a redundant initial FT_Align fragment. llvm-mc -filetype=obj, lacking the redundant `initSections`, doesn't replicate. * faa931b717c02d57f0814caa9133219040e6a85b decreased sizeof(MCFragment). * f1aa6050bd90f8ec4273da55d362e23905ad3a81 added more fragments
2025-08-02MCAsmBackend::applyFixup: Change `Data` to indicate the relocated locationFangrui Song1-16/+19
`Data` now references the first byte of the fixup offset within the current fragment. MCAssembler::layout asserts that the fixup offset is within either the fixed-size content or the optional variable-size tail, as this is the most the generic code can validate without knowing the target-specific fixup size. Many backends applyFixup assert ``` assert(Offset + Size <= F.getSize() && "Invalid fixup offset!"); ``` This refactoring allows a subsequent change to move the fixed-size content outside of MCSection::ContentStorage, fixing the -fsanitize=pointer-overflow issue of #150846 Pull Request: https://github.com/llvm/llvm-project/pull/151724
2025-08-01MCAssembler: Split evaluateFixup to Number of fixups and Number of fixup ↵Fangrui Song1-3/+5
evaluations for relaxation The number of fixups is a more important metric, guiding the data structure optimization.
2025-07-26MC: Allocate initial fragment and define section symbol in changeSectionFangrui Song1-1/+0
Reland #150574 with a MCStreamer::changeSection change: In Mach-O, DWARF sections use Begin as a temporary label, requiring a label definition, unlike section symbols in other file formats. (Tested by dec978036ef1037753e7de5b78c978e71c49217b) --- 13a79bbfe583e1d8cc85d241b580907260065eb8 (2017) introduced fragment creation in MCContext for createELFSectionImpl, which was inappropriate. Fragments should only be created when using MCSteramer, not during `MCContext::get*Section` calls. `initMachOMCObjectFileInfo` defines multiple sections, some of which may not be used by the code generator. This caused symbol names matching these sections to be incorrectly marked as undefined (see https://reviews.llvm.org/D55173). The fragment code was later replicated in other file formats, such as WebAssembly (see https://reviews.llvm.org/D46561), XCOFF, and GOFF. This patch fixes the problem by moving initial fragment allocation from MCContext::createSection to MCStreamer::changeSection. While MCContext still creates a section symbol, the symbol is not attached to the initial fragment. In addition, * Move `emitLabel`/`setFragment` from `switchSection*` and overridden changeSection to `MCObjectStreamer::changeSection` for consistency. * De-virtualize `switchSectionNoPrint`. * test/CodeGen/XCore/section-name.ll now passes. XCore doesn't support MCObjectStreamer. I don't think the MCAsmStreamer output behavior change matters. Pull Request: https://github.com/llvm/llvm-project/pull/150574
2025-07-25Revert "MC: Allocate initial fragment and define section symbol in ↵dyung1-0/+1
changeSection" (#150736) Reverts llvm/llvm-project#150574 This is causing a test failure on AArch64 MacOS bots: https://lab.llvm.org/buildbot/#/builders/190/builds/24187
2025-07-24MC: Allocate initial fragment and define section symbol in changeSectionFangrui Song1-1/+0
13a79bbfe583e1d8cc85d241b580907260065eb8 (2017) introduced fragment creation in MCContext for createELFSectionImpl, which was inappropriate. Fragments should only be created when using MCSteramer, not during `MCContext::get*Section` calls. `initMachOMCObjectFileInfo` defines multiple sections, some of which may not be used by the code generator. This caused symbol names matching these sections to be incorrectly marked as undefined (see https://reviews.llvm.org/D55173). The fragment code was later replicated in other file formats, such as WebAssembly (see https://reviews.llvm.org/D46561), XCOFF, and GOFF. This patch fixes the problem by moving initial fragment allocation from MCContext::createSection to MCStreamer::changeSection. While MCContext still creates a section symbol, the symbol is not attached to the initial fragment. In addition, move `emitLabel`/`setFragment` from `switchSection*` and overridden changeSection to `MCObjectStreamer::changeSection` for consistency. * test/CodeGen/XCore/section-name.ll now passes. XCore doesn't support MCObjectStreamer. I don't think the MCAsmStreamer output behavior change matters. Pull Request: https://github.com/llvm/llvm-project/pull/150574
2025-07-23[llvm] Remove unused includes (NFC) (#150265)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-07-20MCAssembler: Fix ubsan "addition of unsigned offset to" for linker ↵Fangrui Song1-4/+4
relaxation targets after #149465 Similar to 13549fd90af45d2200159cac14a12cf01db56aa1
2025-07-20MCFragment: Remove setContents/setFixupsFangrui Song1-4/+4
Make the fixed-size part of MCFragment append-only to support allocating content as trailing data. Update CodeView callers to use setVarContents instead of setContents. Remove unused setFixups.
2025-07-20MC: Fix fragment-in-BSS checkFangrui Song1-5/+27
* Handle non-zero fill values for `.fill` and `.org` directives. * Restore the fragment type check (5ee34ff1e5cc952116f0da943ddaeb1a71db2940 removed a reachable `llvm_unreachable`) to detect unintended API usage. Remove virtual functions `getVirtualSectionKind` (added in https://reviews.llvm.org/D78138) as they are unnecessary in diagnostics. The a.out object file format has the BSS concept, which has been inherited by COFF, XCOFF, Mach-O, and ELF object file formats. Pull Request: https://github.com/llvm/llvm-project/pull/149721
2025-07-20MC: Rename isVirtualSection to isBssSectionFangrui Song1-2/+2
The term BSS (Block Started by Symbol) is a standard, widely recognized term, available in the a.out object file format and adopted by formats like COFF, XCOFF, Mach-O (called S_ZEROFILL while `__bss` is also used), and ELF. To avoid introducing unfamiliar terms, we should use isBSSSection instead of isVirtualSection.
2025-07-20MC: Refactor FT_Align fragments when linker relaxation is enabledFangrui Song1-64/+62
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-72/+66
Follow-up to #148544 Pull Request: https://github.com/llvm/llvm-project/pull/149030
2025-07-20MC: Optimize emitInstruction and simplify fragment-in-BSS checkFangrui Song1-30/+11
Move the FT_Relaxable-in-BSS check from frequently-called MCObjectStreamer::emitInstruction to MCAssembler::writeSectionData, along with existing checks for other fragment types. For the uncommon diagnostics, losing the location information is acceptable.
2025-07-19MC: Replace FT_PseudoProbe with FT_LEBFangrui Song1-21/+1
The fragment type introduced by https://reviews.llvm.org/D91878 is unnecessary and can be replaced with FT_LEB.
2025-07-17MCAssembler: Modify Contents when VarFixups is not emptyFangrui Song1-7/+11
When there is no VarFixup, VarContentStart is zero. `slice(F.VarContentStart - Contents.size(), F.getSize())` might lead to "runtime error: addition of unsigned offset to" in ubsan builds after #148544
2025-07-17MC: Rework .reloc directive and fix the offset when it evaluates to a constantFangrui Song1-0/+25
* Fix `.reloc constant` to mean section_symbol+constant instead of .+constant . The initial .reloc support from MIPS incorrectly interpreted the offset. * Delay the evaluation of the offset expression after MCAssembler::layout, deleting a lot of code working with MCFragment. * Delete many FIXME from https://reviews.llvm.org/D79625 * Some lld/ELF/Arch/LoongArch.cpp relaxation tests rely on .reloc ., R_LARCH_ALIGN generating ALIGN relocations at specific location. Sort the relocations.
2025-07-15MCFragment: Remove MCDataFragment/MCRelaxableFragment type aliasesFangrui Song1-2/+1
Follow-up to #148544
2025-07-15MC: Restructure MCFragment as a fixed part and a variable tailFangrui Song1-54/+62
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-15MC: Remove bundle alignment modeFangrui Song1-128/+0
The being-removed PNaCl has a Software Fault Isolation mechanism, which requires that certain instructions and groups of instructions do not cross a bundle boundary. When `.bundle_align_mode` is in effect, each instruction is placed in its own fragment, allowing flexible NOP padding. This feature has significantly complicated our refactoring of MCStreamer and MCFragment, leading to considerable effort spent untangling it (including flushPendingLabels (75006466296ed4b0f845cbbec4bf77c21de43b40), MCAssembler iteration improvement, and recent MCFragment refactoring). * Make MCObjectStreamer::emitInstToData non-virtual and delete MCELFStreamer::emitInstTodata * Delete MCELFStreamer::emitValueImpl and emitValueToAlignment Minor instructions:u decrease for both -O0 -g and -O3 builds https://llvm-compile-time-tracker.com/compare.php?from=c06d3a7b728293cbc53ff91239d6cd87c0982ffb&to=9b078c7f228bc5b6cdbfe839f751c9407f8aec3e&stat=instructions:u Pull Request: https://github.com/llvm/llvm-project/pull/148781
2025-07-13MCAlignFragment: Rename fields and use uint8_t FillLenFangrui Song1-18/+13
* Rename the vague `Value` to `Fill`. * FillLen is at most 8. Making the field smaller to facilitate encoding MCAlignFragment as a MCFragment union member. * Replace an unreachable report_fatal_error with assert.
2025-07-08MC: Store MCRelaxableFragment MCInst out-of-lineFangrui Song1-1/+4
Follow-up to #146307 Moved MCInst storage to MCSection, enabling trivial ~MCRelaxableFragment and eliminating the need for a fragment walk in ~MCSection. Updated MCRelaxableFragment::getInst to construct an MCInst on demand. Modified MCAssembler::relaxInstruction's mayNeedRelaxation to accept opcode and operands instead of an MCInst, avoiding redundant MCInst creation. Note that MCObjectStreamer::emitInstructionImpl calls mayNeedRelaxation before determining the target fragment for the MCInst. Unfortunately, we also have to encode `MCInst::Flags` to support the EVEX prefix, e.g. `{evex} xorw $foo, %ax` There is a small decrease in max-rss (stage1-ReleaseLTO-g (link only)) with negligible instructions:u change. https://llvm-compile-time-tracker.com/compare.php?from=0b533f2d9f0551aaffb13dcac8e0fd0a952185b5&to=f26b57f33bc7ccae749a57dfc841de7ce2acc2ef&stat=max-rss&linkStats=on Next: Enable MCFragment to store fixed-size data (was MCDataFragment's job) and optional Opcode/Operands data (was MCRelaxableFragment's job), and delete MCDataFragment/MCRelaxableFragment. This will allow re-encoding of Data+Relax+Data+Relax sequences as Frag+Frag. The saving should outweigh the downside of larger MCFragment. Pull Request: https://github.com/llvm/llvm-project/pull/147229
2025-07-06MCAssembler: Merge fragmentNeedsRelaxation into relaxInstructionFangrui Song1-17/+7
2025-07-05MC: Eliminate redundant fragment relaxationFangrui Song1-10/+16
The relaxOnce function now returns the index of the last modified section, allowing subsequent calls to skip already stable sections. This optimization can often save redundant iteration for trailing .debug_ sections, leading to minor instructions:u decrease. https://llvm-compile-time-tracker.com/compare.php?from=aec88832df5e8c1dcbe259a6cb3d82d44b89ff23&to=8012fb16eff93cba48e5f08166762c5333bd1d42&stat=instructions:u
2025-07-05MC: Simplify fragment code. NFCFangrui Song1-59/+23
2025-07-05MC: Remove llvm/MC/MCFixupKindInfo.hFangrui Song1-1/+0
The file used to define `MCFixupKindInfo`, a simple structure, which is now in MCAsmBackend.h.
2025-07-05MC: Sink FKF_IsAlignedDownTo32Bits to needed targetsFangrui Song1-15/+3
Utilize the generalized MCAsmBackend::evaluateFixup hook. This reduces overhead for other targets (e.g., x86). Now MCAsmBackend::getFixupKindInfo is only used by MCAsmStreamer -show-encoding in the generic code.
2025-07-05MC: Generalize evaluateTargetFixupFangrui Song1-2/+2
Generalize evaluateTargetFixup to be called by all targets, making FKF_IsTarget unneeded. Next: Update targets that use FKF_IsAlignedDownTo32Bits to define `evaluateFixup` and remove FKF_IsAlignedDownTo32Bits from the generic code.
2025-07-04MCFixup: Remove FKF_IsPCRelFangrui Song1-3/+0
PC-relative fixups compute their values as `sym_a - current_location + offset` (S - P + A). Now that targets have set PCRel at fixup creation time, we can remove some overhead from MCAssembler::evaluateFixup.
2025-07-04SPARC: Remove unneeded MCFixupKindInfo::FKF_IsPCRelFangrui Song1-5/+5
SPARC now sets PCRel at fixup creation and no longer needs to the MCAssembler::evaluateFixup workaround that checks MCFixupKindInfo::FKF_IsPCRel.
2025-07-04MCFixup: Improve location accuracy and remove MCFixup::LocFangrui Song1-0/+6
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
2025-07-03MCAssembler: Optimize PCRel fixupsFangrui Song1-3/+5
* MCAssembler::evaluateFixup sets MCFixup::PCRel. * ELFObjectWriter retrieves the bit from the MCFixup argument.
2025-07-02MCAsmBackend: Merge addReloc into applyFixup (#146820)Fangrui Song1-1/+0
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.
2025-07-02MCAssembler: Simplify fixup handlingFangrui Song1-63/+14
2025-07-01MCAssembler: Consistently place MCFragment parameter before MCFixupFangrui Song1-14/+14
... to be consistent with other places, e.g. `recordRelocation`. While here, use references instead of non-null pointers.
2025-07-01MC: Store fragment content and fixups out-of-lineFangrui Song1-31/+33
Moved `Contents` and `Fixups` SmallVector storage to MCSection, enabling trivial destructors for most fragment subclasses and eliminating the need for MCFragment::destroy in ~MCSection. For appending content to the current section, use getContentsForAppending. During assembler relaxation, prefer setContents/setFixups, which may involve copying and reduce the benefits of https://reviews.llvm.org/D145791. Moving only Contents out-of-line caused a slight performance regression (Alexis Engelke's 2024 prototype). By also moving Fragments out-of-line, fragment destructors become trivial, resulting in neglgible instructions:u increase for "stage2-O0-g" and [large max-rss decrease](https://llvm-compile-time-tracker.com/compare.php?from=84e82746c3ff63ec23a8b85e9efd4f7fccf92590&to=555a28c0b2f8250a9cf86fd267a04b0460283e15&stat=max-rss&linkStats=on) for the "stage1-ReleaseLTO-g (link only)" benchmark. ( An older version using fewer inline functions: https://llvm-compile-time-tracker.com/compare.php?from=bb982e733cfcda7e4cfb0583544f68af65211ed1&to=f12d55f97c47717d438951ecddecf8ebd28c296b&linkStats=on ) Now using plain SmallVector in MCSection for storage, with potential for future allocator optimizations, such as allocating `Contents` as the trailing object of MCDataFragment. (GNU Assembler uses gnulib's obstack for fragment management.) Co-authored-by: Alexis Engelke <engelke@in.tum.de> Pull Request: https://github.com/llvm/llvm-project/pull/146307
2025-06-30MC: Merge MCFragment.h into MCSection.hFangrui Song1-1/+0
... 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
2025-06-29MC: Enhance mc-dump outputFangrui Song1-4/+13
* 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.
2025-06-28MC: Remove post-relaxation and Symbol printing from mc-dump outputFangrui Song1-19/+0
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.
2025-06-28MC: Make mc-dump output compactFangrui Song1-10/+6
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.
2025-06-27MC: Reduce MCSymbolRefExpr::VK_None usesFangrui Song1-1/+1
2025-06-02[MC] Relax MCFillFragment and compute fragment offsets eagerlyFangrui Song1-38/+56
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.
2025-06-01MC: Clear some members in resetFangrui Song1-0/+2
2025-06-01MCAssembler: Postpone errors in layout iterationFangrui Song1-5/+20
.org and .fill errors reported in a layout iteration might go away in the final layout. Related to #100283
generated by cgit v1.1 at 2025-09-29 02:02:29 +0000