| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
explicit about the operands. Split out the different variants into separate
instructions. This gives us the ability to, among other things, assign
different scheduling itineraries to the variants. rdar://8477752.
llvm-svn: 117409
|
|
|
|
| |
llvm-svn: 117050
|
|
|
|
| |
llvm-svn: 116776
|
|
|
|
| |
llvm-svn: 115890
|
|
|
|
| |
llvm-svn: 115884
|
|
|
|
|
|
|
|
|
| |
which require the use of the shifter-operand. This will be used to split
the ldr/str instructions such that those versions needing the shifter operand
can get a different scheduling itenerary, as in some cases, the use of the
shifter can cause different scheduling than the simpler forms.
llvm-svn: 115066
|
|
|
|
| |
llvm-svn: 115043
|
|
|
|
| |
llvm-svn: 114709
|
|
|
|
| |
llvm-svn: 114696
|
|
|
|
|
|
|
|
|
|
|
| |
passed the root of the match, even though only a few patterns
actually needed this (one in X86, several in ARM [which should
be refactored anyway], and some in CellSPU that I don't feel
like detangling). Instead of requiring all ComplexPatterns to
take the dead root, have targets opt into getting the root by
putting SDNPWantRoot on the ComplexPattern.
llvm-svn: 114471
|
|
|
|
| |
llvm-svn: 113837
|
|
|
|
|
|
|
| |
register allocation. Remove the NEONPreAllocPass, which is no longer needed.
Yeah!!
llvm-svn: 113818
|
|
|
|
|
|
|
| |
pseudo-instruction approach. Change ARMExpandPseudoInsts to use a table
to record all the NEON load/store information.
llvm-svn: 113812
|
|
|
|
|
|
| |
pattern, so there is no need to define a matching function.
llvm-svn: 113122
|
|
|
|
|
|
|
|
|
| |
instructions prior to regalloc. Since it's getting a little close to
the 2.8 branch deadline, I'll have to leave the rest of the instructions
handled by the NEONPreAllocPass for now, but I didn't want to leave half
of the VLD instructions converted and the other half not.
llvm-svn: 112983
|
|
|
|
|
|
| |
after regalloc.
llvm-svn: 112825
|
|
|
|
|
|
| |
the testcases should be merged.
llvm-svn: 112711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
int x(int t) {
if (t & 256)
return -26;
return 0;
}
We generate this:
tst.w r0, #256
mvn r0, #25
it eq
moveq r0, #0
while gcc generates this:
ands r0, r0, #256
it ne
mvnne r0, #25
bx lr
Scandalous really!
During ISel time, we can look for this particular pattern. One where we have a
"MOVCC" that uses the flag off of a CMPZ that itself is comparing an AND
instruction to 0. Something like this (greatly simplified):
%r0 = ISD::AND ...
ARMISD::CMPZ %r0, 0 @ sets [CPSR]
%r0 = ARMISD::MOVCC 0, -26 @ reads [CPSR]
All we have to do is convert the "ISD::AND" into an "ARM::ANDS" that sets [CPSR]
when it's zero. The zero value will all ready be in the %r0 register and we only
need to change it if the AND wasn't zero. Easy!
llvm-svn: 112664
|
|
|
|
| |
llvm-svn: 112357
|
|
|
|
| |
llvm-svn: 112336
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all the other LDM/STM instructions. This fixes asm printer crashes when
compiling with -O0. I've changed one of the NEON tests (vst3.ll) to run
with -O0 to check this in the future.
Prior to this change VLDM/VSTM used addressing mode #5, but not really.
The offset field was used to hold a count of the number of registers being
loaded or stored, and the AM5 opcode field was expanded to specify the IA
or DB mode, instead of the standard ADD/SUB specifier. Much of the backend
was not aware of these special cases. The crashes occured when rewriting
a frameindex caused the AM5 offset field to be changed so that it did not
have a valid submode. I don't know exactly what changed to expose this now.
Maybe we've never done much with -O0 and NEON. Regardless, there's no longer
any reason to keep a count of the VLDM/VSTM registers, so we can use
addressing mode #4 and clean things up in a lot of places.
llvm-svn: 112322
|
|
|
|
| |
llvm-svn: 112208
|
|
|
|
| |
llvm-svn: 112170
|
|
|
|
|
|
|
|
|
|
|
| |
with the VST4 instructions. Until after register allocation, we want to
represent sets of adjacent registers by a single super-register. These
VST4 pseudo instructions have a single QQ or QQQQ source register operand.
They get expanded to the real VST4 instructions with 4 separate D register
operands. Once this conversion is complete, we'll be able to remove the
NEONPreAllocPass and avoid some fragile and hacky code elsewhere.
llvm-svn: 112108
|
|
|
|
| |
llvm-svn: 111277
|
|
|
|
|
|
| |
shifts cost extra instructions so it might be better to emit them separately to take advantage of dual-issues.
llvm-svn: 109934
|
|
|
|
| |
llvm-svn: 107743
|
|
|
|
|
|
| |
allocated to consecutive registers.
llvm-svn: 107730
|
|
|
|
| |
llvm-svn: 107131
|
|
|
|
| |
llvm-svn: 106279
|
|
|
|
|
|
| |
now, so there's no need to disable them.
llvm-svn: 106155
|
|
|
|
|
|
|
|
|
|
|
| |
VECTOR_SHUFFLEs to REG_SEQUENCE instructions. The standard ISD::BUILD_VECTOR
node corresponds closely to REG_SEQUENCE but I couldn't use it here because
its operands do not get legalized. That is pretty awful, but I guess it
makes sense for other targets. Instead, I have added an ARM-specific version
of BUILD_VECTOR that will have its operands properly legalized.
This fixes the rest of Radar 7872877.
llvm-svn: 105439
|
|
|
|
|
|
|
|
|
| |
A temporary flag -arm-tail-calls defaults to off,
so there is no functional change by default.
Intrepid users may try this; simple cases work
but there are bugs.
llvm-svn: 105413
|
|
|
|
| |
llvm-svn: 105350
|
|
|
|
|
|
|
| |
the instruction class for t2RSB to add that operand in svn r104582.
Radar 8033757.
llvm-svn: 104907
|
|
|
|
|
|
| |
Add assertions in places that depend on consecutive indices.
llvm-svn: 104510
|
|
|
|
|
|
| |
from ARMRegisterInfo.h
llvm-svn: 104508
|
|
|
|
| |
llvm-svn: 104110
|
|
|
|
|
|
| |
Using NEON load / store multiple instructions will no longer create gobs of vmov of D registers!
llvm-svn: 103960
|
|
|
|
| |
llvm-svn: 103898
|
|
|
|
| |
llvm-svn: 103868
|
|
|
|
| |
llvm-svn: 103851
|
|
|
|
| |
llvm-svn: 103833
|
|
|
|
| |
llvm-svn: 103790
|
|
|
|
| |
llvm-svn: 103749
|
|
|
|
| |
llvm-svn: 103453
|
|
|
|
| |
llvm-svn: 103437
|
|
|
|
| |
llvm-svn: 103411
|
|
|
|
|
|
| |
(replacing the previous patch for the same issue).
llvm-svn: 103183
|
|
|
|
|
|
| |
<Edmund.Grimley-Evans@arm.com>
llvm-svn: 103181
|