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
Compares always return a scalar integer or vector of integers. isIntegerTy returns false for vectors, but that's not completely obvious. So using isVectorTy is less confusing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302198 91177308-0d34-0410-b5e6-96231b3b80d8
The sibling folds for 'and' with casts were added with https://reviews.llvm.org/rL273200.
This is a preliminary step for adding the 'or' variants for the folds added with https://reviews.llvm.org/rL301260.
The reason for the strange form with constant LHS in the 1st test is because there's another missing fold in that
case for the inverted predicate. That should be fixed when we add the ConstantRange functionality for 'or-of-icmps'
that already exists for 'and-of-icmps'.
I'm hoping to share more code for the and/or cases, so we won't have these differences. This will allow us to remove
code from InstCombine. It's also possible that we can remove some code here in InstSimplify. I think we have some
duplicated folds because patterns are not matched in a general way.
Differential Revision: https://reviews.llvm.org/D32876
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302189 91177308-0d34-0410-b5e6-96231b3b80d8
This happened on the PPC32/SVR4 path and was discovered when building
FreeBSD on PPC32. It was a typo-class error in the frame lowering code.
This fixes PR26519.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302183 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids problems on code like this:
char buf[16];
__asm {
movups xmm0, [buf]
mov [buf], eax
}
The frontend size in this case (1) is wrong, and the register makes the
instruction matching unambiguous. There are also enough bytes available
that we shouldn't complain to the user that they are potentially using
an incorrectly sized instruction to access the variable.
Supersedes D32636 and D26586 and fixes PR28266
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302179 91177308-0d34-0410-b5e6-96231b3b80d8
