| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
dependent instruction selection.
Differential revision: https://reviews.llvm.org/D35267
llvm-svn: 326703
|
|
|
|
| |
llvm-svn: 326679
|
|
|
|
|
|
| |
storing v2i1 and v4i1 constants.
llvm-svn: 326678
|
|
|
|
|
|
|
|
| |
fix a crash if we are storing a bitcast of a constant.
Loading a constant into a k-register in AVX512 requires a bitcast from a scalar constant. In the test case here we have a k-register store that gets split into multiple parts of KNL. MergeConsecutiveStores sees each of these pieces as a consecutive store and looks through the bitcast to find the underly scalar constant. But when we went to create the combined store we didn't look through the same bitcast.
llvm-svn: 326677
|
|
|
|
|
|
|
|
| |
Add tests for FIADD/FISUB/FISUBR/FIMUL/FIDIV/FIDIVR
Shows we have more FILD stack usage than necessary (arg load, spill, reload to x87)
llvm-svn: 326674
|
|
|
|
| |
llvm-svn: 326670
|
|
|
|
|
|
|
|
| |
legalization if AVX512DQ is not supported.
We were previously doing this with isel patterns. Moving it to op legalization gives us chance to see the required bitcast earlier. And it lets us remove some isel patterns.
llvm-svn: 326669
|
|
|
|
|
|
|
|
|
|
|
|
| |
use a SCALAR_TO_VECTOR rather than a single element BUILD_VECTOR to convert back to a vector type.
X86 considers v1i1 a legal type under AVX512 and as such a truncate from a v1iX type to v1i1 can be turned into a scalar truncate plus a conversion to v1i1. We would much prefer a v1i1 SCALAR_TO_VECTOR over a one element BUILD_VECTOR.
During lowering we were detecting the v1i1 BUILD_VECTOR as a splat BUILD_VECTOR like we try to do for v2i1/v4i1/etc. In this case we create (select i1 splat_elt, v1i1 all-ones, v1i1 all-zeroes). That goes through some more legalization and we end up with a CMOV choosing between 0 and 1 in scalar and a scalar_to_vector.
Arguably we could detect the v1i1 BUILD_VECTOR and do this better in X86 target code. But just using a SCALAR_TO_VECTOR in legalization is much easier.
llvm-svn: 326637
|
|
|
|
| |
llvm-svn: 326627
|
|
|
|
|
|
| |
I forgot to check in the updated test cases after the r326613 commit.
llvm-svn: 326616
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds back-end support for the anyregcc calling convention
for use with patchpoints.
Since all registers are considered call-saved with anyregcc
(except for 0 and 1 which may still be clobbered by PLT stubs
and the like), this required adding support for saving and
restoring vector registers in prologue/epilogue code for the
first time. This is not used by any other calling convention.
llvm-svn: 326612
|
|
|
|
|
|
|
| |
This adds back-end support for the @llvm.experimental.stackmap and
@llvm.experimental.patchpoint intrinsics.
llvm-svn: 326611
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On SystemZ we need to provide a register save area of 160 bytes to
any called function. This size needs to be added when allocating
stack in the function prologue. However, it was not accounted for
as part of MachineFrameInfo::getStackSize(); instead the back-end
used a private routine getAllocatedStackSize().
This is OK for code-gen purposes, but it breaks other users of
the getStackSize() routine, in particular it breaks the recently-
added -stack-size-section feature.
Fix this by updating the main stack size tracked by common code
(in emitPrologue) instead of using the private routine.
No change in code generation intended.
llvm-svn: 326610
|
|
|
|
|
|
|
|
| |
This adds support for specifying vector registers for use with inline
asm statements, either via the 'v' constraint or by explicit register
names (v0 ... v31).
llvm-svn: 326609
|
|
|
|
| |
llvm-svn: 326599
|
|
|
|
|
|
|
|
| |
These instructions are double-pumped, split into 2 128-bit ops and then passing through either FPU pipe.
Found while testing llvm-mca (D43951)
llvm-svn: 326597
|
|
|
|
|
|
|
|
| |
Fixes PR36532
Differential Revision: https://reviews.llvm.org/D43960
llvm-svn: 326596
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the x32 ABI, since the base pointer register (EBX) is a callee save register
it should be saved before use.
This fixes https://bugs.llvm.org/show_bug.cgi?id=36011
Differential Revision: https://reviews.llvm.org/D42358
Patch by Pratik Bhatu
llvm-svn: 326593
|
|
|
|
| |
llvm-svn: 326589
|
|
|
|
| |
llvm-svn: 326588
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326587
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an Armv6m function dynamically re-aligns the stack, access to incoming
stack arguments (and to stack area, allocated for register varargs) is done via
SP, which is incorrect, as the SP is offset by an unknown amount relative to the
value of SP upon function entry.
This patch fixes it, by making access to "fixed" frame objects be done via FP
when the function needs stack re-alignment. It also changes the access to
"fixed" frame objects be done via FP (instead of using R6/BP) also for the case
when the stack frame contains variable sized objects. This should allow more
objects to fit within the immediate offset of the load instruction.
All of the above via a small refactoring to reuse the existing
`ARMFrameLowering::ResolveFrameIndexReference.`
Differential Revision: https://reviews.llvm.org/D43566
llvm-svn: 326584
|
|
|
|
|
|
| |
While working on PR36557.
llvm-svn: 326575
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code generation of VLD3, VLD4, VST3 and VST4 with register writeback is
broken due to 2 separate bugs:
1) VLD1d64TPseudoWB_register and VLD1d64QPseudoWB_register are missing
rules to expand them to non pseudo MIR. These are selected for
ARMISD::VLD3_UPD/VLD4_UPD with v1i64 vectors in SelectVLD.
2) Selection of the right VLD/VST instruction is broken for load and
store of 3 and 4 v1i64 vectors. SelectVLD and SelectVST are called
with MIR opcode for fixed writeback (ie increment is access size)
and call getVLDSTRegisterUpdateOpcode() to select an opcode with
register writeback if base register update is of a different size.
Since getVLDSTRegisterUpdateOpcode() only knows about
VLD1/VLD2/VST1/VST2 the call is currently conditional on the number
of element in the vector.
However, VLD1/VST1 is selected by SelectVLD/SelectVST's caller for
load and stores of 3 or 4 v1i64 vectors. Therefore the opcode is not
updated which later lead to a fixed writeback instruction being
constructed with an extra operand for the register writeback.
This patch addresses the two issues as follows:
- it adds the necessary mapping from VLD1d64TPseudoWB_register and
VLD1d64QPseudoWB_register to VLD1d64Twb_register and
VLD1d64Qwb_register respectively. Like for the existing _fixed
variants, the cost of these is bumped for unaligned access.
- it changes the logic in SelectVLD and SelectVSD to call isVLDfixed
and isVSTfixed respectively to decide whether the opcode should be
updated. It also reworks the logic and comments for pushing the
writeback offset operand and r0 operand to clarify the logic:
writeback offset needs to be pushed if it's a register writeback,
r0 needs to be pushed if not and the instruction is a
VLD1/VLD2/VST1/VST2.
Reviewers: rengolin, t.p.northover, samparker
Reviewed By: samparker
Patch by Thomas Preud'homme <thomas.preudhomme@arm.com>
Differential Revision: https://reviews.llvm.org/D42970
llvm-svn: 326570
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326567
|
|
|
|
|
|
|
|
|
| |
i16 capable ASICs do not support i16 operands for this instruction.
Add tablegen pattern to merge chained i16 additions.
Differential Revision: https://reviews.llvm.org/D43985
llvm-svn: 326535
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326534
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326533
|
|
|
|
| |
llvm-svn: 326532
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326526
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326525
|
|
|
|
| |
llvm-svn: 326524
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326523
|
|
|
|
|
|
|
|
|
|
| |
extending for vectors.
Masking first, prevents the extend from being combine with loads. Its also interfering with some vXi1 extraction code.
Differential Revision: https://reviews.llvm.org/D42679
llvm-svn: 326500
|
|
|
|
|
|
|
|
|
|
|
|
| |
64-bit MMX constant generation usually ends up lowering into SSE instructions before being spilled/reloaded as a MMX type.
This patch bitcasts the constant to a double value to allow correct loading directly to the MMX register.
I've added MMX constant asm comment support to improve testing, it's better to always print the double values as hex constants as MMX is mainly an integer unit (and even with 3DNow! its just floats).
Differential Revision: https://reviews.llvm.org/D43616
llvm-svn: 326497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
splats of constants.
This supports things like
(setcc ugt X, 0) -> (setcc ne X, 0)
I've restricted to only make changes to vectors before legalize ops because I doubt all targets have accurate condition code legality information for vectors given how little we did before.
Differential Revision: https://reviews.llvm.org/D42948
llvm-svn: 326495
|
|
|
|
| |
llvm-svn: 326494
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326490
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326489
|
|
|
|
| |
llvm-svn: 326488
|
|
|
|
| |
llvm-svn: 326484
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326482
|
|
|
|
| |
llvm-svn: 326481
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326479
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326477
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326472
|
|
|
|
| |
llvm-svn: 326471
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326470
|
|
|
|
|
|
| |
Patch by Tom Stellard
llvm-svn: 326468
|