PDBs can be extremely large. We're already mapping the entire
PDB into the process's address space, but to make matters worse
the blocks of the PDB are not arranged contiguously. So, when
we have something like an array or a string embedded into the
stream, we have to make a copy. Since it's convenient to use
traditional data structures to iterate and manipulate these
records, we need the memory to be contiguous.
As a result of this, we were using roughly twice as much memory
as the file size of the PDB, because every stream was copied
out and re-stitched together contiguously.
This patch addresses this by improving the MappedBlockStream
to allocate from a BumpPtrAllocator only when a read requires
a discontiguous read. Furthermore, it introduces some data
structures backed by a stream which can iterate over both
fixed and variable length records of a PDB. Since everything
is backed by a stream and not a buffer, we can read almost
everything from the PDB with zero copies.
Differential Revision: http://reviews.llvm.org/D20654
Reviewed By: ruiu
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270951 91177308-0d34-0410-b5e6-96231b3b80d8
StringError can be used to represent Errors that aren't recoverable based on
the error type, but that have a useful error message that can be reported to
the user or logged.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270948 91177308-0d34-0410-b5e6-96231b3b80d8
If every operands of a constant are mapping to themselves, and the
type does not change, we have an early exit as acknowledged in the
comment:
// Otherwise, we have some other constant to remap. Start by checking to see
// if all operands have an identity remapping.
However instead of checking for identity the code was checking if the
operands were mapped to the constant itself, which is rarely true.
As a consequence, the coverage report showed that the early exit was
never taken.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270944 91177308-0d34-0410-b5e6-96231b3b80d8
CriticalAntiDepBreaker was not correctly tracking defs of the high X86 byte
registers, leading to incorrect use of a busy register to break an
antidependence.
Fixes pr27681, and its duplicates pr27580, pr27804.
Differential Revision: http://reviews.llvm.org/D20456
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270935 91177308-0d34-0410-b5e6-96231b3b80d8
Condition might be simplified to a Constant, but it doesn't have to be
ConstantInt, so we should dyn_cast, instead of cast.
This fixes PR27886.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270924 91177308-0d34-0410-b5e6-96231b3b80d8
This patch builds upon r270776 and speeds up
LiveDebugValues::transferDebugValue() by adding an index that maps each
DebugVariable to its open VarLoc.
The transferDebugValue() function needs to close all open ranges for a
given DebugVariable. Iterating over the set bits of OpenRanges is
prohibitively slow in practice. I experimented with using the sorted map
of VarLocs in the UniqueVector to iterate only over the range of VarLocs
with a given DebugVariable, but the binary search turned out to be even
more expensive than just iterating over the set bits in OpenRanges.
Instead, this patch exploits the fact that there can only be one open
location for each DebugVariable and redundantly stores this location in a
DenseMap.
This patch brings the time spent in the LiveDebugValues pass down to an
almost neglectiable amount.
http://llvm.org/bugs/show_bug.cgi?id=26055http://reviews.llvm.org/D20636
rdar://problem/24091200
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270923 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: * docs/WritingAnLLVMBackend.rst: Makefiles are no longer used. The users should use CMakeLists.txt. In order to add the target, the TARGETS_TO_BUILD is replaced with LLVM_ALL_TARGETS.
Reviewers: gribozavr, void, beanz
Subscribers: llvm-commits
Patch By: Visoiu Mistrih Francis (thegameg)
Differential Revision: http://reviews.llvm.org/D20700
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270921 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for YAML round tripping dyld info lazy bindings. The storage and format of these is the same as regular bind opcodes, they are just interpreted differently by dyld, and can have DONE opcodes in the middle of the opcode lists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270920 91177308-0d34-0410-b5e6-96231b3b80d8
Previously the flags were only being set correctly when the
build type was "Release". Now the build should work properly
for all the supported build types. When building libFuzzer
the optimization level respects whatever is used for the
rest of LLVM but for the LibFuzzer tests we force -O0.
Differential Revision: http://reviews.llvm.org/D20558
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270912 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for YAML round tripping dyld info weak bindings. The storage and format of these is the same as regular bind opcodes, they are just interpreted differently by dyld.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270911 91177308-0d34-0410-b5e6-96231b3b80d8
Global variables and aliases are emitted eagerly, but there may not be any in
the incoming module. In that case, we can save some memory and compile time by
not building, emitting and tracking an empty globals module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270908 91177308-0d34-0410-b5e6-96231b3b80d8
We were creating a weak external that tried to reference a static symbol. That
would always fail to link with link.exe.
We now create an external symbol in the same position as the local and refer
to that. This works with link.exe and matches what gas does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270906 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for YAML round tripping dyld info bind opcodes. Bind opcodes can have signed or unsigned LEB128 data, and they can have symbols associated with them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270901 91177308-0d34-0410-b5e6-96231b3b80d8
Symbol resolution should be done on the top layer of the stack unless there's a
good reason to do otherwise. In this case it would have worked because
OptimizeLayer::addModuleSet eagerly passes all modules down to the
CompileLayer, meaning that searches in CompileLayer will find the definitions.
In later chapters where the top layer's addModuleSet isn't a pass-through, this
would break.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270899 91177308-0d34-0410-b5e6-96231b3b80d8
The aggressive anti-dependency breaker can rename the restored callee-
saved registers. To prevent this, mark these registers are live on all
paths to the return/tail-call instructions, and add implicit use operands
for them to these instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270898 91177308-0d34-0410-b5e6-96231b3b80d8
Canonicalize (srl (bswap i32 x), 16) to (rotr (bswap i32 x), 16), if the high
16-bits of x are zero. Similarly, canonicalize (srl (bswap i64 x), 32) to
(rotr (bswap i64 x), 32), if the high 32-bits of x are zero.
test_rev_w_srl16: test_rev_w_srl16:
and w8, w0, #0xffff and w8, w0, #0xffff
rev w8, w8 ---> rev16 w0, w8
lsr w0, w8, #16
test_rev_x_srl32: test_rev_x_srl32:
rev x8, x8 ---> rev32 x0, x8
lsr x0, x8, #32
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270896 91177308-0d34-0410-b5e6-96231b3b80d8
r270777 improved the precision of alloca vs. inbounbds GEP alias queries: if
we have (a) an inbounds GEP and (b) a pointer based on an alloca, and the
beginning of the object the GEP points to would have a negative offset with
respect to the alloca, then the GEP can not alias pointer (b).
This makes the same logic fire when (b) is based on a GlobalVariable instead
of an alloca.
Differential Revision: http://reviews.llvm.org/D20652
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270893 91177308-0d34-0410-b5e6-96231b3b80d8
An exception could prevent a store from occurring but MemCpyOpt's
callslot optimization would fire anyway, causing the store to occur.
This fixes PR27849.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270892 91177308-0d34-0410-b5e6-96231b3b80d8
