This causes errors like:
ld: error: blah.o: requires dynamic R_X86_64_PC32 reloc against '' which
may overflow at runtime; recompile with -fPIC
blah.cc:function f(): error: undefined reference to ''
blah.o:g(): error: undefined reference to ''
I have not yet come up with an appropriate reproduction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240394 91177308-0d34-0410-b5e6-96231b3b80d8
Now that pr23900 is fixed, we can bring it back with no changes.
Original message:
Make all temporary symbols unnamed.
What this does is make all symbols that would otherwise start with a .L
(or L on MachO) unnamed.
Some of these symbols still show up in the symbol table, but we can just
make them unnamed.
In order to make sure we produce identical results when going thought assembly,
all .L (not just the compiler produced ones), are now unnamed.
Running llc on llvm-as.opt.bc, the peak memory usage goes from 208.24MB to
205.57MB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240302 91177308-0d34-0410-b5e6-96231b3b80d8
What this does is make all symbols that would otherwise start with a .L
(or L on MachO) unnamed.
Some of these symbols still show up in the symbol table, but we can just
make them unnamed.
In order to make sure we produce identical results when going thought assembly,
all .L (not just the compiler produced ones), are now unnamed.
Running llc on llvm-as.opt.bc, the peak memory usage goes from 208.24MB to
205.57MB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240130 91177308-0d34-0410-b5e6-96231b3b80d8
Directional labels can show up in symbol tables (and we have a llvm-mc test for
that). Given that, we need to make sure they are named.
With that out of the way, use setUseNamesOnTempLabels in llvm-mc so that it
too benefits from the memory saving.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239914 91177308-0d34-0410-b5e6-96231b3b80d8
Similarly to User which allocates a number of Use's prior to the this pointer,
allocate space for the Name* for MCSymbol only when we need a name.
Given that an MCSymbol is 48-bytes on 64-bit systems, this saves a decent % of space.
Given the verify_uselistorder test case with debug info and llc, 50k symbols have names
out of 700k so this optimises for the common case of temporary unnamed symbols.
Reviewed by David Blaikie.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239423 91177308-0d34-0410-b5e6-96231b3b80d8
Some temporary symbols are created by MC itself. These symbols are never used
for lookup and are never included in the object symbol table, so we can
avoid creating a name for them.
Other temporaries are created by CodeGen or by the user by explicitly asking
for a name starting with .L (or L on MachO).
These temporaries behave like regular symbols, we just try to avoid including
them in the object symbol table, but sometimes they end up there:
const char *foo() {
return "abc" + 3;
}
will have a relocation pointing to a .L symbol.
It just so happens that almost all MC created temporary has the AlwaysAddSuffix
option and CodeGen/user created ones don't.
One interesting future optimization would be to use unnamed symbols for
all temporaries, but that would require use an st_name of 0 or
having the object writer create the names if a symbol does end up in the
symbol table.
No testcase since this just avoid creating a few extra names for MC created
temporaries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238887 91177308-0d34-0410-b5e6-96231b3b80d8
This create a MCSymbolELF class and moves SymbolSize since only ELF
needs a size expression.
This reduces the size of MCSymbol from 56 to 48 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238801 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
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
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.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236642 91177308-0d34-0410-b5e6-96231b3b80d8
Currently symbol names are printed in quotes if it contains something
outside of the arbitrary set of characters that isAcceptableChar tests
for. On somem targets, it is never OK to print a symbol name in quotes
so allow targets to opt out of this behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235670 91177308-0d34-0410-b5e6-96231b3b80d8
Just store the section in MCSectionELF. This avoids multiple hash lookups.
This will also be used by ARM_EXIDX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234139 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the compiler/assembly programmer to switch back to a
section. This in turn fixes the bootstrap failure on powerpc (tested
on gcc110) without changing the ppc codegen at all.
I will try to cleanup the various getELFSection overloads in a followup patch.
Just using a default argument now would lead to ambiguities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234099 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us catch exceptions in simple cases.
N.B. Things that do not work include (but are not limited to):
- Throwing from within a catch handler.
- Catching an object with a named catch parameter.
- 'CatchHigh' is fictitious, we aren't sure of its purpose.
- We aren't entirely efficient with regards to the number of EH states
that we generate.
- IP-to-State tables are sensitive to the order of emission.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233767 91177308-0d34-0410-b5e6-96231b3b80d8
These sections are never looked up and we know when have to create them. Use
that to save adding them to the regular map and avoid a symbol->string->symbol
conversion for the group symbol.
This also makes the implementation independent of the details of how unique
sections are implemented.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233539 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch code wanting to create temporary labels for a given entity
(function, cu, exception range, etc) had to keep its own counter to have stable
symbol names.
createTempSymbol would still add a suffix to make sure a new symbol was always
returned, but it kept a single counter. Because of that, if we were to use
just createTempSymbol("cu_begin"), the label could change from cu_begin42 to
cu_begin43 because some other code started using temporary labels.
Simplify this by just keeping one counter per prefix and removing the various
specialized counters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232535 91177308-0d34-0410-b5e6-96231b3b80d8
Same as MakeArgString in r232465, keep only LookupSymbol(Twine)
while making sure it handles the StringRef like cases efficiently
using twine::toStringRef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232517 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us pass the symbol to the constructor and avoid the mutable field.
This also opens the way for outputting the symbol only when needed, instead
of outputting them at the start of the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231859 91177308-0d34-0410-b5e6-96231b3b80d8
This removes a bit of duplicated code and more importantly, remembers the
labels so that they don't need to be looked up by name.
This in turn allows for any name to be used and avoids a crash if the name
we wanted was already taken.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230772 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for having multiple sections with the same name and comdat.
Using this in combination with -ffunction-sections allows LLVM to output a .o
file with mulitple sections named .text. This saves space by avoiding long
unique names of the form .text.<C++ mangled name>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229541 91177308-0d34-0410-b5e6-96231b3b80d8
regressions for LLDB on Linux. Rafael indicated on lldb-dev that we
should just go ahead and revert these but that he wasn't at a computer.
The patches backed out are as follows:
r228980: Add support for having multiple sections with the name and ...
r228889: Invert the section relocation map.
r228888: Use the existing SymbolTableIndex intsead of doing a lookup.
r228886: Create the Section -> Rel Section map when it is first needed.
These patches look pretty nice to me, so hoping its not too hard to get
them re-instated. =D
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229080 91177308-0d34-0410-b5e6-96231b3b80d8
Using this in combination with -ffunction-sections allows LLVM to output a .o
file with mulitple sections named .text. This saves space by avoiding long
unique names of the form .text.<C++ mangled name>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228980 91177308-0d34-0410-b5e6-96231b3b80d8
Any code creating an MCSectionELF knows ELF and already provides the flags.
SectionKind is an abstraction used by common code that uses a plain
MCSection.
Use the flags to compute the SectionKind. This removes a lot of
guessing and boilerplate from the MCSectionELF construction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227476 91177308-0d34-0410-b5e6-96231b3b80d8
These intrinsics allow multiple functions to share a single stack
allocation from one function's call frame. The function with the
allocation may only perform one allocation, and it must be in the entry
block.
Functions accessing the allocation call llvm.recoverframeallocation with
the function whose frame they are accessing and a frame pointer from an
active call frame of that function.
These intrinsics are very difficult to inline correctly, so the
intention is that they be introduced rarely, or at least very late
during EH preparation.
Reviewers: echristo, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D6493
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225746 91177308-0d34-0410-b5e6-96231b3b80d8
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222319 91177308-0d34-0410-b5e6-96231b3b80d8
The only difference from r219829 is using
getOrCreateSectionSymbol(*ELFSec)
instead of
GetOrCreateSymbol(ELFSec->getSectionName())
in ELFObjectWriter which causes us to use the correct section symbol even if
we have multiple sections with the same name.
Original messages:
r219829:
Correctly handle references to section symbols.
When processing assembly like
.long .text
we were creating a new undefined symbol .text. GAS on the other hand would
handle that as a reference to the .text section.
This patch implements that by creating the section symbols earlier so that
they are visible during asm parsing.
The patch also updates llvm-readobj to print the symbol number in the relocation
dump so that the test can differentiate between two sections with the same name.
r219835:
Allow forward references to section symbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220021 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Correctly handle references to section symbols."
Revert "Allow forward references to section symbols."
Rui found a regression I am debugging.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220010 91177308-0d34-0410-b5e6-96231b3b80d8
