| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
PLI requires both the Thumb2 and the ARMv7 feature.
Related to <rdar://problem/14403733>.
llvm-svn: 186620
|
| |
|
|
| |
llvm-svn: 186576
|
| |
|
|
| |
llvm-svn: 186574
|
| |
|
|
|
|
| |
Also, fix the namespace for two instructions that I missed previously.
llvm-svn: 186572
|
| |
|
|
|
|
|
|
| |
The N3VDIntnp pattern takes bits<5> and I gave it 6 bits.
Thanks to Jiangning Liu for spotting it!
llvm-svn: 186568
|
| |
|
|
|
|
|
| |
This adds a new class for non-predicable NEON instructions and a
new DecoderNamespace for v8 NEON instructions.
llvm-svn: 186504
|
| |
|
|
|
|
|
|
| |
My patch 'r183551 - ARM FastISel integer sext/zext improvements' was incorrect when emitting ARM register-immediate ASR, LSL, LSR instructions: they are pseudo-instructions in ARMInstrInfo.td and I should have used MOVsi instead.
This is not an issue when code is generated through a .s file, but is an issue when generated straight to a .o (-filetype=obj).
llvm-svn: 186489
|
| |
|
|
|
|
|
|
|
|
|
|
| |
block. Blocks that have an indirect branch terminator, even if it's not the
last terminator, should still be treated as unanalyzable.
<rdar://problem/14437274>
Reducing a useful regression test case is proving difficult - I hope to have
one soon.
llvm-svn: 186461
|
| |
|
|
|
|
|
|
|
|
| |
This adds an instruction alias to make the assembler recognize the alternate literal form: pli [PC, #+/-<imm>]
See A8.8.129 in the ARM ARM (DDI 0406C.b).
Fixes <rdar://problem/14403733>.
llvm-svn: 186459
|
| |
|
|
|
|
|
|
| |
We'd forgotten to provide string representations for the special ARMISD atomic
nodes; this adds them in. No effect on CodeGen, just makes the output of
"-view-whatever-dags" slightly more readable.
llvm-svn: 186406
|
| |
|
|
|
|
|
| |
Intrinsics already existed for the 64-bit variants, so these support operations
of size at most 32-bits.
llvm-svn: 186392
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch enables calls to __aeabi_idivmod when in EABI mode,
by using the remainder value returned on registers (R1),
enabled by the ARM triple "none-eabi". Note that Darwin and
GNUEABI triples will continue lowering on GNU style, that is,
using the stack for the remainder.
Still need to add SREM/UREM support fix for 64-bit lowering.
llvm-svn: 186390
|
| |
|
|
| |
llvm-svn: 186301
|
| |
|
|
|
|
| |
size.
llvm-svn: 186274
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ARM paired GPR COPY was being lowered to two MOVr without CC. This
patch puts the CC back.
My test is a reduction of the case where I encountered the issue,
64-bit atomics use paired GPRs.
The issue only occurs with selectionDAG, FastISel doesn't encounter it
so I didn't bother calling it.
llvm-svn: 186226
|
| |
|
|
| |
llvm-svn: 186212
|
| |
|
|
|
|
|
|
|
|
| |
Fixes a 35% degradation compared to unvectorized code in
MiBench/automotive-susan and an equally serious regression on a private
image processing benchmark.
radar://14351991
llvm-svn: 186188
|
| |
|
|
|
|
|
|
|
|
|
| |
Address calculation for gather/scather in vectorized code can incur a
significant cost making vectorization unbeneficial. Add infrastructure to add
cost.
Tests and cost model for targets will be in follow-up commits.
radar://14351991
llvm-svn: 186187
|
| |
|
|
| |
llvm-svn: 186013
|
| |
|
|
| |
llvm-svn: 185995
|
| |
|
|
|
|
|
|
|
|
| |
functionality change.
Currently ARM is the only backend that supports FMA instructions (for at least some subtargets) but does not implement this virtual, so FMAs are never generated except from explicit fma intrinsic calls. Apparently this is due to the fact that it supports both fused (one rounding step) and unfused (two rounding step) multiply + add instructions. This patch clarifies that this the case without changing behavior by implementing the virtual function to simply return false, as the default TargetLoweringBase version does.
It is possible that some cpus perform the fused version faster than the unfused version and vice-versa, so the function implementation should be revisited if hard data is found.
llvm-svn: 185994
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Propagate the fix from r185712 to Thumb2 codegen as well. Original
commit message applies here as well:
A "pkhtb x, x, y asr #num" uses the lower 16 bits of "y asr #num" and
packs them in the bottom half of "x". An arithmetic and logic shift are
only equivalent in this context if the shift amount is 16. We would be
shifting in ones into the bottom 16bits instead of zeros if "y" is
negative.
rdar://14338767
llvm-svn: 185982
|
| |
|
|
| |
llvm-svn: 185929
|
| |
|
|
| |
llvm-svn: 185926
|
| |
|
|
| |
llvm-svn: 185922
|
| |
|
|
| |
llvm-svn: 185853
|
| |
|
|
|
|
|
|
| |
Fall back to by-element insert rather than building it up on the stack.
rdar://14351991
llvm-svn: 185846
|
| |
|
|
| |
llvm-svn: 185767
|
| |
|
|
| |
llvm-svn: 185714
|
| |
|
|
|
|
|
|
|
|
|
| |
A "pkhtb x, x, y asr #num" uses the lower 16 bits of "y asr #num" and packs them
in the bottom half of "x". An arithmetic and logic shift are only equivalent in
this context if the shift amount is 16. We would be shifting in ones into the
bottom 16bits instead of zeros if "y" is negative.
radar://14338767
llvm-svn: 185712
|
| |
|
|
|
|
|
|
|
|
|
| |
In the SelectionDAG immediate operands to inline asm are constructed as
two separate operands. The first is a constant of value InlineAsm::Kind_Imm
and the second is a constant with the value of the immediate.
In ARMDAGToDAGISel::SelectInlineAsm, if we reach an operand of Kind_Imm we
should skip over the next operand too.
llvm-svn: 185688
|
| |
|
|
| |
llvm-svn: 185651
|
| |
|
|
|
|
|
|
|
| |
instructions.
This adds a new decoder table/namespace 'VFPV8', as these instructions have their
top 4 bits as 0b1111, while other Thumb instructions have 0b1110.
llvm-svn: 185642
|
| |
|
|
|
|
| |
These exception-related opcodes are not used any longer.
llvm-svn: 185625
|
| |
|
|
| |
llvm-svn: 185620
|
| |
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185606
|
| |
|
|
|
|
|
| |
Revert "Simplify landing pad lowering."
Revert "Remove the EXCEPTIONADDR, EHSELECTION, and LSDAADDR ISD opcodes."
llvm-svn: 185600
|
| |
|
|
|
|
| |
These exception-related opcodes are not used any longer.
llvm-svn: 185596
|
| |
|
|
|
|
|
|
| |
the GHC calling convention.
This is purely academic because GHC calls are always tail calls so the register mask will never be used; however, this change makes the code clearer and brings the ARM implementation of the GHC calling convention in line with the X86 implementation. Also, it might save someone else some time trying to figuring out what is happening...
llvm-svn: 185592
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the ARM back-end, build_vector nodes are lowered to a target specific
build_vector that uses floating point type.
This works well, unless the inserted bitcasts survive until instruction
selection. In that case, they incur moves between integer unit and floating
point unit that may result in inefficient code.
In other words, this conversion may introduce artificial dependencies when the
code leading to the build vector cannot be completed with a floating point type.
In particular, this happens when loads are not aligned.
Before this patch, in that case, the compiler generates general purpose loads
and creates the floating point vector from them, instead of directly using the
vector unit.
The patch uses a vector friendly sequence of code when the inserted bitcasts to
floating point survived DAGCombine.
This is done by a target specific DAGCombine that changes the target specific
build_vector into a sequence of insert_vector_elt that get rid of the bitcasts.
<rdar://problem/14170854>
llvm-svn: 185587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
certain Thumb2 add immediate T3 encodings.
Before the fix Thumb2 instructions of type "add rD, rN, #imm" (T3 encoding, see ARM ARM A8.8.4) with rD and rN both being low registers (r0-r7) were classified as having the T4 encoding.
The T4 encoding doesn't have a cc_out operand so for above instructions the operand gets erroneously removed, corrupting the token stream and leading to parse errors later in the process.
This bug prevented "add r1, r7, #0xcbcbcbcb" from being assembled correctly.
Fixes <rdar://problem/14224440>.
llvm-svn: 185575
|
| |
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185540
|
| |
|
|
|
|
|
|
|
|
| |
issues:
1. it should accept only 4-byte aligned addresses
2. the maximum offset should be 1020
3. it should be encoded with the offset scaled by two bits
llvm-svn: 185528
|
| |
|
|
|
|
|
|
|
|
|
| |
Swift cores implement store barriers that are stronger than the ARM
specification but weaker than general barriers. They are, in fact, just about
enough to provide the ordering needed for atomic operations with release
semantics.
This patch makes use of that quirk.
llvm-svn: 185527
|
| |
|
|
|
|
|
|
| |
This is dead code since PIC16 was removed in 2010. The result was an odd mix,
where some parts would carefully pass it along and others would assert it was
zero (most of the object streamer for example).
llvm-svn: 185436
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to ARM EHABI section 9.2, if the
__aeabi_unwind_cpp_pr1() or __aeabi_unwind_cpp_pr2() is
used, then the handler data must be emitted after the unwind
opcodes. The handler data consists of several words, and
should be terminated by zero.
In case that the .handlerdata directive is not specified by
the programmer, we should emit zero to terminate the handler
data.
llvm-svn: 185422
|
| |
|
|
|
|
| |
tablegen enum values. This should be the last fix due to fallout from r185094.
llvm-svn: 185379
|
| |
|
|
|
|
|
|
|
| |
Turns out I'd misread the architecture reference manual and thought
that was a load/store-store barrier, when it's not.
Thanks for pointing it out Eli!
llvm-svn: 185356
|
| |
|
|
|
|
|
|
|
|
|
| |
I believe the full "dmb ish" barrier is not required to guarantee release
semantics for atomic operations. The weaker "dmb ishst" prevents previous
operations being reordered with a store executed afterwards, which is enough.
A key point to note (fortunately already correct) is that this barrier alone is
*insufficient* for sequential consistency, no matter how liberally placed.
llvm-svn: 185339
|
| |
|
|
| |
llvm-svn: 185219
|