diff mbox series

LoongArch: Increase division costs

Message ID 20240326095005.141804-1-xry111@xry111.site
State New
Headers
Series LoongArch: Increase division costs |

Commit Message

Xi Ruoyao March 26, 2024, 9:48 a.m. UTC 
  The latency of LA464 and LA664 division instructions depends on the
input.  When I updated the costs in r14-6642, I unintentionally set the
division costs to the best-case latency (when the first operand is 0).
Per a recent discussion [1] we should use "something sensible" instead
of it.

Use the average of the minimum and maximum latency observed instead.
This enables multiplication to reciprocal sequence reduction and speeds
up the following test case for about 30%:

    int
    main (void)
    {
      unsigned long stat = 0xdeadbeef;
      for (int i = 0; i < 100000000; i++)
        stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
      asm(""::"r"(stat));
    }

[1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html

gcc/ChangeLog:

	* config/loongarch/loongarch-def.cc
	(loongarch_rtx_cost_data::loongarch_rtx_cost_data): Increase
	default division cost to the average of the best case and worst
	case senarios observed.

gcc/testsuite/ChangeLog:

	* gcc.target/loongarch/div-const-reduction.c: New test.
---

Bootstrapped and regtested on loongarch64-linux-gnu.  Ok for trunk?

 gcc/config/loongarch/loongarch-def.cc                    | 8 ++++----
 gcc/testsuite/gcc.target/loongarch/div-const-reduction.c | 9 +++++++++
 2 files changed, 13 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/div-const-reduction.c

Comments

Lulu Cheng March 27, 2024, 2:38 a.m. UTC | #1 
在 2024/3/26 下午5:48, Xi Ruoyao 写道:
> The latency of LA464 and LA664 division instructions depends on the
> input.  When I updated the costs in r14-6642, I unintentionally set the
> division costs to the best-case latency (when the first operand is 0).
> Per a recent discussion [1] we should use "something sensible" instead
> of it.
>
> Use the average of the minimum and maximum latency observed instead.
> This enables multiplication to reciprocal sequence reduction and speeds
> up the following test case for about 30%:
>
>      int
>      main (void)
>      {
>        unsigned long stat = 0xdeadbeef;
>        for (int i = 0; i < 100000000; i++)
>          stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
>        asm(""::"r"(stat));
>      }
>
> [1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html

The test case div-const-reduction.c is modified to assemble the instruction
sequence as follows:
	lu12i.w	$r12,999997440>>12			# 0x3b9ac000
	ori	$r12,$r12,2567
	mod.w	$r13,$r13,$r12

This sequence of instructions takes 5 clock cycles.



The sequence of instructions after adding the patch is:
	lu12i.w	$r15,1152917504>>12			# 0x44b82000
	ori	$r15,$r15,3993
	mulh.w	$r12,$r16,$r15
	srai.w	$r14,$r16,31
	lu12i.w	$r13,999997440>>12			# 0x3b9ac000
	ori	$r13,$r13,2567
	srai.w	$r12,$r12,28
	sub.w	$r12,$r12,$r14
	mul.w	$r12,$r12,$r13
	sub.w	$r16,$r16,$r12
This sequence of instructions takes 11 clock cycles.

This test case is optimized and takes 6 more clock cycles than before optimization,
so I need to run the spec.

Thanks!

> gcc/ChangeLog:
>
> 	* config/loongarch/loongarch-def.cc
> 	(loongarch_rtx_cost_data::loongarch_rtx_cost_data): Increase
> 	default division cost to the average of the best case and worst
> 	case senarios observed.
>
> gcc/testsuite/ChangeLog:
>
> 	* gcc.target/loongarch/div-const-reduction.c: New test.
> ---
>
> Bootstrapped and regtested on loongarch64-linux-gnu.  Ok for trunk?
>
>   gcc/config/loongarch/loongarch-def.cc                    | 8 ++++----
>   gcc/testsuite/gcc.target/loongarch/div-const-reduction.c | 9 +++++++++
>   2 files changed, 13 insertions(+), 4 deletions(-)
>   create mode 100644 gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
>
> diff --git a/gcc/config/loongarch/loongarch-def.cc b/gcc/config/loongarch/loongarch-def.cc
> index e8c129ce643..93e72a520d5 100644
> --- a/gcc/config/loongarch/loongarch-def.cc
> +++ b/gcc/config/loongarch/loongarch-def.cc
> @@ -95,12 +95,12 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
>     : fp_add (COSTS_N_INSNS (5)),
>       fp_mult_sf (COSTS_N_INSNS (5)),
>       fp_mult_df (COSTS_N_INSNS (5)),
> -    fp_div_sf (COSTS_N_INSNS (8)),
> -    fp_div_df (COSTS_N_INSNS (8)),
> +    fp_div_sf (COSTS_N_INSNS (12)),
> +    fp_div_df (COSTS_N_INSNS (15)),
>       int_mult_si (COSTS_N_INSNS (4)),
>       int_mult_di (COSTS_N_INSNS (4)),
> -    int_div_si (COSTS_N_INSNS (5)),
> -    int_div_di (COSTS_N_INSNS (5)),
> +    int_div_si (COSTS_N_INSNS (14)),
> +    int_div_di (COSTS_N_INSNS (22)),
>       movcf2gr (COSTS_N_INSNS (7)),
>       movgr2cf (COSTS_N_INSNS (15)),
>       branch_cost (6),
> diff --git a/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
> new file mode 100644
> index 00000000000..0ee86410dd7
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mtune=la464" } */
> +/* { dg-final { scan-assembler-not "div\.\[dw\]" } } */
> +
> +int
> +test (int a)
> +{
> +  return a % 1000000007;
> +}
Richard Biener March 27, 2024, 7:54 a.m. UTC | #2 
On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao <xry111@xry111.site> wrote:
>
> The latency of LA464 and LA664 division instructions depends on the
> input.  When I updated the costs in r14-6642, I unintentionally set the
> division costs to the best-case latency (when the first operand is 0).
> Per a recent discussion [1] we should use "something sensible" instead
> of it.
>
> Use the average of the minimum and maximum latency observed instead.
> This enables multiplication to reciprocal sequence reduction and speeds
> up the following test case for about 30%:
>
>     int
>     main (void)
>     {
>       unsigned long stat = 0xdeadbeef;
>       for (int i = 0; i < 100000000; i++)
>         stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
>       asm(""::"r"(stat));
>     }

I think you should be able to see a constant divisor and thus could do
better than return the same latency for everything.  For non-constant
divisors using the best-case latency shouldn't be a problem.

> [1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html
>
> gcc/ChangeLog:
>
>         * config/loongarch/loongarch-def.cc
>         (loongarch_rtx_cost_data::loongarch_rtx_cost_data): Increase
>         default division cost to the average of the best case and worst
>         case senarios observed.
>
> gcc/testsuite/ChangeLog:
>
>         * gcc.target/loongarch/div-const-reduction.c: New test.
> ---
>
> Bootstrapped and regtested on loongarch64-linux-gnu.  Ok for trunk?
>
>  gcc/config/loongarch/loongarch-def.cc                    | 8 ++++----
>  gcc/testsuite/gcc.target/loongarch/div-const-reduction.c | 9 +++++++++
>  2 files changed, 13 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
>
> diff --git a/gcc/config/loongarch/loongarch-def.cc b/gcc/config/loongarch/loongarch-def.cc
> index e8c129ce643..93e72a520d5 100644
> --- a/gcc/config/loongarch/loongarch-def.cc
> +++ b/gcc/config/loongarch/loongarch-def.cc
> @@ -95,12 +95,12 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
>    : fp_add (COSTS_N_INSNS (5)),
>      fp_mult_sf (COSTS_N_INSNS (5)),
>      fp_mult_df (COSTS_N_INSNS (5)),
> -    fp_div_sf (COSTS_N_INSNS (8)),
> -    fp_div_df (COSTS_N_INSNS (8)),
> +    fp_div_sf (COSTS_N_INSNS (12)),
> +    fp_div_df (COSTS_N_INSNS (15)),
>      int_mult_si (COSTS_N_INSNS (4)),
>      int_mult_di (COSTS_N_INSNS (4)),
> -    int_div_si (COSTS_N_INSNS (5)),
> -    int_div_di (COSTS_N_INSNS (5)),
> +    int_div_si (COSTS_N_INSNS (14)),
> +    int_div_di (COSTS_N_INSNS (22)),
>      movcf2gr (COSTS_N_INSNS (7)),
>      movgr2cf (COSTS_N_INSNS (15)),
>      branch_cost (6),
> diff --git a/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
> new file mode 100644
> index 00000000000..0ee86410dd7
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mtune=la464" } */
> +/* { dg-final { scan-assembler-not "div\.\[dw\]" } } */
> +
> +int
> +test (int a)
> +{
> +  return a % 1000000007;
> +}
> --
> 2.44.0
>
Xi Ruoyao March 27, 2024, 10:39 a.m. UTC | #3 
On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
> 
> 在 2024/3/26 下午5:48, Xi Ruoyao 写道:
> > The latency of LA464 and LA664 division instructions depends on the
> > input.  When I updated the costs in r14-6642, I unintentionally set the
> > division costs to the best-case latency (when the first operand is 0).
> > Per a recent discussion [1] we should use "something sensible" instead
> > of it.
> > 
> > Use the average of the minimum and maximum latency observed instead.
> > This enables multiplication to reciprocal sequence reduction and speeds
> > up the following test case for about 30%:
> > 
> >      int
> >      main (void)
> >      {
> >        unsigned long stat = 0xdeadbeef;
> >        for (int i = 0; i < 100000000; i++)
> >          stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
> >        asm(""::"r"(stat));
> >      }
> > 
> > [1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html
> 
> The test case div-const-reduction.c is modified to assemble the instruction
> sequence as follows:
> 	lu12i.w	$r12,999997440>>12			# 0x3b9ac000
> 	ori	$r12,$r12,2567
> 	mod.w	$r13,$r13,$r12
> 
> This sequence of instructions takes 5 clock cycles.

Hmm indeed, it seems a waste to do this reduction for int / 1000000007.
I'll try to make a better heuristic as Richard suggests...
Xi Ruoyao March 27, 2024, 12:20 p.m. UTC | #4 
On Wed, 2024-03-27 at 08:54 +0100, Richard Biener wrote:
> On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao <xry111@xry111.site> wrote:
> > 
> > The latency of LA464 and LA664 division instructions depends on the
> > input.  When I updated the costs in r14-6642, I unintentionally set the
> > division costs to the best-case latency (when the first operand is 0).
> > Per a recent discussion [1] we should use "something sensible" instead
> > of it.
> > 
> > Use the average of the minimum and maximum latency observed instead.
> > This enables multiplication to reciprocal sequence reduction and speeds
> > up the following test case for about 30%:
> > 
> >     int
> >     main (void)
> >     {
> >       unsigned long stat = 0xdeadbeef;
> >       for (int i = 0; i < 100000000; i++)
> >         stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
> >       asm(""::"r"(stat));
> >     }
> 
> I think you should be able to see a constant divisor and thus could do
> better than return the same latency for everything.  For non-constant
> divisors using the best-case latency shouldn't be a problem.

Hmm, it seems not really possible as at now.  expand_divmod does
something like:

  max_cost = (unsignedp
          ? udiv_cost (speed, compute_mode)
          : sdiv_cost (speed, compute_mode));

which is reading the pre-calculated costs from a table.  Thus we don't
really know the denominator and cannot estimate the cost based on it :(.

CSE really invokes the cost hook with the actual (mod (a, (const_int
1000000007)) RTX but it's less important.
Richard Biener March 27, 2024, 12:28 p.m. UTC | #5 
On Wed, Mar 27, 2024 at 1:20 PM Xi Ruoyao <xry111@xry111.site> wrote:
>
> On Wed, 2024-03-27 at 08:54 +0100, Richard Biener wrote:
> > On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao <xry111@xry111.site> wrote:
> > >
> > > The latency of LA464 and LA664 division instructions depends on the
> > > input.  When I updated the costs in r14-6642, I unintentionally set the
> > > division costs to the best-case latency (when the first operand is 0).
> > > Per a recent discussion [1] we should use "something sensible" instead
> > > of it.
> > >
> > > Use the average of the minimum and maximum latency observed instead.
> > > This enables multiplication to reciprocal sequence reduction and speeds
> > > up the following test case for about 30%:
> > >
> > >     int
> > >     main (void)
> > >     {
> > >       unsigned long stat = 0xdeadbeef;
> > >       for (int i = 0; i < 100000000; i++)
> > >         stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
> > >       asm(""::"r"(stat));
> > >     }
> >
> > I think you should be able to see a constant divisor and thus could do
> > better than return the same latency for everything.  For non-constant
> > divisors using the best-case latency shouldn't be a problem.
>
> Hmm, it seems not really possible as at now.  expand_divmod does
> something like:
>
>   max_cost = (unsignedp
>           ? udiv_cost (speed, compute_mode)
>           : sdiv_cost (speed, compute_mode));
>
> which is reading the pre-calculated costs from a table.  Thus we don't
> really know the denominator and cannot estimate the cost based on it :(.

Ah, too bad.  OTOH for the actual case it decomposes it could compute
the real cost, avoiding the table which is filled with reg-reg operations only.

> CSE really invokes the cost hook with the actual (mod (a, (const_int
> 1000000007)) RTX but it's less important.
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
Xi Ruoyao March 27, 2024, 12:42 p.m. UTC | #6 
On Wed, 2024-03-27 at 18:39 +0800, Xi Ruoyao wrote:
> On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
> > 
> > 在 2024/3/26 下午5:48, Xi Ruoyao 写道:
> > > The latency of LA464 and LA664 division instructions depends on the
> > > input.  When I updated the costs in r14-6642, I unintentionally set the
> > > division costs to the best-case latency (when the first operand is 0).
> > > Per a recent discussion [1] we should use "something sensible" instead
> > > of it.
> > > 
> > > Use the average of the minimum and maximum latency observed instead.
> > > This enables multiplication to reciprocal sequence reduction and speeds
> > > up the following test case for about 30%:
> > > 
> > >      int
> > >      main (void)
> > >      {
> > >        unsigned long stat = 0xdeadbeef;
> > >        for (int i = 0; i < 100000000; i++)
> > >          stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
> > >        asm(""::"r"(stat));
> > >      }
> > > 
> > > [1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html
> > 
> > The test case div-const-reduction.c is modified to assemble the instruction
> > sequence as follows:
> > 	lu12i.w	$r12,999997440>>12			# 0x3b9ac000
> > 	ori	$r12,$r12,2567
> > 	mod.w	$r13,$r13,$r12
> > 
> > This sequence of instructions takes 5 clock cycles.

It actually may take 5 to 8 cycles depending on the input.  And
multiplication is fully pipelined while division is not, so the
reciprocal sequence should still produce a better throughput.

> Hmm indeed, it seems a waste to do this reduction for int / 1000000007.
> I'll try to make a better heuristic as Richard suggests...

Oops, it seems impossible (w/o refactoring the generic code).  See my
reply to Richi :(.

Can you also try benchmarking with the costs of SI and DI division
increased to (10, 10) instead of (14, 22) - allowing more CSE but not
reciprocal sequence reduction, and (10, 22) - only allowing reduction
for DI but not SI?
Lulu Cheng March 28, 2024, 3:18 a.m. UTC | #7 
在 2024/3/27 下午8:42, Xi Ruoyao 写道:
> On Wed, 2024-03-27 at 18:39 +0800, Xi Ruoyao wrote:
>> On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
>>> 在 2024/3/26 下午5:48, Xi Ruoyao 写道:
>>>> The latency of LA464 and LA664 division instructions depends on the
>>>> input.  When I updated the costs in r14-6642, I unintentionally set the
>>>> division costs to the best-case latency (when the first operand is 0).
>>>> Per a recent discussion [1] we should use "something sensible" instead
>>>> of it.
>>>>
>>>> Use the average of the minimum and maximum latency observed instead.
>>>> This enables multiplication to reciprocal sequence reduction and speeds
>>>> up the following test case for about 30%:
>>>>
>>>>       int
>>>>       main (void)
>>>>       {
>>>>         unsigned long stat = 0xdeadbeef;
>>>>         for (int i = 0; i < 100000000; i++)
>>>>           stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
>>>>         asm(""::"r"(stat));
>>>>       }
>>>>
>>>> [1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html
>>> The test case div-const-reduction.c is modified to assemble the instruction
>>> sequence as follows:
>>> 	lu12i.w	$r12,999997440>>12			# 0x3b9ac000
>>> 	ori	$r12,$r12,2567
>>> 	mod.w	$r13,$r13,$r12
>>>
>>> This sequence of instructions takes 5 clock cycles.
> It actually may take 5 to 8 cycles depending on the input.  And
> multiplication is fully pipelined while division is not, so the
> reciprocal sequence should still produce a better throughput.
>
>> Hmm indeed, it seems a waste to do this reduction for int / 1000000007.
>> I'll try to make a better heuristic as Richard suggests...
> Oops, it seems impossible (w/o refactoring the generic code).  See my
> reply to Richi :(.
>
> Can you also try benchmarking with the costs of SI and DI division
> increased to (10, 10) instead of (14, 22) - allowing more CSE but not
> reciprocal sequence reduction, and (10, 22) - only allowing reduction
> for DI but not SI?
No problem, I'll test both cases ((10,10) and (10,22)).
Lulu Cheng March 29, 2024, 1:23 a.m. UTC | #8 
在 2024/3/27 下午8:42, Xi Ruoyao 写道:
> On Wed, 2024-03-27 at 18:39 +0800, Xi Ruoyao wrote:
>> On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
>>> 在 2024/3/26 下午5:48, Xi Ruoyao 写道:
>>>> The latency of LA464 and LA664 division instructions depends on the
>>>> input.  When I updated the costs in r14-6642, I unintentionally set the
>>>> division costs to the best-case latency (when the first operand is 0).
>>>> Per a recent discussion [1] we should use "something sensible" instead
>>>> of it.
>>>>
>>>> Use the average of the minimum and maximum latency observed instead.
>>>> This enables multiplication to reciprocal sequence reduction and speeds
>>>> up the following test case for about 30%:
>>>>
>>>>       int
>>>>       main (void)
>>>>       {
>>>>         unsigned long stat = 0xdeadbeef;
>>>>         for (int i = 0; i < 100000000; i++)
>>>>           stat = (stat * stat + stat * 114514 + 1919810) % 1000000007;
>>>>         asm(""::"r"(stat));
>>>>       }
>>>>
>>>> [1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html
>>> The test case div-const-reduction.c is modified to assemble the instruction
>>> sequence as follows:
>>> 	lu12i.w	$r12,999997440>>12			# 0x3b9ac000
>>> 	ori	$r12,$r12,2567
>>> 	mod.w	$r13,$r13,$r12
>>>
>>> This sequence of instructions takes 5 clock cycles.
> It actually may take 5 to 8 cycles depending on the input.  And
> multiplication is fully pipelined while division is not, so the
> reciprocal sequence should still produce a better throughput.
>
>> Hmm indeed, it seems a waste to do this reduction for int / 1000000007.
>> I'll try to make a better heuristic as Richard suggests...
> Oops, it seems impossible (w/o refactoring the generic code).  See my
> reply to Richi :(.
>
> Can you also try benchmarking with the costs of SI and DI division
> increased to (10, 10) instead of (14, 22) - allowing more CSE but not
> reciprocal sequence reduction, and (10, 22) - only allowing reduction
> for DI but not SI?

I tested spec2006. In the floating-point program, the test items with large

fluctuations are removed, and the rest is basically unchanged.

The fixed-point 464.h264ref (10,10) was 6.7% higher than (5,5) and (10,22).
Xi Ruoyao April 1, 2024, 1:29 a.m. UTC | #9 
On Fri, 2024-03-29 at 09:23 +0800, chenglulu wrote:

> I tested spec2006. In the floating-point program, the test items with large
> 
> fluctuations are removed, and the rest is basically unchanged.
> 
> The fixed-point 464.h264ref (10,10) was 6.7% higher than (5,5) and (10,22).

So IIUC (10,10) is better than (5,5), (10,22), and the originally
proposed (14,22)?  Then should I make a change to make all 4 costs (SF,
DF, SI, DI) 10?

I'd still want DI % 1000000007 to be reduced as reciprocal sequence (but
not SI % 1000000007) since DI % (smaller const) is quite important for
some workloads like competitive programming.  However "adapting with
different modulos" is not possible w/o refactoring generic code so it
must be deferred to at least GCC 15.
Lulu Cheng April 1, 2024, 2:22 a.m. UTC | #10 
在 2024/4/1 上午9:29, Xi Ruoyao 写道:
> On Fri, 2024-03-29 at 09:23 +0800, chenglulu wrote:
>
>> I tested spec2006. In the floating-point program, the test items with large
>>
>> fluctuations are removed, and the rest is basically unchanged.
>>
>> The fixed-point 464.h264ref (10,10) was 6.7% higher than (5,5) and (10,22).
> So IIUC (10,10) is better than (5,5), (10,22), and the originally
> proposed (14,22)?  Then should I make a change to make all 4 costs (SF,
> DF, SI, DI) 10?

I think this may require the analysis of the spec's test case. I took a 
look at the test results again,

where the scores of SPEC INT 462.libquantum fluctuated greatly, but the 
combination of (10,22)

showed an overall upward trend compared to the scores of the other two 
combinations.

I don't know if (10,22) this combination happens to have the kind of 
test cases in the changelog.

So can we change it together in GCC15?

>
> I'd still want DI % 1000000007 to be reduced as reciprocal sequence (but
> not SI % 1000000007) since DI % (smaller const) is quite important for
> some workloads like competitive programming.  However "adapting with
> different modulos" is not possible w/o refactoring generic code so it
> must be deferred to at least GCC 15.
>
Xi Ruoyao April 1, 2024, 2:23 a.m. UTC | #11 
On Mon, 2024-04-01 at 10:22 +0800, chenglulu wrote:
> 
> 在 2024/4/1 上午9:29, Xi Ruoyao 写道:
> > On Fri, 2024-03-29 at 09:23 +0800, chenglulu wrote:
> > 
> > > I tested spec2006. In the floating-point program, the test items with large
> > > 
> > > fluctuations are removed, and the rest is basically unchanged.
> > > 
> > > The fixed-point 464.h264ref (10,10) was 6.7% higher than (5,5) and (10,22).
> > So IIUC (10,10) is better than (5,5), (10,22), and the originally
> > proposed (14,22)?  Then should I make a change to make all 4 costs (SF,
> > DF, SI, DI) 10?
> 
> I think this may require the analysis of the spec's test case. I took a 
> look at the test results again,
> 
> where the scores of SPEC INT 462.libquantum fluctuated greatly, but the 
> combination of (10,22)
> 
> showed an overall upward trend compared to the scores of the other two
> combinations.
> 
> I don't know if (10,22) this combination happens to have the kind of 
> test cases in the changelog.
> 
> So can we change it together in GCC15?

Ok.  Abandoning this patch then.
diff mbox series

Patch

diff --git a/gcc/config/loongarch/loongarch-def.cc b/gcc/config/loongarch/loongarch-def.cc
index e8c129ce643..93e72a520d5 100644
--- a/gcc/config/loongarch/loongarch-def.cc
+++ b/gcc/config/loongarch/loongarch-def.cc
@@ -95,12 +95,12 @@  loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
   : fp_add (COSTS_N_INSNS (5)),
     fp_mult_sf (COSTS_N_INSNS (5)),
     fp_mult_df (COSTS_N_INSNS (5)),
-    fp_div_sf (COSTS_N_INSNS (8)),
-    fp_div_df (COSTS_N_INSNS (8)),
+    fp_div_sf (COSTS_N_INSNS (12)),
+    fp_div_df (COSTS_N_INSNS (15)),
     int_mult_si (COSTS_N_INSNS (4)),
     int_mult_di (COSTS_N_INSNS (4)),
-    int_div_si (COSTS_N_INSNS (5)),
-    int_div_di (COSTS_N_INSNS (5)),
+    int_div_si (COSTS_N_INSNS (14)),
+    int_div_di (COSTS_N_INSNS (22)),
     movcf2gr (COSTS_N_INSNS (7)),
     movgr2cf (COSTS_N_INSNS (15)),
     branch_cost (6),
diff --git a/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
new file mode 100644
index 00000000000..0ee86410dd7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
@@ -0,0 +1,9 @@ 
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=la464" } */
+/* { dg-final { scan-assembler-not "div\.\[dw\]" } } */
+
+int
+test (int a)
+{
+  return a % 1000000007;
+}