summaryrefslogtreecommitdiffstats
path: root/llvm/test/MC/ARM/directive-arch_extension-fp.s
Commit message (Collapse)AuthorAgeFilesLines
* [ARM] Use new assembler diags for ARMOliver Stannard2017-10-031-122/+122
| | | | | | | | | | | | | | | 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
* Revert "[ARM] Fix assembly and disassembly for VMRS/VMSR"Tim Northover2017-08-081-0/+4
| | | | | | | | 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
* [ARM] Fix assembly and disassembly for VMRS/VMSRAndre Vieira2017-08-071-4/+0
| | | | | | | | | | | | | | | | 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
* ARM: correct handling of features in arch_extensionSaleem Abdulrasool2014-07-271-126/+65
| | | | | | | | | | | | | | | | | | | | | | 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
* ARM IAS: (partially) support .arch_extension directiveSaleem Abdulrasool2014-02-161-0/+344
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
OpenPOWER on IntegriCloud