Thanks Richard, will delete the test case pr30957-1.c in patch V5.
Pan
-----Original Message-----
From: Richard Biener <richard.guent...@gmail.com>
Sent: Thursday, January 11, 2024 4:33 PM
To: Li, Pan2 <pan2...@intel.com>
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
<yanzhang.w...@intel.com>; kito.ch...@gmail.com; jeffreya...@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...@intel.com> wrote:
>
> From: Pan Li <pan2...@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...@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
>
