This exposes a method in MachineFrameInfo that calculates
MaxCallFrameSize and calls it after instruction selection in the ARM
target.
This avoids
ARMBaseRegisterInfo::canRealignStack()/ARMFrameLowering::hasReservedCallFrame()
giving different answers in early/late phases of codegen.
The testcase shows a particular nasty example result of that where we
would fail to properly align an alloca.
Differential Revision: https://reviews.llvm.org/D32622
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302303 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the time we know exactly how many type records we
have in a list, and we want to use the visitor to deserialize
them into actual records in a database. Previously we were
just using push_back() every time without reserving the space
up front in the vector. This is obviously terrible from a
performance standpoint, and it's not uncommon to have PDB
files with half a million type records, where the performance
degredation was quite noticeable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302302 91177308-0d34-0410-b5e6-96231b3b80d8
When randomly accessing an element by offset, we weren't passing
the offset through so if you called .offset() it would return a
value of 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302292 91177308-0d34-0410-b5e6-96231b3b80d8
- MIParser: If the successor list is not specified successors will be
added based on basic block operands in the block and possible
fallthrough.
- MIRPrinter: Adds a new `simplify-mir` option, with that option set:
Skip printing of block successor lists in cases where the
parser is guaranteed to reconstruct it. This means we still print the
list if some successor cannot be determined (happens for example for
jump tables), if the successor order changes or branch probabilities
being unequal.
Differential Revision: https://reviews.llvm.org/D31262
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302289 91177308-0d34-0410-b5e6-96231b3b80d8
No functional change other than improving dbgs logging accuracy on
constant dbg values. Previously we would add things like "i32 42" as
debug values, and then log that we were dropping the debug info, which
is silly.
Delete some dead code that was checking for static allocas. This
remained after r207165, but served no purpose. Currently, static alloca
dbg.values are always sent through the DanglingDebugInfoMap, and are
usually made valid the first time the alloca is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302267 91177308-0d34-0410-b5e6-96231b3b80d8
o Add bpfeb support in BPF dwarfdump unit test case
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@fb.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302265 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar to my recent fix for VarStreamArrayIterator, but the cause
(and thus the fix) is subtley different. The FixedStreamArrayIterator
iterates over a const Array, so the iterator's value type must be const.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302257 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Remove the AArch64AddressTypePromotion pass as we migrated all transformations
done in this pass into CGP in r299379.
Reviewers: qcolombet, jmolloy, javed.absar, mcrosier
Reviewed By: qcolombet
Subscribers: aemerson, rengolin, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D31623
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302245 91177308-0d34-0410-b5e6-96231b3b80d8
Hoisting common code can cause registers that live-in in the successor
blocks to no longer be live-in. The live-in information needs to be
updated to reflect this, or otherwise incorrect code can be generated
later on.
Differential Revision: https://reviews.llvm.org/D32661
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302228 91177308-0d34-0410-b5e6-96231b3b80d8
Recently support was added for substituting one intruction for another by
negating or inverting the immediate, but ORR and ORN were missed so this patch
adds them.
This one is slightly different to the others in that ORN only exists in thumb,
so we only do the substitution in thumb.
Differential Revision: https://reviews.llvm.org/D32534
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302224 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-dwarfdump currently prints no message if decompression fails
for some reason. I noticed that during work on one of LLD patches
where LLD produced an broken output. It was a bit confusing to see
no output for section dumped and no any error message at all.
Patch adds error message for such cases.
Differential revision: https://reviews.llvm.org/D32865
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302221 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes unused code which is no longer required because of changes
to the DIExpression::prepend function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302219 91177308-0d34-0410-b5e6-96231b3b80d8
Verifying the hash values as we are currently doing
results in iterating every type record before the user
even tries to access the first one, and the API user
has no control over, or ability to hook into this
process.
As a result, when the user wants to iterate over types
to print them or index them, this results in a second
iteration over the same list of types. When there's
upwards of 1,000,000 type records, this is obviously
quite undesirable.
This patch raises the verification outside of TpiStream
, and llvm-pdbdump hooks a hash verification visitor
into the normal dumping process. So we still verify
the hash records, but we can do it while not requiring
a second iteration over the type stream.
Differential Revision: https://reviews.llvm.org/D32873
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302206 91177308-0d34-0410-b5e6-96231b3b80d8
I tried to run llvm-pdbdump on a very large (~1.5GB) PDB to
try and identify show-stopping performance problems. This
patch addresses the first such problem.
When loading the DBI stream, before anyone has even tried to
access a single record, we build an in memory map of every
source file for every module. In the particular PDB I was
using, this was over 85 million files. Specifically, the
complexity is O(m*n) where m is the number of modules and
n is the average number of source files (including headers)
per module.
The whole reason for doing this was so that we could have
constant time access to any module and any of its source
file lists. However, we can still get O(1) access to the
source file list for a given module with a simple O(m)
precomputation, and access to the list of modules is
already O(1) anyway.
So this patches reduces the O(m*n) up-front precomputation
to an O(m) one, where n is ~6,500 and n*m is about 85 million
in my pathological test case.
Differential Revision: https://reviews.llvm.org/D32870
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302205 91177308-0d34-0410-b5e6-96231b3b80d8
Building the type database is expensive, and can take multiple
minutes for large PDBs. But we only need it in certain cases
depending on what command line options are specified. So only
build it when we know we're about to need it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302204 91177308-0d34-0410-b5e6-96231b3b80d8
Fix for PR32577.
Global variables may have !associated metadata, which includes a reference to another global. It needs remapping.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302203 91177308-0d34-0410-b5e6-96231b3b80d8
