| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
The 'fast' costs should only work for shifts by uniform constants (uniform non-constant are lowered using the slow default implementation).
Logical shifts were not taking into account that we must mask the psrlw result, so the costs needed to be doubled.
Added missing AVX2/AVX512BW costs as well.
llvm-svn: 291391
|
|
|
|
|
|
| |
XOP was prematurely matching, doubling the cost of ashr/lshr uniform shifts.
llvm-svn: 291390
|
|
|
|
|
|
| |
SSE41 provides pmulld which allows the simpler pslld/paddd/cvttps2dq/pmulld pattern than SSE2's use of pmuludq.
llvm-svn: 291372
|
|
|
|
| |
llvm-svn: 291366
|
|
|
|
|
|
| |
We were matching against general vector shift costs before the uniform splat costs
llvm-svn: 291365
|
|
|
|
| |
llvm-svn: 291354
|
|
|
|
|
|
| |
v64i8 shuffles (PR31470)
llvm-svn: 291347
|
|
|
|
| |
llvm-svn: 291269
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28403
llvm-svn: 291254
|
|
|
|
|
|
| |
Set the costs on the lowest target that supports the type.
llvm-svn: 291229
|
|
|
|
|
|
| |
Added a test demonstrating bug in AVX512 division costs
llvm-svn: 291228
|
|
|
|
|
|
|
|
| |
extract/insertion in AVX1 v4i64 MUL
Matches other MUL/ADD/SUB 256-bit case on AVX1
llvm-svn: 291149
|
|
|
|
| |
llvm-svn: 291140
|
|
|
|
|
|
|
|
| |
Currently only for broadcasts with input and output of the same width.
Differential Revision: https://reviews.llvm.org/D27811
llvm-svn: 291122
|
|
|
|
| |
llvm-svn: 291117
|
|
|
|
| |
llvm-svn: 291112
|
|
|
|
|
|
| |
Actual codegen is much better than the extract+insert patterns that was assumed.
llvm-svn: 290962
|
|
|
|
|
|
| |
(This changed was approved in https://reviews.llvm.org/D28118, but Simon asked to submit it separately).
llvm-svn: 290812
|
|
|
|
|
|
|
|
|
|
|
|
| |
X86 target does not provide any target specific cost calculation for interleave patterns.It uses the common target-independent calculation, which gives very high numbers. As a result, the scalar version is chosen in many cases. The situation on AVX-512 is even worse, since we have 3-src shuffles that significantly reduce the cost.
In this patch I calculate the cost on AVX-512. It will allow to compare interleave pattern with gather/scatter and choose a better solution (PR31426).
* Shiffle-broadcast cost will be changed in Simon's upcoming patch.
Differential Revision: https://reviews.llvm.org/D28118
llvm-svn: 290810
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned on PR30845, we were performing our vXi64 multiplication as:
AloBlo = pmuludq(a, b);
AloBhi = pmuludq(a, psrlqi(b, 32));
AhiBlo = pmuludq(psrlqi(a, 32), b);
return AloBlo + psllqi(AloBhi, 32)+ psllqi(AhiBlo, 32);
when we could avoid one of the upper shifts with:
AloBlo = pmuludq(a, b);
AloBhi = pmuludq(a, psrlqi(b, 32));
AhiBlo = pmuludq(psrlqi(a, 32), b);
return AloBlo + psllqi(AloBhi + AhiBlo, 32);
This matches the lowering on gcc/icc.
Differential Revision: https://reviews.llvm.org/D27756
llvm-svn: 290267
|
|
|
|
|
|
|
|
|
| |
This patch checks that the SlowMisaligned128Store subtarget feature is set
when penalizing such stores in getMemoryOpCost.
Differential Revision: https://reviews.llvm.org/D27677
llvm-svn: 289845
|
|
|
|
| |
llvm-svn: 289819
|
|
|
|
|
|
| |
Incorrect 'undef' mask index matching meant that broadcast shuffles could be detected as reverse shuffles
llvm-svn: 289811
|
|
|
|
| |
llvm-svn: 289800
|
|
|
|
|
|
|
|
| |
In the addressing mode, signed 9-bit imm is [-256, 255], not [-512, 511].
Differential Revision: https://reviews.llvm.org/D27480
llvm-svn: 288876
|
|
|
|
|
|
|
|
| |
Fix a bug when we call isLegalAddressingMode() from getGEPCost().
Differential Revision: https://reviews.llvm.org/D27357
llvm-svn: 288569
|
|
|
|
|
|
|
|
| |
VSX has instructions lxsiwax/lxsdx that can load 32/64 bit value into VSX register cheaply. That patch makes it known to memory cost model, so the vectorization of the test case in pr30990 is beneficial.
Differential Revision: https://reviews.llvm.org/D26713
llvm-svn: 288560
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when cost of scalar operations is evaluated the vector type is
used for scalar operations. Patch fixes this issue and fixes evaluation
of the vector operations cost.
Several test showed that vector cost model is too optimistic. It
allowed vectorization of 8 or less add/fadd operations, though scalar
code is faster. Actually, only for 16 or more operations vector code
provides better performance.
Differential Revision: https://reviews.llvm.org/D26277
llvm-svn: 288398
|
|
|
|
| |
llvm-svn: 288377
|
|
|
|
|
|
| |
This reverts commit a61718435fc4118c82f8aa6133fd81f803789c1e.
llvm-svn: 288371
|
|
|
|
| |
llvm-svn: 288369
|
|
|
|
|
|
|
|
| |
AVX512DQ-only targets
Use 512-bit instructions with subvector insertion/extraction like we do in a number of similar circumstances
llvm-svn: 287882
|
|
|
|
|
|
|
|
| |
AVX512DQ-only targets
Use 512-bit instructions with subvector insertion/extraction like we do in a number of similar circumstances
llvm-svn: 287762
|
|
|
|
| |
llvm-svn: 287760
|
|
|
|
| |
llvm-svn: 287756
|
|
|
|
|
|
|
|
| |
Better coverage of all legal types + special cases.
Removed old fptoui tests which are all handled in fptoui.ll
llvm-svn: 287678
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This extends FCOPYSIGN support to 512-bit vectors.
I've also added tests to show what the 128-bit and 256-bit cases look like with broadcast loads.
Reviewers: delena, zvi, RKSimon, spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26791
llvm-svn: 287298
|
|
|
|
|
|
| |
More realistic v16i8/v32i8/v64i8 MUL costs - we have to extend to vXi16, use PMULLW and then truncate the result
llvm-svn: 286838
|
|
|
|
|
|
|
|
| |
Add explicit v16i16/v32i8 ADD/SUB costs, matching the costs of v4i64/v8i32 - they were missing for some reason.
This has side effects on the LV max bandwidth tests (AVX1 now prefers 128-bit vectors vs AVX2 which still prefers 256-bit)
llvm-svn: 286832
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
There is a bug describing poor cost model for floating point operations:
Bug 29083 - [X86][SSE] Improve costs for floating point operations. This
patch is the second one in series of patches dealing with cost model.
Differential Revision: https://reviews.llvm.org/D25722
llvm-svn: 285564
|
|
|
|
| |
llvm-svn: 285329
|
|
|
|
|
|
|
|
|
|
| |
With DQI but without VLX, lower v2i64 and v4i64 MUL operations with v8i64 MUL (vpmullq).
Updated cost table accordingly.
Differential Revision: https://reviews.llvm.org/D26011
llvm-svn: 285304
|
|
|
|
| |
llvm-svn: 284940
|
|
|
|
|
|
| |
We were defaulting to SSE2 costs which weren't taking into account the availability of PBLENDW/PBLENDVB to improve merging of per-element shift results.
llvm-svn: 284939
|
|
|
|
| |
llvm-svn: 284938
|
|
|
|
|
|
|
|
| |
bit integer vectors
We weren't checking for uniform const costs before the general cost, resulting in very high estimates.
llvm-svn: 284755
|
|
|
|
|
|
|
|
| |
uniform const power-of-2
Shows poor costings in AVX1/AVX512BW for certain vector types
llvm-svn: 284748
|
|
|
|
|
|
|
|
|
|
| |
integer vectors
We weren't accounting for legal types on every subtarget, meaning that many of the costs were using defaults.
We still don't correctly cost (or test) the 512-bit sdiv/udiv by uniform const cases, nor the power-of-2 cases.
llvm-svn: 284744
|
|
|
|
|
|
|
|
| |
bit integer vectors
Shows current bug in AVX1/AVX512BW costs for 256 bit vector types
llvm-svn: 284723
|