| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 302206
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 302205
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 302204
|
| |
|
|
|
|
|
| |
Fix for PR32577.
Global variables may have !associated metadata, which includes a reference to another global. It needs remapping.
llvm-svn: 302203
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 302202
|
| |
|
|
|
|
| |
NFC
llvm-svn: 302201
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D32645
llvm-svn: 302200
|
| |
|
|
|
|
|
|
|
|
| |
During legalization, targets can create Pseudo Instructions with
generic types. We shouldn't try to legalize them.
Reviewed by Quentin, dsanders
https://reviews.llvm.org/D32575
llvm-svn: 302199
|
| |
|
|
|
|
|
|
| |
type is not a vector rather than check for it being an integer.
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.
llvm-svn: 302198
|
| |
|
|
|
|
|
|
| |
to a static cast. Combine the with another static cast. NFC
Differential Revision: https://reviews.llvm.org/D32874
llvm-svn: 302197
|
| |
|
|
|
|
|
| |
Reviewed by Quentin
https://reviews.llvm.org/D32814
llvm-svn: 302196
|
| |
|
|
|
|
| |
its methods construct new ConstantRange objects.
llvm-svn: 302194
|
| |
|
|
|
|
| |
so it just creates and discards a ConstantRange object for no reason.
llvm-svn: 302193
|
| |
|
|
| |
llvm-svn: 302192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 302189
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D32760
llvm-svn: 302185
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 302183
|
| |
|
|
|
|
| |
the .debug_line section.
llvm-svn: 302180
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 302179
|
| |
|
|
|
|
|
|
| |
Putting these next to each other should make it easier to see
what's missing from each side. Patch to plug one of those holes
should be posted soon.
llvm-svn: 302178
|
| |
|
|
|
|
|
|
| |
the module summary. NFCI."
with a fix for the clang backend.
llvm-svn: 302176
|
| |
|
|
| |
llvm-svn: 302175
|
| |
|
|
| |
llvm-svn: 302174
|
| |
|
|
| |
llvm-svn: 302173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case multiply size
Currently multiply is implemented in operator*=. Operator* makes a copy and uses operator*= to modify the copy.
Operator*= itself allocates a temporary buffer to hold the multiply result as it computes it. Then copies it to the buffer in *this.
Operator*= attempts to bound the size of the result based on the number of active bits in its inputs. It also has a couple special cases to handle 0 inputs without any memory allocations or multiply operations. The best case is that it calculates a single word regardless of input bit width. The worst case is that it calculates the a 2x input width result and drop the upper bits.
Since operator* uses operator*= it incurs two allocations, one for a copy of *this and one for the temporary allocation. Neither of these allocations are kept after the method operation is done.
The main usage in the backend appears to be ConstantRange::multiply which uses operator* rather than operator*=.
This patch moves the multiply operation to operator* and implements operator*= using it. This avoids the copy in operator*. operator* now allocates a result buffer sized the same width as its inputs no matter what. This buffer will be used as the buffer for the returned APInt. Finally, we reuse tcMultiply to implement the multiply operation. This function is capable of not calculating additional upper words that will be discarded.
This change does lose the special optimizations for the inputs using less words than their size implies. But it also removed the getActiveBits calls from all multiplies. If we think those optimizations are important we could look at providing additional bounds to tcMultiply to limit the computations.
Differential Revision: https://reviews.llvm.org/D32830
llvm-svn: 302171
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D32768
llvm-svn: 302170
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add an entry to the Lexicon for "BDCE."
Reviewers: jmolloy, hfinkel
Reviewed By: jmolloy
Differential Revision: https://reviews.llvm.org/D31861
llvm-svn: 302169
|
| |
|
|
| |
llvm-svn: 302167
|
| |
|
|
|
|
| |
rdar://problem/31926379
llvm-svn: 302166
|
| |
|
|
| |
llvm-svn: 302165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
require additional support.
Summary:
As of this patch, 350 out of 3938 rules are currently imported.
Depends on D32229
Reviewers: qcolombet, kristof.beyls, rovka, t.p.northover, ab, aditya_nandakumar
Reviewed By: ab
Subscribers: dberris, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D32275
llvm-svn: 302154
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D32596
llvm-svn: 302153
|
| |
|
|
|
|
| |
Fix capitalization and string matching
llvm-svn: 302150
|
| |
|
|
| |
llvm-svn: 302149
|
| |
|
|
|
|
|
|
| |
Patch by Wei-Ren Chen.
Differential Revision: https://reviews.llvm.org/D32682
llvm-svn: 302148
|
| |
|
|
|
|
|
|
|
| |
When a 128 bit COPY is lowered into two instructions, an impl-use operand of
the super-reg should be added to each new instruction in case one of the
sub-regs is undefined.
Review: Ulrich Weigand
llvm-svn: 302146
|
| |
|
|
| |
llvm-svn: 302145
|
| |
|
|
| |
llvm-svn: 302144
|
| |
|
|
|
|
|
|
|
|
| |
summary. NFCI."
This reverts commit r302108. This causes crash in clang bootstrap with LTO.
Contacted the auther in the original commit.
llvm-svn: 302140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow up rL290858 by removing the MIPS specific version of XRayTable
emission in favour of the basic version.
This resolves a buildbot failure where the ELF sections were malformed
causing the linker to reject the object files with xray related sections.
Reviewers: dberris, slthakur
Differential Revision: https://reviews.llvm.org/D32808
llvm-svn: 302138
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression since SVN rev 273808 (which was supposed to
not change functionality).
The regression caused miscompilations (noted in the wild when targeting
AArch64) on platforms with 32 bit long.
Differential Revision: https://reviews.llvm.org/D32850
llvm-svn: 302137
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this patch, I introduce a new altmacro string delimiter.
This review is the second review in a series of four reviews.
(one for each altmacro feature: LOCAL, string delimiter, string '!' escape sign and absolute expression as a string '%' ).
In the alternate macro mode, you can delimit strings with matching angle brackets <..>
when using it as a part of calling macro arguments.
As described in the https://sourceware.org/binutils/docs-2.27/as/Altmacro.html
"<string>
You can delimit strings with matching angle brackets."
assumptions:
1. If an argument begins with '<' and ends with '>'. The argument is considered as a string.
2. Except adding new string mark '<..>', a regular macro behavior is expected.
3. The altmacro cannot affect the regular less/greater behavior.
4. If a comma is present inside an angle brackets it considered as a character and not as a separator.
Differential Revision: https://reviews.llvm.org/D32701
llvm-svn: 302135
|
| |
|
|
|
|
|
|
| |
mul v8i32.
Differential Revision: https://reviews.llvm.org/D32679
llvm-svn: 302127
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added the integer data processing intrinsics from ACLE v2.1 Chapter 9
but I have missed out the saturation_occurred intrinsics for now. For
the instructions that read and write the GE bits, a chain is included
and the only instruction that reads these flags (sel) is only
selectable via the implemented intrinsic.
Differential Revision: https://reviews.llvm.org/D32281
llvm-svn: 302126
|
| |
|
|
|
|
|
|
|
|
| |
According to psABI, PLT stub clobbers XMM8-XMM15.
In Regcall calling convention those registers are used for passing parameters.
Thus we need to prevent lazy binding in Regcall.
Differential Revision: https://reviews.llvm.org/D32430
llvm-svn: 302124
|
| |
|
|
|
|
| |
predicate.
llvm-svn: 302123
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix vpcmpeqq predicate. AVX512 version of vpcmpeqq is not equivalent to AVX one.
Split from https://reviews.llvm.org/D32679
Reviewers: craig.topper, zvi, aymanmus
Reviewed By: craig.topper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32786
llvm-svn: 302119
|
| |
|
|
|
|
|
|
| |
- unsigned AS = getMemInstAlignment(I);
+ unsigned AS = getMemInstAddressSpace(I);
Review: Hal Finkel
llvm-svn: 302114
|
| |
|
|
|
|
|
|
|
|
| |
This makes it simpler for the runtime to consistently handle the entries
in the function sled index in both 32 and 64 bit platforms where the
XRay runtime works.
Follow-up on D32693.
llvm-svn: 302111
|
| |
|
|
|
|
| |
This is based on the same concept from ValueTracking's version of computeKnownBits.
llvm-svn: 302110
|