2019-05-31 04:02:51 +08:00
|
|
|
# REQUIRES: arm-registered-target
|
2019-05-31 10:23:33 +08:00
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8-m.main -o /dev/null %s 2>%t
|
2019-05-30 22:22:26 +08:00
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V8M < %t %s
|
2019-05-31 10:23:33 +08:00
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main -o /dev/null %s 2>%t
|
2019-05-30 22:22:26 +08:00
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M < %t %s
|
2019-05-31 10:23:33 +08:00
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+dsp -o /dev/null %s 2>%t
|
2019-05-30 22:22:26 +08:00
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_DSP < %t %s
|
[ARM] Allow "-march=foo+fp" to vary with foo
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
2019-06-05 21:12:01 +08:00
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp -o /dev/null %s 2>%t
|
|
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_FP < %t %s
|
|
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+nofp -o /dev/null %s 2>%t
|
|
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_FP < %t %s
|
|
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp.dp -o /dev/null %s 2>%t
|
|
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_FPDP < %t %s
|
|
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+nofp.dp -o /dev/null %s 2>%t
|
|
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_FPDP < %t %s
|
2019-05-31 10:23:33 +08:00
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve -o /dev/null %s 2>%t
|
2019-05-30 22:22:26 +08:00
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_MVE < %t %s
|
[ARM] Allow "-march=foo+fp" to vary with foo
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
2019-06-05 21:12:01 +08:00
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+nomve -o /dev/null %s 2>%t
|
|
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_MVE < %t %s
|
|
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve+fp -o /dev/null %s 2>%t
|
|
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_MVE_FP < %t %s
|
2019-05-31 10:23:33 +08:00
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp -o /dev/null %s 2>%t
|
2019-05-30 22:22:26 +08:00
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_MVEFP < %t %s
|
[ARM] Allow "-march=foo+fp" to vary with foo
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
2019-06-05 21:12:01 +08:00
|
|
|
# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+nomve.fp -o /dev/null %s 2>%t
|
|
|
|
|
# RUN: FileCheck --check-prefix=ERROR-V81M_MVEFP < %t %s
|
2019-05-30 22:22:26 +08:00
|
|
|
|
|
|
|
|
.syntax unified
|
|
|
|
|
.thumb
|
|
|
|
|
.text
|
|
|
|
|
|
|
|
|
|
csinc r0, r1, r2, eq
|
|
|
|
|
# ERROR-V8M: :[[@LINE-1]]:1: error
|
|
|
|
|
|
|
|
|
|
qadd r0, r1, r2
|
|
|
|
|
# ERROR-V8M: :[[@LINE-1]]:1: error
|
|
|
|
|
# ERROR-V81M: :[[@LINE-2]]:1: error
|
|
|
|
|
# ERROR-V81M_FP: :[[@LINE-3]]:1: error
|
|
|
|
|
# ERROR-V81M_FPDP: :[[@LINE-4]]:1: error
|
|
|
|
|
|
|
|
|
|
vadd.f16 s0, s1, s2
|
|
|
|
|
# ERROR-V8M: :[[@LINE-1]]:1: error
|
|
|
|
|
# ERROR-V81M: :[[@LINE-2]]:1: error
|
|
|
|
|
# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
|
|
|
|
|
# ERROR-V81M_MVE: :[[@LINE-4]]:1: error
|
|
|
|
|
|
|
|
|
|
vabs.f32 s0, s1
|
|
|
|
|
# ERROR-V8M: :[[@LINE-1]]:1: error
|
|
|
|
|
# ERROR-V81M: :[[@LINE-2]]:1: error
|
|
|
|
|
# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
|
|
|
|
|
# ERROR-V81M_MVE: :[[@LINE-4]]:1: error
|
|
|
|
|
|
|
|
|
|
vcmp.f64 d0,d1
|
|
|
|
|
# ERROR-V8M: :[[@LINE-1]]:1: error
|
|
|
|
|
# ERROR-V81M: :[[@LINE-2]]:1: error
|
|
|
|
|
# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
|
[ARM] Allow "-march=foo+fp" to vary with foo
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
2019-06-05 21:12:01 +08:00
|
|
|
# ERROR-V81M_FP: :[[@LINE-4]]:1: error
|
|
|
|
|
# ERROR-V81M_MVE: :[[@LINE-5]]:1: error
|
|
|
|
|
# ERROR-V81M_MVE_FP: :[[@LINE-6]]:1: error
|
|
|
|
|
# ERROR-V81M_MVEFP: :[[@LINE-7]]:1: error
|
2019-05-30 22:22:26 +08:00
|
|
|
|
|
|
|
|
asrl r0, r1, r2
|
|
|
|
|
# ERROR-V8M: :[[@LINE-1]]:1: error
|
|
|
|
|
# ERROR-V81M: :[[@LINE-2]]:1: error
|
|
|
|
|
# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
|
[ARM] Allow "-march=foo+fp" to vary with foo
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
2019-06-05 21:12:01 +08:00
|
|
|
# ERROR-V81M_FP: :[[@LINE-4]]:1: error
|
|
|
|
|
# ERROR-V81M_FPDP: :[[@LINE-5]]:1: error
|
2019-05-30 22:22:26 +08:00
|
|
|
|
|
|
|
|
vcadd.i8 q0, q1, q2, #90
|
|
|
|
|
# ERROR-V8M: :[[@LINE-1]]:1: error
|
|
|
|
|
# ERROR-V81M: :[[@LINE-2]]:1: error
|
|
|
|
|
# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
|
[ARM] Allow "-march=foo+fp" to vary with foo
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
2019-06-05 21:12:01 +08:00
|
|
|
# ERROR-V81M_FP: :[[@LINE-4]]:1: error
|
|
|
|
|
# ERROR-V81M_FPDP: :[[@LINE-5]]:1: error
|