|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| 
| 
| | rdar://11252521
llvm-svn: 154832 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | As an example, attach range info to the "invalid instruction" message:
$ clang -arch arm -c asm.c
asm.c:2:11: error: invalid instruction
  __asm__("foo r0");
          ^
<inline asm>:1:2: note: instantiated into assembly here
        foo r0
        ^~~
llvm-svn: 154765 | 
| | 
| 
| 
| 
| 
| | explicitly.
llvm-svn: 154689 | 
| | 
| 
| 
| 
| 
| 
| | targets so if the branch target has the high bit set it does not get printed as:
	 beq     0xffffffff8008c404
llvm-svn: 154685 | 
| | 
| 
| 
| 
| 
| | symbolic operands added when using the C disassembler API.
llvm-svn: 154628 | 
| | 
| 
| 
| 
| 
| 
| 
| | They reference the PC directly, so things work properly that way.
rdar://11231229
llvm-svn: 154576 | 
| | 
| 
| 
| 
| 
| | of a VST instruction.
llvm-svn: 154544 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | While there is an encoding for it in VUZP, the result of that is undefined,
so we should avoid it. Define the instruction as a pseudo for VTRN.32
instead, as the ARM ARM indicates.
rdar://11222366
llvm-svn: 154511 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | While there is an encoding for it in VZIP, the result of that is undefined,
so we should avoid it. Define the instruction as a pseudo for VTRN.32
instead, as the ARM ARM indicates.
rdar://11221911
llvm-svn: 154505 | 
| | 
| 
| 
| | llvm-svn: 154484 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | predicates.
Also remove NEON2 since it's not really useful and it is confusing. If
NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it
really mean?
rdar://10139676
llvm-svn: 154480 | 
| | 
| 
| 
| | llvm-svn: 154469 | 
| | 
| 
| 
| 
| 
| | for all opcodes handed by DecodeVLDInstruction() in ARMDisassembler.cpp .
llvm-svn: 154459 | 
| | 
| 
| 
| 
| 
| | rdar://11222742
llvm-svn: 154457 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | 1. The new instruction itinerary entries are not properly described.
2. The asm parser can't handle vfms and vfnms.
3. There were no assembler, disassembler test cases.
4. HasNEON2 has the wrong assembler predicate.
rdar://10139676
llvm-svn: 154456 | 
| | 
| 
| 
| | llvm-svn: 154439 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | We were incorrectly conflating some add variants which don't have a
cc_out operand with the mirroring sub encodings, which do. Part of the
awesome non-orthogonality legacy of thumb1. Similarly, handling of
add/sub of an immediate was sometimes incorrectly removing the cc_out
operand for add/sub register variants.
rdar://11216577
llvm-svn: 154411 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | legalizer always use the DAG entry node. This is wrong when the libcall is
emitted as a tail call since it effectively folds the return node. If
the return node's input chain is not the entry (i.e. call, load, or store)
use that as the tail call input chain.
PR12419
rdar://9770785
rdar://11195178
llvm-svn: 154370 | 
| | 
| 
| 
| 
| 
| | Generalized logic of r154141.
llvm-svn: 154362 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | in-register, such that we can use a single vector store rather then a 
series of scalar stores.
For func_4_8 the generated code
	vldr	d16, LCPI0_0
	vmov	d17, r0, r1
	vadd.i16	d16, d17, d16
	vmov.u16	r0, d16[3]
	strb	r0, [r2, #3]
	vmov.u16	r0, d16[2]
	strb	r0, [r2, #2]
	vmov.u16	r0, d16[1]
	strb	r0, [r2, #1]
	vmov.u16	r0, d16[0]
	strb	r0, [r2]
	bx	lr
becomes
	vldr	d16, LCPI0_0
	vmov	d17, r0, r1
	vadd.i16	d16, d17, d16
	vuzp.8	d16, d17
	vst1.32	{d16[0]}, [r2, :32]
	bx	lr
I'm not fond of how this combine pessimizes 2012-03-13-DAGCombineBug.ll,
but I couldn't think of a way to judiciously apply this combine.
This
	ldrh	r0, [r0, #4]
	strh	r0, [r1]
becomes
	vldr	d16, [r0]
	vmov.u16	r0, d16[2]
	vmov.32	d16[0], r0
	vuzp.16	d16, d17
	vst1.32	{d16[0]}, [r1, :32]
PR11158
rdar://10703339
llvm-svn: 154340 | 
| | 
| 
| 
| | llvm-svn: 154336 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The tLDRr instruction with the last register operand set to the zero register
prints in assembly as if no register was specified, and the assembler encodes
it as a tLDRi instruction with a zero immediate.  With the integrated assembler,
that zero register gets emitted as "r0", so we get "ldr rx, [ry, r0]" which
is broken.  Emit the instruction as tLDRi with a zero immediate.  I don't
know if there's a good way to write a testcase for this.  Suggestions welcome.
Opportunities for follow-up work:
1) The asm printer should complain if a non-optional register operand is set
   to the zero register, instead of silently dropping it.
2) The integrated assembler should complain in the same situation, instead of
   silently emitting the operand as "r0".
llvm-svn: 154261 | 
| | 
| 
| 
| | llvm-svn: 154226 | 
| | 
| 
| 
| | llvm-svn: 154210 | 
| | 
| 
| 
| 
| 
| 
| | After register masks were introdruced to represent the call clobbers, it
is no longer necessary to have duplicate instruction for iOS.
llvm-svn: 154209 | 
| | 
| 
| 
| 
| 
| | which exists for this purpose.
llvm-svn: 154199 | 
| | 
| 
| 
| 
| 
| 
| | ARM and Thumb2 mode can use cmn instructions to compare against negative
immediates. Thumb1 mode can't.
llvm-svn: 154183 | 
| | 
| 
| 
| 
| 
| 
| 
| | We had special instructions for iOS because r9 is call-clobbered, but
that is represented dynamically by the register mask operands now, so
there is no need for the pseudo-instructions.
llvm-svn: 154144 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The load/store optimizer splits LDRD/STRD into two instructions when the
register pairing doesn't work out. For negative offsets in Thumb2, it uses
t2STRi8 to do that. That's fine, except for the case when the offset is in
the range [-4,-1]. In that case, we'll also form a second t2STRi8 with
the original offset plus 4, resulting in a t2STRi8 with a non-negative
offset, which ends up as if it were an STRT, which is completely bogus.
Similarly for loads.
No testcase, unfortunately, as any I've been able to construct is both large
and extremely fragile.
rdar://11193937
llvm-svn: 154141 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | 'add r2, #-1024' should just use 'sub r2, #1024' rather than erroring out.
Thumb1 aliases for adding a negative immediate to the stack pointer,
also.
rdar://11192734
llvm-svn: 154123 | 
| | 
| 
| 
| 
| 
| | some corner cases involving the PC register as an operand for these instructions.
llvm-svn: 154101 | 
| | 
| 
| 
| | llvm-svn: 154100 | 
| | 
| 
| 
| 
| 
| | rdar://11189467
llvm-svn: 154087 | 
| | 
| 
| 
| 
| 
| 
| 
| | Plain 'cpsr' is an alias for 'cpsr_fc'.
rdar://11153753
llvm-svn: 154080 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | A MOVCCr instruction can be commuted by inverting the condition. This
can help reduce register pressure and remove unnecessary copies in some
cases.
<rdar://problem/11182914>
llvm-svn: 154033 | 
| | 
| 
| 
| 
| 
| 
| 
| | This allows us to keep passing reduced masks to SimplifyDemandedBits, but
know about all the bits if SimplifyDemandedBits fails. This allows instcombine
to simplify cases like the one in the included testcase.
llvm-svn: 154011 | 
| | 
| 
| 
| 
| 
| 
| | And indirectly, a dependency on most of the core LLVM optimization
libraries.
llvm-svn: 153957 | 
| | 
| 
| 
| 
| 
| 
| 
| | MCInstPrinter.
All implementations used the same code.
llvm-svn: 153866 | 
| | 
| 
| 
| 
| 
| | using the instruction name table from MCInstrInfo. Reduces static data in the InstPrinter implementations.
llvm-svn: 153863 | 
| | 
| 
| 
| 
| 
| | getInstructionName and the static data it contains since the same tables are already in MCInstrInfo.
llvm-svn: 153860 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | ARMConstantIslandPass still has bugs where jump table compression can
cause constant pool entries to go out of range.
Add a safety margin of 2 bytes when placing constant islands, but use
the real max displacement for verification.
<rdar://problem/11156595>
llvm-svn: 153789 | 
| | 
| 
| 
| | llvm-svn: 153788 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | The 8-bit payload is not contiguous in the opcode. Move the upper nibble
over 4 bits into the correct place.
rdar://11158641
llvm-svn: 153780 | 
| | 
| 
| 
| 
| 
| 
| 
| | When an immediate is both a value [t2_]so_imm and a [t2_]so_imm_neg,
we want to use the non-negated form to make sure we prefer the normal
encoding, not the aliased encoding via the negation of, e.g., 'cmp.w'.
llvm-svn: 153770 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Make the non-tied register operand names line up with what the base
class encoding handler expects.
rdar://11157236
llvm-svn: 153766 | 
| | 
| 
| 
| | llvm-svn: 153765 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | For 'adds r2, r2, #56' outside of an IT block, the 16-bit encoding T2
can be used for this syntax. Prefer the narrow encoding when possible.
rdar://11156277
llvm-svn: 153759 | 
| | 
| 
| 
| 
| 
| 
| 
| | Make sure to treat immediates as unsigned when doing relative comparisons.
rdar://11153621
llvm-svn: 153753 | 
| | 
| 
| 
| 
| 
| 
| 
| | fixup_arm_condbranch.
Patch by Tim Northover!
llvm-svn: 153737 | 
| | 
| 
| 
| 
| 
| | tailcall opt. rdar://11140249
llvm-svn: 153717 |