[v4] LOOP-UNROLL: Leverage HAS_SIGNED_ZERO for var expansion
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gcc_build--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gcc_check--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 |
success
|
Testing passed
|
Commit Message
From: Pan Li <pan2.li@intel.com>
The insert_var_expansion_initialization depends on the
HONOR_SIGNED_ZEROS to initialize the unrolling variables
to +0.0f when -0.0f and no-signed-option. Unfortunately,
we should always keep the -0.0f here because:
* The -0.0f is always the correct initial value.
* We need to support the target that always honor signed zero.
Thus, we need to leverage MODE_HAS_SIGNED_ZEROS when initialize
instead of HONOR_SIGNED_ZEROS. Then the target/backend can
decide to honor the no-signed-zero or not.
The below tests are passed for this patch:
* The riscv regression tests.
* The aarch64 regression tests.
* The x86 bootstrap and regression tests.
gcc/ChangeLog:
* loop-unroll.cc (insert_var_expansion_initialization): Leverage
MODE_HAS_SIGNED_ZEROS for expansion variable initialization.
gcc/testsuite/ChangeLog:
* gcc.dg/pr30957-1.c: Adjust tests cases for different scenarios.
Signed-off-by: Pan Li <pan2.li@intel.com>
---
gcc/loop-unroll.cc | 4 +--
gcc/testsuite/gcc.dg/pr30957-1.c | 48 ++++++++++++++++++++++++++++----
2 files changed, 44 insertions(+), 8 deletions(-)
Comments
On Thu, Jan 11, 2024 at 2:39 AM <pan2.li@intel.com> wrote:
>
> From: Pan Li <pan2.li@intel.com>
>
> The insert_var_expansion_initialization depends on the
> HONOR_SIGNED_ZEROS to initialize the unrolling variables
> to +0.0f when -0.0f and no-signed-option. Unfortunately,
> we should always keep the -0.0f here because:
>
> * The -0.0f is always the correct initial value.
> * We need to support the target that always honor signed zero.
>
> Thus, we need to leverage MODE_HAS_SIGNED_ZEROS when initialize
> instead of HONOR_SIGNED_ZEROS. Then the target/backend can
> decide to honor the no-signed-zero or not.
>
> The below tests are passed for this patch:
>
> * The riscv regression tests.
> * The aarch64 regression tests.
> * The x86 bootstrap and regression tests.
>
> gcc/ChangeLog:
>
> * loop-unroll.cc (insert_var_expansion_initialization): Leverage
> MODE_HAS_SIGNED_ZEROS for expansion variable initialization.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr30957-1.c: Adjust tests cases for different scenarios.
>
> Signed-off-by: Pan Li <pan2.li@intel.com>
> ---
> gcc/loop-unroll.cc | 4 +--
> gcc/testsuite/gcc.dg/pr30957-1.c | 48 ++++++++++++++++++++++++++++----
> 2 files changed, 44 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/loop-unroll.cc b/gcc/loop-unroll.cc
> index 4176a21e308..bfdfe6c2bb7 100644
> --- a/gcc/loop-unroll.cc
> +++ b/gcc/loop-unroll.cc
> @@ -1855,7 +1855,7 @@ insert_var_expansion_initialization (struct var_to_expand *ve,
> rtx var, zero_init;
> unsigned i;
> machine_mode mode = GET_MODE (ve->reg);
> - bool honor_signed_zero_p = HONOR_SIGNED_ZEROS (mode);
> + bool has_signed_zero_p = MODE_HAS_SIGNED_ZEROS (mode);
>
> if (ve->var_expansions.length () == 0)
> return;
> @@ -1869,7 +1869,7 @@ insert_var_expansion_initialization (struct var_to_expand *ve,
> case MINUS:
> FOR_EACH_VEC_ELT (ve->var_expansions, i, var)
> {
> - if (honor_signed_zero_p)
> + if (has_signed_zero_p)
> zero_init = simplify_gen_unary (NEG, mode, CONST0_RTX (mode), mode);
> else
> zero_init = CONST0_RTX (mode);
This change is OK.
> diff --git a/gcc/testsuite/gcc.dg/pr30957-1.c b/gcc/testsuite/gcc.dg/pr30957-1.c
> index 564410913ab..6a9d3d87932 100644
> --- a/gcc/testsuite/gcc.dg/pr30957-1.c
> +++ b/gcc/testsuite/gcc.dg/pr30957-1.c
> @@ -20,16 +20,52 @@ foo (float d, int n)
> return accum;
> }
>
> +float __attribute__((noinline))
> +get_minus_zero()
> +{
> + return 0.0 / -5.0;
> +}
> +
I still think this test shouldn't use -fno-signed-zeros since that makes it
undefined whether the return value is positive or negative - checking
whether get_minus_zero returns negative or positive zero isn't a
good indicator and prone to break.
We have a { dg-add-options ieee } we'd need.
The original testcase indicates variable expansion wouldn't trigger then,
and in the PR it's noted we should remove this broken testcase and the
PR itself is invalid.
I agree there.
So, can you remove the testcase instead?
Thanks,
Richard.
> int
> main ()
> {
> - /* When compiling standard compliant we expect foo to return -0.0. But the
> - variable expansion during unrolling optimization (for this testcase enabled
> - by non-compliant -fassociative-math) instantiates copy(s) of the
> - accumulator which it initializes with +0.0. Hence we expect that foo
> - returns +0.0. */
> - if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != 1.0)
> + /* The variable expansion in unroll requires option unsafe-math-optimizations
> + (aka -fno-signed-zeros, -fno-trapping-math, -fassociative-math
> + and -freciprocal-math).
> +
> + When loop like above will have expansion after unrolling as below:
> +
> + accum_1 += d_1;
> + accum_2 += d_2;
> + accum_3 += d_3;
> + ...
> +
> + The accum_1, accum_2 and accum_3 need to be initialized. Given the
> + floating-point we have
> + +0.0f + -0.0f = +0.0f.
> +
> + Thus, we should initialize the accum_* to -0.0 for correctness. But
> + the things become more complicated when no-signed-zeros, as well as VLA
> + vectorizer mode which doesn't trigger variable expansion. Then we have:
> +
> + Case 1: Trigger variable expansion but target doesn't honor no-signed-zero.
> + minus_zero will be -0.0f and foo (minus_zero, 10) will be -0.0f.
> + Case 2: Trigger variable expansion but target does honor no-signed-zero.
> + minus_zero will be +0.0f and foo (minus_zero, 10) will be +0.0f.
> + Case 3: No variable expansion but target doesn't honor no-signed-zero.
> + minus_zero will be -0.0f and foo (minus_zero, 10) will be -0.0f.
> + Case 4: No variable expansion but target does honor no-signed-zero.
> + minus_zero will be +0.0f and foo (minus_zero, 10) will be +0.0f.
> +
> + The test case covers above 4 cases for running.
> + */
> + float minus_zero = get_minus_zero ();
> + float a = __builtin_copysignf (1.0, minus_zero);
> + float b = __builtin_copysignf (1.0, foo (minus_zero, 10));
> +
> + if (a != b)
> abort ();
> +
> exit (0);
> }
>
> --
> 2.34.1
>
Thanks Richard, will delete the test case pr30957-1.c in patch V5.
Pan
-----Original Message-----
From: Richard Biener <richard.guenther@gmail.com>
Sent: Thursday, January 11, 2024 4:33 PM
To: Li, Pan2 <pan2.li@intel.com>
Cc: gcc-patches@gcc.gnu.org; juzhe.zhong@rivai.ai; Wang, Yanzhang <yanzhang.wang@intel.com>; kito.cheng@gmail.com; jeffreyalaw@gmail.com
Subject: Re: [PATCH v4] LOOP-UNROLL: Leverage HAS_SIGNED_ZERO for var expansion
On Thu, Jan 11, 2024 at 2:39 AM <pan2.li@intel.com> wrote:
>
> From: Pan Li <pan2.li@intel.com>
>
> The insert_var_expansion_initialization depends on the
> HONOR_SIGNED_ZEROS to initialize the unrolling variables
> to +0.0f when -0.0f and no-signed-option. Unfortunately,
> we should always keep the -0.0f here because:
>
> * The -0.0f is always the correct initial value.
> * We need to support the target that always honor signed zero.
>
> Thus, we need to leverage MODE_HAS_SIGNED_ZEROS when initialize
> instead of HONOR_SIGNED_ZEROS. Then the target/backend can
> decide to honor the no-signed-zero or not.
>
> The below tests are passed for this patch:
>
> * The riscv regression tests.
> * The aarch64 regression tests.
> * The x86 bootstrap and regression tests.
>
> gcc/ChangeLog:
>
> * loop-unroll.cc (insert_var_expansion_initialization): Leverage
> MODE_HAS_SIGNED_ZEROS for expansion variable initialization.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr30957-1.c: Adjust tests cases for different scenarios.
>
> Signed-off-by: Pan Li <pan2.li@intel.com>
> ---
> gcc/loop-unroll.cc | 4 +--
> gcc/testsuite/gcc.dg/pr30957-1.c | 48 ++++++++++++++++++++++++++++----
> 2 files changed, 44 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/loop-unroll.cc b/gcc/loop-unroll.cc
> index 4176a21e308..bfdfe6c2bb7 100644
> --- a/gcc/loop-unroll.cc
> +++ b/gcc/loop-unroll.cc
> @@ -1855,7 +1855,7 @@ insert_var_expansion_initialization (struct var_to_expand *ve,
> rtx var, zero_init;
> unsigned i;
> machine_mode mode = GET_MODE (ve->reg);
> - bool honor_signed_zero_p = HONOR_SIGNED_ZEROS (mode);
> + bool has_signed_zero_p = MODE_HAS_SIGNED_ZEROS (mode);
>
> if (ve->var_expansions.length () == 0)
> return;
> @@ -1869,7 +1869,7 @@ insert_var_expansion_initialization (struct var_to_expand *ve,
> case MINUS:
> FOR_EACH_VEC_ELT (ve->var_expansions, i, var)
> {
> - if (honor_signed_zero_p)
> + if (has_signed_zero_p)
> zero_init = simplify_gen_unary (NEG, mode, CONST0_RTX (mode), mode);
> else
> zero_init = CONST0_RTX (mode);
This change is OK.
> diff --git a/gcc/testsuite/gcc.dg/pr30957-1.c b/gcc/testsuite/gcc.dg/pr30957-1.c
> index 564410913ab..6a9d3d87932 100644
> --- a/gcc/testsuite/gcc.dg/pr30957-1.c
> +++ b/gcc/testsuite/gcc.dg/pr30957-1.c
> @@ -20,16 +20,52 @@ foo (float d, int n)
> return accum;
> }
>
> +float __attribute__((noinline))
> +get_minus_zero()
> +{
> + return 0.0 / -5.0;
> +}
> +
I still think this test shouldn't use -fno-signed-zeros since that makes it
undefined whether the return value is positive or negative - checking
whether get_minus_zero returns negative or positive zero isn't a
good indicator and prone to break.
We have a { dg-add-options ieee } we'd need.
The original testcase indicates variable expansion wouldn't trigger then,
and in the PR it's noted we should remove this broken testcase and the
PR itself is invalid.
I agree there.
So, can you remove the testcase instead?
Thanks,
Richard.
> int
> main ()
> {
> - /* When compiling standard compliant we expect foo to return -0.0. But the
> - variable expansion during unrolling optimization (for this testcase enabled
> - by non-compliant -fassociative-math) instantiates copy(s) of the
> - accumulator which it initializes with +0.0. Hence we expect that foo
> - returns +0.0. */
> - if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != 1.0)
> + /* The variable expansion in unroll requires option unsafe-math-optimizations
> + (aka -fno-signed-zeros, -fno-trapping-math, -fassociative-math
> + and -freciprocal-math).
> +
> + When loop like above will have expansion after unrolling as below:
> +
> + accum_1 += d_1;
> + accum_2 += d_2;
> + accum_3 += d_3;
> + ...
> +
> + The accum_1, accum_2 and accum_3 need to be initialized. Given the
> + floating-point we have
> + +0.0f + -0.0f = +0.0f.
> +
> + Thus, we should initialize the accum_* to -0.0 for correctness. But
> + the things become more complicated when no-signed-zeros, as well as VLA
> + vectorizer mode which doesn't trigger variable expansion. Then we have:
> +
> + Case 1: Trigger variable expansion but target doesn't honor no-signed-zero.
> + minus_zero will be -0.0f and foo (minus_zero, 10) will be -0.0f.
> + Case 2: Trigger variable expansion but target does honor no-signed-zero.
> + minus_zero will be +0.0f and foo (minus_zero, 10) will be +0.0f.
> + Case 3: No variable expansion but target doesn't honor no-signed-zero.
> + minus_zero will be -0.0f and foo (minus_zero, 10) will be -0.0f.
> + Case 4: No variable expansion but target does honor no-signed-zero.
> + minus_zero will be +0.0f and foo (minus_zero, 10) will be +0.0f.
> +
> + The test case covers above 4 cases for running.
> + */
> + float minus_zero = get_minus_zero ();
> + float a = __builtin_copysignf (1.0, minus_zero);
> + float b = __builtin_copysignf (1.0, foo (minus_zero, 10));
> +
> + if (a != b)
> abort ();
> +
> exit (0);
> }
>
> --
> 2.34.1
>
@@ -1855,7 +1855,7 @@ insert_var_expansion_initialization (struct var_to_expand *ve,
rtx var, zero_init;
unsigned i;
machine_mode mode = GET_MODE (ve->reg);
- bool honor_signed_zero_p = HONOR_SIGNED_ZEROS (mode);
+ bool has_signed_zero_p = MODE_HAS_SIGNED_ZEROS (mode);
if (ve->var_expansions.length () == 0)
return;
@@ -1869,7 +1869,7 @@ insert_var_expansion_initialization (struct var_to_expand *ve,
case MINUS:
FOR_EACH_VEC_ELT (ve->var_expansions, i, var)
{
- if (honor_signed_zero_p)
+ if (has_signed_zero_p)
zero_init = simplify_gen_unary (NEG, mode, CONST0_RTX (mode), mode);
else
zero_init = CONST0_RTX (mode);
@@ -20,16 +20,52 @@ foo (float d, int n)
return accum;
}
+float __attribute__((noinline))
+get_minus_zero()
+{
+ return 0.0 / -5.0;
+}
+
int
main ()
{
- /* When compiling standard compliant we expect foo to return -0.0. But the
- variable expansion during unrolling optimization (for this testcase enabled
- by non-compliant -fassociative-math) instantiates copy(s) of the
- accumulator which it initializes with +0.0. Hence we expect that foo
- returns +0.0. */
- if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != 1.0)
+ /* The variable expansion in unroll requires option unsafe-math-optimizations
+ (aka -fno-signed-zeros, -fno-trapping-math, -fassociative-math
+ and -freciprocal-math).
+
+ When loop like above will have expansion after unrolling as below:
+
+ accum_1 += d_1;
+ accum_2 += d_2;
+ accum_3 += d_3;
+ ...
+
+ The accum_1, accum_2 and accum_3 need to be initialized. Given the
+ floating-point we have
+ +0.0f + -0.0f = +0.0f.
+
+ Thus, we should initialize the accum_* to -0.0 for correctness. But
+ the things become more complicated when no-signed-zeros, as well as VLA
+ vectorizer mode which doesn't trigger variable expansion. Then we have:
+
+ Case 1: Trigger variable expansion but target doesn't honor no-signed-zero.
+ minus_zero will be -0.0f and foo (minus_zero, 10) will be -0.0f.
+ Case 2: Trigger variable expansion but target does honor no-signed-zero.
+ minus_zero will be +0.0f and foo (minus_zero, 10) will be +0.0f.
+ Case 3: No variable expansion but target doesn't honor no-signed-zero.
+ minus_zero will be -0.0f and foo (minus_zero, 10) will be -0.0f.
+ Case 4: No variable expansion but target does honor no-signed-zero.
+ minus_zero will be +0.0f and foo (minus_zero, 10) will be +0.0f.
+
+ The test case covers above 4 cases for running.
+ */
+ float minus_zero = get_minus_zero ();
+ float a = __builtin_copysignf (1.0, minus_zero);
+ float b = __builtin_copysignf (1.0, foo (minus_zero, 10));
+
+ if (a != b)
abort ();
+
exit (0);
}