idiv: There is no difference between Armv7m and Thumbv7M
behaviour so the specific CHECKs are not needed.
The errors for Armv7-a and Thumbv7-a will always
include "ARM" or "THUMB" respectively so they need their
own CHECK prefix, making CHECK-V7 redundant.
mp: Behaviour is dependent on whether the triple is v6/v7/v7M
regardless of being Arm or Thumb. So we don't need the more
specific CHECK-ARMv7M etc.
simd: Errors are either v7 only, or v7 and v8 so CHECK-V8
is not needed.
fp: Same as simd
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D90918
This converts the ARM AsmParser to use the new assembly matcher error
reporting mechanism, which allows errors to be reported for multiple
instruction encodings when it is ambiguous which one the user intended
to use.
By itself this doesn't improve many error messages, because we don't have
diagnostic text for most operand types, but as we add that then this will allow
more of those diagnostic strings to be used when they are relevant.
Differential revision: https://reviews.llvm.org/D31530
llvm-svn: 314779
This reverts r310243. Only MVFR2 is actually restricted to v8 and it'll be a
little while before we can get a proper fix together. Better that we allow
incorrect code than reject correct in the meantime.
llvm-svn: 310384
This patch addresses two issues with assembly and disassembly for VMRS/VMSR:
1.currently VMRS/VMSR instructions accessing fpsid, mvfr{0-2} and fpexc, are
accepted for non ARMv8-A targets.
2. all VMRS/VMSR instructions accept writing/reading to PC and SP, when only
ARMv7-A and ARMv8-A should be allowed to write/read to SP and none to PC.
This patch addresses those issues and adds tests for these cases.
Differential Revision: https://reviews.llvm.org/D36306
llvm-svn: 310243
The subtarget information is the ultimate source of truth for the feature set
that is enabled at this point. We would previously not propagate the feature
information to the subtarget. While this worked for the most part (features
would be enabled/disabled as requested), if another operation that changed the
feature bits was encountered (such as a mode switch via a .arm or .thumb
directive), we would end up resetting the behaviour of the architectural
extensions.
Handling this properly requires a slightly more complicated handling. We need
to check if the feature is now being toggled. If so, only then do we toggle the
features. In return, we no longer have to calculate the feature bits ourselves.
The test changes are mostly to the diagnosis, which is now more uniform (a nice
side effect!). Add an additional test to ensure that we handle this case
properly.
Thanks to Nico Weber for alerting me to this issue!
llvm-svn: 214057
This adds a partial implementation of the .arch_extension directive to the
integrated ARM assembler. There are a number of limitations to this
implementation arising from the target backend support rather than the
implementation itself. Namely, iWMMXT (v1 and v2), Maverick, and XScale support
is not present in the ARM backend. Currently, there is no check for A-class
only (needed for virt), and no ARMv6k detection (needed for os and sec). The
remainder of the extensions are fully supported.
llvm-svn: 201471
David Spickett