| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 299622
|
| |
|
|
| |
llvm-svn: 299621
|
| |
|
|
| |
llvm-svn: 299619
|
| |
|
|
| |
llvm-svn: 299618
|
| |
|
|
|
|
| |
Just a spelling change in a comment intended to test svn commit access.
llvm-svn: 299616
|
| |
|
|
|
|
|
| |
This will allow orcError to be used in convertToErrorCode implementations,
which will help in transitioning Orc RPC to Error.
llvm-svn: 299610
|
| |
|
|
| |
llvm-svn: 299602
|
| |
|
|
| |
llvm-svn: 299598
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LSV wants to know the maximum size that can be loaded to a vector register.
On X86, this always matches the maximum register width. Implement this
accordingly and add a test to make sure that LSV can vectorize up to the
maximum permissible width on X86.
Reviewers: delena, arsenm
Reviewed By: arsenm
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D31504
llvm-svn: 299589
|
| |
|
|
|
|
|
|
|
|
|
| |
Reason: breaks multiple bots:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/3988
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/1173
Original Review URL: https://reviews.llvm.org/D31671
llvm-svn: 299583
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Remove all the caching the clobber walker does, and that the
caching walker does. With the patch to enable storing clobbering
access results for stores, i can find no improvement with the cache
turned on (and a number of degradations, both time and memory, from
the cost of caching. For a large program i have, we do millions of
lookups and inserts with zero hits).
I haven't tried to rename or simplify the walker otherwise yet.
(Appreciate some perf testing on this past my own testing)
Reviewers: george.burgess.iv, davide
Subscribers: Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31576
llvm-svn: 299578
|
| |
|
|
|
|
|
|
|
| |
This is a follow-on to r299096 which added support for fmadd.
Subtract does not have the case where with two multiply operands we commute in
order to fuse with the multiply with the fewer uses.
llvm-svn: 299572
|
| |
|
|
| |
llvm-svn: 299571
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have these 'and' folds:
// X & -C == -C -> X > u ~C
// X & -C != -C -> X <= u ~C
// iff C is a power of 2
...but we were missing the 'or' siblings.
http://rise4fun.com/Alive/n6
This should improve:
https://bugs.llvm.org/show_bug.cgi?id=32524
...but there are 2 or more other pieces to fix still.
Differential Revision: https://reviews.llvm.org/D31712
llvm-svn: 299570
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary:
Use an explicit work queue instead, to avoid accidentally
causing stack overflows for input with very large CFGs.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D31681
llvm-svn: 299569
|
| |
|
|
|
|
|
| |
There must be some opportunity to refactor big chunks of nearly duplicated code in FoldOrOfICmps / FoldAndOfICmps.
Also, none of this works with vectors, but it should.
llvm-svn: 299568
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added support of the following instructions:
- s_cbranch_cdbgsys
- s_cbranch_cdbgsys_and_user
- s_cbranch_cdbgsys_or_user
- s_cbranch_cdbguser
- s_setkill
Reviewers: vpykhtin
Differential Revision: https://reviews.llvm.org/D31469
llvm-svn: 299567
|
| |
|
|
| |
llvm-svn: 299566
|
| |
|
|
| |
llvm-svn: 299562
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Corrected src0 for v_writelane_b32:
- Enabled inline constants and literals for SI/CI (VOP2)
- Enabled inline constants for VI (VOP3)
Reviewers: vpykhtin, arsenm
https://reviews.llvm.org/D31463
llvm-svn: 299555
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixes PR32505.
Reviewers: uweigand, jonpa
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31609
llvm-svn: 299552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bitwise logic+setcc (PR32401)
This is a generic combine enabled via target hook to reduce icmp logic as discussed in:
https://bugs.llvm.org/show_bug.cgi?id=32401
It's likely that other targets will want to enable this hook for scalar transforms,
and there are probably other patterns that can use bitwise logic to reduce comparisons.
Note that we are missing an IR canonicalization for these patterns, and we will probably
prefer the pair-of-compares form in IR (shorter, more likely to fold).
Differential Revision: https://reviews.llvm.org/D31483
llvm-svn: 299542
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When DAGCombiner visits a SIGN_EXTEND_INREG of a BUILD_VECTOR with
constant operands, a new BUILD_VECTOR node will be created transformed
constants.
Llvm-stress found a case where the new BUILD_VECTOR had constant operands
of an illegal type, because the (legal) element type is in fact not a legal
scalar type.
This patch changes this so that the new BUILD_VECTOR has the same operand
type as the old one.
Review: Eli Friedman, Nirav Dave
https://bugs.llvm.org//show_bug.cgi?id=32422
llvm-svn: 299540
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: vpykhtin, rampitec, arsenm
Subscribers: qcolombet, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye
Differential Revision: https://reviews.llvm.org/D31671
llvm-svn: 299536
|
| |
|
|
| |
llvm-svn: 299535
|
| |
|
|
|
|
| |
shift by immediate opcodes. NFCI
llvm-svn: 299532
|
| |
|
|
|
|
| |
So if FP is disabled, crypto should also be disabled.
llvm-svn: 299531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A number of backends (AArch64, MIPS, ARM) have been using
MCContext::reportError to report issues such as out-of-range fixup values in
their TgtAsmBackend. This is great, but because MCContext couldn't easily be
threaded through to the adjustFixupValue helper function from its usual
callsite (applyFixup), these backends ended up adding an MCContext* argument
and adding another call to applyFixup to processFixupValue. Adding an
MCContext parameter to applyFixup makes this unnecessary, and even better -
applyFixup can take a reference to MCContext rather than a potentially null
pointer.
Differential Revision: https://reviews.llvm.org/D30264
llvm-svn: 299529
|
| |
|
|
|
|
|
|
|
|
| |
This is a latent bug that's been hanging around for a while. For a loop-invariant
pointer, expandBounds would return the range {Ptr, Ptr}, but this was interpreted
as a half-open range, not a closed range. So we ended up planting incorrect
bounds checks. Even worse, they were tautological, so we ended up incorrectly
executing the optimized loop.
llvm-svn: 299526
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a bug in ARC contract pass where an iterator that pointed to a
deleted instruction was dereferenced.
It appears that tryToContractReleaseIntoStoreStrong was incorrectly
assuming that a call to objc_retain would not immediately follow a call
to objc_release.
rdar://problem/25276306
llvm-svn: 299507
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change fixes a "local linkage requires default visibility" assert when attempting to build LLVM with ThinLTO on Windows.
Reviewers: pcc, tejohnson, mehdi_amini
Reviewed By: pcc
Subscribers: llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D31632
llvm-svn: 299491
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before r294774, there was a problem when lowering broadcasts to use
128-bit subvectors.
When we looked through a bitcast to find the broadcast input, we'd keep
using the original type, so you'd end up with things like:
(v8f32 (broadcast
(v4f32 (extract_subvector
(v8i32 V),
...))
))
r294774 fixed it to always emit subvectors with the scalar type of the
original source.
It also introduced some asserts, to check that we use scalars with
the same size, and vectors with the same number of elements.
The scalar size equality is checked earlier when looking through bitcasts,
and is a useful assert.
However, the number of elements don't have to be identical: we're always
going to extract a 128-bit subvector, and we can have different size
inputs if we looked through a concat_vector to find a 256-bit source.
Relax the overzealous assert.
Replace it with a check of the original source vector being 256 or 512
bits. If it's 128 bits, we can't extract_subvector from it.
Fixes PR32371.
llvm-svn: 299490
|
| |
|
|
|
|
|
|
|
|
| |
Decouple this setting from EnableIRPA.
To support function calls on AMDGPU, it is necessary to
report the global register usage throughout the kernel's
call graph, so callees need to be handled first.
llvm-svn: 299487
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stores with some fixes.
Summary:
This enables us to cache the clobbering access for stores, despite the
fact that we can't rewrite the use-def chains themselves.
Early testing shows that, after this change, for larger testcases, it
will be a significant net positive (memory and time) to remove the
walker caching.
Reviewers: george.burgess.iv, davide
Subscribers: Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31567
llvm-svn: 299486
|
| |
|
|
|
|
| |
This reverts revision r299322.
llvm-svn: 299485
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Set correct default flags and section type based on its name for .text,
.data, .bss, .init_array, .fini_array, .preinit_array, .tdata, and .tbss
and support section name suffixes for .data.*, .rodata.*, .text.*,
.bss.*, .tdata.* and .tbss.* which matches the behavior of GAS.
Fixes PR31888.
Differential Revision: https://reviews.llvm.org/D30229
llvm-svn: 299484
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves upon r246462: that prevented FMOVs from being emitted
for the cross-class INSERT_SUBREGs by disabling the formation of
INSERT_SUBREGs of LOAD. But the ld1.s that we started selecting
caused us to introduce partial dependencies on the vector register.
Avoid that by using SCALAR_TO_VECTOR: it's a first-class citizen that
is folded away by many patterns, including the scalar LDRS that we
want in this case.
Credit goes to Adam for finding the issue!
llvm-svn: 299482
|
| |
|
|
|
|
|
|
| |
GAS uses "m" as a compatibility alias for "M" (SHF_MERGE).
"o" is free, except on ia64, where it already means SHF_LINK_ORDER.
llvm-svn: 299479
|
| |
|
|
|
|
| |
We usually give constants a 'C' somewhere in the name...
llvm-svn: 299474
|
| |
|
|
|
|
| |
i1. Matches what we already do for add.
llvm-svn: 299472
|
| |
|
|
| |
llvm-svn: 299468
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an instruction has a true dependency, it makes sense for to use that
register for any undef read operands in the same instruction (we'll have
to wait for that register to become available anyway). This logic
was already implemented. However, the code would then still try to
revisit that instruction and break the dependency (and always fail,
since by definition a true dependency has to be live before the
instruction). Avoid revisiting such instructions as a performance
optimization. No functional change.
Differential Revision: https://reviews.llvm.org/D30173
llvm-svn: 299467
|
| |
|
|
|
|
|
|
|
|
| |
selects and phis
Currently we only fold with ConstantInt RHS. This generalizes to any Constant RHS.
Differential Revision: https://reviews.llvm.org/D31610
llvm-svn: 299466
|
| |
|
|
|
|
|
|
|
|
|
| |
This mode is just like -mcmodel=small except that it moves the
thread pointer from TPIDR_EL0 to TPIDR_EL1.
Patch by Roland McGrath.
Differential Revision: https://reviews.llvm.org/D31624
llvm-svn: 299462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This shares detection logic with ARM(32), since AArch64 capable CPUs may
also run in 32-bit system mode.
We observe weird /proc/cpuinfo output for MSM8992 and MSM8994, where
they report all CPU cores as one single model, depending on which CPU
core the kernel is running on. As a workaround, we hardcode the known
CPU part name for these SoCs.
For big.LITTLE systems, this patch would only return the part name of
the first core (usually the little core). Proper support will be added
in a follow-up change.
Differential Revision: D31675
llvm-svn: 299458
|
| |
|
|
| |
llvm-svn: 299457
|
| |
|
|
| |
llvm-svn: 299456
|
| |
|
|
|
|
|
|
|
|
|
|
| |
MS assembly syntax provide us with the 'EVEN' directive as a synonymous to at&t '.even'.
This patch include the (small, simple) changes need to allow it.
Test is provided at the following (clang-side) review:
https://reviews.llvm.org/D27418
Differential Revision: https://reviews.llvm.org/D27417
llvm-svn: 299453
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the ProcessAllSections flag (introduced in r204398) is set RuntimeDyld is
supposed to make a call to the client's memory manager for every section in each
object that is loaded. Due to some missing checks, this was not happening in all
cases. This patch adds the missing cases, and fixes the Orc unit test that
verifies correct behavior for ProcessAllSections (The unit test had been
silently bailing out due to an ordering issue: a change in the test order meant
that this unit-test was running before the native target was registered. This
issue has also been fixed in this patch).
This fixes <rdar://problem/22789965>
llvm-svn: 299449
|
| |
|
|
|
|
|
|
| |
https://reviews.llvm.org/D30537 / https://reviews.llvm.org/rL296977 added these transforms
and other related transforms to the generic DAGCombiner (with a hook that x86 sets to true),
so these patterns should not exist by the time we reach the target-specific combiner hook.
llvm-svn: 299448
|