Re: [pushed][PATCH v4] LoongArch: Optimize immediate load.

2022-11-27 Thread Lulu Cheng

Pushed r13-4315.

在 2022/11/23 上午12:44, Xi Ruoyao 写道:

On Tue, 2022-11-22 at 22:03 +0800, Xi Ruoyao via Gcc-patches wrote:

While I still can't fully understand the immediate load issue and how
this patch fix it, I've tested this patch (alongside the prefetch
instruction patch) with bootstrap-ubsan.  And the compiled result of
imm-load1.c seems OK.

And it's doing correct thing for Glibc "improved generic string
functions" patch, producing some really tight loop now.


On Thu, 2022-11-17 at 17:59 +0800, Lulu Cheng wrote:

v1 -> v2:
1. Change the code format.
2. Fix bugs in the code.

v2 -> v3:
Modifying a code implementation of an undefined behavior.

v3 -> v4:
Move the part of the immediate number decomposition from expand pass
to split
pass.

Both regression tests and spec2006 passed.

The problem mentioned in the link does not move the four immediate
load
instructions out of the loop. It has been optimized. Now, as in the
test case,
four immediate load instructions are generated outside the loop.
(
https://sourceware.org/pipermail/libc-alpha/2022-September/142202.html
)


Because loop2_invariant pass will extract the instructions that do
not
change
in the loop out of the loop, some instructions will not meet the
extraction
conditions if the machine performs immediate decomposition while
expand pass,
so the immediate decomposition will be transferred to the split
process.

gcc/ChangeLog:

 * config/loongarch/loongarch.cc (enum
loongarch_load_imm_method):
 Remove the member METHOD_INSV that is not currently used.
 (struct loongarch_integer_op): Define a new member
curr_value,
 that records the value of the number stored in the
destination
 register immediately after the current instruction has run.
 (loongarch_build_integer): Assign a value to the curr_value
member variable.
 (loongarch_move_integer): Adds information for the immediate
load instruction.
 * config/loongarch/loongarch.md (*movdi_32bit): Redefine as
define_insn_and_split.
 (*movdi_64bit): Likewise.
 (*movsi_internal): Likewise.
 (*movhi_internal): Likewise.
 * config/loongarch/predicates.md: Return true as long as it
is
CONST_INT, ensure
 that the immediate number is not optimized by decomposition
during expand
 optimization loop.

gcc/testsuite/ChangeLog:

 * gcc.target/loongarch/imm-load.c: New test.
 * gcc.target/loongarch/imm-load1.c: New test.
---
  gcc/config/loongarch/loongarch.cc | 62 ++--
--
-
  gcc/config/loongarch/loongarch.md | 44 +++--
  gcc/config/loongarch/predicates.md    |  2 +-
  gcc/testsuite/gcc.target/loongarch/imm-load.c | 10 +++
  .../gcc.target/loongarch/imm-load1.c  | 26 
  5 files changed, 110 insertions(+), 34 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/loongarch/imm-load.c
  create mode 100644 gcc/testsuite/gcc.target/loongarch/imm-load1.c

diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 8ee32c90573..9e0d6c7c3ea 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -139,22 +139,21 @@ struct loongarch_address_info
  
     METHOD_LU52I:

   Load 52-63 bit of the immediate number.
-
-   METHOD_INSV:
- immediate like 0xfff0fxxx
-   */
+*/
  enum loongarch_load_imm_method
  {
    METHOD_NORMAL,
    METHOD_LU32I,
-  METHOD_LU52I,
-  METHOD_INSV
+  METHOD_LU52I
  };
  
  struct loongarch_integer_op

  {
    enum rtx_code code;
    HOST_WIDE_INT value;
+  /* Represent the result of the immediate count of the load
instruction at
+ each step.  */
+  HOST_WIDE_INT curr_value;
    enum loongarch_load_imm_method method;
  };
  
@@ -1475,24 +1474,27 @@ loongarch_build_integer (struct

loongarch_integer_op *codes,
  {
    /* The value of the lower 32 bit be loaded with one
instruction.
  lu12i.w.  */
-  codes[0].code = UNKNOWN;
-  codes[0].method = METHOD_NORMAL;
-  codes[0].value = low_part;
+  codes[cost].code = UNKNOWN;
+  codes[cost].method = METHOD_NORMAL;
+  codes[cost].value = low_part;
+  codes[cost].curr_value = low_part;
    cost++;
  }
    else
  {
    /* lu12i.w + ior.  */
-  codes[0].code = UNKNOWN;
-  codes[0].method = METHOD_NORMAL;
-  codes[0].value = low_part & ~(IMM_REACH - 1);
+  codes[cost].code = UNKNOWN;
+  codes[cost].method = METHOD_NORMAL;
+  codes[cost].value = low_part & ~(IMM_REACH - 1);
+  codes[cost].curr_value = codes[cost].value;
    cost++;
    HOST_WIDE_INT iorv = low_part & (IMM_REACH - 1);
    if (iorv != 0)
 {
- codes[1].code = IOR;
- codes[1].method = METHOD_NORMAL;
- codes[1].value = iorv;
+ codes[cost].code = IOR;
+ codes[cost].method = METHOD_NORMAL;
+ 

Re: [PATCH v4] LoongArch: Optimize immediate load.

2022-11-22 Thread chenglulu



在 2022/11/23 00:44, Xi Ruoyao 写道:

While I still can't fully understand the immediate load issue and how
this patch fix it, I've tested this patch (alongside the prefetch
instruction patch) with bootstrap-ubsan.  And the compiled result of
imm-load1.c seems OK.

And it's doing correct thing for Glibc "improved generic string
functions" patch, producing some really tight loop now.

In the process of debugging, I found this,bringing the immediate number 
load instruction out of the loop is done in loop2_invariant optimization.


One of the conditions for extraction is that the destination register 
cannot be used more than once, and the sequence before it was modified 
was like this:


(insn 12 11 13 3 (set (reg:DI 90)
    (const_int 16842752 [0x101])) "test.c":13:12 discrim 1 131 
{*movdi_64bit}

 (nil))
(insn 13 12 14 3 (set (reg:DI 91)
    (ior:DI (reg:DI 90)
    (const_int 257 [0x101]))) "test.c":13:12 discrim 1 88 {iordi3}
 (expr_list:REG_DEAD (reg:DI 90)
    (expr_list:REG_EQUAL (const_int 16843009 [0x1010101])
    (nil

(insn 14 13 15 3 (set (reg:DI 91)
    (ior:DI (zero_extend:DI (subreg:SI (reg:DI 91) 0))
    (const_int 282578783305728 [0x10101]))) 
"test.c":13:12 discrim 1 150 {lu32i_d}

 (expr_list:REG_EQUAL (const_int 282578800148737 [0x1010101010101])
    (nil)))
(insn 15 14 17 3 (set (reg:DI 91)
    (ior:DI (and:DI (reg:DI 91)
    (const_int 4503599627370495 [0xf]))
    (const_int 72057594037927936 [0x100]))) 
"test.c":13:12 discrim 1 151 {lu52i_d}

 (expr_list:REG_EQUAL (const_int 72340172838076673 [0x101010101010101])
    (nil)))

Therefore, the last two instructions do not meet the extraction conditions.

But because of the implementation of our instructions, I freed myself up 
immediately to do it loop2_invariant later, so I avoided this problem.




Re: [PATCH v4] LoongArch: Optimize immediate load.

2022-11-22 Thread Xi Ruoyao via Gcc-patches
On Tue, 2022-11-22 at 22:03 +0800, Xi Ruoyao via Gcc-patches wrote:
> While I still can't fully understand the immediate load issue and how
> this patch fix it, I've tested this patch (alongside the prefetch
> instruction patch) with bootstrap-ubsan.  And the compiled result of
> imm-load1.c seems OK.

And it's doing correct thing for Glibc "improved generic string
functions" patch, producing some really tight loop now.

> 
> On Thu, 2022-11-17 at 17:59 +0800, Lulu Cheng wrote:
> > v1 -> v2:
> > 1. Change the code format.
> > 2. Fix bugs in the code.
> > 
> > v2 -> v3:
> > Modifying a code implementation of an undefined behavior.
> > 
> > v3 -> v4:
> > Move the part of the immediate number decomposition from expand pass
> > to split
> > pass.
> > 
> > Both regression tests and spec2006 passed.
> > 
> > The problem mentioned in the link does not move the four immediate
> > load
> > instructions out of the loop. It has been optimized. Now, as in the
> > test case,
> > four immediate load instructions are generated outside the loop.
> > (
> > https://sourceware.org/pipermail/libc-alpha/2022-September/142202.html
> > )
> > 
> > 
> > Because loop2_invariant pass will extract the instructions that do
> > not
> > change
> > in the loop out of the loop, some instructions will not meet the
> > extraction
> > conditions if the machine performs immediate decomposition while
> > expand pass,
> > so the immediate decomposition will be transferred to the split
> > process.
> > 
> > gcc/ChangeLog:
> > 
> > * config/loongarch/loongarch.cc (enum
> > loongarch_load_imm_method):
> > Remove the member METHOD_INSV that is not currently used.
> > (struct loongarch_integer_op): Define a new member
> > curr_value,
> > that records the value of the number stored in the
> > destination
> > register immediately after the current instruction has run.
> > (loongarch_build_integer): Assign a value to the curr_value
> > member variable.
> > (loongarch_move_integer): Adds information for the immediate
> > load instruction.
> > * config/loongarch/loongarch.md (*movdi_32bit): Redefine as
> > define_insn_and_split.
> > (*movdi_64bit): Likewise.
> > (*movsi_internal): Likewise.
> > (*movhi_internal): Likewise.
> > * config/loongarch/predicates.md: Return true as long as it
> > is
> > CONST_INT, ensure
> > that the immediate number is not optimized by decomposition
> > during expand
> > optimization loop.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * gcc.target/loongarch/imm-load.c: New test.
> > * gcc.target/loongarch/imm-load1.c: New test.
> > ---
> >  gcc/config/loongarch/loongarch.cc | 62 ++--
> > --
> > -
> >  gcc/config/loongarch/loongarch.md | 44 +++--
> >  gcc/config/loongarch/predicates.md    |  2 +-
> >  gcc/testsuite/gcc.target/loongarch/imm-load.c | 10 +++
> >  .../gcc.target/loongarch/imm-load1.c  | 26 
> >  5 files changed, 110 insertions(+), 34 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/loongarch/imm-load.c
> >  create mode 100644 gcc/testsuite/gcc.target/loongarch/imm-load1.c
> > 
> > diff --git a/gcc/config/loongarch/loongarch.cc
> > b/gcc/config/loongarch/loongarch.cc
> > index 8ee32c90573..9e0d6c7c3ea 100644
> > --- a/gcc/config/loongarch/loongarch.cc
> > +++ b/gcc/config/loongarch/loongarch.cc
> > @@ -139,22 +139,21 @@ struct loongarch_address_info
> >  
> >     METHOD_LU52I:
> >   Load 52-63 bit of the immediate number.
> > -
> > -   METHOD_INSV:
> > - immediate like 0xfff0fxxx
> > -   */
> > +*/
> >  enum loongarch_load_imm_method
> >  {
> >    METHOD_NORMAL,
> >    METHOD_LU32I,
> > -  METHOD_LU52I,
> > -  METHOD_INSV
> > +  METHOD_LU52I
> >  };
> >  
> >  struct loongarch_integer_op
> >  {
> >    enum rtx_code code;
> >    HOST_WIDE_INT value;
> > +  /* Represent the result of the immediate count of the load
> > instruction at
> > + each step.  */
> > +  HOST_WIDE_INT curr_value;
> >    enum loongarch_load_imm_method method;
> >  };
> >  
> > @@ -1475,24 +1474,27 @@ loongarch_build_integer (struct
> > loongarch_integer_op *codes,
> >  {
> >    /* The value of the lower 32 bit be loaded with one
> > instruction.
> >  lu12i.w.  */
> > -  codes[0].code = UNKNOWN;
> > -  codes[0].method = METHOD_NORMAL;
> > -  codes[0].value = low_part;
> > +  codes[cost].code = UNKNOWN;
> > +  codes[cost].method = METHOD_NORMAL;
> > +  codes[cost].value = low_part;
> > +  codes[cost].curr_value = low_part;
> >    cost++;
> >  }
> >    else
> >  {
> >    /* lu12i.w + ior.  */
> > -  codes[0].code = UNKNOWN;
> > -  codes[0].method = METHOD_NORMAL;
> > -  codes[0].value = low_part & ~(IMM_REACH - 1);
> > +  codes[cost].code = UNKNOWN;
> > +  codes[cost].method = 

Re: [PATCH v4] LoongArch: Optimize immediate load.

2022-11-22 Thread Xi Ruoyao via Gcc-patches
While I still can't fully understand the immediate load issue and how
this patch fix it, I've tested this patch (alongside the prefetch
instruction patch) with bootstrap-ubsan.  And the compiled result of
imm-load1.c seems OK.

On Thu, 2022-11-17 at 17:59 +0800, Lulu Cheng wrote:
> v1 -> v2:
> 1. Change the code format.
> 2. Fix bugs in the code.
> 
> v2 -> v3:
> Modifying a code implementation of an undefined behavior.
> 
> v3 -> v4:
> Move the part of the immediate number decomposition from expand pass
> to split
> pass.
> 
> Both regression tests and spec2006 passed.
> 
> The problem mentioned in the link does not move the four immediate
> load
> instructions out of the loop. It has been optimized. Now, as in the
> test case,
> four immediate load instructions are generated outside the loop.
> (
> https://sourceware.org/pipermail/libc-alpha/2022-September/142202.html)
> 
> 
> Because loop2_invariant pass will extract the instructions that do not
> change
> in the loop out of the loop, some instructions will not meet the
> extraction
> conditions if the machine performs immediate decomposition while
> expand pass,
> so the immediate decomposition will be transferred to the split
> process.
> 
> gcc/ChangeLog:
> 
> * config/loongarch/loongarch.cc (enum
> loongarch_load_imm_method):
> Remove the member METHOD_INSV that is not currently used.
> (struct loongarch_integer_op): Define a new member curr_value,
> that records the value of the number stored in the destination
> register immediately after the current instruction has run.
> (loongarch_build_integer): Assign a value to the curr_value
> member variable.
> (loongarch_move_integer): Adds information for the immediate
> load instruction.
> * config/loongarch/loongarch.md (*movdi_32bit): Redefine as
> define_insn_and_split.
> (*movdi_64bit): Likewise.
> (*movsi_internal): Likewise.
> (*movhi_internal): Likewise.
> * config/loongarch/predicates.md: Return true as long as it is
> CONST_INT, ensure
> that the immediate number is not optimized by decomposition
> during expand
> optimization loop.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/loongarch/imm-load.c: New test.
> * gcc.target/loongarch/imm-load1.c: New test.
> ---
>  gcc/config/loongarch/loongarch.cc | 62 ++
> -
>  gcc/config/loongarch/loongarch.md | 44 +++--
>  gcc/config/loongarch/predicates.md    |  2 +-
>  gcc/testsuite/gcc.target/loongarch/imm-load.c | 10 +++
>  .../gcc.target/loongarch/imm-load1.c  | 26 
>  5 files changed, 110 insertions(+), 34 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/loongarch/imm-load.c
>  create mode 100644 gcc/testsuite/gcc.target/loongarch/imm-load1.c
> 
> diff --git a/gcc/config/loongarch/loongarch.cc
> b/gcc/config/loongarch/loongarch.cc
> index 8ee32c90573..9e0d6c7c3ea 100644
> --- a/gcc/config/loongarch/loongarch.cc
> +++ b/gcc/config/loongarch/loongarch.cc
> @@ -139,22 +139,21 @@ struct loongarch_address_info
>  
>     METHOD_LU52I:
>   Load 52-63 bit of the immediate number.
> -
> -   METHOD_INSV:
> - immediate like 0xfff0fxxx
> -   */
> +*/
>  enum loongarch_load_imm_method
>  {
>    METHOD_NORMAL,
>    METHOD_LU32I,
> -  METHOD_LU52I,
> -  METHOD_INSV
> +  METHOD_LU52I
>  };
>  
>  struct loongarch_integer_op
>  {
>    enum rtx_code code;
>    HOST_WIDE_INT value;
> +  /* Represent the result of the immediate count of the load
> instruction at
> + each step.  */
> +  HOST_WIDE_INT curr_value;
>    enum loongarch_load_imm_method method;
>  };
>  
> @@ -1475,24 +1474,27 @@ loongarch_build_integer (struct
> loongarch_integer_op *codes,
>  {
>    /* The value of the lower 32 bit be loaded with one
> instruction.
>  lu12i.w.  */
> -  codes[0].code = UNKNOWN;
> -  codes[0].method = METHOD_NORMAL;
> -  codes[0].value = low_part;
> +  codes[cost].code = UNKNOWN;
> +  codes[cost].method = METHOD_NORMAL;
> +  codes[cost].value = low_part;
> +  codes[cost].curr_value = low_part;
>    cost++;
>  }
>    else
>  {
>    /* lu12i.w + ior.  */
> -  codes[0].code = UNKNOWN;
> -  codes[0].method = METHOD_NORMAL;
> -  codes[0].value = low_part & ~(IMM_REACH - 1);
> +  codes[cost].code = UNKNOWN;
> +  codes[cost].method = METHOD_NORMAL;
> +  codes[cost].value = low_part & ~(IMM_REACH - 1);
> +  codes[cost].curr_value = codes[cost].value;
>    cost++;
>    HOST_WIDE_INT iorv = low_part & (IMM_REACH - 1);
>    if (iorv != 0)
> {
> - codes[1].code = IOR;
> - codes[1].method = METHOD_NORMAL;
> - codes[1].value = iorv;
> + codes[cost].code = IOR;
> + codes[cost].method = METHOD_NORMAL;
> + codes[cost].value = iorv;
> + 

[PATCH v4] LoongArch: Optimize immediate load.

2022-11-17 Thread Lulu Cheng
v1 -> v2:
1. Change the code format.
2. Fix bugs in the code.

v2 -> v3:
Modifying a code implementation of an undefined behavior.

v3 -> v4:
Move the part of the immediate number decomposition from expand pass to split
pass.

Both regression tests and spec2006 passed.

The problem mentioned in the link does not move the four immediate load
instructions out of the loop. It has been optimized. Now, as in the test case,
four immediate load instructions are generated outside the loop.
(https://sourceware.org/pipermail/libc-alpha/2022-September/142202.html)


Because loop2_invariant pass will extract the instructions that do not change
in the loop out of the loop, some instructions will not meet the extraction
conditions if the machine performs immediate decomposition while expand pass,
so the immediate decomposition will be transferred to the split process.

gcc/ChangeLog:

* config/loongarch/loongarch.cc (enum loongarch_load_imm_method):
Remove the member METHOD_INSV that is not currently used.
(struct loongarch_integer_op): Define a new member curr_value,
that records the value of the number stored in the destination
register immediately after the current instruction has run.
(loongarch_build_integer): Assign a value to the curr_value member 
variable.
(loongarch_move_integer): Adds information for the immediate load 
instruction.
* config/loongarch/loongarch.md (*movdi_32bit): Redefine as 
define_insn_and_split.
(*movdi_64bit): Likewise.
(*movsi_internal): Likewise.
(*movhi_internal): Likewise.
* config/loongarch/predicates.md: Return true as long as it is 
CONST_INT, ensure
that the immediate number is not optimized by decomposition during 
expand
optimization loop.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/imm-load.c: New test.
* gcc.target/loongarch/imm-load1.c: New test.
---
 gcc/config/loongarch/loongarch.cc | 62 ++-
 gcc/config/loongarch/loongarch.md | 44 +++--
 gcc/config/loongarch/predicates.md|  2 +-
 gcc/testsuite/gcc.target/loongarch/imm-load.c | 10 +++
 .../gcc.target/loongarch/imm-load1.c  | 26 
 5 files changed, 110 insertions(+), 34 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/imm-load.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/imm-load1.c

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 8ee32c90573..9e0d6c7c3ea 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -139,22 +139,21 @@ struct loongarch_address_info
 
METHOD_LU52I:
  Load 52-63 bit of the immediate number.
-
-   METHOD_INSV:
- immediate like 0xfff0fxxx
-   */
+*/
 enum loongarch_load_imm_method
 {
   METHOD_NORMAL,
   METHOD_LU32I,
-  METHOD_LU52I,
-  METHOD_INSV
+  METHOD_LU52I
 };
 
 struct loongarch_integer_op
 {
   enum rtx_code code;
   HOST_WIDE_INT value;
+  /* Represent the result of the immediate count of the load instruction at
+ each step.  */
+  HOST_WIDE_INT curr_value;
   enum loongarch_load_imm_method method;
 };
 
@@ -1475,24 +1474,27 @@ loongarch_build_integer (struct loongarch_integer_op 
*codes,
 {
   /* The value of the lower 32 bit be loaded with one instruction.
 lu12i.w.  */
-  codes[0].code = UNKNOWN;
-  codes[0].method = METHOD_NORMAL;
-  codes[0].value = low_part;
+  codes[cost].code = UNKNOWN;
+  codes[cost].method = METHOD_NORMAL;
+  codes[cost].value = low_part;
+  codes[cost].curr_value = low_part;
   cost++;
 }
   else
 {
   /* lu12i.w + ior.  */
-  codes[0].code = UNKNOWN;
-  codes[0].method = METHOD_NORMAL;
-  codes[0].value = low_part & ~(IMM_REACH - 1);
+  codes[cost].code = UNKNOWN;
+  codes[cost].method = METHOD_NORMAL;
+  codes[cost].value = low_part & ~(IMM_REACH - 1);
+  codes[cost].curr_value = codes[cost].value;
   cost++;
   HOST_WIDE_INT iorv = low_part & (IMM_REACH - 1);
   if (iorv != 0)
{
- codes[1].code = IOR;
- codes[1].method = METHOD_NORMAL;
- codes[1].value = iorv;
+ codes[cost].code = IOR;
+ codes[cost].method = METHOD_NORMAL;
+ codes[cost].value = iorv;
+ codes[cost].curr_value = low_part;
  cost++;
}
 }
@@ -1515,11 +1517,14 @@ loongarch_build_integer (struct loongarch_integer_op 
*codes,
{
  codes[cost].method = METHOD_LU52I;
  codes[cost].value = value & LU52I_B;
+ codes[cost].curr_value = value;
  return cost + 1;
}
 
   codes[cost].method = METHOD_LU32I;
   codes[cost].value = (value & LU32I_B) | (sign51 ? LU52I_B : 0);
+  codes[cost].curr_value = (value & 0xf)
+   | (sign51 ? LU52I_B : 0);