This patch fixes a bug in the assembler that was causing bad code to
be emitted.  When switching modes in an assembly file (e.g. arm to
thumb mode) we would always emit the opcode from the original mode.

Consider this small example:

$ cat align.s
.code 16
foo:
  add r0, r0
.align 3
  add r0, r0

$ llvm-mc -triple armv7-none-linux align.s -filetype=obj -o t.o
$ llvm-objdump -triple thumbv7 -d t.o
Disassembly of section .text:
foo:
       0:       00 44         add     r0, r0
       2:       00 f0 20 e3   blx #4195904
       6:       00 00         movs    r0, r0
       8:       00 44         add     r0, r0

This shows that we have actually emitted an arm nop (e320f000)
instead of a thumb nop. Unfortunately, this encodes to a thumb
branch which causes bad things to happen when compiling assembly
code with align directives.

The fix is to notify the ARMAsmBackend when we switch mode. The
MCMachOStreamer was already doing this correctly. This patch makes
the same change for the MCElfStreamer.

There is still a bug in the way nops are emitted for alignment
because the MCAlignment fragment does not store the correct mode.
The ARMAsmBackend will emit nops for the last mode it knew about. In
the example above, we still generate an arm nop if we add a `.code
32` to the end of the file.

PR18019

llvm-svn: 195677

The system LDM and STM instructions can't usually writeback to the base
register. The one exception is when an LDM is actually an exception-return
(i.e. contains PC in the register list).

(There's already a test that "ldm sp!, {r0-r3, pc}^" works, which is why there
is no positive test).

rdar://problem/15223374

llvm-svn: 194512

llvm-svn: 194416

[ARM] Handling for coprocessor instructions that are undefined starting from ARMv8 (Thumb encodings)

llvm-svn: 194263

[ARM] In ARMAsmParser, MatchCoprocessorOperandName() permitted p10 and p11 as operands for coprocessor instructions, resulting in encodings that clash with FP/NEON instruction encodings

llvm-svn: 194253

Cortex-M0 supports these 32-bit instructions despite being Thumb1 only
(mostly). We knew about that but not that the aliases without the default "sy"
operand were also permitted.

llvm-svn: 194094

Add some missing tests, factor out a test not specific to v8 into
its own file.

llvm-svn: 193611

Adds a subtarget feature for the CRC instructions (optional in v8-A) to the ARM (32-bit) backend.

Differential Revision: http://llvm-reviews.chandlerc.com/D2036

llvm-svn: 193599

llvm-svn: 193539

an MCExpr, in order to avoid writing an encoded zero value in the immediate
field.

When getUnconditionalBranchTargetOpValue is called with an MCExpr target, we
don't know what the final immediate field value should be. We shouldn't
explicitly set the immediate field to an encoded zero value as zero is encoded
with a non-zero bit pattern. This leads to bits being set that pollute the
final immediate value. The nature of the encoding is such that the polluted
bits only affect very large immediate values, explaining why this hasn't
caused problems earlier.

Fixes <rdar://problem/15155975>.

llvm-svn: 193535

This commit allows the ARM integrated assembler to parse
and assemble the code with .eabi_attribute, .cpu, and
.fpu directives.

To implement the feature, this commit moves the code from
AttrEmitter to ARMTargetStreamers, and several new test
cases related to cortex-m4, cortex-r5, and cortex-a15 are
added.

Besides, this commit also change the Subtarget->isFPOnlySP()
to Subtarget->hasD16() to match the usage of .fpu directive.

This commit changes the test cases:

* Several .eabi_attribute directives in
  2010-09-29-mc-asm-header-test.ll are removed because the .fpu
  directive already cover the functionality.

* In the Cortex-A15 test case, the value for
  Tag_Advanced_SIMD_arch has be changed from 1 to 2,
  which is more precise.

llvm-svn: 193524

When assembling, a .thumb_func directive is supposed to be applicable to the
next symbol definition, even if there are intervening directives. We were
racing ahead to try and find it, and this commit should fix the issue.

Patch by Gabor Ballabas

llvm-svn: 193403

A TableGen indeterminacy means that the reason for the failure can
vary, and Windows gets the other option.

llvm-svn: 193394

This prevents us from silently accepting invalid instructions on (for example)
Cortex-M4 with just single-precision VFP support.

No tests for the extra Pat Requires because they're essentially assertions: the
affected code should have been lowered to libcalls before ISel.

rdar://problem/15302004

llvm-svn: 193354

The fused multiply instructions were added in VFPv4 but are still NEON
instructions, in particular they shouldn't be available on a Cortex-M4 not
matter how floaty it is.

llvm-svn: 193342

If an alias inherits directly from InstAlias then it doesn't get any default
"Requires" values, so llvm-mc will allow it even on architectures that don't
support the underlying instruction.

This tidies up the obvious VFP and NEON cases I found.

llvm-svn: 193340

POP instructions are aliased to the ARM LDM variants but have different syntax.
This caused two problems: we tried to access a non-existent operand to annotate
the '!', and the error message didn't make much sense.

With some vigorous hand-waving in the error message both problems can be
fixed.

llvm-svn: 193322

llvm-svn: 193238

The set of circumstances where the writeback register is allowed to be in the
list of registers is rather baroque, but I think this implements them all on
the assembly parsing side.

For disassembly, we still warn about an ARM-mode LDM even if the architecture
revision is < v7 (the required architecture information isn't available). It's
a silly instruction anyway, so hopefully no-one will mind.

rdar://problem/15223374

llvm-svn: 193185

Patch by Artyom Skrobov

llvm-svn: 192972

Add hardware division as a default feature on Cortex-A15. Also add test cases to check this, and change diagnostics for the hwdiv-arm feature to something useful.

llvm-svn: 192963

Some previous implicit defaults have changed, for example FP and NEON
are now on by default.

llvm-svn: 192590

llvm-svn: 192458

llvm-svn: 192111

The hint instructions ("nop", "yield", etc) are mostly Thumb2-only, but have
been ported across to the v6M architecture. Fortunately, v6M seems to sit
nicely between v6 (thumb-1 only) and v6T2, so we can add a feature for it
fairly easily.

rdar://problem/15144406

llvm-svn: 192097

When MC was first added, targets could use hasRawTextSupport to keep features
working before they were added to the MC interface.

The design goal of MC is to provide an uniform api for printing assembly and
object files. Short of relaxations and other corner cases, a object file is
just another representation of the assembly.

It was never the intention that targets would keep doing things like

if (hasRawTextSupport())
  Set flags in one way.
else
  Set flags in another way.

When they do that they create two code paths and the object file is no longer
just another representation of the assembly. This also then requires testing
with llc -filetype=obj, which is extremelly brittle.

This patch removes some of these hacks by replacing them with smaller ones.
The ARM flag setting is trivial, so I just moved it to the constructor. For
Mips, the patch adds two temporary hack directives that allow the assembly
to represent the same things as the object file was already able to.

The hope is that the mips developers will replace the hack directives with
the same ones that gas uses and drop the -print-hack-directives flag.

I will also try to implement a target streamer interface, so that we can
move this out of the common code.

In summary, for any new work, two rules of the thumb are
  * Don't use "llc -filetype=obj" in tests.
  * Don't add calls to hasRawTextSupport.

llvm-svn: 192035

Patch by Artyom Skrobov.

llvm-svn: 191885

This also removes the restriction on the immediate field of the 'hint'
instruction.

llvm-svn: 191744

Changing the diagnostic message for out of range branch targets in 191686 broke the tests.

The diagnostic message for out of range branch targets was changed to be more consistent with the other diagnostics.
 

llvm-svn: 191691

llvm-svn: 191683

[ARM] Assembler: ARM LDRD with writeback requires the base register to be different from the destination registers.

See ARM ARM A8.8.72.

Violating this constraint results in unpredictable behavior.

llvm-svn: 191678

llvm-svn: 191664

As specified in A8.8.72/A8.8.73/A8.8.74 in the ARM ARM, all variants of the ARM LDRD instruction have the following two constraints:

LDRD<c> <Rt>, <Rt2>, ...

(a) Rt must be even-numbered and not r14
(b) Rt2 must be R(t+1)

If those two constraints are not met the result of executing the instruction will be unpredictable.

Constraint (b) was already enforced, this commit adds support for constraint (a).

Fixes rdar://14479793.

llvm-svn: 191520

ARM: Teach assembler to enforce constraint for Thumb2 LDRD (literal/immediate) destination register operands.

LDRD<c> <Rt>, <Rt2>, <label>
LDRD<c> <Rt>, <Rt2>, [<Rn>{, #+/-<imm>}]
LDRD<c> <Rt>, <Rt2>, [<Rn>], #+/-<imm>
LDRD<c> <Rt>, <Rt2>, [<Rn>, #+/-<imm>]!

As specified in A8.8.72/A8.8.73 in the ARM ARM, the T1 encoding has a constraint which enforces that Rt != Rt2.

If this constraint is not met the result of executing the instruction will be unpredictable.

Fixes rdar://14479780.

llvm-svn: 191504

llvm-svn: 190996

llvm-svn: 190929

llvm-svn: 190862

Patch by Bradley Smith

llvm-svn: 190694

to be more consistent.

llvm-svn: 190692

got lost during my iterations of review.

Thanks to Hal for spotting it!

llvm-svn: 190604