| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
... 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
|
|
Similar to b65760bc7fcdee8179bf1e57fce3786737528dd8 for ELF.
|
|
|
|
|
|
* Remove the MCAssembler * argument. Change subclasses to use MCAssembler *MCObjectWriter::Asm.
* Remove pure specifier and add an empty implementation
* Change MCFragment * to MCFragment &
|
|
|
|
|
|
We will increase the use of raw relocation types and eliminate fixup
kinds that correspond to relocation types. The getFixupKindInfo
functions will return an rvalue instead. Let's update the return type
from a const reference to a value type.
|
|
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
AArch64MachObjectWriter does this better by using `getSymbolAddress` in
its `recordRelocation` function.
This commit:
1. Moves the `SectionAddrMap` logic into the Mach-O code, removing the
workaround.
2. Fixes a bug in `MachObjectWriter::getSymbolAddress` where it failed
to subtract the `SymB` value. This bug has been present since commit
b200f93125eb019d69c220fa447faea4f5d4eb8a (2011).
|
|
We will replace the MCSymbolRefExpr member in MCValue with MCSymbol.
This change reduces dependence on MCSymbolRefExpr.
|
|
We will replace the MCSymbolRefExpr member in MCValue with MCSymbol.
This change reduces dependence on MCSymbolRefExpr.
|
|
MCValue::SymB is a MCSymbolRefExpr *, which might become MCSymbol * in
the future. Simplify some code that uses MCValue::SymB.
|
|
Follow-up to d6fbffa23c84e622735b3e880fd800985c1c0072 . This commit
updates all call sites and removes the argument from the function.
|
|
Identified with misc-include-cleaner.
|
|
In a mach_header, the cpusubtype is a 32-bit field, but it's split in 2
subfields:
- the low 24 bits containing the cpu subtype proper, (e.g.,
CPU_SUBTYPE_ARM64E 2)
- the high 8 bits containing a capability field used for additional
feature flags.
Notably, it's only the subtype subfield that participates in fat file
slice discrimination: the caps are ignored.
arm64e uses the caps subfield to encode a ptrauth ABI version:
- 0x80 (CPU_SUBTYPE_PTRAUTH_ABI) denotes a versioned binary
- 0x40 denotes a kernel-ABI binary
- 0x00-0x0F holds the ptrauth ABI version
This teaches the basic obj tools to decode that (or ignore it when
unneeded).
It also teaches the MachO writer to default to emitting versioned
binaries, but with a version of 0 (and without the kernel ABI flag).
Modern arm64e requires versioned binaries: a binary with 0x00 caps in
cpusubtype is now rejected by the linker and everything after. We can
live without the sophistication of specifying the version and kernel ABI
for now.
Co-authored-by: Francis Visoiu Mistrih <francisvm@apple.com>
|
|
We could do the same to COFF once WinCOFFObjectWriter is cleaned up
(#100303).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The section offset field is only 32 bits; if the computed section offset
is larger, make sure we don't emit a corrupt object file.
|
|
size()
The pointers cannot be mutated even if the dereferenced MCSection can.
|
|
and make some cleanup.
|
|
|
|
|
|
|
|
This variable is similar to `Ordinal` but only used for Mach-O to place
zerofill sections ("virtual sections" in MC term) after non-zerofill ones.
Follow-up to 7840c0066837797cdeb62aab63044b964aa7f372.
Pull Request: https://github.com/llvm/llvm-project/pull/97474
|
|
|
|
MCAssembler
Continue the MCAsmLayout removal work started by 67957a45ee1ec42ae1671cdbfa0d73127346cc95.
|
|
Otherwise llvm/test/MC/MachO/empty-twice.ll might fail.
Fixes: 7840c0066837797cdeb62aab63044b964aa7f372 ("[MC] Move MCAsmLayout::SectionOrder to MachObjectWriter::SectionOrder")
|
|
Follow-up to 2c1fb411ce3aed148a278660d215e0f88ff9b9be.
SectionOrder is Mach-O specific to place zerofill sections after
non-zerofill sections in the object writer.
|
|
The MCAsmLayout::* forwarders added by
67957a45ee1ec42ae1671cdbfa0d73127346cc95 have all been removed.
|
|
|
|
|
|
MCObjectWriter::executePostLayoutBinding
|
|
MCObjectWriter::{writeObject,writeSectionData}
|
|
|
|
|
|
files
and devirtualize isSectionAtomizableBySymbols.
|
|
e3a20f57d927e422874a8e7730bb7590515b586d (2015) overloaded
isSymbolRefDifferenceFullyResolvedImpl with the IsPCRel parameter.
The overload without IsPCRel is only customized by Mach-O to
dsiable `.long L_var4 - L_var3` folding in
darwin-x86_64-diff-reloc-assign-2.s, but that seems unnecessary.
|
|
The code change from 91ea511436232c3b240d5f0a67a4639d7149dfdc (2011) can
now be removed.
|
|
|
|
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.
|
|
The workaround (relocation suppression) from
7b46bb8e327d45598eb794e14fc87e8c2a55f65e (2011) has been unneeded after
bfd0f01dd75f299bb521a2a31f270b3687be2cee (2014) removed
`if (!A_base) return false;` and `if (!B_base) return false;`
|
|
|
|
Differential Revision: https://reviews.llvm.org/D138653
|
