maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/fast-math.c

314 lines
15 KiB
C
Raw Normal View History

Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// Test that the GCC fast-math floating point flags get lowered to the correct
// permutation of Clang frontend flags. This is non-trivial for a few reasons.
// First, the GCC flags have many different and surprising effects. Second,
// LLVM only supports three switches which is more coarse grained than GCC's
// support.
//
test/Driver/fast-math.c: Mark this as XFAIL:cygming. They use gcc driver for as. llvm-svn: 155691
2012-04-27 12:36:27 +08:00
// Both of them use gcc driver for as.
clang/test/Driver: Introduce the feature "clang-driver", set if gcc driver is not used. It is not set at targetting cygming. See PR12920. llvm-svn: 169824
2012-12-11 15:06:09 +08:00
// REQUIRES: clang-driver
test/Driver/fast-math.c: Mark this as XFAIL:cygming. They use gcc driver for as. llvm-svn: 155691
2012-04-27 12:36:27 +08:00
//
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: %clang -### -fno-honor-infinities -c %s 2>&1 \
Add a missing pipe in the test from r197896 Spotted by Edward llvm-svn: 197903
2013-12-23 16:50:43 +08:00
// RUN: | FileCheck --check-prefix=CHECK-NO-INFS %s
Make some f_Group definitions anonymous and test an alternative spelling These names weren't referred to anywhere in the source so don't need a written name. Depends on the TableGen fix for anonymous records in LLVM r197869. llvm-svn: 197896
2013-12-23 06:38:57 +08:00
// infinites [sic] is a supported alternative spelling of infinities.
// RUN: %clang -### -fno-honor-infinites -c %s 2>&1 \
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: | FileCheck --check-prefix=CHECK-NO-INFS %s
// CHECK-NO-INFS: "-cc1"
// CHECK-NO-INFS: "-menable-no-infs"
//
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
// RUN: %clang -### -fno-fast-math -fno-honor-infinities -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-NO-INFS %s
// CHECK-NO-FAST-MATH-NO-INFS: "-cc1"
// CHECK-NO-FAST-MATH-NO-INFS: "-menable-no-infs"
//
// RUN: %clang -### -fno-honor-infinities -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-INFS-NO-FAST-MATH %s
// CHECK-NO-INFS-NO-FAST-MATH: "-cc1"
// CHECK-NO-INFS-NO-FAST-MATH-NOT: "-menable-no-infs"
//
Process the -fno-signed-zeros optimization flag (PR20870) The driver currently accepts but ignores the -fno-signed-zeros flag. This patch passes the flag through and enables 'nsz' fast-math-flag generation in IR. The existing OpenCL flag for the same functionality is made into an alias here. It may be removed in a subsequent patch. This should resolve bug 20870 ( http://llvm.org/bugs/show_bug.cgi?id=20870 ); patches for the optimizer were checked in at: http://llvm.org/viewvc/llvm-project?view=revision&revision=225050 http://llvm.org/viewvc/llvm-project?view=revision&revision=224583 Differential Revision: http://reviews.llvm.org/D6873 llvm-svn: 226915
2015-01-24 00:40:50 +08:00
// RUN: %clang -### -fno-signed-zeros -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-SIGNED-ZEROS %s
// CHECK-NO-SIGNED-ZEROS: "-cc1"
// CHECK-NO-SIGNED-ZEROS: "-fno-signed-zeros"
//
// RUN: %clang -### -fno-fast-math -fno-signed-zeros -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-NO-SIGNED-ZEROS %s
// CHECK-NO-FAST-MATH-NO-SIGNED-ZEROS: "-cc1"
// CHECK-NO-FAST-MATH-NO-SIGNED-ZEROS: "-fno-signed-zeros"
//
// RUN: %clang -### -fno-signed-zeros -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-SIGNED-ZEROS-NO-FAST-MATH %s
// CHECK-NO-SIGNED-ZEROS-NO-FAST-MATH: "-cc1"
// CHECK-NO-SIGNED-ZEROS-NO-FAST-MATH-NOT: "-fno-signed-zeros"
//
Process the -freciprocal-math optimization flag (PR20912) The driver currently accepts but ignores the -freciprocal-math flag. This patch passes the flag through and enables 'arcp' fast-math-flag generation in IR. Note that this change does not actually enable the optimization for any target. The reassociation optimization that this flag specifies was implemented by http://reviews.llvm.org/D6334 : http://llvm.org/viewvc/llvm-project?view=revision&revision=222510 Because the optimization is done in the backend rather than IR, the backend must be modified to understand instruction-level fast-math-flags or a new function-level attribute must be created. Also note that -freciprocal-math is independent of any target-specific usage of reciprocal estimate hardware instructions. That requires its own flag ('-mrecip'). https://llvm.org/bugs/show_bug.cgi?id=20912 llvm-svn: 234493
2015-04-09 23:03:23 +08:00
// RUN: %clang -### -freciprocal-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-RECIPROCAL-MATH %s
// CHECK-RECIPROCAL-MATH: "-cc1"
// CHECK-RECIPROCAL-MATH: "-freciprocal-math"
//
// RUN: %clang -### -fno-fast-math -freciprocal-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-RECIPROCAL-MATH %s
// CHECK-NO-FAST-MATH-RECIPROCAL-MATH: "-cc1"
// CHECK-NO-FAST-MATH-RECIPROCAL-MATH: "-freciprocal-math"
//
// RUN: %clang -### -freciprocal-math -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-RECIPROCAL-MATH-NO-FAST-MATH %s
// CHECK-RECIPROCAL-MATH-NO-FAST-MATH: "-cc1"
// CHECK-RECIPROCAL-MATH-NO-FAST-MATH-NOT: "-freciprocal-math"
//
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: %clang -### -fno-honor-nans -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NANS %s
// CHECK-NO-NANS: "-cc1"
// CHECK-NO-NANS: "-menable-no-nans"
//
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
// RUN: %clang -### -fno-fast-math -fno-honor-nans -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-NO-NANS %s
// CHECK-NO-FAST-MATH-NO-NANS: "-cc1"
// CHECK-NO-FAST-MATH-NO-NANS: "-menable-no-nans"
//
// RUN: %clang -### -fno-honor-nans -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NANS-NO-FAST-MATH %s
// CHECK-NO-NANS-NO-FAST-MATH: "-cc1"
// CHECK-NO-NANS-NO-FAST-MATH-NOT: "-menable-no-nans"
//
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: %clang -### -fmath-errno -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-MATH-ERRNO %s
// CHECK-MATH-ERRNO: "-cc1"
// CHECK-MATH-ERRNO: "-fmath-errno"
//
Fix a long-standing bug where Clang had a different default from GCC on Linux and other (non-Darwin) platforms and have it use -fmath-errno by default (for better or worse). Darwin has seen the light here and uses -fno-math-errno by default, this patch preserves that. If any maintainers for a non-Linux platform would also like to opt-in to -fno-math-errno by default, I'm happy to add folks, but we're currently getting buts and misleading comparisons with GCC due to this difference in behavior on Linux at least. llvm-svn: 155607
2012-04-26 10:10:51 +08:00
// RUN: %clang -### -fmath-errno -fno-math-errno -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
Fix a logic bug in the handling of -fmath-errno in the driver. We would imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math, regardless of in which order and regardless of the tool chain default. I've fixed this to follow the logic: 1) If the last dominating flag is -fno-math-errno, -ffast-math, or -Ofast, then do not use math-errno. 2) If the last dominating flag is an explicit -fmath-errno, do use math-errno. 3) Otherwise, use the toolchain default. This, for example, allows the flag sequence '-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or '-fno-math-errno' to preserve the toolchain default. Most notably, this should prevent users trying to disable fast-math optimizations on Darwin and BSD platforms from simultaneously enabling (pointless) -fmath-errno. I've enhanced the tests (after more reorganization) to cover this and other weird permutations of flags and targets. llvm-svn: 182203
2013-05-19 04:47:36 +08:00
// CHECK-NO-MATH-ERRNO: "-cc1"
// CHECK-NO-MATH-ERRNO-NOT: "-fmath-errno"
//
// Target defaults for -fmath-errno (reusing the above checks).
// RUN: %clang -### -target i686-unknown-linux -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-MATH-ERRNO %s
Fix a long-standing bug where Clang had a different default from GCC on Linux and other (non-Darwin) platforms and have it use -fmath-errno by default (for better or worse). Darwin has seen the light here and uses -fno-math-errno by default, this patch preserves that. If any maintainers for a non-Linux platform would also like to opt-in to -fno-math-errno by default, I'm happy to add folks, but we're currently getting buts and misleading comparisons with GCC due to this difference in behavior on Linux at least. llvm-svn: 155607
2012-04-26 10:10:51 +08:00
// RUN: %clang -### -target i686-apple-darwin -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
Driver: Turn the default value for -fmath-errno into a proper target hook and disable it by default on more platforms. For now -fno-math-errno is the default on BSD-derived platforms (Darwin, DragonFlyBSD, FreeBSD, NetBSD, OpenBSD). If the default is not right for your platform, please yell. I only verified the result with the default compilers on Darwin and FreeBSD. llvm-svn: 155990
2012-05-02 22:55:48 +08:00
// RUN: %clang -### -target x86_64-unknown-freebsd -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
// RUN: %clang -### -target x86_64-unknown-netbsd -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
// RUN: %clang -### -target x86_64-unknown-openbsd -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
// RUN: %clang -### -target x86_64-unknown-dragonfly -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
[Driver] Fuchsia defaults to -fno-math-errno Patch by Roland McGrath Differential Revision: https://reviews.llvm.org/D35747 llvm-svn: 308855
2017-07-24 06:30:13 +08:00
// RUN: %clang -### -target x86_64-fuchsia -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
Fix a logic bug in the handling of -fmath-errno in the driver. We would imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math, regardless of in which order and regardless of the tool chain default. I've fixed this to follow the logic: 1) If the last dominating flag is -fno-math-errno, -ffast-math, or -Ofast, then do not use math-errno. 2) If the last dominating flag is an explicit -fmath-errno, do use math-errno. 3) Otherwise, use the toolchain default. This, for example, allows the flag sequence '-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or '-fno-math-errno' to preserve the toolchain default. Most notably, this should prevent users trying to disable fast-math optimizations on Darwin and BSD platforms from simultaneously enabling (pointless) -fmath-errno. I've enhanced the tests (after more reorganization) to cover this and other weird permutations of flags and targets. llvm-svn: 182203
2013-05-19 04:47:36 +08:00
//
// Check that -ffast-math disables -fmath-errno, and -fno-fast-math merely
// preserves the target default. Also check various flag set operations between
// the two flags. (Resuses above checks.)
// RUN: %clang -### -ffast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
// RUN: %clang -### -fmath-errno -ffast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
// RUN: %clang -### -ffast-math -fmath-errno -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-MATH-ERRNO %s
// RUN: %clang -### -target i686-unknown-linux -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-MATH-ERRNO %s
// RUN: %clang -### -target i686-unknown-linux -fno-math-errno -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-MATH-ERRNO %s
// RUN: %clang -### -target i686-apple-darwin -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
// RUN: %clang -### -target i686-apple-darwin -fno-math-errno -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
// RUN: %clang -### -fno-fast-math -fno-math-errno -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
Fix a long-standing bug where Clang had a different default from GCC on Linux and other (non-Darwin) platforms and have it use -fmath-errno by default (for better or worse). Darwin has seen the light here and uses -fno-math-errno by default, this patch preserves that. If any maintainers for a non-Linux platform would also like to opt-in to -fno-math-errno by default, I'm happy to add folks, but we're currently getting buts and misleading comparisons with GCC due to this difference in behavior on Linux at least. llvm-svn: 155607
2012-04-26 10:10:51 +08:00
//
// RUN: %clang -### -fno-math-errno -fassociative-math -freciprocal-math \
// RUN: -fno-signed-zeros -fno-trapping-math -c %s 2>&1 \
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UNSAFE-MATH %s
// CHECK-UNSAFE-MATH: "-cc1"
// CHECK-UNSAFE-MATH: "-menable-unsafe-fp-math"
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// CHECK-UNSAFE-MATH: "-mreassociate"
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
//
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
// RUN: %clang -### -fno-fast-math -fno-math-errno -fassociative-math -freciprocal-math \
// RUN: -fno-signed-zeros -fno-trapping-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH-UNSAFE-MATH %s
// CHECK-NO-FAST-MATH-UNSAFE-MATH: "-cc1"
// CHECK-NO-FAST-MATH-UNSAFE-MATH: "-menable-unsafe-fp-math"
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// CHECK-NO-FAST-MATH-UNSAFE-MATH: "-mreassociate"
// The 2nd -fno-fast-math overrides -fassociative-math.
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
// RUN: %clang -### -fno-fast-math -fno-math-errno -fassociative-math -freciprocal-math \
// RUN: -fno-fast-math -fno-signed-zeros -fno-trapping-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-UNSAFE-MATH-NO-FAST-MATH %s
// CHECK-UNSAFE-MATH-NO-FAST-MATH: "-cc1"
// CHECK-UNSAFE-MATH-NO-FAST-MATH-NOT: "-menable-unsafe-fp-math"
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// CHECK-UNSAFE-MATH-NO-FAST-MATH-NOT: "-mreassociate"
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
//
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// Check that various umbrella flags also enable these frontend options.
// RUN: %clang -### -ffast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-INFS %s
// RUN: %clang -### -ffast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NANS %s
// RUN: %clang -### -ffast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-UNSAFE-MATH %s
// RUN: %clang -### -ffinite-math-only -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-INFS %s
// RUN: %clang -### -ffinite-math-only -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NANS %s
Fix a long-standing bug where Clang had a different default from GCC on Linux and other (non-Darwin) platforms and have it use -fmath-errno by default (for better or worse). Darwin has seen the light here and uses -fno-math-errno by default, this patch preserves that. If any maintainers for a non-Linux platform would also like to opt-in to -fno-math-errno by default, I'm happy to add folks, but we're currently getting buts and misleading comparisons with GCC due to this difference in behavior on Linux at least. llvm-svn: 155607
2012-04-26 10:10:51 +08:00
// RUN: %clang -### -funsafe-math-optimizations -fno-math-errno -c %s 2>&1 \
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UNSAFE-MATH %s
//
// One umbrella flag is *really* weird and also changes the semantics of the
// program by adding a special preprocessor macro. Check that the frontend flag
[Driver] Restructure handling of -ffast-math and similar options The way -ffast-math and the various related options to tweak floating-point handling are handled is inflexible and rather confusing. This patch restructures things so that we go through the options adjusting our idea of what's enabled as we go, instead of trying to figure each individual thing out by working backwards from the end, as this makes the behaviour of each individual option more clear. Doing it this way also means we get gcc-compatible behaviour for when the __FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend on the final set of features that are enabled and not just on -ffast-math and -ffinite-math-only specifically. Differential Revision: http://reviews.llvm.org/D30582 llvm-svn: 297837
2017-03-15 22:03:32 +08:00
// modeling this semantic change is provided. Also check that the flag is not
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// present if any of the optimizations are disabled.
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: %clang -### -ffast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FAST-MATH %s
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FAST-MATH %s
[Driver] Restructure handling of -ffast-math and similar options The way -ffast-math and the various related options to tweak floating-point handling are handled is inflexible and rather confusing. This patch restructures things so that we go through the options adjusting our idea of what's enabled as we go, instead of trying to figure each individual thing out by working backwards from the end, as this makes the behaviour of each individual option more clear. Doing it this way also means we get gcc-compatible behaviour for when the __FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend on the final set of features that are enabled and not just on -ffast-math and -ffinite-math-only specifically. Differential Revision: http://reviews.llvm.org/D30582 llvm-svn: 297837
2017-03-15 22:03:32 +08:00
// RUN: %clang -### -funsafe-math-optimizations -ffinite-math-only \
// RUN: -fno-math-errno -ffp-contract=fast -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FAST-MATH %s
// RUN: %clang -### -fno-honor-infinities -fno-honor-nans -fno-math-errno \
// RUN: -fassociative-math -freciprocal-math -fno-signed-zeros \
// RUN: -fno-trapping-math -ffp-contract=fast -c %s 2>&1 \
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: | FileCheck --check-prefix=CHECK-FAST-MATH %s
// CHECK-FAST-MATH: "-cc1"
// CHECK-FAST-MATH: "-ffast-math"
[Driver] Restructure handling of -ffast-math and similar options The way -ffast-math and the various related options to tweak floating-point handling are handled is inflexible and rather confusing. This patch restructures things so that we go through the options adjusting our idea of what's enabled as we go, instead of trying to figure each individual thing out by working backwards from the end, as this makes the behaviour of each individual option more clear. Doing it this way also means we get gcc-compatible behaviour for when the __FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend on the final set of features that are enabled and not just on -ffast-math and -ffinite-math-only specifically. Differential Revision: http://reviews.llvm.org/D30582 llvm-svn: 297837
2017-03-15 22:03:32 +08:00
// CHECK-FAST-MATH: "-ffinite-math-only"
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
//
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH %s
[Driver] Restructure handling of -ffast-math and similar options The way -ffast-math and the various related options to tweak floating-point handling are handled is inflexible and rather confusing. This patch restructures things so that we go through the options adjusting our idea of what's enabled as we go, instead of trying to figure each individual thing out by working backwards from the end, as this makes the behaviour of each individual option more clear. Doing it this way also means we get gcc-compatible behaviour for when the __FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend on the final set of features that are enabled and not just on -ffast-math and -ffinite-math-only specifically. Differential Revision: http://reviews.llvm.org/D30582 llvm-svn: 297837
2017-03-15 22:03:32 +08:00
// RUN: %clang -### -ffast-math -fno-finite-math-only -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH %s
// RUN: %clang -### -ffast-math -fno-unsafe-math-optimizations -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH %s
// RUN: %clang -### -ffast-math -fmath-errno -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH %s
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// RUN: %clang -### -ffast-math -fno-associative-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FAST-MATH --check-prefix=CHECK-ASSOC-MATH %s
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
// CHECK-NO-FAST-MATH: "-cc1"
// CHECK-NO-FAST-MATH-NOT: "-ffast-math"
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// CHECK-ASSOC-MATH-NOT: "-mreassociate"
[driver] Add support for the -fno-fast-math option. rdar://12299433 llvm-svn: 164638
2012-09-26 06:03:25 +08:00
//
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// Check various means of disabling these flags, including disabling them after
// they've been enabled via an umbrella flag.
// RUN: %clang -### -fno-honor-infinities -fhonor-infinities -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-INFS %s
// RUN: %clang -### -ffinite-math-only -fhonor-infinities -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-INFS %s
// RUN: %clang -### -ffinite-math-only -fno-finite-math-only -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-INFS %s
// RUN: %clang -### -ffast-math -fhonor-infinities -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-INFS %s
// RUN: %clang -### -ffast-math -fno-finite-math-only -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-INFS %s
// CHECK-NO-NO-INFS: "-cc1"
// CHECK-NO-NO-INFS-NOT: "-menable-no-infs"
[Driver] Restructure handling of -ffast-math and similar options The way -ffast-math and the various related options to tweak floating-point handling are handled is inflexible and rather confusing. This patch restructures things so that we go through the options adjusting our idea of what's enabled as we go, instead of trying to figure each individual thing out by working backwards from the end, as this makes the behaviour of each individual option more clear. Doing it this way also means we get gcc-compatible behaviour for when the __FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend on the final set of features that are enabled and not just on -ffast-math and -ffinite-math-only specifically. Differential Revision: http://reviews.llvm.org/D30582 llvm-svn: 297837
2017-03-15 22:03:32 +08:00
// CHECK-NO-NO-INFS-NOT: "-ffinite-math-only"
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// CHECK-NO-NO-INFS: "-o"
//
// RUN: %clang -### -fno-honor-nans -fhonor-nans -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-NANS %s
// RUN: %clang -### -ffinite-math-only -fhonor-nans -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-NANS %s
// RUN: %clang -### -ffinite-math-only -fno-finite-math-only -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-NANS %s
// RUN: %clang -### -ffast-math -fhonor-nans -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-NANS %s
// RUN: %clang -### -ffast-math -fno-finite-math-only -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-NO-NANS %s
// CHECK-NO-NO-NANS: "-cc1"
// CHECK-NO-NO-NANS-NOT: "-menable-no-nans"
[Driver] Restructure handling of -ffast-math and similar options The way -ffast-math and the various related options to tweak floating-point handling are handled is inflexible and rather confusing. This patch restructures things so that we go through the options adjusting our idea of what's enabled as we go, instead of trying to figure each individual thing out by working backwards from the end, as this makes the behaviour of each individual option more clear. Doing it this way also means we get gcc-compatible behaviour for when the __FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend on the final set of features that are enabled and not just on -ffast-math and -ffinite-math-only specifically. Differential Revision: http://reviews.llvm.org/D30582 llvm-svn: 297837
2017-03-15 22:03:32 +08:00
// CHECK-NO-NO-NANS-NOT: "-ffinite-math-only"
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// CHECK-NO-NO-NANS: "-o"
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// A later inverted option overrides an earlier option.
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: %clang -### -fassociative-math -freciprocal-math -fno-signed-zeros \
// RUN: -fno-trapping-math -fno-associative-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: %clang -### -funsafe-math-optimizations -fno-associative-math -c %s \
// RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: %clang -### -funsafe-math-optimizations -fno-reciprocal-math -c %s \
// RUN: 2>&1 | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
// RUN: %clang -### -funsafe-math-optimizations -fsigned-zeros -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
// RUN: %clang -### -funsafe-math-optimizations -ftrapping-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
// RUN: %clang -### -funsafe-math-optimizations -fno-unsafe-math-optimizations \
// RUN: -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
// RUN: %clang -### -ffast-math -fno-associative-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// RUN: %clang -### -ffast-math -fno-reciprocal-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
// RUN: %clang -### -ffast-math -fsigned-zeros -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
// RUN: %clang -### -ffast-math -ftrapping-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
// RUN: %clang -### -ffast-math -fno-unsafe-math-optimizations -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-UNSAFE-MATH %s
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// CHECK-NO-UNSAFE-MATH: "-cc1"
// CHECK-NO-UNSAFE-MATH-NOT: "-menable-unsafe-fp-math"
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// CHECK-NO_UNSAFE-MATH-NOT: "-mreassociate"
Fix PR11685 by implementing -ffast-math and its various friends in the Clang driver. This involves a bunch of silly option parsing code to try to carefully emulate GCC's options. Currently, this takes a conservative approach, and unless all of the unsafe optimizations are enabled, none of them are. The fine grained control doesn't seem particularly useful. If it ever becomes useful, we can add that to LLVM first, and then expose it here. This also fixes a few tiny bugs in the flag management around -fhonor-infinities and -fhonor-nans; the flags now form proper sets both for enabling and disabling, with the last flag winning. I've also implemented a moderately terrifying GCC feature where a language change is also provided by the '-ffast-math' flag by defining the __FAST_MATH__ preprocessor macro. This feature is tracked and serialized in the frontend but it isn't used yet. A subsequent patch will add the preprocessor macro and tests for it. I've manually tested that codegen appears to respect this, but I've not dug in enough to see if there is an easy way to test codegen options w/o relying on the particulars of LLVM's optimizations. llvm-svn: 147434
2012-01-02 22:19:45 +08:00
// CHECK-NO-UNSAFE-MATH: "-o"
[Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
2017-12-17 00:11:17 +08:00
// Reassociate is allowed because it does not require reciprocal-math.
// RUN: %clang -### -fassociative-math -freciprocal-math -fno-signed-zeros \
// RUN: -fno-trapping-math -fno-reciprocal-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-REASSOC-NO-UNSAFE-MATH %s
// CHECK-REASSOC-NO-UNSAFE-MATH: "-cc1"
// CHECK-REASSOC-NO-UNSAFE-MATH-NOT: "-menable-unsafe-fp-math"
// CHECK-REASSOC-NO_UNSAFE-MATH: "-mreassociate"
// CHECK-REASSOC-NO-UNSAFE-MATH-NOT: "-menable-unsafe-fp-math"
// CHECK-REASSOC-NO-UNSAFE-MATH: "-o"
// In these runs, reassociate is not allowed because both no-signed-zeros and no-trapping-math are required.
// RUN: %clang -### -fassociative-math -freciprocal-math -fno-signed-zeros \
// RUN: -fno-trapping-math -fsigned-zeros -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-REASSOC-NO-UNSAFE-MATH %s
// RUN: %clang -### -fassociative-math -freciprocal-math -fno-signed-zeros \
// RUN: -fno-trapping-math -ftrapping-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-REASSOC-NO-UNSAFE-MATH %s
// CHECK-NO-REASSOC-NO-UNSAFE-MATH: "-cc1"
// CHECK-NO-REASSOC-NO-UNSAFE-MATH-NOT: "-menable-unsafe-fp-math"
// CHECK-NO-REASSOC-NO_UNSAFE-MATH-NOT: "-mreassociate"
// CHECK-NO-REASSOC-NO-UNSAFE-MATH-NOT: "-menable-unsafe-fp-math"
// CHECK-NO-REASSOC-NO-UNSAFE-MATH: "-o"
Revision r280064 adds new options -fdenormal-fp-math and passes through option -ffast-math to CC1, but it included a wrong llvm regression tests which was removed in r280065. Although regression test noexceptionsfpmath.c makes sure -fno-trapping-math ends up as a function attribute, this adds a test that explicitly checks the driver output for -fno-trapping-math. llvm-svn: 280227
2016-08-31 20:31:03 +08:00
// RUN: %clang -### -ftrapping-math -fno-trapping-math -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-TRAPPING-MATH %s
// CHECK-NO-TRAPPING-MATH: "-fno-trapping-math"
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00
// This isn't fast-math, but the option is handled in the same place as other FP params.
[Driver, CodeGen] rename options to disable an FP cast optimization As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
2018-05-01 02:19:03 +08:00
// Last option wins, and strict behavior is assumed by default.
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00
[Driver, CodeGen] rename options to disable an FP cast optimization As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
2018-05-01 02:19:03 +08:00
// RUN: %clang -### -fno-strict-float-cast-overflow -c %s 2>&1 \
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00
// RUN: | FileCheck --check-prefix=CHECK-FPOV-WORKAROUND %s
// CHECK-FPOV-WORKAROUND: "-cc1"
[Driver, CodeGen] rename options to disable an FP cast optimization As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
2018-05-01 02:19:03 +08:00
// CHECK-FPOV-WORKAROUND: "-fno-strict-float-cast-overflow"
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00
// RUN: %clang -### -c %s 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FPOV-WORKAROUND-DEFAULT %s
// CHECK-FPOV-WORKAROUND-DEFAULT: "-cc1"
[Driver, CodeGen] rename options to disable an FP cast optimization As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
2018-05-01 02:19:03 +08:00
// CHECK-FPOV-WORKAROUND-DEFAULT-NOT: "strict-float-cast-overflow"
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00
[Driver, CodeGen] rename options to disable an FP cast optimization As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
2018-05-01 02:19:03 +08:00
// RUN: %clang -### -fstrict-float-cast-overflow -c %s 2>&1 \
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00
// RUN: | FileCheck --check-prefix=CHECK-NO-FPOV-WORKAROUND %s
// CHECK-NO-FPOV-WORKAROUND: "-cc1"
[Driver, CodeGen] rename options to disable an FP cast optimization As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
2018-05-01 02:19:03 +08:00
// CHECK-NO-FPOV-WORKAROUND-NOT: "strict-float-cast-overflow"
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00
[Driver, CodeGen] rename options to disable an FP cast optimization As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
2018-05-01 02:19:03 +08:00
// RUN: %clang -### -fno-strict-float-cast-overflow -fstrict-float-cast-overflow -c %s 2>&1 \
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00
// RUN: | FileCheck --check-prefix=CHECK-NO-FPOV-WORKAROUND-OVERRIDE %s
// CHECK-NO-FPOV-WORKAROUND-OVERRIDE: "-cc1"
[Driver, CodeGen] rename options to disable an FP cast optimization As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
2018-05-01 02:19:03 +08:00
// CHECK-NO-FPOV-WORKAROUND-OVERRIDE-NOT: "strict-float-cast-overflow"
[Driver, CodeGen] add options to enable/disable an FP cast optimization As discussed in the post-commit thread for: rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html ) We need a way to opt-out of a float-to-int-to-float cast optimization because too much existing code relies on the platform-specific undefined result of those casts when the float-to-int overflows. The LLVM changes associated with adding this function attribute are here: rL330947 rL330950 rL330951 Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that catches this problem: rL330958 Differential Revision: https://reviews.llvm.org/D46135 llvm-svn: 331041
2018-04-27 22:22:48 +08:00