replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/clang/test/Driver/armv8.1m.main.c

63 lines
2.8 KiB
C
Raw Normal View History

[ARM] Add CLI support for Armv8.1-M and MVE Given the existing infrastructure in LLVM side for +fp and +fp.dp, this is more or less trivial, needing only one tiny source change and a couple of tests. Patch by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60699 llvm-svn: 362096
2019-05-30 22:22:26 +08:00
// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+dsp -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-DSP < %t %s
// CHECK-DSP: "-target-feature" "+dsp"
[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: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-FP < %t %s
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-FP-DAG: "-target-feature" "+fp-armv8d16sp"
// CHECK-FP-NOT: "-target-feature" "+fp-armv8d16"
// CHECK-FP-NOT: "-target-feature" "+fp-armv8sp"
// CHECK-FP-NOT: "-target-feature" "+fp-armv8"
[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
// CHECK-FP-NOT: "-target-feature" "+fp64"
// CHECK-FP-NOT: "-target-feature" "+d32"
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-FP-DAG: "-target-feature" "+fullfp16"
[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: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+nofp -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-NOFP < %t %s
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-NOFP-DAG: "-target-feature" "-vfp2"
// CHECK-NOFP-DAG: "-target-feature" "-vfp3"
// CHECK-NOFP-DAG: "-target-feature" "-fp16"
// CHECK-NOFP-DAG: "-target-feature" "-vfp4"
// CHECK-NOFP-DAG: "-target-feature" "-fp-armv8"
// CHECK-NOFP-DAG: "-target-feature" "-fp64"
// CHECK-NOFP-DAG: "-target-feature" "-d32"
// CHECK-NOFP-DAG: "-target-feature" "-neon"
// CHECK-NOFP-DAG: "-target-feature" "-crypto"
[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: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp.dp -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-FPDP < %t %s
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-FPDP-NOT: "-target-feature" "+fp-armv8sp"
// CHECK-FPDP-DAG: "-target-feature" "+fp-armv8d16"
// CHECK-FPDP-NOT: "-target-feature" "+fp-armv8"
// CHECK-FPDP-DAG: "-target-feature" "+fullfp16"
// CHECK-FPDP-DAG: "-target-feature" "+fp64"
[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
// CHECK-FPDP-NOT: "-target-feature" "+d32"
// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+nofp.dp -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-NOFPDP < %t %s
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-NOFPDP-DAG: "-target-feature" "-fp64"
[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
[ARM] Add CLI support for Armv8.1-M and MVE Given the existing infrastructure in LLVM side for +fp and +fp.dp, this is more or less trivial, needing only one tiny source change and a couple of tests. Patch by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60699 llvm-svn: 362096
2019-05-30 22:22:26 +08:00
// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-MVE < %t %s
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-MVE-DAG: "-target-feature" "+mve"
[ARM] Add CLI support for Armv8.1-M and MVE Given the existing infrastructure in LLVM side for +fp and +fp.dp, this is more or less trivial, needing only one tiny source change and a couple of tests. Patch by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60699 llvm-svn: 362096
2019-05-30 22:22:26 +08:00
[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: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+nomve -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-NOMVE < %t %s
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-NOMVE-DAG: "-target-feature" "-mve"
[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
[ARM] Add CLI support for Armv8.1-M and MVE Given the existing infrastructure in LLVM side for +fp and +fp.dp, this is more or less trivial, needing only one tiny source change and a couple of tests. Patch by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60699 llvm-svn: 362096
2019-05-30 22:22:26 +08:00
// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve.fp -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-MVEFP < %t %s
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-MVEFP-DAG: "-target-feature" "+mve.fp"
[ARM] Add CLI support for Armv8.1-M and MVE Given the existing infrastructure in LLVM side for +fp and +fp.dp, this is more or less trivial, needing only one tiny source change and a couple of tests. Patch by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60699 llvm-svn: 362096
2019-05-30 22:22:26 +08:00
// CHECK-MVEFP-NOT: "-target-feature" "+fp64"
[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: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+nomve.fp -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-NOMVEFP < %t %s
// CHECK-NOMVEFP: "-target-feature" "-mve.fp"
// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-MVEFP_DP < %t %s
[ARM] Fix bugs introduced by the fp64/d32 rework. Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
2019-06-07 20:42:54 +08:00
// CHECK-MVEFP_DP-DAG: "-target-feature" "+mve.fp"
// CHECK-MVEFP_DP-DAG: "-target-feature" "+fp64"
[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
[ARM] Add CLI support for Armv8.1-M and MVE Given the existing infrastructure in LLVM side for +fp and +fp.dp, this is more or less trivial, needing only one tiny source change and a couple of tests. Patch by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60699 llvm-svn: 362096
2019-05-30 22:22:26 +08:00
double foo (double a) { return a; }