| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 288100
|
|
|
|
| |
llvm-svn: 288088
|
|
|
|
| |
llvm-svn: 288073
|
|
|
|
|
|
| |
This reverts commit r287773 which caused issues with ppc64le builds.
llvm-svn: 288035
|
|
|
|
| |
llvm-svn: 287941
|
|
|
|
|
|
|
|
| |
same, then the condition doesn't matter and the vselect can be removed.
Selects with scalar condition already handle this correctly.
llvm-svn: 287904
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Reduce indentation level; preparation for D24956.
Reviewers: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27063
llvm-svn: 287831
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Forward store values to matching loads down through token
factors. Factored from D14834.
Reviewers: jyknight, hfinkel
Subscribers: hfinkel, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D26080
llvm-svn: 287773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have the following DAGCombiner transformations:
(mul (shl X, c1), c2) -> (mul X, c2 << c1)
(mul (shl X, C), Y) -> (shl (mul X, Y), C)
(shl (mul x, c1), c2) -> (mul x, c1 << c2)
Usually the constant shift is optimised by SelectionDAG::getNode when it is
constructed, by SelectionDAG::FoldConstantArithmetic, but when we're dealing
with vectors and one of those vector constants contains an undef element
FoldConstantArithmetic does not fold and we enter an infinite loop.
Fix this by making FoldConstantArithmetic use getNode to decide how to fold each
vector element, the same as FoldConstantVectorArithmetic does, and rather than
adding the constant shift to the work list instead only apply the transformation
if it's already been folded into a constant, as if it's not we're going to loop
endlessly. Additionally add missing NoOpaques to one of those transformations,
which I noticed when writing the tests for this.
Differential Revision: https://reviews.llvm.org/D26605
llvm-svn: 287766
|
|
|
|
|
|
|
|
| |
Implemented widening (v2f32) and splitting (v16f64).
On splitting, I use "popcnt" to calculate memory increment.
More type legalization work will come in the next patches.
llvm-svn: 287761
|
|
|
|
|
|
|
|
|
|
| |
Add basic ComputeNumSignBits support for TRUNCATE ops for cases where the source's number of sign bits overlaps with the truncated size.
Improves X86 SIGN_EXTEND_IN_REG vector cases which were needlessly sign extending boolean vector results.
Differential Revision: https://reviews.llvm.org/D26851
llvm-svn: 287635
|
|
|
|
|
|
|
|
|
|
| |
A target intrinsic may be defined as possibly reading memory,
but the call site may have additional knowledge that it doesn't read
memory. The intrinsic lowering will expect the pessimistic
assumption of the intrinsic definition, so the chain should
still be used.
llvm-svn: 287593
|
|
|
|
|
|
| |
We were calling SVT.getSizeInBits() several times in a row - just call it once and reuse the result.
llvm-svn: 287556
|
|
|
|
| |
llvm-svn: 287541
|
|
|
|
|
|
| |
Identified by Pedro Giffuni in PR27636.
llvm-svn: 287487
|
|
|
|
| |
llvm-svn: 287387
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previously used "names" are rather descriptions (they use multiple
words and contain spaces), use short programming language identifier
like strings for the "names" which should be used when exporting to
machine parseable formats.
Also removed a unused TimerGroup from Hexxagon.
Differential Revision: https://reviews.llvm.org/D25583
llvm-svn: 287369
|
|
|
|
| |
llvm-svn: 287222
|
|
|
|
|
|
| |
This patch updates a bunch of places where add_dependencies was being explicitly called to add dependencies on intrinsics_gen to instead use the DEPENDS named parameter. This cleanup is needed for a patch I'm working on to add a dependency debugging mode to the build system.
llvm-svn: 287206
|
|
|
|
|
|
| |
While there, rename them to follow the coding style.
llvm-svn: 287169
|
|
|
|
|
|
|
|
|
|
|
| |
They're not SelectionDAG- or FunctionLoweringInfo-specific. They
are, however, specific to building MMI from IR.
We could make them members, but it's nice having MMI be a "simple" data
structure and this logic kept separate.
This also lets us reuse them from GlobalISel.
llvm-svn: 287167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes the runtime results produces by the fallback multiplication expansion introduced in r270720.
For tests I created a fuzz tester that compares the results with Boost.Multiprecision.
Reviewers: hfinkel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26628
llvm-svn: 286998
|
|
|
|
|
|
|
|
|
|
|
| |
For 64bit ABIs it is common practice to use relative Jump Tables with
potentially different relocation bases. As the logic for the jump table
itself doesn't depend on the relocation base, make it easier for targets
to use the generic logic. Start by dropping the now redundant MIPS logic.
Differential Revision: https://reviews.llvm.org/D26578
llvm-svn: 286951
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bugzilla:
https://llvm.org/bugs/show_bug.cgi?id=29002
pr29002
Differential Revision: https://reviews.llvm.org/D26449
llvm-svn: 286938
|
|
|
|
| |
llvm-svn: 286582
|
|
|
|
| |
llvm-svn: 286578
|
|
|
|
| |
llvm-svn: 286576
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generic infrastructure to compute the Newton series for reciprocal and
reciprocal square root was conceived to allow a target to compute the series
itself. However, the original code did not properly consider this condition
if returned by a target. This patch addresses the issues to allow a target
to compute the series on its own.
Differential revision: https://reviews.llvm.org/D22975
llvm-svn: 286523
|
|
|
|
| |
llvm-svn: 286516
|
|
|
|
| |
llvm-svn: 286509
|
|
|
|
| |
llvm-svn: 286481
|
|
|
|
| |
llvm-svn: 286473
|
|
|
|
| |
llvm-svn: 286471
|
|
|
|
| |
llvm-svn: 286461
|
|
|
|
|
|
|
|
| |
We were failing to extract a constant splat shift value if the shifted value was being masked.
The (shl (and (setcc) N01CV) N1CV) -> (and (setcc) N01CV<<N1CV) combine was unnecessarily preventing this.
llvm-svn: 286454
|
|
|
|
| |
llvm-svn: 286448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed an issue with vector usage of TargetLowering::isConstTrueVal / TargetLowering::isConstFalseVal boolean result matching.
The comment said we shouldn't handle constant splat vectors with undef elements. But the the actual code was returning false if the build vector contained no undef elements....
This patch now ignores the number of undefs (getConstantSplatNode will return null if the build vector is all undefs).
The change has also unearthed a couple of missed opportunities in AVX512 comparison code that will need to be addressed.
Differential Revision: https://reviews.llvm.org/D26031
llvm-svn: 286238
|
|
|
|
|
|
|
|
|
|
| |
This patch avoids scalarization of CTLZ by instead expanding to use CTPOP (ref: "Hacker's Delight") when the necessary operations are available.
This also adds the necessary cost models for X86 SSE2 targets (the main beneficiary) to ensure vectorization only happens when its useful.
Differential Revision: https://reviews.llvm.org/D25910
llvm-svn: 286233
|
|
|
|
|
|
|
|
| |
gets to ISel.
Differential Revision: https://reviews.llvm.org/D26292
llvm-svn: 286119
|
|
|
|
| |
llvm-svn: 286075
|
|
|
|
| |
llvm-svn: 286071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Have MergeConsecutiveStores explicitly return information about the stores
that were merged, so that we can safely determine whether the starting
node has been freed.
Reviewers: chandlerc, bogner, niravd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25601
llvm-svn: 285916
|
|
|
|
|
|
|
|
| |
2 new intrinsics covering AVX-512 compress/expand functionality.
This implementation includes syntax, DAG builder, operation lowering and tests.
Does not include: handling of illegal data types, codegen prepare pass and the cost model.
llvm-svn: 285876
|
|
|
|
|
|
| |
Avoids APInt construction and slower comparisons.
llvm-svn: 285822
|
|
|
|
| |
llvm-svn: 285802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bits (PR30841)
This bug was exposed by using nsw/nuw for more aggressive folds in:
https://reviews.llvm.org/rL284844
The changes mimic the IR demanded bits logic in InstCombiner::SimplifyDemandedUseBits(),
but we can't just flip flag bits in the DAG; we have to create a new node that has the
bits cleared.
This should fix:
https://llvm.org/bugs/show_bug.cgi?id=30841
llvm-svn: 285656
|
|
|
|
| |
llvm-svn: 285522
|
|
|
|
| |
llvm-svn: 285521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
computeKnownBits
Currently computeKnownBits returns the common known zero/one bits for all elements of vector data, when we may only be interested in one/some of the elements.
This patch adds a DemandedElts argument that allows us to specify the elements we actually care about. The original computeKnownBits implementation calls with a DemandedElts demanding all elements to match current behaviour. Scalar types set this to 1.
The approach was found to be easier than trying to add a per-element known bits solution, for a similar usefulness given the combines where computeKnownBits is typically used.
I've only added support for a few opcodes so far (the ones that have proven straightforward to test), all others will default to demanding all elements but can be updated in due course.
DemandedElts support could similarly be added to computeKnownBitsForTargetNode in a future commit.
This looked like this had caused compile time regressions on some buildbots (and was reverted in rL285381), but appears to have just been a harmless bystander!
Differential Revision: https://reviews.llvm.org/D25691
llvm-svn: 285494
|
|
|
|
|
|
|
|
|
|
| |
Instead of asserting that the shift count is != 0 we just bail out
as it's not profitable trying to optimize a node which will be
removed anyway.
Differential Revision: https://reviews.llvm.org/D26098
llvm-svn: 285480
|