They now contain the fragments. If we don't call the destructors the
fragments leak.
Found by an asan bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238161 91177308-0d34-0410-b5e6-96231b3b80d8
Normally an ELF .o has two string tables, one for symbols, one for section
names.
With the scheme of naming sections like ".text.foo" where foo is a symbol,
there is a big potential saving in using a single one.
Building llvm+clang+lld with master and with this patch the results were:
master: 193,267,008 bytes
patch: 186,107,952 bytes
master non unique section names: 183,260,192 bytes
patch non unique section names: 183,118,632 bytes
So using non usique saves 10,006,816 bytes, and the patch saves 7,159,056 while
still using distinct names for the sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238073 91177308-0d34-0410-b5e6-96231b3b80d8
Shave a pointer off of `MCSymbolName` by storing `StringMapEntry<bool>*`
instead of `StringRef`. This brings `sizeof(MCSymbol)` down to 64 on
64-bit platforms, a nice round number. My profile showed memory
dropping from 914 MB down to 908 MB, roughly 0.7%. Other than memory
usage, no functionality change here.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238005 91177308-0d34-0410-b5e6-96231b3b80d8
Lift `MCSymbolData::Index` up a level to `MCSymbol`, as preparation for
packing it into the bitfield in `MCSymbol`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238001 91177308-0d34-0410-b5e6-96231b3b80d8
This starts merging MCSection and MCSectionData.
There are a few issues with the current split between MCSection and
MCSectionData.
* It optimizes the the not as important case. We want the production
of .o files to be really fast, but the split puts the information used
for .o emission in a separate data structure.
* The ELF/COFF/MachO hierarchy is not represented in MCSectionData,
leading to some ad-hoc ways to represent the various flags.
* It makes it harder to remember where each item is.
The attached patch starts merging the two by moving the alignment from
MCSectionData to MCSection.
Most of the patch is actually just dropping 'const', since
MCSectionData is mutable, but MCSection was not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237936 91177308-0d34-0410-b5e6-96231b3b80d8
Create a low-overhead path for `EmitLabelDifference()` that emits a
emits an absolute number when (1) the output is an object stream and (2)
the two symbols are in the same data fragment.
This drops memory usage on Mach-O from 975 MB down to 919 MB (5.8%).
The only call is when `!doesDwarfUseRelocationsAcrossSections()` --
i.e., on Mach-O -- since otherwise an absolute offset from the start of
the section needs a relocation. (`EmitLabelDifference()` is cheaper on
ELF anyway, since it creates 1 fewer temp symbol, and it gets called far
less often. It's not clear to me if this is even a bottleneck there.)
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237876 91177308-0d34-0410-b5e6-96231b3b80d8
Finally remove the `MCSymbolData::Symbol` pointer. It was still being
used to track whether `MCSymbolData` had been initialized, but this is
better tracked by the bitfield in `MCSymbol`.
The only caller of `MCSymbolData::initialize()` was `MCAssembler`, which
(other than `Symbol`) passed in all-0 values. Replace all that
indirection with a default constructor.
The main point is a cleanup (and there's more cleanup to do), but there
are also some small memory savings. I measured ~989 MB down to ~975 MB,
cutting a little over 1% off the top of `llc`.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237873 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the last use of `MCSymbolData::getSymbol()`. There's some
*really* hairy stuff going on in `MachObjectWriter::WriteNList()` that I
want to come back to. In particular, it updates `Symbol` to point at
its aliasee (if any), but leaves `Data` behind, and it's not clear
whether everything makes sense there.
For now I've left the logic unchanged by adding `OrigSymbol` and moving
the FIXME from r237750 up a bit higher. I've filed PR23598 to track
looking into this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237867 91177308-0d34-0410-b5e6-96231b3b80d8
Remove most remaining calls to `MCSymbolData::getSymbol()`, instead
using the already available `MCSymbol` directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237829 91177308-0d34-0410-b5e6-96231b3b80d8
This code appends the filename to the directory then looks that up in a StringMap. We should be using the existing Twine::toStringRef method instead of Twine::str() as most times we'll succeed in the lookup.
Its possible that we should also consider allowing StringMap to lookup a key using a Twine in addition to a StringRef but that would complicate the code with little known benefit above and beyond this change.
This saves 170k temporary allocations when running llc on the verify_use_list_order bitcode with debug info for x86.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237823 91177308-0d34-0410-b5e6-96231b3b80d8
r237490 accidentally dropped MCSymbolData from the MCAssembler dump.
Add it back underneath the MCSymbol dump. Remove the MCSymbol dump from
MCSymbolData, since this would cause an infinite co-recursion, and
besides, that back pointer is going away.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237807 91177308-0d34-0410-b5e6-96231b3b80d8
Replace uses of `MCSymbolData` with `MCSymbol` where both are needed, so
we can remove the backpointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237799 91177308-0d34-0410-b5e6-96231b3b80d8
Transition one API from `MCSymbolData` to `MCSymbol`. The function
needs both, and the backpointer from `MCSymbolData` to `MCSymbol` is
going away.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237498 91177308-0d34-0410-b5e6-96231b3b80d8
