maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/build-attributes.ll

1720 lines
84 KiB
LLVM
Raw Normal View History

[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
; This tests that MC/asm header conversion is smooth and that the
; build attributes are correct
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=thumbv5-linux-gnueabi -mcpu=xscale -mattr=+strict-align | FileCheck %s --check-prefix=XSCALE
; RUN: llc < %s -mtriple=armv6-linux-gnueabi -mattr=+strict-align | FileCheck %s --check-prefix=V6
; RUN: llc < %s -mtriple=armv6-linux-gnueabi -mattr=+strict-align -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=V6-FAST
; RUN: llc < %s -mtriple=armv6-linux-gnueabi -mattr=+strict-align -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mattr=+strict-align | FileCheck %s --check-prefix=V6M
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mattr=+strict-align -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=V6M-FAST
; RUN: llc < %s -mtriple=thumbv6sm-linux-gnueabi -mattr=+strict-align | FileCheck %s --check-prefix=V6M
; RUN: llc < %s -mtriple=thumbv6sm-linux-gnueabi -mattr=+strict-align -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=V6M-FAST
; RUN: llc < %s -mtriple=armv6-linux-gnueabi -mcpu=arm1156t2f-s -mattr=+strict-align | FileCheck %s --check-prefix=ARM1156T2F-S
; RUN: llc < %s -mtriple=armv6-linux-gnueabi -mcpu=arm1156t2f-s -mattr=+strict-align -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=ARM1156T2F-S-FAST
; RUN: llc < %s -mtriple=armv6-linux-gnueabi -mcpu=arm1156t2f-s -mattr=+strict-align -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi | FileCheck %s --check-prefix=V7M
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=V7M-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi | FileCheck %s --check-prefix=V7
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=V7-FAST
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi | FileCheck %s --check-prefix=V8
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=V8-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; RUN: llc < %s -mtriple=thumbv8-linux-gnueabi | FileCheck %s --check-prefix=Vt8
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=thumbv8-linux-gnueabi -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Add subtarget feature support for Cortex-A53 Some previous implicit defaults have changed, for example FP and NEON are now on by default. llvm-svn: 192590
2013-10-14 21:16:57 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mattr=-neon,-crypto | FileCheck %s --check-prefix=V8-FPARMv8
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mattr=-fp-armv8,-crypto | FileCheck %s --check-prefix=V8-NEON
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mattr=-crypto | FileCheck %s --check-prefix=V8-FPARMv8-NEON
; RUN: llc < %s -mtriple=armv8-linux-gnueabi | FileCheck %s --check-prefix=V8-FPARMv8-NEON-CRYPTO
[ARM] Add ARMv8-M Baseline/Mainline LLVM targeting llvm-svn: 257878
2016-01-15 18:24:39 +08:00
; RUN: llc < %s -mtriple=thumbv8m.base-linux-gnueabi | FileCheck %s --check-prefix=V8MBASELINE
; RUN: llc < %s -mtriple=thumbv8m.main-linux-gnueabi | FileCheck %s --check-prefix=V8MMAINLINE
[ARM] Add DSP build attribute and extension targeting This patch was originally committed as r257885, but was reverted due to windows failures. The cause of these failures has been fixed under r258677, hence re-committing the original patch. llvm-svn: 258683
2016-01-25 19:26:11 +08:00
; RUN: llc < %s -mtriple=thumbv8m.main-linux-gnueabi -mattr=+dsp | FileCheck %s --check-prefix=V8MMAINLINE_DSP
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a5 | FileCheck %s --check-prefix=CORTEX-A5-DEFAULT
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a5 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A5-DEFAULT-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a5 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a5 -mattr=-neon,+d16 | FileCheck %s --check-prefix=CORTEX-A5-NONEON
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a5 -mattr=-vfp2 | FileCheck %s --check-prefix=CORTEX-A5-NOFPU
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a5 -mattr=-vfp2 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A5-NOFPU-FAST
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a8 -float-abi=soft | FileCheck %s --check-prefix=CORTEX-A8-SOFT
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a8 -float-abi=soft -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A8-SOFT-FAST
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a8 -float-abi=hard | FileCheck %s --check-prefix=CORTEX-A8-HARD
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a8 -float-abi=hard -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A8-HARD-FAST
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a8 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a8 -float-abi=soft | FileCheck %s --check-prefix=CORTEX-A8-SOFT
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a9 -float-abi=soft | FileCheck %s --check-prefix=CORTEX-A9-SOFT
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a9 -float-abi=soft -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A9-SOFT-FAST
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a9 -float-abi=hard | FileCheck %s --check-prefix=CORTEX-A9-HARD
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a9 -float-abi=hard -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A9-HARD-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a9 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a12 | FileCheck %s --check-prefix=CORTEX-A12-DEFAULT
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a9 -float-abi=soft | FileCheck %s --check-prefix=CORTEX-A9-SOFT
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a12 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A12-DEFAULT-FAST
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a12 -mattr=-vfp2 | FileCheck %s --check-prefix=CORTEX-A12-NOFPU
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a12 -mattr=-vfp2 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A12-NOFPU-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a12 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a15 | FileCheck %s --check-prefix=CORTEX-A15
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a15 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A15-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a15 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Adds support for the Cortex-A17 to the ARM backend Patch by Matthew Wahab. llvm-svn: 219606
2014-10-13 18:22:19 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a17 | FileCheck %s --check-prefix=CORTEX-A17-DEFAULT
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a17 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A17-FAST
Adds support for the Cortex-A17 to the ARM backend Patch by Matthew Wahab. llvm-svn: 219606
2014-10-13 18:22:19 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a17 -mattr=-vfp2 | FileCheck %s --check-prefix=CORTEX-A17-NOFPU
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a17 -mattr=-vfp2 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A17-NOFPU-FAST
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10645 llvm-svn: 240930
2015-06-29 17:32:29 +08:00
Clang patch r280064 introduced ways to set the FP exceptions and denormal types. This is the LLVM counterpart and it adds options that map onto FP exceptions and denormal build attributes allowing better fp math library selections. Differential Revision: https://reviews.llvm.org/D24070 llvm-svn: 280246
2016-08-31 22:17:38 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a15 -enable-no-trapping-fp-math | FileCheck %s --check-prefix=NO-TRAPPING-MATH
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a15 -denormal-fp-math=ieee | FileCheck %s --check-prefix=DENORMAL-IEEE
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a15 -denormal-fp-math=preserve-sign | FileCheck %s --check-prefix=DENORMAL-PRESERVE-SIGN
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a15 -denormal-fp-math=positive-zero | FileCheck %s --check-prefix=DENORMAL-POSITIVE-ZERO
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10645 llvm-svn: 240930
2015-06-29 17:32:29 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mattr=-neon,+vfp3,+fp16 | FileCheck %s --check-prefix=GENERIC-FPU-VFPV3-FP16
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mattr=-neon,+vfp3,+d16,+fp16 | FileCheck %s --check-prefix=GENERIC-FPU-VFPV3-D16-FP16
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mattr=-neon,+vfp3,+fp-only-sp,+d16 | FileCheck %s --check-prefix=GENERIC-FPU-VFPV3XD
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mattr=-neon,+vfp3,+fp-only-sp,+d16,+fp16 | FileCheck %s --check-prefix=GENERIC-FPU-VFPV3XD-FP16
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mattr=+neon,+fp16 | FileCheck %s --check-prefix=GENERIC-FPU-NEON-FP16
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7-linux-gnueabi -mcpu=cortex-a17 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Recommit of r335326, with the test fixed that I missed. llvm-svn: 335331
2018-06-22 18:03:03 +08:00
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m0 | FileCheck %s --check-prefix=CORTEX-M0
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m0 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M0-FAST
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m0 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m0plus | FileCheck %s --check-prefix=CORTEX-M0PLUS
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m0plus -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M0PLUS-FAST
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m0plus -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m1 | FileCheck %s --check-prefix=CORTEX-M1
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m1 -mattr=+strict-align -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M1-FAST
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=cortex-m1 -mattr=+strict-align -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=sc000 -mattr=+strict-align | FileCheck %s --check-prefix=SC000
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=sc000 -mattr=+strict-align -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=SC000-FAST
; RUN: llc < %s -mtriple=thumbv6m-linux-gnueabi -mcpu=sc000 -mattr=+strict-align -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Do not generate Tag_DIV_use=AllowDIVExt when hardware div is non-optional: it should have the default value of AllowDIVIfExists llvm-svn: 199638
2014-01-20 18:18:42 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=cortex-m3 | FileCheck %s --check-prefix=CORTEX-M3
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=cortex-m3 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M3-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=cortex-m3 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=sc300 | FileCheck %s --check-prefix=SC300
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=sc300 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=SC300-FAST
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=sc300 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=cortex-m4 -float-abi=soft | FileCheck %s --check-prefix=CORTEX-M4-SOFT
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=cortex-m4 -float-abi=soft -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M4-SOFT-FAST
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=cortex-m4 -float-abi=hard | FileCheck %s --check-prefix=CORTEX-M4-HARD
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=cortex-m4 -float-abi=hard -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M4-HARD-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=thumbv7m-linux-gnueabi -mcpu=cortex-m4 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP (LLVM) The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modelled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218747
2014-10-01 17:02:17 +08:00
; RUN: llc < %s -mtriple=thumbv7em-linux-gnueabi -mcpu=cortex-m7 -mattr=-vfp2 | FileCheck %s --check-prefix=CORTEX-M7 --check-prefix=CORTEX-M7-SOFT
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=thumbv7em-linux-gnueabi -mcpu=cortex-m7 -mattr=-vfp2 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M7-NOFPU-FAST
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP (LLVM) The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modelled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218747
2014-10-01 17:02:17 +08:00
; RUN: llc < %s -mtriple=thumbv7em-linux-gnueabi -mcpu=cortex-m7 -mattr=+fp-only-sp | FileCheck %s --check-prefix=CORTEX-M7 --check-prefix=CORTEX-M7-SINGLE
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=thumbv7em-linux-gnueabi -mcpu=cortex-m7 -mattr=+fp-only-sp -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M7-FAST
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; RUN: llc < %s -mtriple=thumbv7em-linux-gnueabi -mcpu=cortex-m7 | FileCheck %s --check-prefix=CORTEX-M7-DOUBLE
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=thumbv7em-linux-gnueabi -mcpu=cortex-m7 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Enable Cortex-M23 and Cortex-M33 support. Add both cores to the target parser and TableGen. Test that eabi attributes are set correctly for both cores. Additionally, test the absence and presence of MOVT in Cortex-M23 and Cortex-M33, respectively. Committed on behalf of Sanne Wouda. Reviewers : rengolin, olista01. Differential Revision: https://reviews.llvm.org/D29073 llvm-svn: 293761
2017-02-01 19:55:03 +08:00
; RUN: llc < %s -mtriple=thumbv8-linux-gnueabi -mcpu=cortex-m23 | FileCheck %s --check-prefix=CORTEX-M23
; RUN: llc < %s -mtriple=thumbv8-linux-gnueabi -mcpu=cortex-m33 | FileCheck %s --check-prefix=CORTEX-M33
; RUN: llc < %s -mtriple=thumbv8-linux-gnueabi -mcpu=cortex-m33 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-M33-FAST
; RUN: llc < %s -mtriple=thumbv8-linux-gnueabi -mcpu=cortex-m33 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] support for Cortex-R4/R4F Currently, llvm (backend) doesn't know cortex-r4, even though it is the default target for armv7r. Using "--target=armv7r-arm-none-eabi" provokes 'cortex-r4' is not a recognized processor for this target' by llvm. This patch adds support for cortex-r4 and, very closely related, r4f. llvm-svn: 234486
2015-04-09 22:07:28 +08:00
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r4 | FileCheck %s --check-prefix=CORTEX-R4
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r4f | FileCheck %s --check-prefix=CORTEX-R4F
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r5 | FileCheck %s --check-prefix=CORTEX-R5
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r5 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-R5-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r5 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r7 | FileCheck %s --check-prefix=CORTEX-R7
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r7 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-R7-FAST
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r7 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Cortex-R8 support This patch adds Cortex-R8 to Target Parser and TableGen. It also adds CodeGen tests for the build attributes. Patch by Pablo Barrio. Differential Revision: http://reviews.llvm.org/D17925 llvm-svn: 263132
2016-03-11 01:38:41 +08:00
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r8 | FileCheck %s --check-prefix=CORTEX-R8
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r8 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-R8-FAST
; RUN: llc < %s -mtriple=armv7r-linux-gnueabi -mcpu=cortex-r8 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Add Cortex-A32 support Adding Cortex-A32 as an available target in the ARM backend. Patch by Sam Parker. llvm-svn: 263956
2016-03-22 01:29:01 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a32 | FileCheck %s --check-prefix=CORTEX-A32
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a32 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A32-FAST
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a32 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[AArch64]: Add support for Cortex-A35 Adds support for the new Cortex-A35 ARMv8-A core. llvm-svn: 254503
2015-12-02 19:53:44 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a35 | FileCheck %s --check-prefix=CORTEX-A35
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a35 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A35-FAST
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a35 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a53 | FileCheck %s --check-prefix=CORTEX-A53
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a53 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A53-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a53 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Add Cortex-A57 support llvm-svn: 192591
2013-10-14 21:17:07 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a57 | FileCheck %s --check-prefix=CORTEX-A57
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a57 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A57-FAST
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a57 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Adding support to LLVM for targeting Cortex-A72 Currently, Cortex-A72 is modelled as an Cortex-A57 except the fp load balancing pass isn't enabled for Cortex-A72 as it's not profitable to have it enabled for this core. Patch by Ranjeet Singh. llvm-svn: 228140
2015-02-04 21:31:29 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a72 | FileCheck %s --check-prefix=CORTEX-A72
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a72 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A72-FAST
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a72 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
This adds support for Cortex-A73 as an available target. Differential Revision: http://reviews.llvm.org/D20865 llvm-svn: 271508
2016-06-02 18:48:52 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=cortex-a73 | FileCheck %s --check-prefix=CORTEX-A73
[AArch64, ARM] Add v8.1a architecture and generic cpu New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: t.p.northover Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8505 llvm-svn: 233290
2015-03-27 01:05:54 +08:00
; RUN: llc < %s -mtriple=armv8.1a-linux-gnueabi | FileCheck %s --check-prefix=GENERIC-ARMV8_1-A
[AArch64] Add support for Samsung Exynos-M1 Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A). Differential Revision: http://reviews.llvm.org/D15663 llvm-svn: 256828
2016-01-05 20:51:59 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m1 | FileCheck %s --check-prefix=EXYNOS-M1
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m1 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=EXYNOS-M1-FAST
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m1 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[AArch64] Add support for Samsung Exynos M2 (NFC). llvm-svn: 277364
2016-08-02 02:39:45 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m2 | FileCheck %s --check-prefix=EXYNOS-M2
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m2 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=EXYNOS-M1-FAST
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m2 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] Fix typo in checking prefix llvm-svn: 289617
2016-12-14 08:02:03 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m3 | FileCheck %s --check-prefix=EXYNOS-M3
Add support for Samsung Exynos M3 (NFC) llvm-svn: 289613
2016-12-14 07:31:41 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m3 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=EXYNOS-M1-FAST
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m3 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[AArch64, ARM] Add support for Samsung Exynos M4 Create a separate feature set for Exynos M4 and add test cases. llvm-svn: 334115
2018-06-07 02:56:00 +08:00
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m4 | FileCheck %s --check-prefix=EXYNOS-M4
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m4 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=EXYNOS-M1-FAST
; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mcpu=exynos-m4 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[AArch64, ARM] Add v8.1a architecture and generic cpu New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: t.p.northover Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8505 llvm-svn: 233290
2015-03-27 01:05:54 +08:00
; RUN: llc < %s -mtriple=armv8.1a-linux-gnueabi -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=GENERIC-ARMV8_1-A-FAST
; RUN: llc < %s -mtriple=armv8.1a-linux-gnueabi -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 | FileCheck %s --check-prefix=CORTEX-A7-CHECK
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A7-CHECK-FAST
[ARM] Disabling vfp4 should disable fp16 ARMTargetParser::getFPUFeatures should disable fp16 whenever it disables vfp4, as otherwise something like -mcpu=cortex-a7 -mfpu=none leaves us with fp16 enabled (though the only effect that will have is a wrong build attribute). Differential Revision: http://reviews.llvm.org/D10397 llvm-svn: 239599
2015-06-12 17:38:51 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 -mattr=-vfp2,-vfp3,-vfp4,-neon,-fp16 | FileCheck %s --check-prefix=CORTEX-A7-NOFPU
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 -mattr=-vfp2,-vfp3,-vfp4,-neon,-fp16 -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A7-NOFPU-FAST
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 -mattr=+vfp4,-neon | FileCheck %s --check-prefix=CORTEX-A7-FPUV4
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 -enable-sign-dependent-rounding-fp-math | FileCheck %s --check-prefix=DYN-ROUNDING
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 -mattr=+vfp4,-neon -enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast | FileCheck %s --check-prefix=CORTEX-A7-FPUV4-FAST
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 -mattr=+vfp4,,+d16,-neon | FileCheck %s --check-prefix=CORTEX-A7-FPUV4
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+strict-align -relocation-model=pic | FileCheck %s --check-prefix=RELOC-PIC
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+strict-align -relocation-model=static | FileCheck %s --check-prefix=RELOC-OTHER
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+strict-align -relocation-model=dynamic-no-pic | FileCheck %s --check-prefix=RELOC-OTHER
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+strict-align | FileCheck %s --check-prefix=RELOC-OTHER
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+strict-align | FileCheck %s --check-prefix=PCS-R9-USE
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+reserve-r9,+strict-align | FileCheck %s --check-prefix=PCS-R9-RESERVE
[ARM] Add support for embedded position-independent code This patch adds support for some new relocation models to the ARM backend: * Read-only position independence (ROPI): Code and read-only data is accessed PC-relative. The offsets between all code and RO data sections are known at static link time. This does not affect read-write data. * Read-write position independence (RWPI): Read-write data is accessed relative to the static base register (r9). The offsets between all writeable data sections are known at static link time. This does not affect read-only data. These two modes are independent (they specify how different objects should be addressed), so they can be used individually or together. They are otherwise the same as the "static" relocation model, and are not compatible with SysV-style PIC using a global offset table. These modes are normally used by bare-metal systems or systems with small real-time operating systems. They are designed to avoid the need for a dynamic linker, the only initialisation required is setting r9 to an appropriate value for RWPI code. I have only added support to SelectionDAG, not FastISel, because FastISel is currently disabled for bare-metal targets where these modes would be used. Differential Revision: https://reviews.llvm.org/D23195 llvm-svn: 278015
2016-08-08 23:28:31 +08:00
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+strict-align -relocation-model=ropi | FileCheck %s --check-prefix=RELOC-ROPI
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+strict-align -relocation-model=rwpi | FileCheck %s --check-prefix=RELOC-RWPI
; RUN: llc < %s -mtriple=arm-none-linux-gnueabi -mattr=+strict-align -relocation-model=ropi-rwpi | FileCheck %s --check-prefix=RELOC-ROPI-RWPI
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
[AArch64, ARM] Add v8.1a architecture and generic cpu New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: t.p.northover Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8505 llvm-svn: 233290
2015-03-27 01:05:54 +08:00
; ARMv8.1a (AArch32)
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=armv8.1a-none-linux-gnueabi | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=armv8.1a-none-linux-gnueabi -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
[AArch64, ARM] Add v8.1a architecture and generic cpu New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: t.p.northover Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8505 llvm-svn: 233290
2015-03-27 01:05:54 +08:00
; RUN: llc < %s -mtriple=armv8.1a-none-linux-gnueabi | FileCheck %s --check-prefix=NO-STRICT-ALIGN
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
; ARMv8a (AArch32)
[ARM] Add Cortex-A32 support Adding Cortex-A32 as an available target in the ARM backend. Patch by Sam Parker. llvm-svn: 263956
2016-03-22 01:29:01 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=cortex-a32 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=cortex-a32 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
[AArch64]: Add support for Cortex-A35 Adds support for the new Cortex-A35 ARMv8-A core. llvm-svn: 254503
2015-12-02 19:53:44 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=cortex-a35 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=cortex-a35 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
ARM: test default values for TAG_CPU_unaligned_access attribute. It should be on for every target that supports unaligned accesses (e.g. not v6m). Patch by Charlie Turner. llvm-svn: 220912
2014-10-31 01:05:44 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=cortex-a57 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=cortex-a57 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
Adding support to LLVM for targeting Cortex-A72 Currently, Cortex-A72 is modelled as an Cortex-A57 except the fp load balancing pass isn't enabled for Cortex-A72 as it's not profitable to have it enabled for this core. Patch by Ranjeet Singh. llvm-svn: 228140
2015-02-04 21:31:29 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=cortex-a72 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=cortex-a72 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
[AArch64] Add support for Samsung Exynos-M1 Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A). Differential Revision: http://reviews.llvm.org/D15663 llvm-svn: 256828
2016-01-05 20:51:59 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=exynos-m1 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=exynos-m1 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
[AArch64] Add support for Samsung Exynos M2 (NFC). llvm-svn: 277364
2016-08-02 02:39:45 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=exynos-m2 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=exynos-m2 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
Add support for Samsung Exynos M3 (NFC) llvm-svn: 289613
2016-12-14 07:31:41 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=exynos-m3 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=exynos-m3 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
[AArch64, ARM] Add support for Samsung Exynos M4 Create a separate feature set for Exynos M4 and add test cases. llvm-svn: 334115
2018-06-07 02:56:00 +08:00
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=exynos-m4 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=armv8-none-linux-gnueabi -mcpu=exynos-m4 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
[AArch64] Add support for Samsung Exynos-M1 Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A). Differential Revision: http://reviews.llvm.org/D15663 llvm-svn: 256828
2016-01-05 20:51:59 +08:00
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
; ARMv7a
ARM: test default values for TAG_CPU_unaligned_access attribute. It should be on for every target that supports unaligned accesses (e.g. not v6m). Patch by Charlie Turner. llvm-svn: 220912
2014-10-31 01:05:44 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -mcpu=cortex-a7 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
[ARM] Add support for armv7ve triple in llvm (PR31358). Gcc supports target armv7ve which is armv7-a with virtualization extensions. This change adds support for this in llvm for gcc compatibility. Also remove redundant FeatureHWDiv, FeatureHWDivARM for a few models as this is specified automatically by FeatureVirtualization. Patch by Manoj Gupta. Differential Revision: https://reviews.llvm.org/D29472 llvm-svn: 294661
2017-02-10 07:29:14 +08:00
; ARMv7ve
; RUN: llc < %s -mtriple=armv7ve-none-linux-gnueabi | FileCheck %s --check-prefix=V7VE
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
; ARMv7r
ARM: test default values for TAG_CPU_unaligned_access attribute. It should be on for every target that supports unaligned accesses (e.g. not v6m). Patch by Charlie Turner. llvm-svn: 220912
2014-10-31 01:05:44 +08:00
; RUN: llc < %s -mtriple=armv7r-none-linux-gnueabi -mcpu=cortex-r5 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=armv7r-none-linux-gnueabi -mcpu=cortex-r5 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
[ARM] Add support for armv7e-m to the .arch directive This will allow compilation of assembly files targeting armv7e-m without having to specify the Tag_CPU_arch attribute as a workaround. Differential revision: https://reviews.llvm.org/D40370 Patch by Ian Tessier! llvm-svn: 319303
2017-11-29 18:12:15 +08:00
; ARMv7em
; RUN: llc < %s -mtriple=thumbv7em-none-linux-gnueabi -mcpu=cortex-m4 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=thumbv7em-none-linux-gnueabi -mcpu=cortex-m4 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
; ARMv7m
ARM: test default values for TAG_CPU_unaligned_access attribute. It should be on for every target that supports unaligned accesses (e.g. not v6m). Patch by Charlie Turner. llvm-svn: 220912
2014-10-31 01:05:44 +08:00
; RUN: llc < %s -mtriple=thumbv7m-none-linux-gnueabi -mcpu=cortex-m3 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=thumbv7m-none-linux-gnueabi -mcpu=cortex-m3 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
; ARMv6
; RUN: llc < %s -mtriple=armv6-none-netbsd-gnueabi -mcpu=arm1136j-s | FileCheck %s --check-prefix=NO-STRICT-ALIGN
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=armv6-none-linux-gnueabi -mcpu=arm1136j-s -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
; RUN: llc < %s -mtriple=armv6-none-linux-gnueabi -mcpu=arm1136j-s | FileCheck %s --check-prefix=NO-STRICT-ALIGN
[ARM] Add support for ARMV6K subtarget (LLVM) ARMv6K is another layer between ARMV6 and ARMV6T2. This is the LLVM side of the changes. ARMV6 family LLVM implementation. +-------------------------------------+ | ARMV6 | +----------------+--------------------+ | ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors +----------------+--------------------+ have support for hint instructions | ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can +-------------------------------------+ be either real or default to NOP. | ARMV7 (arm,thumb,thumb2) | The two processors also use +-------------------------------------+ different encoding for them. Patch by Vinicius Tinti. llvm-svn: 232468
2015-03-17 19:55:28 +08:00
; ARMv6k
ARM: add arm1176j-f processor I doubt anyone actually uses it, and I'm not even entirely convinced it exists myself; but it is our default for "clang -arch armv6". Functionally, if it does exist it's identical to the arm1176jz-f from LLVM's point of view (the difference is apparently in the "Security Extensions"). llvm-svn: 301962
2017-05-03 03:06:13 +08:00
; RUN: llc < %s -mtriple=armv6k-none-netbsd-gnueabi -mcpu=arm1176j-s 2> %t | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: FileCheck %s < %t --allow-empty --check-prefix=CPU-SUPPORTED
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=armv6k-none-linux-gnueabi -mcpu=arm1176j-s -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
; RUN: llc < %s -mtriple=armv6k-none-linux-gnueabi -mcpu=arm1176j-s | FileCheck %s --check-prefix=NO-STRICT-ALIGN
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
; ARMv6m
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=thumb-none-linux-gnueabi -mcpu=cortex-m0 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
; RUN: llc < %s -mtriple=thumb-none-linux-gnueabi -mattr=+strict-align -mcpu=cortex-m0 | FileCheck %s --check-prefix=STRICT-ALIGN
; RUN: llc < %s -mtriple=thumbv6m-none-linux-gnueabi -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
; RUN: llc < %s -mtriple=thumb-none-linux-gnueabi -mcpu=cortex-m0 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
; ARMv5
[ARM] Define subtarget feature strict-align. This commit defines subtarget feature strict-align and uses it instead of cl::opt -arm-strict-align to decide whether strict alignment should be forced. Also, remove the logic that was checking the OS and architecture as clang is now responsible for setting strict-align based on the command line options specified and the target architecute and OS. rdar://problem/21529937 http://reviews.llvm.org/D11470 llvm-svn: 243493
2015-07-29 06:44:28 +08:00
; RUN: llc < %s -mtriple=armv5-none-linux-gnueabi -mcpu=arm1022e | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=armv5-none-linux-gnueabi -mcpu=arm1022e -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
[ARM]: Add Cortex-R52 target to LLVM This patch adds Cortex-R52, the new ARM real-time processor, to LLVM. Cortex-R52 implements the ARMv8-R architecture. llvm-svn: 283542
2016-10-07 20:06:40 +08:00
; ARMv8-R
; RUN: llc < %s -mtriple=arm-none-none-eabi -mcpu=cortex-r52 -mattr=-vfp2,-fp16 | FileCheck %s --check-prefix=ARMv8R --check-prefix=ARMv8R-NOFPU
; RUN: llc < %s -mtriple=arm-none-none-eabi -mcpu=cortex-r52 -mattr=-neon,+fp-only-sp,+d16 | FileCheck %s --check-prefix=ARMv8R --check-prefix=ARMv8R-SP
; RUN: llc < %s -mtriple=arm-none-none-eabi -mcpu=cortex-r52 | FileCheck %s --check-prefix=ARMv8R --check-prefix=ARMv8R-NEON
[ARM] Enable Cortex-M23 and Cortex-M33 support. Add both cores to the target parser and TableGen. Test that eabi attributes are set correctly for both cores. Additionally, test the absence and presence of MOVT in Cortex-M23 and Cortex-M33, respectively. Committed on behalf of Sanne Wouda. Reviewers : rengolin, olista01. Differential Revision: https://reviews.llvm.org/D29073 llvm-svn: 293761
2017-02-01 19:55:03 +08:00
; ARMv8-M
Recommit of r335326, with the test fixed that I missed. llvm-svn: 335331
2018-06-22 18:03:03 +08:00
; RUN: llc < %s -mtriple=thumbv8-none-none-eabi -mcpu=cortex-m23 | FileCheck %s --check-prefix=STRICT-ALIGN
[ARM] Enable Cortex-M23 and Cortex-M33 support. Add both cores to the target parser and TableGen. Test that eabi attributes are set correctly for both cores. Additionally, test the absence and presence of MOVT in Cortex-M23 and Cortex-M33, respectively. Committed on behalf of Sanne Wouda. Reviewers : rengolin, olista01. Differential Revision: https://reviews.llvm.org/D29073 llvm-svn: 293761
2017-02-01 19:55:03 +08:00
; RUN: llc < %s -mtriple=thumbv8-none-none-eabi -mcpu=cortex-m33 | FileCheck %s --check-prefix=NO-STRICT-ALIGN
; RUN: llc < %s -mtriple=thumbv8-none-none-eabi -mcpu=cortex-m33 -mattr=+strict-align | FileCheck %s --check-prefix=STRICT-ALIGN
ARM: add arm1176j-f processor I doubt anyone actually uses it, and I'm not even entirely convinced it exists myself; but it is our default for "clang -arch armv6". Functionally, if it does exist it's identical to the arm1176jz-f from LLVM's point of view (the difference is apparently in the "Security Extensions"). llvm-svn: 301962
2017-05-03 03:06:13 +08:00
; CPU-SUPPORTED-NOT: is not a recognized processor for this target
Move the xscale build attribute test to the proper place and remove the old one. The encoding of build attributes is already tested in CodeGen/ARM/build-attributes-encoding.s llvm-svn: 199393
2014-01-16 23:11:54 +08:00
; XSCALE: .eabi_attribute 6, 5
; XSCALE: .eabi_attribute 8, 1
; XSCALE: .eabi_attribute 9, 1
Emit ABI_FP_rounding attribute. LLVM understands a -enable-sign-dependent-rounding-fp-math codegen option. When the user has specified this option, the Tag_ABI_FP_rounding attribute should be emitted with value 1. This option currently does not appear to disable transformations and optimizations that assume default floating point rounding behavior, AFAICT, but the intention should be recorded in the build attributes, regardless of what the compiler actually does with the intention. Change-Id: If838578df3dc652b6f2796b8d152545674bcb30e llvm-svn: 223218
2014-12-03 16:12:26 +08:00
; DYN-ROUNDING: .eabi_attribute 19, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; V6: .eabi_attribute 6, 6
; V6: .eabi_attribute 8, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
;; We assume round-to-nearest by default (matches GCC)
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; V6-NOT: .eabi_attribute 27
; V6-NOT: .eabi_attribute 36
; V6-NOT: .eabi_attribute 42
; V6-NOT: .eabi_attribute 44
; V6-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V6-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The default choice made by llc is for a V6 CPU without an FPU.
;; This is not an interesting detail, but for such CPUs, the default intention is to use
;; software floating-point support. The choice is not important for targets without
;; FPU support!
; V6: .eabi_attribute 20, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V6: .eabi_attribute 21, 1
; V6-NOT: .eabi_attribute 22
; V6: .eabi_attribute 23, 3
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; V6: .eabi_attribute 24, 1
; V6: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; V6-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; V6: .eabi_attribute 38, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V6-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; Despite the V6 CPU having no FPU by default, we chose to flush to
;; positive zero here. There's no hardware support doing this, but the
;; fast maths software library might.
; V6-FAST-NOT: .eabi_attribute 20
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V6-FAST-NOT: .eabi_attribute 21
; V6-FAST-NOT: .eabi_attribute 22
; V6-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Add armv6s[-]m as an alias to armv6[-]m llvm-svn: 228696
2015-02-10 23:15:08 +08:00
;; We emit 6, 12 for both v6-M and v6S-M, technically this is incorrect for
;; V6-M, however we don't model the OS extension so this is fine.
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; V6M: .eabi_attribute 6, 12
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; V6M: .eabi_attribute 7, 77
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; V6M: .eabi_attribute 8, 0
; V6M: .eabi_attribute 9, 1
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; V6M-NOT: .eabi_attribute 27
; V6M-NOT: .eabi_attribute 36
; V6M-NOT: .eabi_attribute 42
; V6M-NOT: .eabi_attribute 44
; V6M-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V6M-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The default choice made by llc is for a V6M CPU without an FPU.
;; This is not an interesting detail, but for such CPUs, the default intention is to use
;; software floating-point support. The choice is not important for targets without
;; FPU support!
; V6M: .eabi_attribute 20, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V6M: .eabi_attribute 21, 1
; V6M-NOT: .eabi_attribute 22
; V6M: .eabi_attribute 23, 3
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; V6M: .eabi_attribute 24, 1
; V6M: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; V6M-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; V6M: .eabi_attribute 38, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V6M-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; Despite the V6M CPU having no FPU by default, we chose to flush to
;; positive zero here. There's no hardware support doing this, but the
;; fast maths software library might.
; V6M-FAST-NOT: .eabi_attribute 20
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V6M-FAST-NOT: .eabi_attribute 21
; V6M-FAST-NOT: .eabi_attribute 22
; V6M-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; ARM1156T2F-S: .cpu arm1156t2f-s
; ARM1156T2F-S: .eabi_attribute 6, 8
; ARM1156T2F-S: .eabi_attribute 8, 1
; ARM1156T2F-S: .eabi_attribute 9, 2
; ARM1156T2F-S: .fpu vfpv2
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; ARM1156T2F-S-NOT: .eabi_attribute 27
; ARM1156T2F-S-NOT: .eabi_attribute 36
; ARM1156T2F-S-NOT: .eabi_attribute 42
; ARM1156T2F-S-NOT: .eabi_attribute 44
; ARM1156T2F-S-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; ARM1156T2F-S-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; ARM1156T2F-S: .eabi_attribute 20, 1
; ARM1156T2F-S: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; ARM1156T2F-S-NOT: .eabi_attribute 22
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; ARM1156T2F-S: .eabi_attribute 23, 3
; ARM1156T2F-S: .eabi_attribute 24, 1
; ARM1156T2F-S: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; ARM1156T2F-S-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; ARM1156T2F-S: .eabi_attribute 38, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; ARM1156T2F-S-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; V6 cores default to flush to positive zero (value 0). Note that value 2 is also equally
;; valid for this core, it's an implementation defined question as to which of 0 and 2 you
;; select. LLVM historically picks 0.
; ARM1156T2F-S-FAST-NOT: .eabi_attribute 20
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; ARM1156T2F-S-FAST-NOT: .eabi_attribute 21
; ARM1156T2F-S-FAST-NOT: .eabi_attribute 22
; ARM1156T2F-S-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; V7M: .eabi_attribute 6, 10
; V7M: .eabi_attribute 7, 77
; V7M: .eabi_attribute 8, 0
; V7M: .eabi_attribute 9, 2
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; V7M-NOT: .eabi_attribute 27
; V7M-NOT: .eabi_attribute 36
; V7M-NOT: .eabi_attribute 42
; V7M-NOT: .eabi_attribute 44
; V7M-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V7M-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The default choice made by llc is for a V7M CPU without an FPU.
;; This is not an interesting detail, but for such CPUs, the default intention is to use
;; software floating-point support. The choice is not important for targets without
;; FPU support!
; V7M: .eabi_attribute 20, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V7M: .eabi_attribute 21, 1
; V7M-NOT: .eabi_attribute 22
; V7M: .eabi_attribute 23, 3
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; V7M: .eabi_attribute 24, 1
; V7M: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; V7M-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; V7M: .eabi_attribute 38, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V7M-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; Despite the V7M CPU having no FPU by default, we chose to flush
;; preserving sign. This matches what the hardware would do in the
;; architecture revision were to exist on the current target.
; V7M-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V7M-FAST-NOT: .eabi_attribute 21
; V7M-FAST-NOT: .eabi_attribute 22
; V7M-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; V7: .syntax unified
; V7: .eabi_attribute 6, 10
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; V7-NOT: .eabi_attribute 27
; V7-NOT: .eabi_attribute 36
; V7-NOT: .eabi_attribute 42
; V7-NOT: .eabi_attribute 44
; V7-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V7-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; In safe-maths mode we default to an IEEE 754 compliant choice.
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; V7: .eabi_attribute 20, 1
; V7: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V7-NOT: .eabi_attribute 22
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; V7: .eabi_attribute 23, 3
; V7: .eabi_attribute 24, 1
; V7: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; V7-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; V7: .eabi_attribute 38, 1
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V7-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The default CPU does have an FPU and it must be VFPv3 or better, so it flushes
;; denormals to zero preserving the sign.
; V7-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V7-FAST-NOT: .eabi_attribute 21
; V7-FAST-NOT: .eabi_attribute 22
; V7-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Add support for armv7ve triple in llvm (PR31358). Gcc supports target armv7ve which is armv7-a with virtualization extensions. This change adds support for this in llvm for gcc compatibility. Also remove redundant FeatureHWDiv, FeatureHWDivARM for a few models as this is specified automatically by FeatureVirtualization. Patch by Manoj Gupta. Differential Revision: https://reviews.llvm.org/D29472 llvm-svn: 294661
2017-02-10 07:29:14 +08:00
; V7VE: .syntax unified
; V7VE: .eabi_attribute 6, 10 @ Tag_CPU_arch
; V7VE: .eabi_attribute 7, 65 @ Tag_CPU_arch_profile
; V7VE: .eabi_attribute 8, 1 @ Tag_ARM_ISA_use
; V7VE: .eabi_attribute 9, 2 @ Tag_THUMB_ISA_use
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; V7VE: .eabi_attribute 42, 1 @ Tag_MPextension_use
; V7VE: .eabi_attribute 44, 2 @ Tag_DIV_use
; V7VE: .eabi_attribute 68, 3 @ Tag_Virtualization_use
[ARM] Add support for armv7ve triple in llvm (PR31358). Gcc supports target armv7ve which is armv7-a with virtualization extensions. This change adds support for this in llvm for gcc compatibility. Also remove redundant FeatureHWDiv, FeatureHWDivARM for a few models as this is specified automatically by FeatureVirtualization. Patch by Manoj Gupta. Differential Revision: https://reviews.llvm.org/D29472 llvm-svn: 294661
2017-02-10 07:29:14 +08:00
; V7VE: .eabi_attribute 17, 1 @ Tag_ABI_PCS_GOT_use
; V7VE: .eabi_attribute 20, 1 @ Tag_ABI_FP_denormal
; V7VE: .eabi_attribute 21, 1 @ Tag_ABI_FP_exceptions
; V7VE: .eabi_attribute 23, 3 @ Tag_ABI_FP_number_model
; V7VE: .eabi_attribute 24, 1 @ Tag_ABI_align_needed
; V7VE: .eabi_attribute 25, 1 @ Tag_ABI_align_preserved
; V7VE: .eabi_attribute 38, 1 @ Tag_ABI_FP_16bit_format
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; V8: .syntax unified
Emit the build attribute Tag_conformance. Claim conformance to version 2.09 of the ARM ABI. This build attribute must be emitted first amongst the build attributes when written to an object file. This is to simplify conformance detection by consumers. Change-Id: If9eddcfc416bc9ad6e5cc8cdcb05d0031af7657e llvm-svn: 225166
2015-01-05 21:12:17 +08:00
; V8: .eabi_attribute 67, "2.09"
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; V8: .eabi_attribute 6, 14
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; V8-NOT: .eabi_attribute 44
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V8-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; V8: .eabi_attribute 20, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V8: .eabi_attribute 21, 1
; V8-NOT: .eabi_attribute 22
; V8: .eabi_attribute 23, 3
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; V8-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The default does have an FPU, and for V8-A, it flushes preserving sign.
; V8-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; V8-FAST-NOT: .eabi_attribute 21
; V8-FAST-NOT: .eabi_attribute 22
; V8-FAST: .eabi_attribute 23, 1
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
; Vt8: .syntax unified
; Vt8: .eabi_attribute 6, 14
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; Vt8-NOT: .eabi_attribute 19
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; Vt8: .eabi_attribute 20, 1
; Vt8: .eabi_attribute 21, 1
; Vt8-NOT: .eabi_attribute 22
; Vt8: .eabi_attribute 23, 3
Tiny patch for proof-of-concept cleanup of ARMAsmPrinter::EmitStartOfAsmFile() Small test for sanity check of resulting ARM .s file. Tested against -r115129. llvm-svn: 115133
2010-09-30 10:45:56 +08:00
[ARMv8] Change hasV8Fp to hasFPARMv8, and other command line options to be more consistent. llvm-svn: 190692
2013-09-13 21:46:57 +08:00
; V8-FPARMv8: .syntax unified
; V8-FPARMv8: .eabi_attribute 6, 14
; V8-FPARMv8: .fpu fp-armv8
Add a Subtarget feature 'v8fp' to the ARM backend. llvm-svn: 185073
2013-06-27 19:49:26 +08:00
; V8-NEON: .syntax unified
; V8-NEON: .eabi_attribute 6, 14
[arm] Enhance the test case by checking .fpu directive. llvm-svn: 191891
2013-10-03 20:18:56 +08:00
; V8-NEON: .fpu neon
Add a Subtarget feature 'v8fp' to the ARM backend. llvm-svn: 185073
2013-06-27 19:49:26 +08:00
; V8-NEON: .eabi_attribute 12, 3
[ARMv8] Change hasV8Fp to hasFPARMv8, and other command line options to be more consistent. llvm-svn: 190692
2013-09-13 21:46:57 +08:00
; V8-FPARMv8-NEON: .syntax unified
; V8-FPARMv8-NEON: .eabi_attribute 6, 14
; V8-FPARMv8-NEON: .fpu neon-fp-armv8
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; V8-FPARMv8-NEON: .eabi_attribute 12, 3
; V8-FPARMv8-NEON-CRYPTO: .syntax unified
; V8-FPARMv8-NEON-CRYPTO: .eabi_attribute 6, 14
; V8-FPARMv8-NEON-CRYPTO: .fpu crypto-neon-fp-armv8
; V8-FPARMv8-NEON-CRYPTO: .eabi_attribute 12, 3
[ARM] Add ARMv8-M Baseline/Mainline LLVM targeting llvm-svn: 257878
2016-01-15 18:24:39 +08:00
; V8MBASELINE: .syntax unified
; '6' is Tag_CPU_arch, '16' is ARM v8-M Baseline
; V8MBASELINE: .eabi_attribute 6, 16
; '7' is Tag_CPU_arch_profile, '77' is 'M'
; V8MBASELINE: .eabi_attribute 7, 77
; '8' is Tag_ARM_ISA_use
; V8MBASELINE: .eabi_attribute 8, 0
; '9' is Tag_Thumb_ISA_use
; V8MBASELINE: .eabi_attribute 9, 3
; V8MMAINLINE: .syntax unified
; '6' is Tag_CPU_arch, '17' is ARM v8-M Mainline
; V8MMAINLINE: .eabi_attribute 6, 17
; V8MMAINLINE: .eabi_attribute 7, 77
; V8MMAINLINE: .eabi_attribute 8, 0
; V8MMAINLINE: .eabi_attribute 9, 3
[ARM] Add DSP build attribute and extension targeting This patch was originally committed as r257885, but was reverted due to windows failures. The cause of these failures has been fixed under r258677, hence re-committing the original patch. llvm-svn: 258683
2016-01-25 19:26:11 +08:00
; V8MMAINLINE_DSP-NOT: .eabi_attribute 46
; V8MMAINLINE_DSP: .syntax unified
; V8MBASELINE_DSP: .eabi_attribute 6, 17
; V8MBASELINE_DSP: .eabi_attribute 7, 77
; V8MMAINLINE_DSP: .eabi_attribute 8, 0
; V8MMAINLINE_DSP: .eabi_attribute 9, 3
; V8MMAINLINE_DSP: .eabi_attribute 46, 1
[ARM] Add ARMv8-M Baseline/Mainline LLVM targeting llvm-svn: 257878
2016-01-15 18:24:39 +08:00
Emit unaligned access build attribute for ARM Patch by Charlie Turner. llvm-svn: 219301
2014-10-08 20:26:22 +08:00
; Tag_CPU_unaligned_access
; NO-STRICT-ALIGN: .eabi_attribute 34, 1
; STRICT-ALIGN: .eabi_attribute 34, 0
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; Tag_CPU_arch 'ARMv7'
; CORTEX-A7-CHECK: .eabi_attribute 6, 10
; CORTEX-A7-NOFPU: .eabi_attribute 6, 10
; CORTEX-A7-FPUV4: .eabi_attribute 6, 10
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; Tag_CPU_arch_profile 'A'
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-CHECK: .eabi_attribute 7, 65
; CORTEX-A7-NOFPU: .eabi_attribute 7, 65
; CORTEX-A7-FPUV4: .eabi_attribute 7, 65
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; Tag_ARM_ISA_use
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-CHECK: .eabi_attribute 8, 1
; CORTEX-A7-NOFPU: .eabi_attribute 8, 1
; CORTEX-A7-FPUV4: .eabi_attribute 8, 1
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; Tag_THUMB_ISA_use
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-CHECK: .eabi_attribute 9, 2
; CORTEX-A7-NOFPU: .eabi_attribute 9, 2
; CORTEX-A7-FPUV4: .eabi_attribute 9, 2
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-CHECK: .fpu neon-vfpv4
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; CORTEX-A7-NOFPU-NOT: .fpu
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-FPUV4: .fpu vfpv4
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A7-CHECK-NOT: .eabi_attribute 19
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; Tag_FP_HP_extension
; CORTEX-A7-CHECK: .eabi_attribute 36, 1
; CORTEX-A7-NOFPU-NOT: .eabi_attribute 36
; CORTEX-A7-FPUV4: .eabi_attribute 36, 1
; Tag_MPextension_use
; CORTEX-A7-CHECK: .eabi_attribute 42, 1
; CORTEX-A7-NOFPU: .eabi_attribute 42, 1
; CORTEX-A7-FPUV4: .eabi_attribute 42, 1
; Tag_DIV_use
; CORTEX-A7-CHECK: .eabi_attribute 44, 2
; CORTEX-A7-NOFPU: .eabi_attribute 44, 2
; CORTEX-A7-FPUV4: .eabi_attribute 44, 2
; Tag_DSP_extension
; CORTEX-A7-CHECK-NOT: .eabi_attribute 46
; Tag_Virtualization_use
; CORTEX-A7-CHECK: .eabi_attribute 68, 3
; CORTEX-A7-NOFPU: .eabi_attribute 68, 3
; CORTEX-A7-FPUV4: .eabi_attribute 68, 3
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; Tag_ABI_FP_denormal
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
; CORTEX-A7-CHECK: .eabi_attribute 20, 1
;; The A7 has VFPv3 support by default, so flush preserving sign.
; CORTEX-A7-CHECK-FAST: .eabi_attribute 20, 2
; CORTEX-A7-NOFPU: .eabi_attribute 20, 1
;; Despite there being no FPU, we chose to flush to zero preserving
;; sign. This matches what the hardware would do for this architecture
;; revision.
; CORTEX-A7-NOFPU-FAST: .eabi_attribute 20, 2
; CORTEX-A7-FPUV4: .eabi_attribute 20, 1
;; The VFPv4 FPU flushes preserving sign.
; CORTEX-A7-FPUV4-FAST: .eabi_attribute 20, 2
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; Tag_ABI_FP_exceptions
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-CHECK: .eabi_attribute 21, 1
; CORTEX-A7-NOFPU: .eabi_attribute 21, 1
; CORTEX-A7-FPUV4: .eabi_attribute 21, 1
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; Tag_ABI_FP_user_exceptions
; CORTEX-A7-CHECK-NOT: .eabi_attribute 22
; CORTEX-A7-NOFPU-NOT: .eabi_attribute 22
; CORTEX-A7-FPUV4-NOT: .eabi_attribute 22
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; Tag_ABI_FP_number_model
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-CHECK: .eabi_attribute 23, 3
; CORTEX-A7-NOFPU: .eabi_attribute 23, 3
; CORTEX-A7-FPUV4: .eabi_attribute 23, 3
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
; Tag_ABI_align_needed
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-CHECK: .eabi_attribute 24, 1
; CORTEX-A7-NOFPU: .eabi_attribute 24, 1
; CORTEX-A7-FPUV4: .eabi_attribute 24, 1
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
ARM: update build attributes for ABI r2.09 Update names for the names as per the current ABI errata. Mark deprecated tags as such. llvm-svn: 199576
2014-01-19 16:25:35 +08:00
; Tag_ABI_align_preserved
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A7-CHECK: .eabi_attribute 25, 1
; CORTEX-A7-NOFPU: .eabi_attribute 25, 1
; CORTEX-A7-FPUV4: .eabi_attribute 25, 1
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; Tag_FP_16bit_format
; CORTEX-A7-CHECK: .eabi_attribute 38, 1
; CORTEX-A7-NOFPU: .eabi_attribute 38, 1
; CORTEX-A7-FPUV4: .eabi_attribute 38, 1
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-DEFAULT: .cpu cortex-a5
; CORTEX-A5-DEFAULT: .eabi_attribute 6, 10
; CORTEX-A5-DEFAULT: .eabi_attribute 7, 65
; CORTEX-A5-DEFAULT: .eabi_attribute 8, 1
; CORTEX-A5-DEFAULT: .eabi_attribute 9, 2
; CORTEX-A5-DEFAULT: .fpu neon-vfpv4
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A5-DEFAULT: .eabi_attribute 42, 1
; CORTEX-A5-DEFAULT-NOT: .eabi_attribute 44
; CORTEX-A5-DEFAULT: .eabi_attribute 68, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A5-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-DEFAULT: .eabi_attribute 20, 1
; CORTEX-A5-DEFAULT: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A5-DEFAULT-NOT: .eabi_attribute 22
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-DEFAULT: .eabi_attribute 23, 3
; CORTEX-A5-DEFAULT: .eabi_attribute 24, 1
; CORTEX-A5-DEFAULT: .eabi_attribute 25, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A5-DEFAULT-FAST-NOT: .eabi_attribute 19
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
;; The A5 defaults to a VFPv4 FPU, so it flushed preserving the sign when -ffast-math
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; is given.
; CORTEX-A5-DEFAULT-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A5-DEFAULT-FAST-NOT: .eabi_attribute 21
; CORTEX-A5-DEFAULT-FAST-NOT: .eabi_attribute 22
; CORTEX-A5-DEFAULT-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-NONEON: .cpu cortex-a5
; CORTEX-A5-NONEON: .eabi_attribute 6, 10
; CORTEX-A5-NONEON: .eabi_attribute 7, 65
; CORTEX-A5-NONEON: .eabi_attribute 8, 1
; CORTEX-A5-NONEON: .eabi_attribute 9, 2
; CORTEX-A5-NONEON: .fpu vfpv4-d16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A5-NONEON: .eabi_attribute 42, 1
; CORTEX-A5-NONEON: .eabi_attribute 68, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-NONEON: .eabi_attribute 20, 1
; CORTEX-A5-NONEON: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A5-NONEON-NOT: .eabi_attribute 22
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-NONEON: .eabi_attribute 23, 3
; CORTEX-A5-NONEON: .eabi_attribute 24, 1
; CORTEX-A5-NONEON: .eabi_attribute 25, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A5-NONEON-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The A5 defaults to a VFPv4 FPU, so it flushed preserving sign when -ffast-math
;; is given.
; CORTEX-A5-NONEON-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A5-NONEON-FAST-NOT: .eabi_attribute 21
; CORTEX-A5-NONEON-FAST-NOT: .eabi_attribute 22
; CORTEX-A5-NONEON-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-NOFPU: .cpu cortex-a5
; CORTEX-A5-NOFPU: .eabi_attribute 6, 10
; CORTEX-A5-NOFPU: .eabi_attribute 7, 65
; CORTEX-A5-NOFPU: .eabi_attribute 8, 1
; CORTEX-A5-NOFPU: .eabi_attribute 9, 2
; CORTEX-A5-NOFPU-NOT: .fpu
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A5-NOFPU: .eabi_attribute 42, 1
; CORTEX-A5-NOFPU: .eabi_attribute 68, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A5-NOFPU-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-NOFPU: .eabi_attribute 20, 1
; CORTEX-A5-NOFPU: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A5-NOFPU-NOT: .eabi_attribute 22
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
; CORTEX-A5-NOFPU: .eabi_attribute 23, 3
; CORTEX-A5-NOFPU: .eabi_attribute 24, 1
; CORTEX-A5-NOFPU: .eabi_attribute 25, 1
[ARM] add the overlooked tests for Cortex-A7 build attributes llvm-svn: 195365
2013-11-22 00:22:39 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A5-NOFPU-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; Despite there being no FPU, we chose to flush to zero preserving
;; sign. This matches what the hardware would do for this architecture
;; revision.
; CORTEX-A5-NOFPU-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A5-NOFPU-FAST-NOT: .eabi_attribute 21
; CORTEX-A5-NOFPU-FAST-NOT: .eabi_attribute 22
; CORTEX-A5-NOFPU-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
; CORTEX-A8-SOFT: .cpu cortex-a8
; CORTEX-A8-SOFT: .eabi_attribute 6, 10
; CORTEX-A8-SOFT: .eabi_attribute 7, 65
; CORTEX-A8-SOFT: .eabi_attribute 8, 1
; CORTEX-A8-SOFT: .eabi_attribute 9, 2
; CORTEX-A8-SOFT: .fpu neon
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A8-SOFT-NOT: .eabi_attribute 27
; CORTEX-A8-SOFT-NOT: .eabi_attribute 36, 1
; CORTEX-A8-SOFT-NOT: .eabi_attribute 42, 1
; CORTEX-A8-SOFT-NOT: .eabi_attribute 44
; CORTEX-A8-SOFT: .eabi_attribute 68, 1
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
; CORTEX-A8-SOFT-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-A8-SOFT: .eabi_attribute 20, 1
; CORTEX-A8-SOFT: .eabi_attribute 21, 1
; CORTEX-A8-SOFT-NOT: .eabi_attribute 22
; CORTEX-A8-SOFT: .eabi_attribute 23, 3
; CORTEX-A8-SOFT: .eabi_attribute 24, 1
; CORTEX-A8-SOFT: .eabi_attribute 25, 1
; CORTEX-A8-SOFT-NOT: .eabi_attribute 28
; CORTEX-A8-SOFT: .eabi_attribute 38, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A9-SOFT: .cpu cortex-a9
; CORTEX-A9-SOFT: .eabi_attribute 6, 10
; CORTEX-A9-SOFT: .eabi_attribute 7, 65
; CORTEX-A9-SOFT: .eabi_attribute 8, 1
; CORTEX-A9-SOFT: .eabi_attribute 9, 2
; CORTEX-A9-SOFT: .fpu neon
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A9-SOFT-NOT: .eabi_attribute 27
; CORTEX-A9-SOFT: .eabi_attribute 36, 1
; CORTEX-A9-SOFT: .eabi_attribute 42, 1
; CORTEX-A9-SOFT-NOT: .eabi_attribute 44
; CORTEX-A9-SOFT: .eabi_attribute 68, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A9-SOFT-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A9-SOFT: .eabi_attribute 20, 1
; CORTEX-A9-SOFT: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A9-SOFT-NOT: .eabi_attribute 22
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A9-SOFT: .eabi_attribute 23, 3
; CORTEX-A9-SOFT: .eabi_attribute 24, 1
; CORTEX-A9-SOFT: .eabi_attribute 25, 1
; CORTEX-A9-SOFT-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-A9-SOFT: .eabi_attribute 38, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
; CORTEX-A8-SOFT-FAST-NOT: .eabi_attribute 19
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A9-SOFT-FAST-NOT: .eabi_attribute 19
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
;; The A9 defaults to a VFPv3 FPU, so it flushes preserving the sign when
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; -ffast-math is specified.
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
; CORTEX-A8-SOFT-FAST: .eabi_attribute 20, 2
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
; CORTEX-A9-SOFT-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A5-SOFT-FAST-NOT: .eabi_attribute 21
; CORTEX-A5-SOFT-FAST-NOT: .eabi_attribute 22
; CORTEX-A5-SOFT-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
; CORTEX-A8-HARD: .cpu cortex-a8
; CORTEX-A8-HARD: .eabi_attribute 6, 10
; CORTEX-A8-HARD: .eabi_attribute 7, 65
; CORTEX-A8-HARD: .eabi_attribute 8, 1
; CORTEX-A8-HARD: .eabi_attribute 9, 2
; CORTEX-A8-HARD: .fpu neon
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A8-HARD-NOT: .eabi_attribute 27
; CORTEX-A8-HARD-NOT: .eabi_attribute 36, 1
; CORTEX-A8-HARD-NOT: .eabi_attribute 42, 1
; CORTEX-A8-HARD: .eabi_attribute 68, 1
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
; CORTEX-A8-HARD-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-A8-HARD: .eabi_attribute 20, 1
; CORTEX-A8-HARD: .eabi_attribute 21, 1
; CORTEX-A8-HARD-NOT: .eabi_attribute 22
; CORTEX-A8-HARD: .eabi_attribute 23, 3
; CORTEX-A8-HARD: .eabi_attribute 24, 1
; CORTEX-A8-HARD: .eabi_attribute 25, 1
; CORTEX-A8-HARD: .eabi_attribute 28, 1
; CORTEX-A8-HARD: .eabi_attribute 38, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A9-HARD: .cpu cortex-a9
; CORTEX-A9-HARD: .eabi_attribute 6, 10
; CORTEX-A9-HARD: .eabi_attribute 7, 65
; CORTEX-A9-HARD: .eabi_attribute 8, 1
; CORTEX-A9-HARD: .eabi_attribute 9, 2
; CORTEX-A9-HARD: .fpu neon
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A9-HARD-NOT: .eabi_attribute 27
; CORTEX-A9-HARD: .eabi_attribute 36, 1
; CORTEX-A9-HARD: .eabi_attribute 42, 1
; CORTEX-A9-HARD: .eabi_attribute 68, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A9-HARD-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A9-HARD: .eabi_attribute 20, 1
; CORTEX-A9-HARD: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A9-HARD-NOT: .eabi_attribute 22
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A9-HARD: .eabi_attribute 23, 3
; CORTEX-A9-HARD: .eabi_attribute 24, 1
; CORTEX-A9-HARD: .eabi_attribute 25, 1
; CORTEX-A9-HARD: .eabi_attribute 28, 1
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-A9-HARD: .eabi_attribute 38, 1
[ARM] Add Virtualization subtarget feature and more build attributes in this area Add a Virtualization ARM subtarget feature along with adding proper build attribute emission for Tag_Virtualization_use (encodes Virtualization and TrustZone) and Tag_MPextension_use. Also rework test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll testcase to something that is more maintainable. This changes the focus of this testcase away from testing CPU defaults (which is tested elsewhere), onto specifically testing that attributes are encoded correctly. llvm-svn: 193859
2013-11-01 21:27:35 +08:00
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
; CORTEX-A8-HARD-FAST-NOT: .eabi_attribute 19
;; The A8 defaults to a VFPv3 FPU, so it flushes preserving the sign when
;; -ffast-math is specified.
; CORTEX-A8-HARD-FAST: .eabi_attribute 20, 2
; CORTEX-A8-HARD-FAST-NOT: .eabi_attribute 21
; CORTEX-A8-HARD-FAST-NOT: .eabi_attribute 22
; CORTEX-A8-HARD-FAST: .eabi_attribute 23, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A9-HARD-FAST-NOT: .eabi_attribute 19
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
;; The A9 defaults to a VFPv3 FPU, so it flushes preserving the sign when
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; -ffast-math is specified.
; CORTEX-A9-HARD-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A9-HARD-FAST-NOT: .eabi_attribute 21
; CORTEX-A9-HARD-FAST-NOT: .eabi_attribute 22
; CORTEX-A9-HARD-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
; CORTEX-A12-DEFAULT: .cpu cortex-a12
; CORTEX-A12-DEFAULT: .eabi_attribute 6, 10
; CORTEX-A12-DEFAULT: .eabi_attribute 7, 65
; CORTEX-A12-DEFAULT: .eabi_attribute 8, 1
; CORTEX-A12-DEFAULT: .eabi_attribute 9, 2
; CORTEX-A12-DEFAULT: .fpu neon-vfpv4
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A12-DEFAULT: .eabi_attribute 42, 1
; CORTEX-A12-DEFAULT: .eabi_attribute 44, 2
; CORTEX-A12-DEFAULT: .eabi_attribute 68, 3
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A12-DEFAULT-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
; CORTEX-A12-DEFAULT: .eabi_attribute 20, 1
; CORTEX-A12-DEFAULT: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A12-DEFAULT-NOT: .eabi_attribute 22
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
; CORTEX-A12-DEFAULT: .eabi_attribute 23, 3
; CORTEX-A12-DEFAULT: .eabi_attribute 24, 1
; CORTEX-A12-DEFAULT: .eabi_attribute 25, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A12-DEFAULT-FAST-NOT: .eabi_attribute 19
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
;; The A12 defaults to a VFPv3 FPU, so it flushes preserving the sign when
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; -ffast-math is specified.
; CORTEX-A12-DEFAULT-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A12-HARD-FAST-NOT: .eabi_attribute 21
; CORTEX-A12-HARD-FAST-NOT: .eabi_attribute 22
; CORTEX-A12-HARD-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
; CORTEX-A12-NOFPU: .cpu cortex-a12
; CORTEX-A12-NOFPU: .eabi_attribute 6, 10
; CORTEX-A12-NOFPU: .eabi_attribute 7, 65
; CORTEX-A12-NOFPU: .eabi_attribute 8, 1
; CORTEX-A12-NOFPU: .eabi_attribute 9, 2
; CORTEX-A12-NOFPU-NOT: .fpu
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A12-NOFPU: .eabi_attribute 42, 1
; CORTEX-A12-NOFPU: .eabi_attribute 44, 2
; CORTEX-A12-NOFPU: .eabi_attribute 68, 3
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A12-NOFPU-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
; CORTEX-A12-NOFPU: .eabi_attribute 20, 1
; CORTEX-A12-NOFPU: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A12-NOFPU-NOT: .eabi_attribute 22
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
; CORTEX-A12-NOFPU: .eabi_attribute 23, 3
; CORTEX-A12-NOFPU: .eabi_attribute 24, 1
; CORTEX-A12-NOFPU: .eabi_attribute 25, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A12-NOFPU-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; Despite there being no FPU, we chose to flush to zero preserving
;; sign. This matches what the hardware would do for this architecture
;; revision.
; CORTEX-A12-NOFPU-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A12-NOFPU-FAST-NOT: .eabi_attribute 21
; CORTEX-A12-NOFPU-FAST-NOT: .eabi_attribute 22
; CORTEX-A12-NOFPU-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
; CORTEX-A15: .cpu cortex-a15
; CORTEX-A15: .eabi_attribute 6, 10
; CORTEX-A15: .eabi_attribute 7, 65
; CORTEX-A15: .eabi_attribute 8, 1
; CORTEX-A15: .eabi_attribute 9, 2
; CORTEX-A15: .fpu neon-vfpv4
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A15-NOT: .eabi_attribute 27
; CORTEX-A15: .eabi_attribute 36, 1
; CORTEX-A15: .eabi_attribute 42, 1
; CORTEX-A15: .eabi_attribute 44, 2
; CORTEX-A15: .eabi_attribute 68, 3
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A15-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
; CORTEX-A15: .eabi_attribute 20, 1
; CORTEX-A15: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A15-NOT: .eabi_attribute 22
[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
; CORTEX-A15: .eabi_attribute 23, 3
; CORTEX-A15: .eabi_attribute 24, 1
; CORTEX-A15: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A15-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-A15: .eabi_attribute 38, 1
[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A15-FAST-NOT: .eabi_attribute 19
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
;; The A15 defaults to a VFPv3 FPU, so it flushes preserving the sign when
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; -ffast-math is specified.
; CORTEX-A15-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A15-FAST-NOT: .eabi_attribute 21
; CORTEX-A15-FAST-NOT: .eabi_attribute 22
; CORTEX-A15-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Adds support for the Cortex-A17 to the ARM backend Patch by Matthew Wahab. llvm-svn: 219606
2014-10-13 18:22:19 +08:00
; CORTEX-A17-DEFAULT: .cpu cortex-a17
; CORTEX-A17-DEFAULT: .eabi_attribute 6, 10
; CORTEX-A17-DEFAULT: .eabi_attribute 7, 65
; CORTEX-A17-DEFAULT: .eabi_attribute 8, 1
; CORTEX-A17-DEFAULT: .eabi_attribute 9, 2
; CORTEX-A17-DEFAULT: .fpu neon-vfpv4
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A17-DEFAULT: .eabi_attribute 42, 1
; CORTEX-A17-DEFAULT: .eabi_attribute 44, 2
; CORTEX-A17-DEFAULT: .eabi_attribute 68, 3
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A17-DEFAULT-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
Adds support for the Cortex-A17 to the ARM backend Patch by Matthew Wahab. llvm-svn: 219606
2014-10-13 18:22:19 +08:00
; CORTEX-A17-DEFAULT: .eabi_attribute 20, 1
; CORTEX-A17-DEFAULT: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A17-DEFAULT-NOT: .eabi_attribute 22
Adds support for the Cortex-A17 to the ARM backend Patch by Matthew Wahab. llvm-svn: 219606
2014-10-13 18:22:19 +08:00
; CORTEX-A17-DEFAULT: .eabi_attribute 23, 3
; CORTEX-A17-DEFAULT: .eabi_attribute 24, 1
; CORTEX-A17-DEFAULT: .eabi_attribute 25, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A17-FAST-NOT: .eabi_attribute 19
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
;; The A17 defaults to a VFPv3 FPU, so it flushes preserving the sign when
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; -ffast-math is specified.
; CORTEX-A17-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A17-FAST-NOT: .eabi_attribute 21
; CORTEX-A17-FAST-NOT: .eabi_attribute 22
; CORTEX-A17-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Adds support for the Cortex-A17 to the ARM backend Patch by Matthew Wahab. llvm-svn: 219606
2014-10-13 18:22:19 +08:00
; CORTEX-A17-NOFPU: .cpu cortex-a17
; CORTEX-A17-NOFPU: .eabi_attribute 6, 10
; CORTEX-A17-NOFPU: .eabi_attribute 7, 65
; CORTEX-A17-NOFPU: .eabi_attribute 8, 1
; CORTEX-A17-NOFPU: .eabi_attribute 9, 2
; CORTEX-A17-NOFPU-NOT: .fpu
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A17-NOFPU: .eabi_attribute 42, 1
; CORTEX-A17-NOFPU: .eabi_attribute 44, 2
; CORTEX-A17-NOFPU: .eabi_attribute 68, 3
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A17-NOFPU-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
Adds support for the Cortex-A17 to the ARM backend Patch by Matthew Wahab. llvm-svn: 219606
2014-10-13 18:22:19 +08:00
; CORTEX-A17-NOFPU: .eabi_attribute 20, 1
; CORTEX-A17-NOFPU: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A17-NOFPU-NOT: .eabi_attribute 22
Adds support for the Cortex-A17 to the ARM backend Patch by Matthew Wahab. llvm-svn: 219606
2014-10-13 18:22:19 +08:00
; CORTEX-A17-NOFPU: .eabi_attribute 23, 3
; CORTEX-A17-NOFPU: .eabi_attribute 24, 1
; CORTEX-A17-NOFPU: .eabi_attribute 25, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A17-NOFPU-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; Despite there being no FPU, we chose to flush to zero preserving
;; sign. This matches what the hardware would do for this architecture
;; revision.
; CORTEX-A17-NOFPU-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A17-NOFPU-FAST-NOT: .eabi_attribute 21
; CORTEX-A17-NOFPU-FAST-NOT: .eabi_attribute 22
; CORTEX-A17-NOFPU-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Clang patch r280064 introduced ways to set the FP exceptions and denormal types. This is the LLVM counterpart and it adds options that map onto FP exceptions and denormal build attributes allowing better fp math library selections. Differential Revision: https://reviews.llvm.org/D24070 llvm-svn: 280246
2016-08-31 22:17:38 +08:00
; Test flags -enable-no-trapping-fp-math and -denormal-fp-math:
; NO-TRAPPING-MATH: .eabi_attribute 21, 0
; DENORMAL-IEEE: .eabi_attribute 20, 1
; DENORMAL-PRESERVE-SIGN: .eabi_attribute 20, 2
; DENORMAL-POSITIVE-ZERO: .eabi_attribute 20, 0
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-M0: .cpu cortex-m0
; CORTEX-M0: .eabi_attribute 6, 12
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M0: .eabi_attribute 7, 77
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-M0: .eabi_attribute 8, 0
; CORTEX-M0: .eabi_attribute 9, 1
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M0-NOT: .eabi_attribute 27
; CORTEX-M0-NOT: .eabi_attribute 36
; CORTEX-M0: .eabi_attribute 34, 0
; CORTEX-M0-NOT: .eabi_attribute 42
; CORTEX-M0-NOT: .eabi_attribute 44
; CORTEX-M0-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M0-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
; CORTEX-M0: .eabi_attribute 20, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M0: .eabi_attribute 21, 1
; CORTEX-M0-NOT: .eabi_attribute 22
; CORTEX-M0: .eabi_attribute 23, 3
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-M0: .eabi_attribute 24, 1
; CORTEX-M0: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-M0-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-M0: .eabi_attribute 38, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M0-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; Despite the M0 CPU having no FPU in this scenario, we chose to
;; flush to positive zero here. There's no hardware support doing
;; this, but the fast maths software library might and such behaviour
;; would match hardware support on this architecture revision if it
;; existed.
; CORTEX-M0-FAST-NOT: .eabi_attribute 20
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M0-FAST-NOT: .eabi_attribute 21
; CORTEX-M0-FAST-NOT: .eabi_attribute 22
; CORTEX-M0-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; CORTEX-M0PLUS: .cpu cortex-m0plus
; CORTEX-M0PLUS: .eabi_attribute 6, 12
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M0PLUS: .eabi_attribute 7, 77
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; CORTEX-M0PLUS: .eabi_attribute 8, 0
; CORTEX-M0PLUS: .eabi_attribute 9, 1
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M0PLUS-NOT: .eabi_attribute 27
; CORTEX-M0PLUS-NOT: .eabi_attribute 36
; CORTEX-M0PLUS-NOT: .eabi_attribute 42
; CORTEX-M0PLUS-NOT: .eabi_attribute 44
; CORTEX-M0PLUS-NOT: .eabi_attribute 68
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; CORTEX-M0PLUS-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-M0PLUS: .eabi_attribute 20, 1
; CORTEX-M0PLUS: .eabi_attribute 21, 1
; CORTEX-M0PLUS-NOT: .eabi_attribute 22
; CORTEX-M0PLUS: .eabi_attribute 23, 3
; CORTEX-M0PLUS: .eabi_attribute 24, 1
; CORTEX-M0PLUS: .eabi_attribute 25, 1
; CORTEX-M0PLUS-NOT: .eabi_attribute 28
; CORTEX-M0PLUS: .eabi_attribute 38, 1
; CORTEX-M0PLUS-FAST-NOT: .eabi_attribute 19
;; Despite the M0+ CPU having no FPU in this scenario, we chose to
;; flush to positive zero here. There's no hardware support doing
;; this, but the fast maths software library might and such behaviour
;; would match hardware support on this architecture revision if it
;; existed.
; CORTEX-M0PLUS-FAST-NOT: .eabi_attribute 20
; CORTEX-M0PLUS-FAST-NOT: .eabi_attribute 21
; CORTEX-M0PLUS-FAST-NOT: .eabi_attribute 22
; CORTEX-M0PLUS-FAST: .eabi_attribute 23, 1
; CORTEX-M1: .cpu cortex-m1
; CORTEX-M1: .eabi_attribute 6, 12
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M1: .eabi_attribute 7, 77
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; CORTEX-M1: .eabi_attribute 8, 0
; CORTEX-M1: .eabi_attribute 9, 1
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M1-NOT: .eabi_attribute 27
; CORTEX-M1-NOT: .eabi_attribute 36
; CORTEX-M1-NOT: .eabi_attribute 42
; CORTEX-M1-NOT: .eabi_attribute 44
; CORTEX-M1-NOT: .eabi_attribute 68
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; CORTEX-M1-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-M1: .eabi_attribute 20, 1
; CORTEX-M1: .eabi_attribute 21, 1
; CORTEX-M1-NOT: .eabi_attribute 22
; CORTEX-M1: .eabi_attribute 23, 3
; CORTEX-M1: .eabi_attribute 24, 1
; CORTEX-M1: .eabi_attribute 25, 1
; CORTEX-M1-NOT: .eabi_attribute 28
; CORTEX-M1: .eabi_attribute 38, 1
; CORTEX-M1-FAST-NOT: .eabi_attribute 19
;; Despite the M1 CPU having no FPU in this scenario, we chose to
;; flush to positive zero here. There's no hardware support doing
;; this, but the fast maths software library might and such behaviour
;; would match hardware support on this architecture revision if it
;; existed.
; CORTEX-M1-FAST-NOT: .eabi_attribute 20
; CORTEX-M1-FAST-NOT: .eabi_attribute 21
; CORTEX-M1-FAST-NOT: .eabi_attribute 22
; CORTEX-M1-FAST: .eabi_attribute 23, 1
; SC000: .cpu sc000
; SC000: .eabi_attribute 6, 12
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; SC000: .eabi_attribute 7, 77
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; SC000: .eabi_attribute 8, 0
; SC000: .eabi_attribute 9, 1
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; SC000-NOT: .eabi_attribute 27
; SC000-NOT: .eabi_attribute 42
; SC000-NOT: .eabi_attribute 44
; SC000-NOT: .eabi_attribute 68
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; SC000-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; SC000: .eabi_attribute 20, 1
; SC000: .eabi_attribute 21, 1
; SC000-NOT: .eabi_attribute 22
; SC000: .eabi_attribute 23, 3
; SC000: .eabi_attribute 24, 1
; SC000: .eabi_attribute 25, 1
; SC000-NOT: .eabi_attribute 28
; SC000: .eabi_attribute 38, 1
; SC000-FAST-NOT: .eabi_attribute 19
;; Despite the SC000 CPU having no FPU in this scenario, we chose to
;; flush to positive zero here. There's no hardware support doing
;; this, but the fast maths software library might and such behaviour
;; would match hardware support on this architecture revision if it
;; existed.
; SC000-FAST-NOT: .eabi_attribute 20
; SC000-FAST-NOT: .eabi_attribute 21
; SC000-FAST-NOT: .eabi_attribute 22
; SC000-FAST: .eabi_attribute 23, 1
[ARM] Do not generate Tag_DIV_use=AllowDIVExt when hardware div is non-optional: it should have the default value of AllowDIVIfExists llvm-svn: 199638
2014-01-20 18:18:42 +08:00
; CORTEX-M3: .cpu cortex-m3
; CORTEX-M3: .eabi_attribute 6, 10
; CORTEX-M3: .eabi_attribute 7, 77
; CORTEX-M3: .eabi_attribute 8, 0
; CORTEX-M3: .eabi_attribute 9, 2
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M3-NOT: .eabi_attribute 27
; CORTEX-M3-NOT: .eabi_attribute 36
; CORTEX-M3-NOT: .eabi_attribute 42
; CORTEX-M3-NOT: .eabi_attribute 44
; CORTEX-M3-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M3-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Do not generate Tag_DIV_use=AllowDIVExt when hardware div is non-optional: it should have the default value of AllowDIVIfExists llvm-svn: 199638
2014-01-20 18:18:42 +08:00
; CORTEX-M3: .eabi_attribute 20, 1
; CORTEX-M3: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M3-NOT: .eabi_attribute 22
[ARM] Do not generate Tag_DIV_use=AllowDIVExt when hardware div is non-optional: it should have the default value of AllowDIVIfExists llvm-svn: 199638
2014-01-20 18:18:42 +08:00
; CORTEX-M3: .eabi_attribute 23, 3
; CORTEX-M3: .eabi_attribute 24, 1
; CORTEX-M3: .eabi_attribute 25, 1
; CORTEX-M3-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-M3: .eabi_attribute 38, 1
[ARM] Do not generate Tag_DIV_use=AllowDIVExt when hardware div is non-optional: it should have the default value of AllowDIVIfExists llvm-svn: 199638
2014-01-20 18:18:42 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M3-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; Despite there being no FPU, we chose to flush to zero preserving
;; sign. This matches what the hardware would do for this architecture
;; revision.
; CORTEX-M3-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M3-FAST-NOT: .eabi_attribute 21
; CORTEX-M3-FAST-NOT: .eabi_attribute 22
; CORTEX-M3-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; SC300: .cpu sc300
; SC300: .eabi_attribute 6, 10
; SC300: .eabi_attribute 7, 77
; SC300: .eabi_attribute 8, 0
; SC300: .eabi_attribute 9, 2
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; SC300-NOT: .eabi_attribute 27
; SC300-NOT: .eabi_attribute 36
; SC300-NOT: .eabi_attribute 42
; SC300-NOT: .eabi_attribute 44
; SC300-NOT: .eabi_attribute 68
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; SC300-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; SC300: .eabi_attribute 20, 1
; SC300: .eabi_attribute 21, 1
; SC300-NOT: .eabi_attribute 22
; SC300: .eabi_attribute 23, 3
; SC300: .eabi_attribute 24, 1
; SC300: .eabi_attribute 25, 1
; SC300-NOT: .eabi_attribute 28
; SC300: .eabi_attribute 38, 1
; SC300-FAST-NOT: .eabi_attribute 19
;; Despite there being no FPU, we chose to flush to zero preserving
;; sign. This matches what the hardware would do for this architecture
;; revision.
; SC300-FAST: .eabi_attribute 20, 2
; SC300-FAST-NOT: .eabi_attribute 21
; SC300-FAST-NOT: .eabi_attribute 22
; SC300-FAST: .eabi_attribute 23, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-M4-SOFT: .cpu cortex-m4
; CORTEX-M4-SOFT: .eabi_attribute 6, 13
; CORTEX-M4-SOFT: .eabi_attribute 7, 77
; CORTEX-M4-SOFT: .eabi_attribute 8, 0
; CORTEX-M4-SOFT: .eabi_attribute 9, 2
[ARM] Add support for -sp- FPUs and FPU none to TargetParser These are added mainly for the benefit of clang, but this also means that they are now allowed in .fpu directives and we emit the correct .fpu directive when single-precision-only is used. Differential Revision: http://reviews.llvm.org/D10238 llvm-svn: 239151
2015-06-05 21:31:19 +08:00
; CORTEX-M4-SOFT: .fpu fpv4-sp-d16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M4-SOFT: .eabi_attribute 27, 1
; CORTEX-M4-SOFT: .eabi_attribute 36, 1
; CORTEX-M4-SOFT-NOT: .eabi_attribute 42
; CORTEX-M4-SOFT-NOT: .eabi_attribute 44
; CORTEX-M4-SOFT-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M4-SOFT-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-M4-SOFT: .eabi_attribute 20, 1
; CORTEX-M4-SOFT: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M4-SOFT-NOT: .eabi_attribute 22
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-M4-SOFT: .eabi_attribute 23, 3
; CORTEX-M4-SOFT: .eabi_attribute 24, 1
; CORTEX-M4-SOFT: .eabi_attribute 25, 1
; CORTEX-M4-SOFT-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-M4-SOFT: .eabi_attribute 38, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M4-SOFT-FAST-NOT: .eabi_attribute 19
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
;; The M4 defaults to a VFPv4 FPU, so it flushes preserving the sign when
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; -ffast-math is specified.
; CORTEX-M4-SOFT-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M4-SOFT-FAST-NOT: .eabi_attribute 21
; CORTEX-M4-SOFT-FAST-NOT: .eabi_attribute 22
; CORTEX-M4-SOFT-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-M4-HARD: .cpu cortex-m4
; CORTEX-M4-HARD: .eabi_attribute 6, 13
; CORTEX-M4-HARD: .eabi_attribute 7, 77
; CORTEX-M4-HARD: .eabi_attribute 8, 0
; CORTEX-M4-HARD: .eabi_attribute 9, 2
[ARM] Add support for -sp- FPUs and FPU none to TargetParser These are added mainly for the benefit of clang, but this also means that they are now allowed in .fpu directives and we emit the correct .fpu directive when single-precision-only is used. Differential Revision: http://reviews.llvm.org/D10238 llvm-svn: 239151
2015-06-05 21:31:19 +08:00
; CORTEX-M4-HARD: .fpu fpv4-sp-d16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M4-HARD: .eabi_attribute 27, 1
; CORTEX-M4-HARD: .eabi_attribute 36, 1
; CORTEX-M4-HARD-NOT: .eabi_attribute 42
; CORTEX-M4-HARD-NOT: .eabi_attribute 44
; CORTEX-M4-HARD-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M4-HARD-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-M4-HARD: .eabi_attribute 20, 1
; CORTEX-M4-HARD: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M4-HARD-NOT: .eabi_attribute 22
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-M4-HARD: .eabi_attribute 23, 3
; CORTEX-M4-HARD: .eabi_attribute 24, 1
; CORTEX-M4-HARD: .eabi_attribute 25, 1
; CORTEX-M4-HARD: .eabi_attribute 28, 1
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-M4-HARD: .eabi_attribute 38, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M4-HARD-FAST-NOT: .eabi_attribute 19
Add missing build attribute regression tests for Cortex-A8 Differential Revision: http://reviews.llvm.org/D16576 llvm-svn: 258923
2016-01-27 19:34:51 +08:00
;; The M4 defaults to a VFPv4 FPU, so it flushes preserving the sign when
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; -ffast-math is specified.
; CORTEX-M4-HARD-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M4-HARD-FAST-NOT: .eabi_attribute 21
; CORTEX-M4-HARD-FAST-NOT: .eabi_attribute 22
; CORTEX-M4-HARD-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP (LLVM) The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modelled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218747
2014-10-01 17:02:17 +08:00
; CORTEX-M7: .cpu cortex-m7
; CORTEX-M7: .eabi_attribute 6, 13
; CORTEX-M7: .eabi_attribute 7, 77
; CORTEX-M7: .eabi_attribute 8, 0
; CORTEX-M7: .eabi_attribute 9, 2
; CORTEX-M7-SOFT-NOT: .fpu
[ARM] Add support for -sp- FPUs and FPU none to TargetParser These are added mainly for the benefit of clang, but this also means that they are now allowed in .fpu directives and we emit the correct .fpu directive when single-precision-only is used. Differential Revision: http://reviews.llvm.org/D10238 llvm-svn: 239151
2015-06-05 21:31:19 +08:00
; CORTEX-M7-SINGLE: .fpu fpv5-sp-d16
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP (LLVM) The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modelled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218747
2014-10-01 17:02:17 +08:00
; CORTEX-M7-DOUBLE: .fpu fpv5-d16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M7-SOFT-NOT: .eabi_attribute 27
; CORTEX-M7-SINGLE: .eabi_attribute 27, 1
; CORTEX-M7-DOUBLE-NOT: .eabi_attribute 27
; CORTEX-M7: .eabi_attribute 36, 1
; CORTEX-M7-NOT: .eabi_attribute 44
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP (LLVM) The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modelled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218747
2014-10-01 17:02:17 +08:00
; CORTEX-M7: .eabi_attribute 17, 1
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M7-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP (LLVM) The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modelled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218747
2014-10-01 17:02:17 +08:00
; CORTEX-M7: .eabi_attribute 20, 1
; CORTEX-M7: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M7-NOT: .eabi_attribute 22
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP (LLVM) The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modelled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218747
2014-10-01 17:02:17 +08:00
; CORTEX-M7: .eabi_attribute 23, 3
; CORTEX-M7: .eabi_attribute 24, 1
; CORTEX-M7: .eabi_attribute 25, 1
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-M7: .eabi_attribute 38, 1
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP (LLVM) The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modelled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218747
2014-10-01 17:02:17 +08:00
; CORTEX-M7: .eabi_attribute 14, 0
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-M7-NOFPU-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The M7 has the ARMv8 FP unit, which always flushes preserving sign.
; CORTEX-M7-FAST: .eabi_attribute 20, 2
;; Despite there being no FPU, we chose to flush to zero preserving
;; sign. This matches what the hardware would do for this architecture
;; revision.
; CORTEX-M7-NOFPU-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-M7-NOFPU-FAST-NOT: .eabi_attribute 21
; CORTEX-M7-NOFPU-FAST-NOT: .eabi_attribute 22
; CORTEX-M7-NOFPU-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] support for Cortex-R4/R4F Currently, llvm (backend) doesn't know cortex-r4, even though it is the default target for armv7r. Using "--target=armv7r-arm-none-eabi" provokes 'cortex-r4' is not a recognized processor for this target' by llvm. This patch adds support for cortex-r4 and, very closely related, r4f. llvm-svn: 234486
2015-04-09 22:07:28 +08:00
; CORTEX-R4: .cpu cortex-r4
; CORTEX-R4: .eabi_attribute 6, 10
; CORTEX-R4: .eabi_attribute 7, 82
; CORTEX-R4: .eabi_attribute 8, 1
; CORTEX-R4: .eabi_attribute 9, 2
; CORTEX-R4-NOT: .fpu vfpv3-d16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-R4-NOT: .eabi_attribute 36
; CORTEX-R4-NOT: .eabi_attribute 42
; CORTEX-R4-NOT: .eabi_attribute 44
; CORTEX-R4-NOT: .eabi_attribute 68
[ARM] support for Cortex-R4/R4F Currently, llvm (backend) doesn't know cortex-r4, even though it is the default target for armv7r. Using "--target=armv7r-arm-none-eabi" provokes 'cortex-r4' is not a recognized processor for this target' by llvm. This patch adds support for cortex-r4 and, very closely related, r4f. llvm-svn: 234486
2015-04-09 22:07:28 +08:00
; CORTEX-R4-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-R4: .eabi_attribute 20, 1
; CORTEX-R4: .eabi_attribute 21, 1
; CORTEX-R4-NOT: .eabi_attribute 22
; CORTEX-R4: .eabi_attribute 23, 3
; CORTEX-R4: .eabi_attribute 24, 1
; CORTEX-R4: .eabi_attribute 25, 1
; CORTEX-R4-NOT: .eabi_attribute 28
; CORTEX-R4: .eabi_attribute 38, 1
; CORTEX-R4F: .cpu cortex-r4f
; CORTEX-R4F: .eabi_attribute 6, 10
; CORTEX-R4F: .eabi_attribute 7, 82
; CORTEX-R4F: .eabi_attribute 8, 1
; CORTEX-R4F: .eabi_attribute 9, 2
; CORTEX-R4F: .fpu vfpv3-d16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-R4F-NOT: .eabi_attribute 27, 1
; CORTEX-R4F-NOT: .eabi_attribute 36
; CORTEX-R4F-NOT: .eabi_attribute 42
; CORTEX-R4F-NOT: .eabi_attribute 44
; CORTEX-R4F-NOT: .eabi_attribute 68
[ARM] support for Cortex-R4/R4F Currently, llvm (backend) doesn't know cortex-r4, even though it is the default target for armv7r. Using "--target=armv7r-arm-none-eabi" provokes 'cortex-r4' is not a recognized processor for this target' by llvm. This patch adds support for cortex-r4 and, very closely related, r4f. llvm-svn: 234486
2015-04-09 22:07:28 +08:00
; CORTEX-R4F-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-R4F: .eabi_attribute 20, 1
; CORTEX-R4F: .eabi_attribute 21, 1
; CORTEX-R4F-NOT: .eabi_attribute 22
; CORTEX-R4F: .eabi_attribute 23, 3
; CORTEX-R4F: .eabi_attribute 24, 1
; CORTEX-R4F: .eabi_attribute 25, 1
; CORTEX-R4F-NOT: .eabi_attribute 28
; CORTEX-R4F: .eabi_attribute 38, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-R5: .cpu cortex-r5
; CORTEX-R5: .eabi_attribute 6, 10
; CORTEX-R5: .eabi_attribute 7, 82
[ARM] Add Virtualization subtarget feature and more build attributes in this area Add a Virtualization ARM subtarget feature along with adding proper build attribute emission for Tag_Virtualization_use (encodes Virtualization and TrustZone) and Tag_MPextension_use. Also rework test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll testcase to something that is more maintainable. This changes the focus of this testcase away from testing CPU defaults (which is tested elsewhere), onto specifically testing that attributes are encoded correctly. llvm-svn: 193859
2013-11-01 21:27:35 +08:00
; CORTEX-R5: .eabi_attribute 8, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-R5: .eabi_attribute 9, 2
[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
; CORTEX-R5: .fpu vfpv3-d16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-R5-NOT: .eabi_attribute 27, 1
; CORTEX-R5-NOT: .eabi_attribute 36
; CORTEX-R5: .eabi_attribute 44, 2
; CORTEX-R5-NOT: .eabi_attribute 42
; CORTEX-R5-NOT: .eabi_attribute 68
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-R5-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-R5: .eabi_attribute 20, 1
; CORTEX-R5: .eabi_attribute 21, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-R5-NOT: .eabi_attribute 22
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-R5: .eabi_attribute 23, 3
; CORTEX-R5: .eabi_attribute 24, 1
; CORTEX-R5: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-R5-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-R5: .eabi_attribute 38, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-R5-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The R5 has the VFPv3 FP unit, which always flushes preserving sign.
; CORTEX-R5-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-R5-FAST-NOT: .eabi_attribute 21
; CORTEX-R5-FAST-NOT: .eabi_attribute 22
; CORTEX-R5-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; CORTEX-R7: .cpu cortex-r7
; CORTEX-R7: .eabi_attribute 6, 10
; CORTEX-R7: .eabi_attribute 7, 82
; CORTEX-R7: .eabi_attribute 8, 1
; CORTEX-R7: .eabi_attribute 9, 2
Removed FeatureVFPOnlySP from the Cortex-R7 processor model description and changed the regression test accordingly. The default configuration of a Cortex-R7 is to implement the VFPv3-D16 architecture and the feature line as it was is too restrictive. llvm-svn: 259480
2016-02-02 17:28:20 +08:00
; CORTEX-R7: .fpu vfpv3-d16-fp16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-R7: .eabi_attribute 36, 1
; CORTEX-R7: .eabi_attribute 42, 1
; CORTEX-R7: .eabi_attribute 44, 2
; CORTEX-R7-NOT: .eabi_attribute 68
[ARM] Add missing M/R class CPUs Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229660
2015-02-18 18:33:30 +08:00
; CORTEX-R7-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-R7: .eabi_attribute 20, 1
; CORTEX-R7: .eabi_attribute 21, 1
; CORTEX-R7-NOT: .eabi_attribute 22
; CORTEX-R7: .eabi_attribute 23, 3
; CORTEX-R7: .eabi_attribute 24, 1
; CORTEX-R7: .eabi_attribute 25, 1
; CORTEX-R7-NOT: .eabi_attribute 28
; CORTEX-R7: .eabi_attribute 38, 1
; CORTEX-R7-FAST-NOT: .eabi_attribute 19
;; The R7 has the VFPv3 FP unit, which always flushes preserving sign.
; CORTEX-R7-FAST: .eabi_attribute 20, 2
; CORTEX-R7-FAST-NOT: .eabi_attribute 21
; CORTEX-R7-FAST-NOT: .eabi_attribute 22
; CORTEX-R7-FAST: .eabi_attribute 23, 1
[ARM] Cortex-R8 support This patch adds Cortex-R8 to Target Parser and TableGen. It also adds CodeGen tests for the build attributes. Patch by Pablo Barrio. Differential Revision: http://reviews.llvm.org/D17925 llvm-svn: 263132
2016-03-11 01:38:41 +08:00
; CORTEX-R8: .cpu cortex-r8
; CORTEX-R8: .eabi_attribute 6, 10
; CORTEX-R8: .eabi_attribute 7, 82
; CORTEX-R8: .eabi_attribute 8, 1
; CORTEX-R8: .eabi_attribute 9, 2
; CORTEX-R8: .fpu vfpv3-d16-fp16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-R8: .eabi_attribute 36, 1
; CORTEX-R8: .eabi_attribute 42, 1
; CORTEX-R8: .eabi_attribute 44, 2
; CORTEX-R8-NOT: .eabi_attribute 68
[ARM] Cortex-R8 support This patch adds Cortex-R8 to Target Parser and TableGen. It also adds CodeGen tests for the build attributes. Patch by Pablo Barrio. Differential Revision: http://reviews.llvm.org/D17925 llvm-svn: 263132
2016-03-11 01:38:41 +08:00
; CORTEX-R8-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-R8: .eabi_attribute 20, 1
; CORTEX-R8: .eabi_attribute 21, 1
; CORTEX-R8-NOT: .eabi_attribute 22
; CORTEX-R8: .eabi_attribute 23, 3
; CORTEX-R8: .eabi_attribute 24, 1
; CORTEX-R8: .eabi_attribute 25, 1
; CORTEX-R8-NOT: .eabi_attribute 28
; CORTEX-R8: .eabi_attribute 38, 1
; CORTEX-R8-FAST-NOT: .eabi_attribute 19
;; The R8 has the VFPv3 FP unit, which always flushes preserving sign.
; CORTEX-R8-FAST: .eabi_attribute 20, 2
; CORTEX-R8-FAST-NOT: .eabi_attribute 21
; CORTEX-R8-FAST-NOT: .eabi_attribute 22
; CORTEX-R8-FAST: .eabi_attribute 23, 1
[ARM] Add Cortex-A32 support Adding Cortex-A32 as an available target in the ARM backend. Patch by Sam Parker. llvm-svn: 263956
2016-03-22 01:29:01 +08:00
; CORTEX-A32: .cpu cortex-a32
; CORTEX-A32: .eabi_attribute 6, 14
; CORTEX-A32: .eabi_attribute 7, 65
; CORTEX-A32: .eabi_attribute 8, 1
; CORTEX-A32: .eabi_attribute 9, 2
; CORTEX-A32: .fpu crypto-neon-fp-armv8
; CORTEX-A32: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A32-NOT: .eabi_attribute 27
; CORTEX-A32: .eabi_attribute 36, 1
; CORTEX-A32: .eabi_attribute 42, 1
; CORTEX-A32-NOT: .eabi_attribute 44
; CORTEX-A32: .eabi_attribute 68, 3
[ARM] Add Cortex-A32 support Adding Cortex-A32 as an available target in the ARM backend. Patch by Sam Parker. llvm-svn: 263956
2016-03-22 01:29:01 +08:00
; CORTEX-A32-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-A32: .eabi_attribute 20, 1
; CORTEX-A32: .eabi_attribute 21, 1
; CORTEX-A32-NOT: .eabi_attribute 22
; CORTEX-A32: .eabi_attribute 23, 3
; CORTEX-A32: .eabi_attribute 24, 1
; CORTEX-A32: .eabi_attribute 25, 1
; CORTEX-A32-NOT: .eabi_attribute 28
; CORTEX-A32: .eabi_attribute 38, 1
; CORTEX-A32-FAST-NOT: .eabi_attribute 19
;; The A32 has the ARMv8 FP unit, which always flushes preserving sign.
; CORTEX-A32-FAST: .eabi_attribute 20, 2
; CORTEX-A32-FAST-NOT: .eabi_attribute 21
; CORTEX-A32-FAST-NOT: .eabi_attribute 22
; CORTEX-A32-FAST: .eabi_attribute 23, 1
[ARM] Enable Cortex-M23 and Cortex-M33 support. Add both cores to the target parser and TableGen. Test that eabi attributes are set correctly for both cores. Additionally, test the absence and presence of MOVT in Cortex-M23 and Cortex-M33, respectively. Committed on behalf of Sanne Wouda. Reviewers : rengolin, olista01. Differential Revision: https://reviews.llvm.org/D29073 llvm-svn: 293761
2017-02-01 19:55:03 +08:00
; CORTEX-M23: .cpu cortex-m23
; CORTEX-M23: .eabi_attribute 6, 16
; CORTEX-M23: .eabi_attribute 7, 77
; CORTEX-M23: .eabi_attribute 8, 0
; CORTEX-M23: .eabi_attribute 9, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M23-NOT: .eabi_attribute 27
Recommit of r335326, with the test fixed that I missed. llvm-svn: 335331
2018-06-22 18:03:03 +08:00
; CORTEX-M23: .eabi_attribute 34, 0
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M23-NOT: .eabi_attribute 44
[ARM] Enable Cortex-M23 and Cortex-M33 support. Add both cores to the target parser and TableGen. Test that eabi attributes are set correctly for both cores. Additionally, test the absence and presence of MOVT in Cortex-M23 and Cortex-M33, respectively. Committed on behalf of Sanne Wouda. Reviewers : rengolin, olista01. Differential Revision: https://reviews.llvm.org/D29073 llvm-svn: 293761
2017-02-01 19:55:03 +08:00
; CORTEX-M23: .eabi_attribute 17, 1
;; We default to IEEE 754 compliance
; CORTEX-M23-NOT: .eabi_attribute 19
; CORTEX-M23: .eabi_attribute 20, 1
; CORTEX-M23: .eabi_attribute 21, 1
; CORTEX-M23: .eabi_attribute 23, 3
; CORTEX-M23: .eabi_attribute 24, 1
; CORTEX-M23-NOT: .eabi_attribute 28
; CORTEX-M23: .eabi_attribute 25, 1
; CORTEX-M23: .eabi_attribute 38, 1
; CORTEX-M23: .eabi_attribute 14, 0
; CORTEX-M33: .cpu cortex-m33
; CORTEX-M33: .eabi_attribute 6, 17
; CORTEX-M33: .eabi_attribute 7, 77
; CORTEX-M33: .eabi_attribute 8, 0
; CORTEX-M33: .eabi_attribute 9, 3
; CORTEX-M33: .fpu fpv5-sp-d16
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-M33: .eabi_attribute 27, 1
; CORTEX-M33: .eabi_attribute 36, 1
; CORTEX-M33-NOT: .eabi_attribute 44
; CORTEX-M33: .eabi_attribute 46, 1
; CORTEX-M33: .eabi_attribute 34, 1
[ARM] Enable Cortex-M23 and Cortex-M33 support. Add both cores to the target parser and TableGen. Test that eabi attributes are set correctly for both cores. Additionally, test the absence and presence of MOVT in Cortex-M23 and Cortex-M33, respectively. Committed on behalf of Sanne Wouda. Reviewers : rengolin, olista01. Differential Revision: https://reviews.llvm.org/D29073 llvm-svn: 293761
2017-02-01 19:55:03 +08:00
; CORTEX-M33: .eabi_attribute 17, 1
;; We default to IEEE 754 compliance
; CORTEX-M23-NOT: .eabi_attribute 19
; CORTEX-M33: .eabi_attribute 20, 1
; CORTEX-M33: .eabi_attribute 21, 1
; CORTEX-M33: .eabi_attribute 23, 3
; CORTEX-M33: .eabi_attribute 24, 1
; CORTEX-M33: .eabi_attribute 25, 1
; CORTEX-M33-NOT: .eabi_attribute 28
; CORTEX-M33: .eabi_attribute 38, 1
; CORTEX-M33: .eabi_attribute 14, 0
; CORTEX-M33-FAST-NOT: .eabi_attribute 19
; CORTEX-M33-FAST: .eabi_attribute 20, 2
; CORTEX-M33-FAST-NOT: .eabi_attribute 21
; CORTEX-M33-FAST-NOT: .eabi_attribute 22
; CORTEX-M33-FAST: .eabi_attribute 23, 1
[AArch64]: Add support for Cortex-A35 Adds support for the new Cortex-A35 ARMv8-A core. llvm-svn: 254503
2015-12-02 19:53:44 +08:00
; CORTEX-A35: .cpu cortex-a35
; CORTEX-A35: .eabi_attribute 6, 14
; CORTEX-A35: .eabi_attribute 7, 65
; CORTEX-A35: .eabi_attribute 8, 1
; CORTEX-A35: .eabi_attribute 9, 2
; CORTEX-A35: .fpu crypto-neon-fp-armv8
; CORTEX-A35: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A35-NOT: .eabi_attribute 27
; CORTEX-A35: .eabi_attribute 36, 1
; CORTEX-A35: .eabi_attribute 42, 1
; CORTEX-A35-NOT: .eabi_attribute 44
; CORTEX-A35: .eabi_attribute 68, 3
[AArch64]: Add support for Cortex-A35 Adds support for the new Cortex-A35 ARMv8-A core. llvm-svn: 254503
2015-12-02 19:53:44 +08:00
; CORTEX-A35-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-A35: .eabi_attribute 20, 1
; CORTEX-A35: .eabi_attribute 21, 1
; CORTEX-A35-NOT: .eabi_attribute 22
; CORTEX-A35: .eabi_attribute 23, 3
; CORTEX-A35: .eabi_attribute 24, 1
; CORTEX-A35: .eabi_attribute 25, 1
; CORTEX-A35-NOT: .eabi_attribute 28
; CORTEX-A35: .eabi_attribute 38, 1
; CORTEX-A35-FAST-NOT: .eabi_attribute 19
;; The A35 has the ARMv8 FP unit, which always flushes preserving sign.
; CORTEX-A35-FAST: .eabi_attribute 20, 2
; CORTEX-A35-FAST-NOT: .eabi_attribute 21
; CORTEX-A35-FAST-NOT: .eabi_attribute 22
; CORTEX-A35-FAST: .eabi_attribute 23, 1
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-A53: .cpu cortex-a53
; CORTEX-A53: .eabi_attribute 6, 14
; CORTEX-A53: .eabi_attribute 7, 65
; CORTEX-A53: .eabi_attribute 8, 1
; CORTEX-A53: .eabi_attribute 9, 2
Add subtarget feature support for Cortex-A53 Some previous implicit defaults have changed, for example FP and NEON are now on by default. llvm-svn: 192590
2013-10-14 21:16:57 +08:00
; CORTEX-A53: .fpu crypto-neon-fp-armv8
; CORTEX-A53: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A53-NOT: .eabi_attribute 27
; CORTEX-A53: .eabi_attribute 36, 1
; CORTEX-A53: .eabi_attribute 42, 1
; CORTEX-A53-NOT: .eabi_attribute 44
; CORTEX-A53: .eabi_attribute 68, 3
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A53-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
; CORTEX-A53: .eabi_attribute 20, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A53: .eabi_attribute 21, 1
; CORTEX-A53-NOT: .eabi_attribute 22
; CORTEX-A53: .eabi_attribute 23, 3
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
; CORTEX-A53: .eabi_attribute 24, 1
; CORTEX-A53: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A53-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-A53: .eabi_attribute 38, 1
[ARMv8] Emit the proper .fpu directive. Patch by Bradley Smith! llvm-svn: 190683
2013-09-13 19:51:52 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A53-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The A53 has the ARMv8 FP unit, which always flushes preserving sign.
; CORTEX-A53-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A53-FAST-NOT: .eabi_attribute 21
; CORTEX-A53-FAST-NOT: .eabi_attribute 22
; CORTEX-A53-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Add Cortex-A57 support llvm-svn: 192591
2013-10-14 21:17:07 +08:00
; CORTEX-A57: .cpu cortex-a57
; CORTEX-A57: .eabi_attribute 6, 14
; CORTEX-A57: .eabi_attribute 7, 65
; CORTEX-A57: .eabi_attribute 8, 1
; CORTEX-A57: .eabi_attribute 9, 2
; CORTEX-A57: .fpu crypto-neon-fp-armv8
; CORTEX-A57: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A57-NOT: .eabi_attribute 27
; CORTEX-A57: .eabi_attribute 36, 1
; CORTEX-A57: .eabi_attribute 42, 1
; CORTEX-A57-NOT: .eabi_attribute 44
; CORTEX-A57: .eabi_attribute 68, 3
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A57-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; We default to IEEE 754 compliance
; CORTEX-A57: .eabi_attribute 20, 1
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A57: .eabi_attribute 21, 1
; CORTEX-A57-NOT: .eabi_attribute 22
; CORTEX-A57: .eabi_attribute 23, 3
Add Cortex-A57 support llvm-svn: 192591
2013-10-14 21:17:07 +08:00
; CORTEX-A57: .eabi_attribute 24, 1
; CORTEX-A57: .eabi_attribute 25, 1
[ARM] Fix Tag_ABI_HardFP_use build attribute Fix Tag_ABI_HardFP_use build attribute to handle single precision FP, replace deprecated Tag_ABI_HardFP_use value of 3 with 0 and also add some tests for Tag_ABI_VFP_args. llvm-svn: 193856
2013-11-01 19:21:16 +08:00
; CORTEX-A57-NOT: .eabi_attribute 28
Emit Tag_ABI_FP_16bit_format build attribute. The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet supported, there is not a user switch to change this behaviour. This build attribute should capture the default behaviour of the compiler, which is to expose the IEEE 754 version of __fp16. When -mfp16-format is emitted, that will be the way to control the value of this build attribute. Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0 llvm-svn: 224115
2014-12-12 19:59:18 +08:00
; CORTEX-A57: .eabi_attribute 38, 1
Add Cortex-A57 support llvm-svn: 192591
2013-10-14 21:17:07 +08:00
Add tests for default value of Tag_ABI_FP_rounding. Change-Id: I051866d073fc6ce87ce3e693a3762da6d81f4393 llvm-svn: 223217
2014-12-03 15:59:50 +08:00
; CORTEX-A57-FAST-NOT: .eabi_attribute 19
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
;; The A57 has the ARMv8 FP unit, which always flushes preserving sign.
; CORTEX-A57-FAST: .eabi_attribute 20, 2
Add missing FP build attribute tests. The test file test/CodeGen/ARM/build-attributes.ll was missing several floating-point build attribute tests. The intention of this commit is that for each CPU / architecture currently tested, there are now tests that make sure the following attributes are sufficiently checked, * Tag_ABI_FP_rounding * Tag_ABI_FP_denormal * Tag_ABI_FP_exceptions * Tag_ABI_FP_user_exceptions * Tag_ABI_FP_number_model Also in this commit, the -unsafe-fp-math flag has been augmented with the full suite of flags Clang sends to LLVM when you pass -ffast-math to Clang. That is, `-unsafe-fp-math' has been changed to `-enable-unsafe-fp-math -disable-fp-elim -enable-no-infs-fp-math -enable-no-nans-fp-math -fp-contract=fast' Change-Id: I35d766076bcbbf09021021c0a534bf8bf9a32dfc llvm-svn: 223454
2014-12-05 16:22:47 +08:00
; CORTEX-A57-FAST-NOT: .eabi_attribute 21
; CORTEX-A57-FAST-NOT: .eabi_attribute 22
; CORTEX-A57-FAST: .eabi_attribute 23, 1
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
Adding support to LLVM for targeting Cortex-A72 Currently, Cortex-A72 is modelled as an Cortex-A57 except the fp load balancing pass isn't enabled for Cortex-A72 as it's not profitable to have it enabled for this core. Patch by Ranjeet Singh. llvm-svn: 228140
2015-02-04 21:31:29 +08:00
; CORTEX-A72: .cpu cortex-a72
; CORTEX-A72: .eabi_attribute 6, 14
; CORTEX-A72: .eabi_attribute 7, 65
; CORTEX-A72: .eabi_attribute 8, 1
; CORTEX-A72: .eabi_attribute 9, 2
; CORTEX-A72: .fpu crypto-neon-fp-armv8
; CORTEX-A72: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A72-NOT: .eabi_attribute 27
; CORTEX-A72: .eabi_attribute 36, 1
; CORTEX-A72: .eabi_attribute 42, 1
; CORTEX-A72-NOT: .eabi_attribute 44
; CORTEX-A72: .eabi_attribute 68, 3
Adding support to LLVM for targeting Cortex-A72 Currently, Cortex-A72 is modelled as an Cortex-A57 except the fp load balancing pass isn't enabled for Cortex-A72 as it's not profitable to have it enabled for this core. Patch by Ranjeet Singh. llvm-svn: 228140
2015-02-04 21:31:29 +08:00
; CORTEX-A72-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-A72: .eabi_attribute 20, 1
; CORTEX-A72: .eabi_attribute 21, 1
; CORTEX-A72-NOT: .eabi_attribute 22
; CORTEX-A72: .eabi_attribute 23, 3
; CORTEX-A72: .eabi_attribute 24, 1
; CORTEX-A72: .eabi_attribute 25, 1
; CORTEX-A72-NOT: .eabi_attribute 28
; CORTEX-A72: .eabi_attribute 38, 1
; CORTEX-A72-FAST-NOT: .eabi_attribute 19
;; The A72 has the ARMv8 FP unit, which always flushes preserving sign.
; CORTEX-A72-FAST: .eabi_attribute 20, 2
; CORTEX-A72-FAST-NOT: .eabi_attribute 21
; CORTEX-A72-FAST-NOT: .eabi_attribute 22
; CORTEX-A72-FAST: .eabi_attribute 23, 1
This adds support for Cortex-A73 as an available target. Differential Revision: http://reviews.llvm.org/D20865 llvm-svn: 271508
2016-06-02 18:48:52 +08:00
; CORTEX-A73: .cpu cortex-a73
; CORTEX-A73: .eabi_attribute 6, 14
; CORTEX-A73: .eabi_attribute 7, 65
; CORTEX-A73: .eabi_attribute 8, 1
; CORTEX-A73: .eabi_attribute 9, 2
; CORTEX-A73: .fpu crypto-neon-fp-armv8
; CORTEX-A73: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; CORTEX-A73-NOT: .eabi_attribute 27
; CORTEX-A73: .eabi_attribute 36, 1
; CORTEX-A73: .eabi_attribute 42, 1
; CORTEX-A73-NOT: .eabi_attribute 44
; CORTEX-A73: .eabi_attribute 68, 3
This adds support for Cortex-A73 as an available target. Differential Revision: http://reviews.llvm.org/D20865 llvm-svn: 271508
2016-06-02 18:48:52 +08:00
; CORTEX-A73-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; CORTEX-A73: .eabi_attribute 20, 1
; CORTEX-A73: .eabi_attribute 21, 1
; CORTEX-A73-NOT: .eabi_attribute 22
; CORTEX-A73: .eabi_attribute 23, 3
; CORTEX-A73: .eabi_attribute 24, 1
; CORTEX-A73: .eabi_attribute 25, 1
; CORTEX-A73-NOT: .eabi_attribute 28
; CORTEX-A73: .eabi_attribute 38, 1
; CORTEX-A73: .eabi_attribute 14, 0
[AArch64] Add support for Samsung Exynos-M1 Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A). Differential Revision: http://reviews.llvm.org/D15663 llvm-svn: 256828
2016-01-05 20:51:59 +08:00
; EXYNOS-M1: .cpu exynos-m1
; EXYNOS-M1: .eabi_attribute 6, 14
; EXYNOS-M1: .eabi_attribute 7, 65
; EXYNOS-M1: .eabi_attribute 8, 1
; EXYNOS-M1: .eabi_attribute 9, 2
; EXYNOS-M1: .fpu crypto-neon-fp-armv8
; EXYNOS-M1: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; EXYNOS-M1-NOT: .eabi_attribute 27
; EXYNOS-M1: .eabi_attribute 36, 1
; EXYNOS-M1: .eabi_attribute 42, 1
; EXYNOS-M1-NOT: .eabi_attribute 44
; EXYNOS-M1: .eabi_attribute 68, 3
[AArch64] Add support for Samsung Exynos-M1 Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A). Differential Revision: http://reviews.llvm.org/D15663 llvm-svn: 256828
2016-01-05 20:51:59 +08:00
; EXYNOS-M1-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; EXYNOS-M1: .eabi_attribute 20, 1
; EXYNOS-M1: .eabi_attribute 21, 1
; EXYNOS-M1-NOT: .eabi_attribute 22
; EXYNOS-M1: .eabi_attribute 23, 3
; EXYNOS-M1: .eabi_attribute 24, 1
; EXYNOS-M1: .eabi_attribute 25, 1
; EXYNOS-M1-NOT: .eabi_attribute 28
; EXYNOS-M1: .eabi_attribute 38, 1
; EXYNOS-M1-FAST-NOT: .eabi_attribute 19
;; The exynos-m1 has the ARMv8 FP unit, which always flushes preserving sign.
; EXYNOS-M1-FAST: .eabi_attribute 20, 2
; EXYNOS-M1-FAST-NOT: .eabi_attribute 21
; EXYNOS-M1-FAST-NOT: .eabi_attribute 22
; EXYNOS-M1-FAST: .eabi_attribute 23, 1
[AArch64] Add support for Samsung Exynos M2 (NFC). llvm-svn: 277364
2016-08-02 02:39:45 +08:00
; EXYNOS-M2: .cpu exynos-m2
; EXYNOS-M2: .eabi_attribute 6, 14
; EXYNOS-M2: .eabi_attribute 7, 65
; EXYNOS-M2: .eabi_attribute 8, 1
; EXYNOS-M2: .eabi_attribute 9, 2
; EXYNOS-M2: .fpu crypto-neon-fp-armv8
; EXYNOS-M2: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; EXYNOS-M2-NOT: .eabi_attribute 27
; EXYNOS-M2: .eabi_attribute 36, 1
; EXYNOS-M2: .eabi_attribute 42, 1
; EXYNOS-M2-NOT: .eabi_attribute 44
; EXYNOS-M2: .eabi_attribute 68, 3
[AArch64] Add support for Samsung Exynos M2 (NFC). llvm-svn: 277364
2016-08-02 02:39:45 +08:00
; EXYNOS-M2-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; EXYNOS-M2: .eabi_attribute 20, 1
; EXYNOS-M2: .eabi_attribute 21, 1
; EXYNOS-M2-NOT: .eabi_attribute 22
; EXYNOS-M2: .eabi_attribute 23, 3
; EXYNOS-M2: .eabi_attribute 24, 1
; EXYNOS-M2: .eabi_attribute 25, 1
; EXYNOS-M2-NOT: .eabi_attribute 28
; EXYNOS-M2: .eabi_attribute 38, 1
[ARM] Fix typo in checking prefix llvm-svn: 289617
2016-12-14 08:02:03 +08:00
; EXYNOS-M3: .cpu exynos-m3
Add support for Samsung Exynos M3 (NFC) llvm-svn: 289613
2016-12-14 07:31:41 +08:00
; EXYNOS-M3: .eabi_attribute 6, 14
; EXYNOS-M3: .eabi_attribute 7, 65
; EXYNOS-M3: .eabi_attribute 8, 1
; EXYNOS-M3: .eabi_attribute 9, 2
; EXYNOS-M3: .fpu crypto-neon-fp-armv8
; EXYNOS-M3: .eabi_attribute 12, 3
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; EXYNOS-M3-NOT: .eabi_attribute 27
; EXYNOS-M3: .eabi_attribute 36, 1
; EXYNOS-M3: .eabi_attribute 42, 1
; EXYNOS-M3-NOT: .eabi_attribute 44
; EXYNOS-M3: .eabi_attribute 68, 3
Add support for Samsung Exynos M3 (NFC) llvm-svn: 289613
2016-12-14 07:31:41 +08:00
; EXYNOS-M3-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; EXYNOS-M3: .eabi_attribute 20, 1
; EXYNOS-M3: .eabi_attribute 21, 1
; EXYNOS-M3-NOT: .eabi_attribute 22
; EXYNOS-M3: .eabi_attribute 23, 3
; EXYNOS-M3: .eabi_attribute 24, 1
; EXYNOS-M3: .eabi_attribute 25, 1
; EXYNOS-M3-NOT: .eabi_attribute 28
; EXYNOS-M3: .eabi_attribute 38, 1
[AArch64, ARM] Add support for Samsung Exynos M4 Create a separate feature set for Exynos M4 and add test cases. llvm-svn: 334115
2018-06-07 02:56:00 +08:00
; EXYNOS-M4: .cpu exynos-m4
; EXYNOS-M4: .eabi_attribute 6, 14
; EXYNOS-M4: .eabi_attribute 7, 65
; EXYNOS-M4: .eabi_attribute 8, 1
; EXYNOS-M4: .eabi_attribute 9, 2
; EXYNOS-M4: .fpu crypto-neon-fp-armv8
; EXYNOS-M4: .eabi_attribute 12, 3
; EXYNOS-M4-NOT: .eabi_attribute 27
; EXYNOS-M4: .eabi_attribute 36, 1
; EXYNOS-M4: .eabi_attribute 42, 1
; EXYNOS-M4-NOT: .eabi_attribute 44
; EXYNOS-M4: .eabi_attribute 68, 3
; EXYNOS-M4-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; EXYNOS-M4: .eabi_attribute 20, 1
; EXYNOS-M4: .eabi_attribute 21, 1
; EXYNOS-M4-NOT: .eabi_attribute 22
; EXYNOS-M4: .eabi_attribute 23, 3
; EXYNOS-M4: .eabi_attribute 24, 1
; EXYNOS-M4: .eabi_attribute 25, 1
; EXYNOS-M4-NOT: .eabi_attribute 28
; EXYNOS-M4: .eabi_attribute 38, 1
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10645 llvm-svn: 240930
2015-06-29 17:32:29 +08:00
; GENERIC-FPU-VFPV3-FP16: .fpu vfpv3-fp16
; GENERIC-FPU-VFPV3-D16-FP16: .fpu vfpv3-d16-fp16
; GENERIC-FPU-VFPV3XD: .fpu vfpv3xd
; GENERIC-FPU-VFPV3XD-FP16: .fpu vfpv3xd-fp16
; GENERIC-FPU-NEON-FP16: .fpu neon-fp16
[AArch64, ARM] Add v8.1a architecture and generic cpu New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: t.p.northover Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8505 llvm-svn: 233290
2015-03-27 01:05:54 +08:00
; GENERIC-ARMV8_1-A: .eabi_attribute 6, 14
; GENERIC-ARMV8_1-A: .eabi_attribute 7, 65
; GENERIC-ARMV8_1-A: .eabi_attribute 8, 1
; GENERIC-ARMV8_1-A: .eabi_attribute 9, 2
; GENERIC-ARMV8_1-A: .fpu crypto-neon-fp-armv8
; GENERIC-ARMV8_1-A: .eabi_attribute 12, 4
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; GENERIC-ARMV8_1-A-NOT: .eabi_attribute 27
; GENERIC-ARMV8_1-A: .eabi_attribute 36, 1
; GENERIC-ARMV8_1-A: .eabi_attribute 42, 1
; GENERIC-ARMV8_1-A-NOT: .eabi_attribute 44
; GENERIC-ARMV8_1-A: .eabi_attribute 68, 3
[AArch64, ARM] Add v8.1a architecture and generic cpu New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: t.p.northover Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8505 llvm-svn: 233290
2015-03-27 01:05:54 +08:00
; GENERIC-ARMV8_1-A-NOT: .eabi_attribute 19
;; We default to IEEE 754 compliance
; GENERIC-ARMV8_1-A: .eabi_attribute 20, 1
; GENERIC-ARMV8_1-A: .eabi_attribute 21, 1
; GENERIC-ARMV8_1-A-NOT: .eabi_attribute 22
; GENERIC-ARMV8_1-A: .eabi_attribute 23, 3
; GENERIC-ARMV8_1-A: .eabi_attribute 24, 1
; GENERIC-ARMV8_1-A: .eabi_attribute 25, 1
; GENERIC-ARMV8_1-A-NOT: .eabi_attribute 28
; GENERIC-ARMV8_1-A: .eabi_attribute 38, 1
; GENERIC-ARMV8_1-A-FAST-NOT: .eabi_attribute 19
;; GENERIC-ARMV8_1-A has the ARMv8 FP unit, which always flushes preserving sign.
; GENERIC-ARMV8_1-A-FAST: .eabi_attribute 20, 2
; GENERIC-ARMV8_1-A-FAST-NOT: .eabi_attribute 21
; GENERIC-ARMV8_1-A-FAST-NOT: .eabi_attribute 22
; GENERIC-ARMV8_1-A-FAST: .eabi_attribute 23, 1
[ARM] Emit correct build attributes for the relocation models. Patch by Asiri Rathnayake. llvm-svn: 209656
2014-05-27 21:30:21 +08:00
; RELOC-PIC: .eabi_attribute 15, 1
; RELOC-PIC: .eabi_attribute 16, 1
; RELOC-PIC: .eabi_attribute 17, 2
; RELOC-OTHER: .eabi_attribute 17, 1
[ARM] Add support for embedded position-independent code This patch adds support for some new relocation models to the ARM backend: * Read-only position independence (ROPI): Code and read-only data is accessed PC-relative. The offsets between all code and RO data sections are known at static link time. This does not affect read-write data. * Read-write position independence (RWPI): Read-write data is accessed relative to the static base register (r9). The offsets between all writeable data sections are known at static link time. This does not affect read-only data. These two modes are independent (they specify how different objects should be addressed), so they can be used individually or together. They are otherwise the same as the "static" relocation model, and are not compatible with SysV-style PIC using a global offset table. These modes are normally used by bare-metal systems or systems with small real-time operating systems. They are designed to avoid the need for a dynamic linker, the only initialisation required is setting r9 to an appropriate value for RWPI code. I have only added support to SelectionDAG, not FastISel, because FastISel is currently disabled for bare-metal targets where these modes would be used. Differential Revision: https://reviews.llvm.org/D23195 llvm-svn: 278015
2016-08-08 23:28:31 +08:00
; RELOC-ROPI-NOT: .eabi_attribute 15,
; RELOC-ROPI: .eabi_attribute 16, 1
; RELOC-ROPI: .eabi_attribute 17, 1
; RELOC-RWPI: .eabi_attribute 15, 2
; RELOC-RWPI-NOT: .eabi_attribute 16,
; RELOC-RWPI: .eabi_attribute 17, 1
; RELOC-ROPI-RWPI: .eabi_attribute 15, 2
; RELOC-ROPI-RWPI: .eabi_attribute 16, 1
; RELOC-ROPI-RWPI: .eabi_attribute 17, 1
[ARM] Emit correct build attributes for the relocation models. Patch by Asiri Rathnayake. llvm-svn: 209656
2014-05-27 21:30:21 +08:00
[ARM] Emit ABI_PCS_R9_use build attribute. Patch by Ben Foster! Differential Revision: http://reviews.llvm.org/D4657 llvm-svn: 213944
2014-07-25 22:03:14 +08:00
; PCS-R9-USE: .eabi_attribute 14, 0
; PCS-R9-RESERVE: .eabi_attribute 14, 3
[ARM]: Add Cortex-R52 target to LLVM This patch adds Cortex-R52, the new ARM real-time processor, to LLVM. Cortex-R52 implements the ARMv8-R architecture. llvm-svn: 283542
2016-10-07 20:06:40 +08:00
; ARMv8R: .eabi_attribute 67, "2.09" @ Tag_conformance
; ARMv8R: .eabi_attribute 6, 15 @ Tag_CPU_arch
; ARMv8R: .eabi_attribute 7, 82 @ Tag_CPU_arch_profile
; ARMv8R: .eabi_attribute 8, 1 @ Tag_ARM_ISA_use
; ARMv8R: .eabi_attribute 9, 2 @ Tag_THUMB_ISA_use
; ARMv8R-NOFPU-NOT: .fpu
; ARMv8R-NOFPU-NOT: .eabi_attribute 12
; ARMv8R-SP: .fpu fpv5-sp-d16
; ARMv8R-SP-NOT: .eabi_attribute 12
; ARMv8R-NEON: .fpu neon-fp-armv8
; ARMv8R-NEON: .eabi_attribute 12, 3 @ Tag_Advanced_SIMD_arch
; ARMv8R-NOFPU-NOT: .eabi_attribute 27
; ARMv8R-SP: .eabi_attribute 27, 1 @ Tag_ABI_HardFP_use
; ARMv8R-NEON-NOT: .eabi_attribute 27
; ARMv8R-NOFPU-NOT: .eabi_attribute 36
; ARMv8R-SP: .eabi_attribute 36, 1 @ Tag_FP_HP_extension
; ARMv8R-NEON: .eabi_attribute 36, 1 @ Tag_FP_HP_extension
; ARMv8R: .eabi_attribute 42, 1 @ Tag_MPextension_use
; ARMv8R: .eabi_attribute 68, 2 @ Tag_Virtualization_use
[ARM] Add hardware build attributes in assembler In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
2017-04-18 20:52:35 +08:00
; ARMv8R: .eabi_attribute 38, 1 @ Tag_ABI_FP_16bit_format
; ARMv8R: .eabi_attribute 14, 0 @ Tag_ABI_PCS_R9_use
[ARM]: Add Cortex-R52 target to LLVM This patch adds Cortex-R52, the new ARM real-time processor, to LLVM. Cortex-R52 implements the ARMv8-R architecture. llvm-svn: 283542
2016-10-07 20:06:40 +08:00
Tiny patch for proof-of-concept cleanup of ARMAsmPrinter::EmitStartOfAsmFile() Small test for sanity check of resulting ARM .s file. Tested against -r115129. llvm-svn: 115133
2010-09-30 10:45:56 +08:00
define i32 @f(i64 %z) {
Emit Tag_ABI_FP_denormal correctly in fast-math mode. The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture, * For VFPv2, it is implementation defined as to whether the sign of zero is preserved. * For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero. When FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign. Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd llvm-svn: 223110
2014-12-02 16:22:29 +08:00
ret i32 0
Tiny patch for proof-of-concept cleanup of ARMAsmPrinter::EmitStartOfAsmFile() Small test for sanity check of resulting ARM .s file. Tested against -r115129. llvm-svn: 115133
2010-09-30 10:45:56 +08:00
}