llvm-svn: 126930

Patch by Jyun-Yan You, with some minor adjustments and a testcase from me.

llvm-svn: 126915

Patch by Ted Kremenek!

llvm-svn: 126895

llvm-svn: 126882

shift.

   16-bit: imm6<5:3> = '001', 8 - <imm> is encded in imm6<2:0>
   32-bit: imm6<5:4> = '01',16 - <imm> is encded in imm6<3:0>
   64-bit: imm6<5> = '1', 32 - <imm> is encded in imm6<4:0>

llvm-svn: 126723

llvm-svn: 126689

llvm-svn: 126687

needed two predicate operands before the imm operand.

llvm-svn: 126662

llvm-svn: 126661

patch to the front-end.  Radar 7662569.

llvm-svn: 126655

llvm-svn: 126477

llvm-svn: 126467

D registers since the vpush list may not have gaps. Make sure the stack
adjustment instruction isn't moved between them. Ditto for vpop in
epilogues.

Sorry, can't reduce a small test case.
rdar://9043312

llvm-svn: 126457

llvm-svn: 126298

The previous codegen for the slow path (when values are in VFP / NEON
registers) was incorrect if the source is NaN.

The new codegen uses NEON vbsl instruction to copy the sign bit. e.g.
        vmov.i32        d1, #0x80000000
        vbsl    d1, d2, d0
If NEON is not available, it uses integer instructions to copy the sign bit.
rdar://9034702

llvm-svn: 126295

llvm-svn: 126238

llvm-svn: 126192

llvm-svn: 126191

up by the dynamic linker, but it's better to use the correct instruction
to begin with.

Fixes rdar://9011034

llvm-svn: 126176

Skipping over debugvalue instructions to determine whether the split spot is in a IT block. rdar://9030770

llvm-svn: 126159

In other words, do not keep track of argument's location.  The debugger (gdb) is not prepared to see line table entries for arguments. For the debugger, "second" line table entry marks beginning of function body.
This requires some coordination with debugger to get this working. 
 - The debugger needs to be aware of prolog_end attribute attached with line table entries.
 - The compiler needs to accurately mark prolog_end in line table entries (at -O0 and at -O1+)

llvm-svn: 126155

of testing for its presence at cmake time.

This way the build automatically regenerates the makefiles when a svn
update brings in a new sublibrary.

llvm-svn: 126068

llvm-svn: 126004

llvm-svn: 125949

testcases for the disassembler to make sure it still works for "msr".

llvm-svn: 125948

No one uses *-mingw64. mingw-w64 is represented as {i686|x86_64}-w64-mingw32. In llvm side, i686 and x64 can be treated as similar way.

llvm-svn: 125747

Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones.

llvm-svn: 125624

This is necessary to avoid a crash in certain tangled situations where a kill
flag is first correctly moved to a merged instruction, and then needs to be
moved again:

  STR %R0, a...
  STR %R0<kill>, b...

First becomes:

  STR %R0, b...
  STM a, %R0<kill>, ...

and then:

  STM a, %R0, ...
  STM b, %R0<kill>, ...

We can now remove the kill flag from the merged STM when needed. 8960050.

llvm-svn: 125591

llvm-svn: 125563

llvm-svn: 125534

llvm-svn: 125521

- Add custom operand matching for imod and iflags.
- Rename SplitMnemonicAndCC to SplitMnemonic since it splits more than CC
  from mnemonic.
- While adding ".w" as an operand, don't change "Head" to avoid passing the
  wrong mnemonic to ParseOperand.
- Add asm parser tests.
- Add disassembler tests just to make sure it can catch all cps versions.

llvm-svn: 125489

have their low bits set to zero.  This allows us to optimize
out explicit stack alignment code like in stack-align.ll:test4 when
it is redundant.

Doing this causes the code generator to start turning FI+cst into
FI|cst all over the place, which is general goodness (that is the
canonical form) except that various pieces of the code generator
don't handle OR aggressively.  Fix this by introducing a new
SelectionDAG::isBaseWithConstantOffset predicate, and using it
in places that are looking for ADD(X,CST).  The ARM backend in
particular was missing a lot of addressing mode folding opportunities
around OR.

llvm-svn: 125470

Teach the AsmMatcher handling to distinguish between an error custom-parsing
an operand and a failure to match. The former should propogate the error
upwards, while the latter should continue attempting to parse with
alternative matchers.

Update the ARM asm parser accordingly.

llvm-svn: 125426

This avoids moving each element to the integer register file and calling __divsi3 etc. on it.

llvm-svn: 125402

This
define float @foo(float %x, float %y) nounwind readnone {
entry:
  %0 = tail call float @copysignf(float %x, float %y) nounwind readnone
  ret float %0
}

Was compiled to:
    vmov     s0, r1
    bic      r0, r0, #-2147483648
    vmov     s1, r0
    vcmpe.f32    s0, #0
    vmrs         apsr_nzcv, fpscr
    it           lt
    vneglt.f32   s1, s1
    vmov         r0, s1
    bx           lr

This fails to copy the sign of -0.0f because it's lost during the float to int
conversion. Also, it's sub-optimal when the inputs are in GPR registers.

Now it uses integer and + or operations when it's profitable. And it's correct!
    lsrs    r1, r1, #31
    bfi     r0, r1, #31, #1
    bx      lr
rdar://8984306

llvm-svn: 125357

Revert both r121082 (which broke a bunch of constant pool stuff) and r125074 (which worked around it).  This should get us back to the old, correct behavior, though it will make the integrated assembler unhappy for the time being.

llvm-svn: 125127

t2LDRpci with t2LDRi12.
There are a couple of problems with this.
1. The encoding for the literal and immediate constant are different.
   Note bit 7 of the literal case is 'U' so it can be negative.
2. t2LDRi12 is now narrowed to tLDRpci before constant island pass is run.
   So we end up never using the Thumb2 instruction, which ends up creating a
   lot more constant islands.

llvm-svn: 125074

llvm-svn: 125055

parsing of operands introduced in r125030. As a small note, besides using a more
generic approach we can also have more descriptive output when debugging
llvm-mc, example:

mcr  p7, #1, r5, c1, c1, #4

note: parsed instruction:
  ['mcr', <ARMCC::al>,
          <coprocessor number: 7>,
          1,
          <register 73>,
          <coprocessor register: 1>,
          <coprocessor register: 1>,
          4]
llvm-svn: 125052