| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in PR34686, we are relying on a PSHUFD+PSHUFLW+PSHUFHW shuffle chain for most general vXi16 unary shuffles.
This patch checks for simpler PSHUFLW+PSHUFD and PSHUFHW+PSHUFD cases beforehand, building on some existing code that just handled splat shuffles.
By doing so we also prevent premature use of PSHUFB shuffles which can be slower and require the creation/loading of constant shuffle masks.
We now have the 'fast-variable-shuffle' option for hardware that prefers combining 2 or more shuffles to VPSHUFB etc.
Differential Revision: https://reviews.llvm.org/D38318
llvm-svn: 321553
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revision 320791 introduced a pass that transforms reg+reg instructions to
reg+imm if they're fed by "load immediate". However, it didn't
handle out-of-range shifts correctly as reported in PR35688.
This patch fixes that and therefore the PR.
Furthermore, there was undefined behaviour in the patch where the RHS of an
initialization expression was 32 bits and constant `1` was shifted left 32
bits. This was fixed by ensuring the RHS is 64 bits just like the LHS.
Differential Revision: https://reviews.llvm.org/D41369
llvm-svn: 321551
|
| |
|
|
| |
llvm-svn: 321542
|
| |
|
|
| |
llvm-svn: 321541
|
| |
|
|
|
|
|
|
|
|
|
|
| |
narrower extend.
Previously we used an extend from v8i1 to v8i32/v8i64. Then extracted to the final width. But if we have VLX we should extract first. This way we don't end up with an overly large extend.
This allows us to use vcmpeq to make all ones for the sign extend when DQI isn't available. Otherwise we get a VPTERNLOG.
If we make v2i1/v4i1 legal like proposed in D41560, we could always do this and rely on the lowering of the extend to widen when necessary.
llvm-svn: 321538
|
| |
|
|
|
|
|
|
|
|
| |
The exception handler thunk needs to reference the LSDA of the parent
function, which won't be emitted if it's available_externally.
Fixes PR35736. ThinLTO ends up producing available_externally functions
that use _CxxFrameHandler3.
llvm-svn: 321532
|
| |
|
|
| |
llvm-svn: 321527
|
| |
|
|
|
|
|
|
|
|
| |
If there are 17 or more leading zeros to the v4i32 elements, then we can use PMADD for the integer multiply when PMULLD is unavailable or slow.
The 17 bits need to be zero as the PMADDWD performs a v8i16 signed-mul-extend + pairwise-add - the upper 16 so we're adding a zero pair and the 17th bit so we don't incorrectly sign extend.
Differential Revision: https://reviews.llvm.org/D41484
llvm-svn: 321516
|
| |
|
|
|
|
|
|
| |
My original implementation ran as a DAG combine post type legalization, but it turns out we don't run that DAG combine step if type legalization didn't change anything. Attempts to make the combine run before type legalization as well hit other issues.
So just do it in LowerMUL where we can catch more cases.
llvm-svn: 321496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r319980 added new patterns to the machine combiner for transforming (fsub (fmul
x y) z) into (fmla (fneg z) x y). That is, fsub's where the first source
operand is an fmul are transformed. We previously only matched the case where
the second source operand of an fsub was an fmul, transforming (fsub z (fmul x
y)) into (fmls z x y). Now, if we have an fsub where both source operands are
fmuls, both of the above patterns are applicable.
However, the order in which we add the patterns to the list of candidates
determines the transformation that takes place, since only the first pattern
that matches will be used. This patch changes the order these two patterns are
added to the list of candidates such that we prefer the case where the second
source operand is an fmul (the fmls case), rather than the other one (the
fmla/fneg case). When both source operands are fmuls, this ordering results in
fewer instructions.
Differential Revision: https://reviews.llvm.org/D41587
llvm-svn: 321491
|
| |
|
|
|
|
| |
v8i32 is legal von AVX1, but it doesn't have pmuludq for it.
llvm-svn: 321490
|
| |
|
|
|
|
|
|
| |
For example, float operations may fail to constant fold under certain circumstances (inf/nan/denormal creation etc.)
Reduced from oss-fuzz #4802 test case
llvm-svn: 321488
|
| |
|
|
|
|
|
|
| |
getSExtValue/getZExtValue
Reduced from oss-fuzz #4782 test case
llvm-svn: 321464
|
| |
|
|
| |
llvm-svn: 321462
|
| |
|
|
|
|
|
|
| |
(add X, 1), 2) for i1
Reduced from oss-fuzz #4773 test case
llvm-svn: 321455
|
| |
|
|
| |
llvm-svn: 321452
|
| |
|
|
|
|
| |
SSE/AVX counterparts.
llvm-svn: 321451
|
| |
|
|
|
|
|
|
|
|
| |
upper bits are all sign bits or zeros.
Normally we catch this during lowering, but vXi64 mul is considered legal when we have AVX512DQ.
This DAG combine allows us to avoid PMULLQ with AVX512DQ if we can prove its unnecessary. PMULLQ is 3 uops that take 4 cycles each. While pmuldq/pmuludq is only one 4 cycle uop.
llvm-svn: 321437
|
| |
|
|
|
|
|
|
| |
demonstrate where we fail to use pmuldq/pmuludq and use to pmullq instead.
It's nice that pmullq exists, but it has higher latency and probably lower throughput than pmuldq/pmuludq. We should prefer those if we can.
llvm-svn: 321436
|
| |
|
|
| |
llvm-svn: 321426
|
| |
|
|
|
|
|
|
| |
(PR21160, PR34080, PR34454).
Match regular x87 memory fold instructions with load/sideeffects tags, to prevent the schedulers from re-ordering them across the fnstcw/fldcw sequences for truncating stores while they are still pseudo during the stack conversion pass.
llvm-svn: 321424
|
| |
|
|
|
|
| |
scheduled differently
llvm-svn: 321423
|
| |
|
|
|
|
| |
Did my best to reduce this, but the X87 scheduling bug is hard to hit at the best of times...
llvm-svn: 321422
|
| |
|
|
|
|
| |
Previously we extended v2i1 to v2f64 and then tried to use cvtuqq2pd/cvtqq2pd, but that only works with avx512dq. So we ended up scalarizing it. Now we widen to v4i1 first and extend to v4i32.
llvm-svn: 321420
|
| |
|
|
|
|
|
|
| |
other combines a chance to run.
This moves the combine for turning ANDs into shuffle with zero out of SimplifyVBinOps and places it only in visitAND below the reassociate handling. This fixes the specific case I noticed where we failed to combine two ands with constants.
llvm-svn: 321417
|
| |
|
|
|
|
| |
RHS not just all zeros/ones.
llvm-svn: 321415
|
| |
|
|
|
|
| |
of constant build vectors.
llvm-svn: 321414
|
| |
|
|
|
|
| |
This can help AVX-512 code where mask types are legal allowing us to remove extends and truncates to/from mask types.
llvm-svn: 321408
|
| |
|
|
|
|
|
|
|
|
| |
TargetLowering::getVectorElementPointer so that the FrameIndex is on the left.
This seems to improve X86's ability to match this into an address computation. Otherwise the other operand gets assigned to the base register and the stack pointer + frame index ends up in the index register. But index registers can't encode ESP/RSP so we end up having to move it into another register to meet the constraint.
I could try to improve the address matcher in X86, but swapping the producer seemed easier. Several other places already have the operands in this order so this is at least consistent.
llvm-svn: 321370
|
| |
|
|
|
|
|
|
| |
non-constant index just use either a 128-bit type or the vXi8 type with the correct number of elements.
Despite what the comment said there isn't better codegen for 512-bit vectors. The 128/256/512 bit implementation jus stores to memory and loads an element. There's no advantage to doing that with a larger size. In fact in many cases it causes a stack realignment and generates worse code.
llvm-svn: 321369
|
| |
|
|
|
|
| |
calls options. NFC
llvm-svn: 321357
|
| |
|
|
|
|
|
| |
Mark conversions between pointers and 32-bit scalars as legal, map them
to the GPR and select to a simple COPY.
llvm-svn: 321356
|
| |
|
|
|
|
|
|
|
|
| |
Pointer constants are pretty rare, since we usually represent them as
integer constants and then cast to pointer. One notable exception is the
null pointer constant, which is represented directly as a G_CONSTANT 0
with pointer type. Mark it as legal and make sure it is selected like
any other integer constant.
llvm-svn: 321354
|
| |
|
|
|
|
|
| |
Improve ReduceLoadWidth for SRL Patch is causing an issue on the
PPC64 BE santizer.
llvm-svn: 321349
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
for prefetch instructions.
Previously prefetch was only considered legal if sse was enabled, but it should be supported with 3dnow as well.
The prfchw flag now imply at least some form of prefetch without the write hint is available, either the sse or 3dnow version. This is true even if 3dnow and sse are explicitly disabled.
Similarly prefetchwt1 feature implies availability of prefetchw and the the prefetcht0/1/2/nta instructions. This way we can support _MM_HINT_ET0 using prefetchw and _MM_HINT_ET1 with prefetchwt1. And its assumed that if we have levels for the write hint we would have levels for the non-write hint, thus why we enable the sse prefetch instructions.
I believe this behavior is consistent with gcc. I've updated the prefetch.ll to test all of these combinations.
llvm-svn: 321335
|
| |
|
|
| |
llvm-svn: 321334
|
| |
|
|
|
|
|
|
| |
extract_vector_elt from vXi1 with a non-const index.
We have a better range of instructions we can use if we can fill with the value i1 value rather than zeroing.
llvm-svn: 321315
|
| |
|
|
|
|
|
|
| |
512-bit if we have VLX.
This should only affect what we do for v8i16. Previously we went to v8i64, but if we have VLX we only need v8i32. This prevents an unnecessary zmm usage.
llvm-svn: 321303
|
| |
|
|
|
|
|
|
| |
We should have equally good shuffle options for v8i32 with VLX. This was spotted during my attempts to remove 512-bit vectors from SKX.
We still use 512-bits for v16i1, v32i1, and v64i1. I'm less sure we can handle those well with narrower vectors. i32 and i64 element sizes get the best shuffle support.
llvm-svn: 321291
|
| |
|
|
|
|
|
|
| |
Patch to allow detectAVGPattern handle vectors larger than the legal size (128 SSE2, 256 AVX2, 512 AVX512BW), splitting the vectors accordingly.
Differential Revision: https://reviews.llvm.org/D41440
llvm-svn: 321288
|
| |
|
|
|
|
|
|
| |
combine to work on non-splat vectors
The knownbits_mask_or_shuffle_uitofp change is interesting - shuffle combines manage to kick in, removing the AND constant mask load. For targets with fast-variable-shuffle this should reduce further to VPOR+VPSHUFB+VCVTDQ2PS.
llvm-svn: 321279
|
| |
|
|
| |
llvm-svn: 321278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build failure was caused by an assertion in pre-legalization DAGCombine:
Combining: t6: ppcf128 = uint_to_fp t5
... into: t20: f32 = PPCISD::FCFIDUS t19
which is clearly wrong since ppcf128 are definitely different type with f32 and
we cannot change the node value type when do DAGCombine. The fix is don't
handle ppc_fp128 or i1 conversions in PPCTargetLowering::combineFPToIntToFP and
leave it to downstream to legalize it and expand it to small legal types.
Differential Revision: https://reviews.llvm.org/D41411
llvm-svn: 321276
|
| |
|
|
|
|
| |
work on non-splat vectors
llvm-svn: 321275
|
| |
|
|
| |
llvm-svn: 321268
|
| |
|
|
| |
llvm-svn: 321261
|
| |
|
|
|
|
|
|
|
|
|
| |
If the SRL node is only used by an AND, we may be able to set the
ExtVT to the width of the mask, making the AND redundant. To support
this, another check has been added in isLegalNarrowLoad which queries
whether the load is valid.
Differential Revision: https://reviews.llvm.org/D41350
llvm-svn: 321259
|
| |
|
|
|
|
| |
PSHUFB has the ability to implicitly 0 elements which VPERMI2W can't do. So give a chance to use it first.
llvm-svn: 321251
|
| |
|
|
|
|
| |
otherwise used two PSHUFBs ORed together.
llvm-svn: 321249
|
| |
|
|
|
|
| |
supported.
llvm-svn: 321248
|