| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Note that the non-splat lshr+lshr test folded, but that does not
work in general. Something is missing or wrong in computeKnownBits
as the non-splat shl+shl test still shows.
llvm-svn: 288005
 | 
| | 
| 
| 
|  | 
llvm-svn: 288004
 | 
| | 
| 
| 
| 
| 
|  | 
Moved most of matching code into matchVectorShuffleAsShift to share with target shuffle combines (in a future commit).
llvm-svn: 288003
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
instruction's load size is smaller than the register size.
If we were to unfold these, the load size would be increased to the register size. This is not safe to do since the enlarged load can do things like cross a page boundary into a page that doesn't exist.
I probably missed some instructions, but this should be a large portion of them.
llvm-svn: 288001
 | 
| | 
| 
| 
|  | 
llvm-svn: 287997
 | 
| | 
| 
| 
|  | 
llvm-svn: 287995
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
instructions that don't have a restriction.
Most of these are the SSE4.1 PMOVZX/PMOVSX instructions which all read less than 128-bits. The only other was PMOVUPD which by definition is an unaligned load.
llvm-svn: 287991
 | 
| | 
| 
| 
| 
| 
|  | 
IsProfitableToFold.
llvm-svn: 287987
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
X86DAGToDAGISel::selectScalarSSELoad to pass the load node to IsProfitableToFold and IsLegalToFold.
Previously we were passing the SCALAR_TO_VECTOR node.
llvm-svn: 287986
 | 
| | 
| 
| 
|  | 
llvm-svn: 287985
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
from being folded multiple times.
Summary: When selectScalarSSELoad is looking for a scalar_to_vector of a scalar load, it makes sure the load is only used by the scalar_to_vector. But it doesn't make sure the scalar_to_vector is only used once. This can cause the same load to be folded multiple times. This can be bad for performance. This also causes the chain output to be duplicated, but not connected to anything so chain dependencies will not be satisfied.
Reviewers: RKSimon, zvi, delena, spatel
Subscribers: andreadb, llvm-commits
Differential Revision: https://reviews.llvm.org/D26790
llvm-svn: 287983
 | 
| | 
| 
| 
|  | 
llvm-svn: 287980
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
There are other spots where we can use this; we're currently dropping 
metadata in some places, and there are proposed changes where we will
want to propagate metadata.
IRBuilder's CreateSelect() already has a parameter like this, so this
change makes the regular 'Create' API line up with that.
llvm-svn: 287976
 | 
| | 
| 
| 
|  | 
llvm-svn: 287975
 | 
| | 
| 
| 
| 
| 
|  | 
folding tables.
llvm-svn: 287974
 | 
| | 
| 
| 
| 
| 
|  | 
tables.
llvm-svn: 287972
 | 
| | 
| 
| 
| 
| 
|  | 
available. Fix the avx512vl stack folding tests to clobber more registers or otherwise they use xmm16 after this change.
llvm-svn: 287971
 | 
| | 
| 
| 
|  | 
llvm-svn: 287970
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Reviewers: arsenm, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, llvm-commits, tony-tye
Differential Revision: https://reviews.llvm.org/D26724
llvm-svn: 287962
 | 
| | 
| 
| 
| 
| 
|  | 
The W bit distinquishes which operand is the memory operand. But if the mod bits are 3 then the memory operand is a register and there are two possible encodings. We already did this correctly for several other XOP instructions.
llvm-svn: 287961
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
tables for consistency.
Not sure this is truly needed but we had the floating point equivalents, the aligned equivalents, and the EVEX equivalents. So this just makes it complete.
llvm-svn: 287960
 | 
| | 
| 
| 
| 
| 
|  | 
alphabetical order. This is consistent with the older sections of the table. NFC
llvm-svn: 287956
 | 
| | 
| 
| 
| 
| 
| 
|  | 
We were a little sloppy with adding tailcall markers.  Be more
consistent by using setTailCallKind instead of setTailCall.
llvm-svn: 287955
 | 
| | 
| 
| 
| 
| 
|  | 
suggested as a better solution by Matt
llvm-svn: 287942
 | 
| | 
| 
| 
|  | 
llvm-svn: 287941
 | 
| | 
| 
| 
|  | 
llvm-svn: 287940
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
a vselect with 32-bit element size.
Summary:
Shuffle lowering may have widened the element size of a i32 shuffle to i64 before selecting X86ISD::SHUF128. If this shuffle was used by a vselect this can prevent us from selecting masked operations.
This patch detects this and changes the element size to match the vselect.
I don't handle changing integer to floating point or vice versa as its not clear if its better to push such a bitcast to the inputs of the shuffle or to the user of the vselect. So I'm ignoring that case for now.
Reviewers: delena, zvi, RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27087
llvm-svn: 287939
 | 
| | 
| 
| 
|  | 
llvm-svn: 287937
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit 4404d0d6e354e80dd7f8f0a0e12d8ad809cf007e.
llvm-svn: 287936
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit 79d4f8b8b1ce430c3d5dac4fc72a9eebaed24fe1.
llvm-svn: 287935
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit e834ce5976567575621901fb967b8018b9916d71.
llvm-svn: 287934
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit 057bbbe4ae170247ba37f08f2e70ef185267d1bb.
llvm-svn: 287933
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit 124ad83dae04514f943902446520c859adee0e96.
llvm-svn: 287932
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit f18de36554eb22416f8ba58e094e0272523a4301.
llvm-svn: 287931
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit a5a179ffd94fd4136df461ec76fb30f04afa87ce.
llvm-svn: 287930
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
instructions.
Summary:
The iterative algorithm for Loop Unswitching may render some of the branches unreachable in the unswitched loops.
Given the exponential nature of the algorithm, this is quite an overhead.
This patch fixes this problem by selectively unswitching only those branches within a loop that are reachable from the loop header.
Reviewers: Michael Zolothukin, Anna Thomas, Weiming Zhao.
Subscribers: llvm-commits.
Differential Revision: http://reviews.llvm.org/D26299
llvm-svn: 287925
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This patch corrects the behaviour of code such as:
   .local foo
   jal foo
foo:
to use the correct jal expansion when writing ELF files.
Patch by: Daniel Sanders
Reviewers: zoran.jovanovic, seanbruno, vkalintiris
Differential Revision: https://reviews.llvm.org/D24722
llvm-svn: 287918
 | 
| | 
| 
| 
|  | 
llvm-svn: 287909
 | 
| | 
| 
| 
|  | 
llvm-svn: 287908
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
same, then the condition doesn't matter and the vselect can be removed.
Selects with scalar condition already handle this correctly.
llvm-svn: 287904
 | 
| | 
| 
| 
|  | 
llvm-svn: 287898
 | 
| | 
| 
| 
|  | 
llvm-svn: 287889
 | 
| | 
| 
| 
| 
| 
|  | 
No functional change.
llvm-svn: 287888
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Vectorize UINT_TO_FP v2i32 -> v2f64 instead of scalarization (albeit still on the SIMD unit).
The codegen matches that generated by legalization (and is in fact used by AVX for UINT_TO_FP v4i32 -> v4f64), but has to be done in the x86 backend to account for legalization via 4i32.
Differential Revision: https://reviews.llvm.org/D26938
llvm-svn: 287886
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
AVX512DQ-only targets
Use 512-bit instructions with subvector insertion/extraction like we do in a number of similar circumstances
llvm-svn: 287882
 | 
| | 
| 
| 
| 
| 
|  | 
of upper 64-bits of xmm result
llvm-svn: 287878
 | 
| | 
| 
| 
|  | 
llvm-svn: 287877
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The bug arises during register allocation on i686 for
CMPXCHG8B instruction when base pointer is needed. CMPXCHG8B
needs 4 implicit registers (EAX, EBX, ECX, EDX) and a memory address,
plus ESI is reserved as the base pointer. With such constraints the only
way register allocator would do its job successfully is when the addressing
mode of the instruction requires only one register. If that is not the case
- we are emitting additional LEA instruction to compute the address.
It fixes PR28755.
Patch by Alexander Ivchenko <alexander.ivchenko@intel.com>
Differential Revision: https://reviews.llvm.org/D25088
llvm-svn: 287875
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Move the definitions of three variables out of the switch.
Patch by Alexander Ivchenko <alexander.ivchenko@intel.com>
Differential Revision: https://reviews.llvm.org/D25192
llvm-svn: 287874
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
- It does not modify the input instruction
- Second operand of any address is always an Index Register,
  make sure we actually check for that, instead of a check for
  an immediate value
Patch by Alexander Ivchenko <alexander.ivchenko@intel.com>
Differential Revision: https://reviews.llvm.org/D24938
llvm-svn: 287873
 |