This is still a really odd function. Most calls are in object format specific
contexts and should probably be replaced with a more direct query, but at least
now this is not too obnoxious to use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240777 91177308-0d34-0410-b5e6-96231b3b80d8
Replace the `std::vector<>` for `DIE::Children` with an intrusively
linked list. This is a strict memory improvement: it requires no
auxiliary storage, and reduces `sizeof(DIE)` by one pointer. It also
factors out the DIE-related malloc traffic.
This drops llc memory usage from 735 MB down to 718 MB, or ~2.3%.
(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@240736 91177308-0d34-0410-b5e6-96231b3b80d8
Change `DIE::Values` to a singly linked list, where each node is
allocated on a `BumpPtrAllocator`. In order to support `push_back()`,
the list is circular, and points at the tail element instead of the
head. I abstracted the core list logic out to `IntrusiveBackList` so
that it can be reused for `DIE::Children`, which also cares about
`push_back()`.
This drops llc memory usage from 799 MB down to 735 MB, about 8%.
(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@240733 91177308-0d34-0410-b5e6-96231b3b80d8
Split out code to patch up the `DW_AT_stmt_list` for the cloned DIE, and
reorganize it so that it doesn't depend on `DIE::values_begin()` and
`DIE::values_end()` (which I'm trying to kill off).
David Blaikie and I talked about adding a range-algorithm version of
`std::find_if()`, but the assertion *still* required getting at the end
iterator. IMO, a separate helper function with an early return is
easier to reason about here.
A follow-up commit that removes `DIE::setValue()` and mutates the
`DIEValue` directly is coming shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240701 91177308-0d34-0410-b5e6-96231b3b80d8
* Have it return a iterator_range.
* Remove the global function.
* Rename to getDynamicSymbolIterators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240644 91177308-0d34-0410-b5e6-96231b3b80d8
On ELF that was already the case since getting the size of a symbol
never fails.
On MachO and COFF we could fail trying to get the section of a symbol. But
we don't really need the section, just the section number to know if two
symbols are in the same section or not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240580 91177308-0d34-0410-b5e6-96231b3b80d8
It is perfectly possible for SHNDX to contain indexes that have the same value
as reserved st_shndx values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240544 91177308-0d34-0410-b5e6-96231b3b80d8
COFF and MachO only define symbol sizes for common symbols. Reflect that
in the class hierarchy by having a method for common symbols only in the base
and a general one in ELF.
This avoids the need of using a magic value for the size, which had a few
problems
* Most callers didn't check for it.
* The ones that did could not tell the magic value from a file actually having
that value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240529 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the -mcpu= option to llvm-rtdyld. With this option, one
can test relocations for different types of CPUs (e.g. Mips64r6).
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D10503
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240477 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
lto_codegen_set_should_embed_uselists is introduced in r235943 but not
added to lto.exports. Add to export list to expose the API.
Reviewers: dexonsmith
Subscribers: rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D10658
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240442 91177308-0d34-0410-b5e6-96231b3b80d8
Only common symbol on MachO and COFF have a size.
For COFF we already had a custom format.
For MachO, there is no native objdump and we were printing it as ELF. Now
we only print the sizes for symbols that actually have them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240422 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
That way llvm-objdump can rely on it without adding an extra dependency
on CodeGen.
This change duplicates the FaultKind enum and the code that serializes
it to a string. I could not figure out a way to get around this without
adding a new dependency to Object
Reviewers: rafael, ab
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10619
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240364 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: I don't think anyone is relying on this behavior for bootstrapping (because I don't think it works), but if you do need it, speak now or forever hold your peace.
Reviewers: chapuni, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10613
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240344 91177308-0d34-0410-b5e6-96231b3b80d8
The reason we need to search by name rather than by Triple::ArchType
is to handle subarchitecture correclty. There is no different ArchType
for the x86_64h architecture (it identifies itself as x86_64), or for
the various ARM subarches. The only way to get to the subarch slice
in an universal binary is to search by name.
This issue led to hard to debug and transient symbolication failures
in Asan tests (it mostly works, because the files are very similar).
This also affects the Profiling infrastucture as it is the other user
of that API.
Reviewers: samsonov, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10604
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240339 91177308-0d34-0410-b5e6-96231b3b80d8
There are 3 types of relocations on MachO
* Scattered
* Section based
* Symbol based
On ELF and COFF relocations are symbol based.
We were in the strange situation that we abstracted over two of them. This makes
section based relocations MachO only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240149 91177308-0d34-0410-b5e6-96231b3b80d8
In a relocation target can take 3 basic forms
* A r_value in scattered relocations.
* A symbol in external relocations.
* A section is non-external relocations.
Have the dump reflect that. With this change we go from
CHECK-NEXT: Extern: 0
CHECK-NEXT: Type: X86_64_RELOC_SUBTRACTOR (5)
CHECK-NEXT: Symbol: 0x2
CHECK-NEXT: Scattered: 0
To just
// CHECK-NEXT: Type: X86_64_RELOC_SUBTRACTOR (5)
// CHECK-NEXT: Section: __data (2)
Since the relocation is with a section, we print the seciton name and don't
need to say that it is not scattered or external.
Someone motivated can add further special cases for things like
ARM64_RELOC_ADDEND and ARM_RELOC_PAIR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240073 91177308-0d34-0410-b5e6-96231b3b80d8
The personality routine currently lives in the LandingPadInst.
This isn't desirable because:
- All LandingPadInsts in the same function must have the same
personality routine. This means that each LandingPadInst beyond the
first has an operand which produces no additional information.
- There is ongoing work to introduce EH IR constructs other than
LandingPadInst. Moving the personality routine off of any one
particular Instruction and onto the parent function seems a lot better
than have N different places a personality function can sneak onto an
exceptional function.
Differential Revision: http://reviews.llvm.org/D10429
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239940 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
Summary:
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10381
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239815 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar patches.
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
The first time this was committed it accidentally fixed an inconsistency in
triples in llvm-mc and this caused a failure. This inconsistency was fixed in
r239808.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239812 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
GetTarget() may modify TripleName without also updating TheTriple.
This can lead to situations where the MCObjectStreamer has a different triple
to the rest of LLVM.
This inconsistency caused sparc-little-endian.s to pass on Windows because most
of LLVM had sparcel-pc-win32 while MCObjectStreamer had "". I believe the same
kind of thing was also true of Darwin.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin, rafael
Differential Revision: http://reviews.llvm.org/D10450
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239808 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a build failure with `LLVM_ENABLE_MODULES` due to
`ProfileData::instr` conflicting with a function `instr()` in
`<curses.h>`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239793 91177308-0d34-0410-b5e6-96231b3b80d8
This commit connects the machine function analysis pass (which creates machine
functions) to the MIR parser, which will initialize the machine functions
with the state from the MIR file and reconstruct the machine IR.
This commit introduces a new interface called 'MachineFunctionInitializer',
which can be used to provide custom initialization for the machine functions.
This commit also introduces a new diagnostic class called
'DiagnosticInfoMIRParser' which is used for MIR parsing errors.
This commit modifies the default diagnostic handling in LLVMContext - now the
the diagnostics are printed directly into llvm::errs() so that the MIR parsing
errors can be printed with colours.
Reviewers: Justin Bogner
Differential Revision: http://reviews.llvm.org/D9928
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239753 91177308-0d34-0410-b5e6-96231b3b80d8
The plugin now save the bitcode before and after optimizations and the
.o that is passed to the linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239726 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar trivial patches.
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239721 91177308-0d34-0410-b5e6-96231b3b80d8
