| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
I missed this one when first unifying how we handle begin and end symbols.
llvm-svn: 237912
|
|
|
|
| |
llvm-svn: 237909
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
llvm-svn: 237876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
llvm-svn: 237873
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 237867
|
|
|
|
|
|
|
| |
We aren't yet emitting the LSDA yet, so this will still fail to
assemble.
llvm-svn: 237852
|
|
|
|
|
|
|
| |
Remove most remaining calls to `MCSymbolData::getSymbol()`, instead
using the already available `MCSymbol` directly.
llvm-svn: 237829
|
|
|
|
|
|
| |
Move APIs over from `MCSymbolData` to `MCSymbol`.
llvm-svn: 237826
|
|
|
|
|
|
|
|
|
|
|
|
| |
lookup. NFC.
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.
llvm-svn: 237823
|
|
|
|
|
|
| |
Switch from MCSymbolData to MCSymbol in LocalCommon.
llvm-svn: 237816
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 237807
|
|
|
|
|
|
| |
Use `MCSymbol` over `MCSymbolData` where both are needed.
llvm-svn: 237803
|
|
|
|
|
|
|
| |
Replace uses of `MCSymbolData` with `MCSymbol` where both are needed, so
we can remove the backpointer.
llvm-svn: 237799
|
|
|
|
|
|
| |
Continue to prefer `MCSymbol` when we need both.
llvm-svn: 237798
|
|
|
|
|
|
| |
Stop using MCSymbolData where we also need MCSymbol.
llvm-svn: 237770
|
|
|
|
|
|
|
| |
Pass through an `MCSymbol` instead of an `MCSymbolData` so we can get
rid of the back pointer.
llvm-svn: 237750
|
|
|
|
|
|
|
| |
Continue to canonicalize on MCSymbol instead of MCSymbolData when both
are needed.
llvm-svn: 237749
|
|
|
|
| |
llvm-svn: 237595
|
|
|
|
|
|
|
| |
The naming was a mish-mash of old and new style. Update to be consistent
with the new. NFC.
llvm-svn: 237594
|
|
|
|
|
|
| |
Switch from `MCSymbolData` to `MCSymbol`.
llvm-svn: 237502
|
|
|
|
|
|
|
|
| |
Transition one API from `MCSymbolData` to `MCSymbol`. The function
needs both, and the backpointer from `MCSymbolData` to `MCSymbol` is
going away.
llvm-svn: 237498
|
|
|
|
|
|
|
| |
Change `MCFragment::Atom` from an `MCSymbolData` to an `MCSymbol`,
moving in the direction of removing the back-pointer.
llvm-svn: 237497
|
|
|
|
|
|
|
|
| |
Instead of storing a list of the `MCSymbolData` in use, store the
`MCSymbol`s. Churning in the direction of removing the back pointer
from `MCSymbolData`.
llvm-svn: 237496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turn `MCSymbolData` into a field inside of `MCSymbol`. Keep all the old
API alive for now, so that consumers can be updated in a later commit.
This means we still temporarily need the back pointer from
`MCSymbolData` to `MCSymbol`, but I'll remove it in a follow-up.
This optimizes for object emission over assembly emission. By removing
the `DenseMap` in `MCAssembler`, llc memory usage drops from around 1040
MB to 1001 MB (3.8%).
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
llvm-svn: 237490
|
|
|
|
|
|
|
|
|
| |
Stop exposing the storage for `MCAssembler::Symbols`, and have
`MCAssembler` add symbols directly to its list instead of using a hook
in `MCSymbolData`. This opens up room for a follow-up commit to switch
from a linked list to a vector.
llvm-svn: 237486
|
|
|
|
| |
llvm-svn: 237483
|
|
|
|
| |
llvm-svn: 237481
|
|
|
|
|
|
|
|
|
|
| |
trimmed. NFC.
MCInstrDesc.h includes things like MCInst.h which i can now remove after this. That will be a future commit.
Reviewed by Jim Grosbach.
llvm-svn: 237478
|
|
|
|
|
|
| |
s/InitMCCodeGenInfo/initMCCodeGenInfo/
llvm-svn: 237471
|
|
|
|
|
|
| |
s/EncodeInstruction/encodeInstruction/
llvm-svn: 237469
|
|
|
|
|
|
| |
s/MCFixup::Create/MCFixup::create/
llvm-svn: 237468
|
|
|
|
| |
llvm-svn: 237408
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9692
llvm-svn: 237327
|
|
|
|
|
|
| |
MCOperand::Create*() methods renamed to MCOperand::create*().
llvm-svn: 237275
|
|
|
|
| |
llvm-svn: 237261
|
|
|
|
|
|
|
| |
The buildbots are still not satisfied.
MIPS and ARM are failing (even though at least MIPS was expected to pass).
llvm-svn: 237245
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
The first two times this was committed (r229831, r233055), it caused several buildbot failures.
At least some of the ARM and MIPS ones were due to gcc/binutils issues, and should now be fixed.
llvm-svn: 237234
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dwarf-4
The DWARF-4 specification added 2 new fields in the CIE header called
address_size and segment_size.
Create these 2 new fields when generating dwarf-4 CIE entries, print out
the new fields when dumping the CIE and update tests
Differential Revision: http://reviews.llvm.org/D9558
llvm-svn: 237145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't create names for temporary symbols when using an object streamer.
The names never make it to the output anyway. From the starting point
of r236629, my heap profile says this drops peak memory usage from 1100
MB to 1058 MB for CodeGen of `verify-uselistorder`, a savings of almost
4% on peak memory, and removes `StringMap<bool, BumpPtrAllocator...>`
from the profile entirely.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
llvm-svn: 236642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The object format can be set to something other than MachO, e.g.
to use ELF-on-Darwin for MCJIT. This already works on Windows, so
there's no reason it shouldn't on Darwin.
Reviewers: lhames, grosbach
Subscribers: rafael, grosbach, t.p.northover, llvm-commits
Differential Revision: http://reviews.llvm.org/D6185
llvm-svn: 236455
|
|
|
|
|
|
| |
hits this code path.
llvm-svn: 236348
|
|
|
|
| |
llvm-svn: 236275
|
|
|
|
|
|
|
|
|
|
| |
This is actually fairly simple in the current code layout: Check if we should
compress just before writing out and everything else just works.
This removes the last case in which the object writer was creating a
fragment.
llvm-svn: 236267
|
|
|
|
| |
llvm-svn: 236261
|
|
|
|
| |
llvm-svn: 236260
|
|
|
|
|
|
| |
Add string to the section header string table as we add sections.
llvm-svn: 236257
|
|
|
|
|
|
|
| |
This avoids passing it around and lets us build a small helper to add
a section to the table.
llvm-svn: 236255
|
|
|
|
| |
llvm-svn: 236253
|
|
|
|
|
|
|
|
|
|
|
| |
During ELF writing, there is no need to further relax the sections, so we
should not be creating fragments. This patch avoids doing so in all cases
but debug section compression (that is next).
Also, the ELF format is fairly simple to write. We can do a single pass over
the sections to write them out and compute the section header table.
llvm-svn: 236235
|
|
|
|
|
|
| |
warning; NFC.
llvm-svn: 236234
|