6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-13 20:32:21 +00:00
Code Issues Projects Releases Wiki Activity
635fb9fb59
llvm-6502/test/MC/ARM/directive-arch_extension-simd.s

228 lines
7.5 KiB
ArmAsm
Raw Normal View History

ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
@ RUN: not llvm-mc -triple armv7-eabi -filetype asm -o /dev/null 2>&1 %s \
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ RUN: | FileCheck %s -check-prefix CHECK-V7 -check-prefix CHECK
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
@ RUN: not llvm-mc -triple armv8-eabi -filetype asm -o /dev/null 2>&1 %s \
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ RUN: | FileCheck %s -check-prefix CHECK-V8 -check-prefix CHECK
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
@ RUN: not llvm-mc -triple thumbv7-eabi -filetype asm -o /dev/null 2>&1 %s \
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ RUN: | FileCheck %s -check-prefix CHECK-V7 -check-prefix CHECK
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
@ RUN: not llvm-mc -triple thumbv8-eabi -filetype asm -o /dev/null 2>&1 %s \
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ RUN: | FileCheck %s -check-prefix CHECK-V8 -check-prefix CHECK
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
.syntax unified
.arch_extension simd
@ CHECK-V7: error: architectural extension 'simd' is not allowed for the current base architecture
@ CHECK-V7-NEXT: .arch_extension simd
@ CHECK-V7-NEXT: ^
.type simd,%function
simd:
vmaxnm.f32 s0, s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vminnm.f32 s0, s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vmaxnm.f64 d0, d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vminnm.f64 d0, d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvta.s32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvta.u32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvta.s32.f64 s0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvta.u32.f64 s0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtn.s32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtn.u32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtn.s32.f64 s0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtn.u32.f64 s0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtp.s32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtp.u32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtp.s32.f64 s0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtp.u32.f64 s0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtm.s32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtm.u32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtm.s32.f64 s0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vcvtm.u32.f64 s0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintz.f32 s0, s1
@ CHECK-V7: error: instruction requires: FPARMv8
vrintz.f64 d0, d1
@ CHECK-V7: error: instruction requires: FPARMv8
vrintz.f32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintz.f64.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintr.f32 s0, s1
@ CHECK-V7: error: instruction requires: FPARMv8
vrintr.f64 d0, d1
@ CHECK-V7: error: instruction requires: FPARMv8
vrintr.f32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintr.f64.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintx.f32 s0, s1
@ CHECK-V7: error: instruction requires: FPARMv8
vrintx.f64 d0, d1
@ CHECK-V7: error: instruction requires: FPARMv8
vrintx.f32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintx.f64.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrinta.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrinta.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrinta.f32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrinta.f64.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintn.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintn.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintn.f32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintn.f64.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintp.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintp.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintp.f32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintp.f64.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintm.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintm.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintm.f32.f32 s0, s0
@ CHECK-V7: error: instruction requires: FPARMv8
vrintm.f64.f64 d0, d0
@ CHECK-V7: error: instruction requires: FPARMv8
.arch_extension nosimd
@ CHECK-V7: error: architectural extension 'simd' is not allowed for the current base architecture
@ CHECK-V7-NEXT: .arch_extension nosimd
@ CHECK-V7-NEXT: ^
.type nosimd,%function
nosimd:
vmaxnm.f32 s0, s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vminnm.f32 s0, s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vmaxnm.f64 d0, d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vminnm.f64 d0, d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvta.s32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvta.u32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvta.s32.f64 s0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvta.u32.f64 s0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtn.s32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtn.u32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtn.s32.f64 s0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtn.u32.f64 s0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtp.s32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtp.u32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtp.s32.f64 s0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtp.u32.f64 s0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtm.s32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtm.u32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtm.s32.f64 s0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vcvtm.u32.f64 s0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintz.f32 s0, s1
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintz.f64 d0, d1
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintz.f32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintz.f64.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintr.f32 s0, s1
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintr.f64 d0, d1
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintr.f32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintr.f64.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintx.f32 s0, s1
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintx.f64 d0, d1
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintx.f32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintx.f64.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrinta.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrinta.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrinta.f32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrinta.f64.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintn.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintn.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintn.f32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintn.f64.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintp.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintp.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintp.f32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintp.f64.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintm.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintm.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintm.f32.f32 s0, s0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
vrintm.f64.f64 d0, d0
ARM: correct handling of features in arch_extension 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214057 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 19:07:09 +00:00
@ CHECK: error: instruction requires: FPARMv8
ARM IAS: (partially) support .arch_extension directive 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201471 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-16 00:16:41 +00:00
Reference in New Issue Copy Permalink