| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 151251
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value is zero. Instead of a cmov + op, issue an conditional op instead. e.g.
cmp r9, r4
mov r4, #0
moveq r4, #1
orr lr, lr, r4
should be:
cmp r9, r4
orreq lr, lr, #1
That is, optimize (or x, (cmov 0, y, cond)) to (or.cond x, y). Similarly extend
this to xor as well as (and x, (cmov -1, y, cond)) => (and.cond x, y).
It's possible to extend this to ADD and SUB but I don't think they are common.
rdar://8659097
llvm-svn: 151224
|
| |
|
|
| |
llvm-svn: 149961
|
| |
|
|
| |
llvm-svn: 148578
|
| |
|
|
|
|
| |
rdar://10663487
llvm-svn: 147876
|
| |
|
|
| |
llvm-svn: 147069
|
| |
|
|
|
|
|
| |
In addition to improving the representation, this adds support for assembly
parsing of these instructions.
llvm-svn: 146588
|
| |
|
|
|
|
|
|
|
|
|
| |
Refactor the instructions into fixed writeback and register-stride
writeback variants to simplify the offset operand (no more optional
register operand using reg0). This is a simpler representation and allows
the assembly parser to more easily handle these instructions.
Add tests for the instruction variants now supported.
llvm-svn: 146278
|
| |
|
|
| |
llvm-svn: 145450
|
| |
|
|
| |
llvm-svn: 145442
|
| |
|
|
| |
llvm-svn: 143369
|
| |
|
|
|
|
|
| |
Previously, we were only setting the alignment bits on over-aligned
loads and stores.
llvm-svn: 143160
|
| |
|
|
| |
llvm-svn: 143158
|
| |
|
|
|
|
|
|
| |
Split am6offset into fixed and register offset variants so the instruction
encodings are explicit rather than relying an a magic reg0 marker.
Needed to being able to parse these.
llvm-svn: 142853
|
| |
|
|
| |
llvm-svn: 142332
|
| |
|
|
| |
llvm-svn: 141591
|
| |
|
|
|
|
| |
hang, and possibly SPEC/CINT2006/464_h264ref.
llvm-svn: 141560
|
| |
|
|
|
|
| |
instructions there.
llvm-svn: 141481
|
| |
|
|
|
|
| |
Patch by Ana Pazos!
llvm-svn: 141365
|
| |
|
|
| |
llvm-svn: 141248
|
| |
|
|
|
|
|
|
| |
merging an lsl #2 that has multiple uses on A9. This shift is free, so there is
no problem merging it in multiple places. Other unprofitable shifts will not be
merged.
llvm-svn: 141247
|
| |
|
|
| |
llvm-svn: 141173
|
| |
|
|
|
|
| |
it returns false, at least as far as I could tell by reading the code.
llvm-svn: 141172
|
| |
|
|
|
|
|
|
| |
Math is hard, and isScaledConstantInRange() always returned false for
negative constants. It was doing unsigned division of negative numbers
before casting back to signed.
llvm-svn: 140425
|
| |
|
|
| |
llvm-svn: 139636
|
| |
|
|
|
|
|
|
| |
need to preserve the sign of the index. This fixes miscompilations of Quicksort in the nightly testsuite, and hopefully others as well.
<rdar://problem/10046188>
llvm-svn: 138885
|
| |
|
|
| |
llvm-svn: 138868
|
| |
|
|
| |
llvm-svn: 138845
|
| |
|
|
|
|
| |
differently. Update the manual instruction selection code that was encoding them the addrmode2 way even though LDR_PRE_IMM/LDRB_PRE_IMM had switched to addrmode_imm12. Should fix a number of nightly test failures.
llvm-svn: 138758
|
| |
|
|
| |
llvm-svn: 138657
|
| |
|
|
|
|
| |
were failing to specify enough fixed bits of LDR_PRE/LDRB_PRE, resulting in decoding conflicts. Separate them into immediate vs. register versions, allowing us to specify the necessary fixed bits. This in turn results in the test being decoded properly, and being rejected as UNPREDICTABLE rather than a hard failure.
llvm-svn: 138653
|
| |
|
|
|
|
|
|
|
| |
Add the predicate operand to the instructions. Update the back end
accordingly where the instructions are used. Restrict the SP operands
to actually only be SP, as otherwise these break assembly parsing for the
normal instruction variants.
llvm-svn: 138445
|
| |
|
|
|
|
|
|
|
|
| |
Refactor STR[B] pre and post indexed instructions to use addressing modes for
memory operands, which is necessary for assembly parsing and is more consistent
with the rest of the memory instruction definitions. Make some incremental
progress on refactoring away the mega-operand addrmode2 along the way, which
is nice.
llvm-svn: 136978
|
| |
|
|
|
|
|
|
|
| |
Encode the width operand as it encodes in the instruction, which simplifies
the disassembler and the encoder, by using the imm1_32 operand def. Add a
diagnostic for the context-sensitive constraint that the width must be in
the range [1,32-lsb].
llvm-svn: 136264
|
| |
|
|
|
|
| |
for allowing the fixed-length disassembler to distinguish between SBFX and STR_PRE.
llvm-svn: 136141
|
| |
|
|
| |
llvm-svn: 135785
|
| |
|
|
|
|
| |
necessitates a lot of changes to related bits.
llvm-svn: 135722
|
| |
|
|
|
|
| |
allowing us to distinguish the encodings that use shifted registers from those that use shifted immediates. This is necessary to allow the fixed-length decoder to distinguish things like BICS vs LDRH.
llvm-svn: 135693
|
| |
|
|
|
|
| |
ARM MC code from target.
llvm-svn: 135636
|
| |
|
|
|
|
|
|
| |
sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.
llvm-svn: 134021
|
| |
|
|
|
|
|
|
| |
first operand. This operand is lowered away by the time we reach MachineInstrs, so the actual register-allocation handling of them doesn't need to change.
This is intended to support using REG_SEQUENCE SDNode's with type MVT::untyped, and is part of the long road to eliminating some of the hacks we currently use to support register pairs and other strange constraints, particularly on ARM NEON.
llvm-svn: 133178
|
| |
|
|
|
|
|
|
| |
to load/store i64 values. Since there's no current support to explicitly
declare such restrictions, implement it by using specific hardcoded register
pairs during isel.
llvm-svn: 132248
|
| |
|
|
| |
llvm-svn: 130557
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Making use of VFP / NEON floating point multiply-accumulate / subtraction is
difficult on current ARM implementations for a few reasons.
1. Even though a single vmla has latency that is one cycle shorter than a pair
of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause
additional pipeline stall. So it's frequently better to single codegen
vmul + vadd.
2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to
stall for 4 cycles. We need to schedule them apart.
3. A vmla followed vmla is a special case. Obvious issuing back to back RAW
vmla + vmla is very bad. But this isn't ideal either:
vmul
vadd
vmla
Instead, we want to expand the second vmla:
vmla
vmul
vadd
Even with the 4 cycle vmul stall, the second sequence is still 2 cycles
faster.
Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough
but it isn't the optimial solution. This patch attempts to make it possible to
use vmla / vmls in cases where it is profitable.
A. Add missing isel predicates which cause vmla to be codegen'ed.
B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to
compute a fmul and a fmla.
C. Add additional isel checks for vmla, avoid cases where vmla is feeding into
fp instructions (except for the #3 exceptional case).
D. Add ARM hazard recognizer to model the vmla / vmls hazards.
E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the
vmla / vmls will trigger one of the special hazards.
Enable these fp vmlx codegen changes for Cortex-A9.
llvm-svn: 129775
|
| |
|
|
| |
llvm-svn: 129738
|
| |
|
|
| |
llvm-svn: 127899
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
can. As Nate pointed out, VTBL isn't super performant, but it *has* to be better
than this:
_shuf:
@ BB#0: @ %entry
push {r4, r7, lr}
add r7, sp, #4
sub sp, #12
mov r4, sp
bic r4, r4, #7
mov sp, r4
mov r2, sp
vmov d16, r0, r1
orr r0, r2, #6
orr r3, r2, #7
vst1.8 {d16[0]}, [r3]
vst1.8 {d16[5]}, [r0]
subs r4, r7, #4
orr r0, r2, #5
vst1.8 {d16[4]}, [r0]
orr r0, r2, #4
vst1.8 {d16[4]}, [r0]
orr r0, r2, #3
vst1.8 {d16[0]}, [r0]
orr r0, r2, #2
vst1.8 {d16[2]}, [r0]
orr r0, r2, #1
vst1.8 {d16[1]}, [r0]
vst1.8 {d16[3]}, [r2]
vldr.64 d16, [sp]
vmov r0, r1, d16
mov sp, r4
pop {r4, r7, pc}
The "illegal" testcase in vext.ll is no longer illegal.
<rdar://problem/9078775>
llvm-svn: 127630
|
| |
|
|
| |
llvm-svn: 127509
|
| |
|
|
| |
llvm-svn: 127090
|
| |
|
|
| |
llvm-svn: 126477
|