| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 272236
|
| |
|
|
|
|
|
| |
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty backtraces if they crash.
llvm-svn: 272232
|
| |
|
|
|
|
| |
They have probably been discarded during optimization.
llvm-svn: 272231
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TPI hash table contains a parallel array for the type records.
For each type record R, a hash value is calculated by `H(R) % NumBuckets`
where H is a hash function, and the result is stored to a bucket element.
H is TPI1::hashPrec function in microsoft-pdb repository.
Our hash function does not support all type record types yet.
Currently it supports only records for line number.
I'll extend it in a follow up patch.
The aim of verify the hash table is not only detect corrupted files.
It ensures that our understanding of how the hash values are calculated
is correct.
llvm-svn: 272229
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Break on all switch cases for outer and inner switches.
No functionality changed.
Reviewers: llvm-commits, sanjoy
Differential Revision: http://reviews.llvm.org/D21158
llvm-svn: 272228
|
| |
|
|
|
|
|
|
| |
Without that check it was possible to write test cases where the size
was not specified and we ended up with weird asserts down the road,
because the default value (1) would not make sense.
llvm-svn: 272226
|
| |
|
|
| |
llvm-svn: 272225
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes PR26682. Also add LCSSA as a preserved pass to LoopSimplify,
that looks correct to me and allows to write a test for the issue.
Reviewers: chandlerc, bogner, sanjoy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21112
llvm-svn: 272224
|
| |
|
|
|
|
|
|
| |
We are going to use the hash functions from TPI streams.
Differential Revision: http://reviews.llvm.org/D21142
llvm-svn: 272223
|
| |
|
|
| |
llvm-svn: 272221
|
| |
|
|
|
|
| |
This improves the debuggability of the pass.
llvm-svn: 272210
|
| |
|
|
|
|
|
|
| |
For complex rewrittings, which do not occur currently, the related
machine instruction may have been deleted in the process. Therefore, do
not try to print it after the mapping is applied.
llvm-svn: 272209
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
computation of the end of range.
Refactor the code so that we do not compute in two different places the
end iterator for the range of new virtual registers for a given operand.
Although this refactoring was intended as NFC, this is not the case
because it actually fixes a bug where we were returning a range off by 1
(too long). Right now, this could not result in an actual bug because we
were accessing this range via the BreakDown size of the related operand.
llvm-svn: 272208
|
| |
|
|
|
|
| |
Improve debuggability of the OperandsMapper helper class.
llvm-svn: 272207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes PR27617.
Bug description: The SLPVectorizer asserts on encountering GEPs with different index types, such as i8 and i64.
The patch includes a simple relaxation of the assert to allow constants being of different types, along with a regression test that will provoke the unrelaxed assert.
Reviewers: nadav, mzolotukhin
Subscribers: JesperAntonsson, llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D20685
Patch by Jesper Antonsson!
llvm-svn: 272206
|
| |
|
|
| |
llvm-svn: 272204
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
backward-hot-prob consistently.
Summary:
Consider the following diamond CFG:
A
/ \
B C
\/
D
Suppose A->B and A->C have probabilities 81% and 19%. In block-placement, A->B is called a hot edge and the final placement should be ABDC. However, the current implementation outputs ABCD. This is because when choosing the next block of B, it checks if Freq(C->D) > Freq(B->D) * 20%, which is true (if Freq(A) = 100, then Freq(B->D) = 81, Freq(C->D) = 19, and 19 > 81*20%=16.2). Actually, we should use 25% instead of 20% as the probability here, so that we have 19 < 81*25%=20.25, and the desired ABDC layout will be generated.
Reviewers: djasper, davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D20989
llvm-svn: 272203
|
| |
|
|
| |
llvm-svn: 272199
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If
it is present and non-zero, the backend will emit it as a
DW_AT_calling_convention attribute. On the CodeView side, we translate
it to the appropriate enum for the LF_PROCEDURE record.
I added a new LLVM vendor specific enum to the list of DWARF calling
conventions. DWARF does not appear to attempt to standardize these, so I
assume it's OK to do this until we coordinate with GCC on how to emit
vectorcall convention functions.
Reviewers: dexonsmith, majnemer, aaboud, amccarth
Subscribers: mehdi_amini, llvm-commits
Differential Revision: http://reviews.llvm.org/D21114
llvm-svn: 272197
|
| |
|
|
| |
llvm-svn: 272196
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with user specified count has been applied.
Summary:
Previously SetLoopAlreadyUnrolled() set the disable pragma only if
there was some loop metadata.
Now it set the pragma in all cases. This helps to prevent multiple
unroll when -unroll-count=N is given.
Reviewers: mzolotukhin
Differential Revision: http://reviews.llvm.org/D20765
From: Evgeny Stupachenko <evstupac@gmail.com>
llvm-svn: 272195
|
| |
|
|
|
|
|
|
| |
This is the preparation patch to port the analysis to new PM
Differential Revision: http://reviews.llvm.org/D20560
llvm-svn: 272194
|
| |
|
|
| |
llvm-svn: 272193
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: iteratee
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21087
llvm-svn: 272192
|
| |
|
|
| |
llvm-svn: 272191
|
| |
|
|
|
|
|
| |
Avoids unnecessary copies. All changes audited & pass tests with asan.
No functional change intended.
llvm-svn: 272190
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21107
llvm-svn: 272187
|
| |
|
|
|
|
|
| |
MSVC calls the copy ctor on StratifiedSets for some reason. So,
undelete it.
llvm-svn: 272184
|
| |
|
|
|
|
|
|
|
|
| |
Again, the Microsoft linker does not like empty substreams.
We still emit an empty string table if CodeView is enabled, but that
doesn't cause problems because it always contains at least one null
byte.
llvm-svn: 272183
|
| |
|
|
|
|
|
| |
This is NFC as far as externally visible behavior is concerned, but will
keep us from spinning in the worklist traversal algorithm unnecessarily.
llvm-svn: 272182
|
| |
|
|
|
|
|
|
|
|
|
| |
Absence of may-unwind calls is not enough to guarantee that a
UB-generating use of an add-rec poison in the loop latch will actually
cause UB. We also need to guard against calls that terminate the thread
or infinite loop themselves.
This partially addresses PR28012.
llvm-svn: 272181
|
| |
|
|
|
|
| |
Calls to `@llvm.dbg.*` can be assumed to terminate.
llvm-svn: 272180
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The worklist algorithm introduced in rL271151 didn't check to see if the
direct users of the post-inc add recurrence propagates poison. This
change fixes the problem and makes the code structure more obvious.
Note for release managers: correctness wise, this bug wasn't a
regression introduced by rL271151 -- the behavior of SCEV around
post-inc add recurrences was strictly improved (in terms of correctness)
in rL271151.
llvm-svn: 272179
|
| |
|
|
| |
llvm-svn: 272177
|
| |
|
|
|
|
|
|
|
|
|
| |
When repairing with a copy, instead of accounting for the cost of that
copy and actually inserting it, we may be able to use an alternative
source for the register to repair and just use it.
Make sure this is documented, so that we consider that opportunity at
some point.
llvm-svn: 272176
|
| |
|
|
|
|
|
| |
r272064 apparently made them angry. This undoes some changes made in
r272064 (defaulting move ctors) to make them happy again.
llvm-svn: 272173
|
| |
|
|
|
|
|
| |
Reviewed By: ruiu
Differential Revision: http://reviews.llvm.org/D21128
llvm-svn: 272172
|
| |
|
|
| |
llvm-svn: 272171
|
| |
|
|
|
|
|
|
|
|
| |
Teach AArch64RegisterBankInfo that G_OR can be mapped on either GPR or
FPR for 64-bit or 32-bit values.
Add test cases demonstrating how this information is used to coalesce a
computation on a single register bank.
llvm-svn: 272170
|
| |
|
|
|
|
|
| |
The RegBankSelect pass can now rely on the target to do the remapping of
the instructions.
llvm-svn: 272169
|
| |
|
|
|
|
|
|
|
| |
Now, the target will be able to provide its how implementation to remap
an instruction. This open the way to crazier optimizations, but to
beginning with, we will be able to handle something else than the
default mapping.
llvm-svn: 272165
|
| |
|
|
|
|
|
|
|
| |
Now that we have an entity that hold the remap information the
rewritting should be easier to do.
No functional changes.
llvm-svn: 272164
|
| |
|
|
|
|
|
| |
The repairing code has no reason to change the source or destination of
the registers.
llvm-svn: 272163
|
| |
|
|
|
|
|
| |
This helper class is used to encapsulate the necessary information
to remap an instruction.
llvm-svn: 272161
|
| |
|
|
|
|
|
|
|
|
| |
When the command line option is set, it overrides any thing that the
target may have set. The rationale is that we get what we asked for.
Options are respectively regbankselect-fast and regbankselect-greedy for
fast and greedy mode.
llvm-svn: 272158
|
| |
|
|
|
|
|
|
|
|
|
| |
repairing.
Copies are easy because we repair only when there is a mismatch. For
non-copy repairing, i.e., cases that involves breaking down or gathering
up the value, one of the operand may not have a register bank yet. Thus,
derivate a cost from that, requires more work.
llvm-svn: 272157
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MSR instructions can write to the CPSR, but we did not model this
fact, so we could emit them in the middle of IT blocks, changing the
condition flags for later instructions in the block.
The tests use two calls to llvm.write_register.i32 because it is valid
to use these instructions at the end of an IT block, which if conversion
does do in some cases. With two calls, the first clobbers the flags, so
a branch has to be used to make the second one conditional.
Differential Revision: http://reviews.llvm.org/D21139
llvm-svn: 272154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The architecture enumeration is shared across ARM and AArch64. However, the
data is not. The code incorrectly would index into the array using the
architecture index which was offset by the ARMv7 architecture enumeration. We
do not have a marker for indicating the architectural family to which the
enumeration belongs so we cannot be clever about offsetting the index (at least
it is not immediately apparent to me). Instead, fall back to the tried-and-true
method of slowly iterating the array (its not a large array, so the impact of
this is not too high).
Because of the incorrect indexing, if we were lucky, we would crash, but usually
we would return an invalid StringRef. We did not have any tests for the AArch64
target parser previously;. Extend the previous tests I had added for ARM to
cover AArch64 for ensuring that we return expected StringRefs.
Take the opportunity to change some iterator types to references.
This work is needed to support parsing `.arch name` directives in the AArch64
target asm parser.
llvm-svn: 272145
|
| |
|
|
| |
llvm-svn: 272140
|
| |
|
|
| |
llvm-svn: 272139
|