| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Based on a patch by jfcaron3@gmail.com!
PR19806
llvm-svn: 209216
|
|
|
|
|
|
|
|
|
|
|
|
| |
and tests
After discussion with Zoran, we have decided to temporarily revert this commit.
It's causing some difficult to resolve conflicts and we are under time pressure
to deliver an initial MIPS64r6 compiler.
We will re-apply an equivalent patch once the time pressure has passed.
llvm-svn: 209211
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the results of a ComplexPattern check to be distributed to separate
named Operands, instead of the current system where all results must apply (and
match perfectly) with a single Operand.
For example, if "some_addrmode" is a ComplexPattern producing two results, you
can write:
def : Pat<(load (some_addrmode GPR64:$base, imm:$offset)),
(INST GPR64:$base, imm:$offset)>;
This should allow neater instruction definitions in TableGen that don't put all
possible aspects of addressing into a single operand, but are still usable with
relatively simple C++ CodeGen idioms.
llvm-svn: 209206
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 209203
|
|
|
|
| |
llvm-svn: 209200
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When multiple aliases overlap, the correct string to print can often be
determined purely by considering the InstAlias declarations in some particular
order. This allows the user to specify that order manually when desired,
without resorting to hacking around with the default lexicographical order on
Record instantiation, which is error-prone and ugly.
I was also mistaken about "add w2, w3, w4" being the same as "add w2, w3, w4,
uxtw". That's only true if Rn is the stack pointer.
llvm-svn: 209199
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to Intel Software Optimization Manual on Silvermont in some cases LEA
is better to be replaced with ADD instructions:
"The rule of thumb for ADDs and LEAs is that it is justified to use LEA
with a valid index and/or displacement for non-destructive destination purposes
(especially useful for stack offset cases), or to use a SCALE.
Otherwise, ADD(s) are preferable."
Differential Revision: http://reviews.llvm.org/D3826
llvm-svn: 209198
|
|
|
|
|
|
|
| |
Patch by Dave Estes<cestes@codeaurora.org>!
PR19761 http://reviews.llvm.org/D3829
llvm-svn: 209176
|
|
|
|
| |
llvm-svn: 209174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types larger than i128.
Currently the X86 backend doesn't support types larger than i128 very well. For
example an i192 multiply will assert in codegen when the 2nd argument is a constant and the constant got hoisted.
This fix changes the cost model to never hoist constants for types larger than
i128. Once the codegen issues have been resolved, the cost model can be updated
to allow also larger types.
This is related to <rdar://problem/16954938>
llvm-svn: 209162
|
|
|
|
|
|
|
|
|
|
| |
Instructions TZCNT (requires BMI1) and LZCNT (requires LZCNT), always
provide the operand size as output if the input operand is zero.
We can take advantage of this knowledge during instruction selection
stage in order to simplify a few corner case.
llvm-svn: 209159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When inserting an element that's coming from a vector load or a broadcast
of a vector (or scalar) load, combine the load into the insertps
instruction.
Added PerformINSERTPSCombine for the case where we need to fix the load
(load of a vector + insertps with a non-zero CountS).
Added patterns for the broadcasts.
Also added tests for SSE4.1, AVX, and AVX2.
Reviewers: delena, nadav, craig.topper
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3581
llvm-svn: 209156
|
|
|
|
| |
llvm-svn: 209139
|
|
|
|
| |
llvm-svn: 209134
|
|
|
|
| |
llvm-svn: 209132
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3808
llvm-svn: 209129
|
|
|
|
|
|
| |
case labels. No functional changes intended.
llvm-svn: 209126
|
|
|
|
|
|
|
|
|
|
| |
bswap not.
- On ARM/ARM64 we get a vrev because the shuffle matching code is really smart. We still unroll anything that's not v4i32 though.
- On X86 we get a pshufb with SSSE3. Required more cleverness in isShuffleMaskLegal.
- On PPC we get a vperm for v8i16 and v4i32. v2i64 is unrolled.
llvm-svn: 209123
|
|
|
|
|
|
|
|
|
| |
Rather than create a series of function calls to setup the library calls, create
a table with the information and just use the table to drive the configuration
of the library calls. This makes it easier to both inspect the list as well as
to modify it. NFC.
llvm-svn: 209089
|
|
|
|
|
|
|
|
|
| |
Windows on ARM uses R11 for the frame pointer even though the environment is a
pure Thumb-2, thumb-only environment. Replicate this behaviour to improve
Windows ABI compatibility. This register is used for fast stack walking, and
thus is part of the Windows ABI.
llvm-svn: 209085
|
|
|
|
|
|
|
|
|
|
|
| |
Use the ARMBaseRegisterInfo to query the frame register. The base register info
is aware of the frame register that is used for the frame pointer. Use that to
determine the frame register rather than duplicating the knowledge. Although,
the code path is slightly different in that it may return SP, that can only
occur if the frame pointer has been omitted in the machine function, which is
supposed to contain the desired value in that case.
llvm-svn: 209084
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a mechanical change changing all the call sites to the newer
chained-function construction pattern. This removes the horrible 15-parameter
constructor for the CallLoweringInfo in favour of setting properties of the call
via chained functions. No functional change beyond the removal of the old
constructors are intended.
llvm-svn: 209082
|
|
|
|
|
|
|
|
|
| |
This is a preliminary step to help ease the construction of CallLoweringInfo.
Changing the construction to a chained function pattern requires that the
parameter be nullable. However, rather than copying the vector, save a pointer
rather than the reference to permit a late binding of the arguments.
llvm-svn: 209080
|
|
|
|
|
|
| |
Remove some whitespace. NFC.
llvm-svn: 209079
|
|
|
|
|
|
| |
No functional change, just a small cleanup.
llvm-svn: 209064
|
|
|
|
|
|
|
|
| |
WoA uses COFF, not ELF. ARMISelLowering::createTLOF would previously return ELF
for any non-MachO platform. This was a missed site when the original change for
target format support for Windows on ARM was done.
llvm-svn: 209057
|
|
|
|
|
|
|
|
|
|
| |
were added in SSE2, no SSSE3. Found this while auditing all uses of
SSSE3 in the X86 target. I don't actually expect this to make
a significant difference on anything and I don't have any detailed test
cases but I updated the existing test cases that already covered some of
this code path.
llvm-svn: 209056
|
|
|
|
| |
llvm-svn: 209048
|
|
|
|
|
|
|
|
|
|
| |
vselects with constant masks, after legalization, will get turned into
specialized shuffle_vectors so they can be matched to blend+imm
instructions.
Fixed some tests.
llvm-svn: 209044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LowerVSELECT will, if possible, generate a X86ISD::BLENDI DAG node if the
condition is constant and we can emit that instruction, given the
subtarget.
This is not enough for all cases. An additional SELECTCombine optimization
will be committed.
Fixed tests that were expecting variable blends but where a blend+imm can
be generated.
Added test where we can't emit blend+immediate.
Added avx2 blend+imm tests.
llvm-svn: 209043
|
|
|
|
|
|
|
|
| |
No functionality change intended. The types that previously were set to
lower as Expand or Legal are doing the same thing with this lowering
function.
llvm-svn: 209042
|
|
|
|
| |
llvm-svn: 209040
|
|
|
|
|
|
|
|
| |
This will allow us to use a single MachineInstr to represent
instructions which behave the same but have different encodings
on some subtargets.
llvm-svn: 209028
|
|
|
|
|
|
| |
This was inspired by the PredicateControl class in the MIPS backend.
llvm-svn: 209027
|
|
|
|
| |
llvm-svn: 209026
|
|
|
|
| |
llvm-svn: 209025
|
|
|
|
| |
llvm-svn: 209024
|
|
|
|
| |
llvm-svn: 209023
|
|
|
|
|
|
|
| |
Patch by Dave Estes <cestes@codeaurora.org>
http://reviews.llvm.org/D3769
llvm-svn: 209001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ldr x1, [x0, #64]
add x0, x0, #64
->
ldr x1, [x0], #64
is not a valid transformation, the correct transformation (and what the code actually does) is:
ldr x1, [x0, #64]
add x0, x0, #64
->
ldr x1, [x0, #64]!
llvm-svn: 208998
|
|
|
|
|
|
| |
Patch by Moritz Roth!
llvm-svn: 208994
|
|
|
|
|
|
| |
Patch by Moritz Roth!
llvm-svn: 208992
|
|
|
|
|
|
|
|
| |
immediately for now.
Patch by Moritz Roth!
llvm-svn: 208991
|
|
|
|
|
|
| |
Patch by Moritz Roth!
llvm-svn: 208990
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3743
llvm-svn: 208987
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3707
llvm-svn: 208981
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r208934.
The patch depends on aliases to GEPs with non zero offsets. That is not
supported and fairly broken.
The good news is that GlobalAlias is being redesigned and will have support
for offsets, so this patch should be a nice match for it.
llvm-svn: 208978
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3718
llvm-svn: 208977
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3691
llvm-svn: 208974
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3788
llvm-svn: 208971
|