| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 238330
|
|
|
|
| |
llvm-svn: 238329
|
|
|
|
| |
llvm-svn: 238328
|
|
|
|
| |
llvm-svn: 238327
|
|
|
|
| |
llvm-svn: 238320
|
|
|
|
| |
llvm-svn: 238317
|
|
|
|
| |
llvm-svn: 238315
|
|
|
|
| |
llvm-svn: 238311
|
|
|
|
|
|
|
|
|
|
| |
.eh_frame to be read-only.
This broke the llvm-mips-linux builder and several of our out-of-tree builders.
Initial investigations show that the commit probably isn't the problem but
reverting anyway while I investigate.
llvm-svn: 238302
|
|
|
|
|
|
|
| |
This shouldn't happen, but it's nice not to abort when printing broken machine
functions.
llvm-svn: 238287
|
|
|
|
|
|
| |
There is now no SectionData to be created.
llvm-svn: 238208
|
|
|
|
|
|
| |
I will fix the name shortly.
llvm-svn: 238204
|
|
|
|
|
|
| |
A step towards merging MCSection and MCSectionData.
llvm-svn: 238203
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 several times this was committed (e.g. r229831, r233055), it caused several buildbot failures.
Apparently the reason for most failures was both clang and gcc's inability to deal with large numbers (> 10K) of bitset constructor calls in tablegen-generated initializers of instruction info tables.
This should now be fixed.
llvm-svn: 238192
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Following on from r209907 which made personality encodings indirect, do the
same for TType encodings. This fixes the case where a try/catch block needs
to generate references to, for example, std::exception in the
.gcc_except_table.
This commit uses DW_EH_PE_sdata8 for N64 as far as is possible at the moment.
However, it is possible to end up with DW_EH_PE_sdata4 when a TargetMachine is
not available. There's no risk of issues with inconsistency here since the
tables are self describing but it does mean there is a small chance of the
PC-relative offset being out of range for particularly large programs.
Reviewers: petarj
Reviewed By: petarj
Subscribers: srhines, joerg, tberghammer, llvm-commits
Differential Revision: http://reviews.llvm.org/D9669
llvm-svn: 238190
|
|
|
|
| |
llvm-svn: 238172
|
|
|
|
| |
llvm-svn: 238170
|
|
|
|
|
|
|
|
| |
Fixes the leaks when running llc.
Also found by an asan bot.
llvm-svn: 238167
|
|
|
|
| |
llvm-svn: 238165
|
|
|
|
| |
llvm-svn: 238163
|
|
|
|
|
|
| |
Another step in merging MCSectionData and MCSection.
llvm-svn: 238162
|
|
|
|
|
|
|
|
|
| |
They now contain the fragments. If we don't call the destructors the
fragments leak.
Found by an asan bot.
llvm-svn: 238161
|
|
|
|
|
|
| |
Part of the work to merge MCSectionData into MCSection.
llvm-svn: 238160
|
|
|
|
|
|
|
| |
This also changes MCAssembler to store a vector of MCSections instead of an
iplist of MCSectionData.
llvm-svn: 238159
|
|
|
|
|
|
| |
Another step in merging MCSectionData and MCSection.
llvm-svn: 238158
|
|
|
|
|
|
| |
This just reduces the noise from another patch.
llvm-svn: 238156
|
|
|
|
|
|
|
| |
Removing the logic from the constructor will make it easier to merge
MCSectionData and MCSection.
llvm-svn: 238155
|
|
|
|
| |
llvm-svn: 238150
|
|
|
|
| |
llvm-svn: 238143
|
|
|
|
| |
llvm-svn: 238142
|
|
|
|
| |
llvm-svn: 238141
|
|
|
|
| |
llvm-svn: 238139
|
|
|
|
|
|
| |
Part of the work to merge MCSectionData and MCSection.
llvm-svn: 238137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 238073
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
llvm-svn: 238005
|
|
|
|
|
|
|
| |
Lift `MCSymbolData::Index` up a level to `MCSymbol`, as preparation for
packing it into the bitfield in `MCSymbol`.
llvm-svn: 238001
|
|
|
|
| |
llvm-svn: 237956
|
|
|
|
|
|
|
| |
Now is is just its use of MCSymbolData that requires it to take a non const
MCAssembler.
llvm-svn: 237951
|
|
|
|
|
|
| |
It used to use an MCAssembler just to record the alignment of the sections.
llvm-svn: 237944
|
|
|
|
|
|
|
| |
It never creates sections, so it can use Asm.getSectionData instead of
Asm.getOrCreateSectionData.
llvm-svn: 237943
|
|
|
|
| |
llvm-svn: 237940
|
|
|
|
| |
llvm-svn: 237938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 237936
|
|
|
|
| |
llvm-svn: 237915
|
|
|
|
| |
llvm-svn: 237913
|
|
|
|
|
|
| |
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
|