[PATCH] Adding target hook allows to reject initialization of register

[PATCH] Adding target hook allows to reject initialization of register

[Jojo R]

Some target like RISC-V allow to group vector register as a whole,
and only operate part of it in fact, but the 'init-regs' pass will add initialization
for uninitialized registers. Add this hook to reject this action for reducing instruction.

	gcc/
	* init-regs.c (initialize_uninitialized_regs): Call register_reject_init_p.
	* target.def (register_reject_init_p): New hook.
	* doc/tm.texi.in: Add TARGET_REGISTER_REJECT_INIT_P.
	* doc/tm.texi: Regenerated.
---
 gcc/doc/tm.texi    | 6 ++++++
 gcc/doc/tm.texi.in | 2 ++
 gcc/init-regs.c    | 5 +++++
 gcc/target.def     | 8 ++++++++
 4 files changed, 21 insertions(+)

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index a30fdcbbf3d6..83fd5496ca3f 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12588,3 +12588,9 @@ Return an RTX representing @var{tagged_pointer} with its tag set to zero.
 Store the result in @var{target} if convenient.
 The default clears the top byte of the original pointer.
 @end deftypefn
+
+@deftypefn {Target Hook} bool TARGET_REGISTER_REJECT_INIT_P (rtx @var{reg})
+This target hook should return @code{true} if reject initialization for a uninitialized @var{reg}.
+
+The default value of this hook is @code{NULL}.
+@end deftypefn
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 611fc500ac86..13174ce66d59 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -8180,3 +8180,5 @@ maintainer is familiar with.
 @hook TARGET_MEMTAG_EXTRACT_TAG
 
 @hook TARGET_MEMTAG_UNTAGGED_POINTER
+
+@hook TARGET_REGISTER_REJECT_INIT_P
diff --git a/gcc/init-regs.c b/gcc/init-regs.c
index 72e898f3e334..51c0d669d30b 100644
--- a/gcc/init-regs.c
+++ b/gcc/init-regs.c
@@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
+#include "target.h"
 #include "rtl.h"
 #include "tree.h"
 #include "df.h"
@@ -101,6 +102,10 @@ initialize_uninitialized_regs (void)
 		  rtx_insn *move_insn;
 		  rtx reg = DF_REF_REAL_REG (use);
 
+		  if (targetm.register_reject_init_p
+		      && targetm.register_reject_init_p (reg))
+		    continue;
+
 		  bitmap_set_bit (already_genned, regno);
 
 		  start_sequence ();
diff --git a/gcc/target.def b/gcc/target.def
index 7676d5e626e3..c2b54421618d 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -4545,6 +4545,14 @@ by a subtarget.",
  unsigned HOST_WIDE_INT, (void),
  NULL)
 
+/* Return true if reject initialization for a uninitialized register.  */
+DEFHOOK
+(register_reject_init_p,
+ "This target hook should return @code{true} if reject initialization for a uninitialized @var{reg}.\n\
+\n\
+The default value of this hook is @code{NULL}.",
+ bool, (rtx reg), NULL)
+
 /* Functions relating to calls - argument passing, returns, etc.  */
 /* Members of struct call have no special macro prefix.  */
 HOOK_VECTOR (TARGET_CALLS, calls)
-- 
2.24.3 (Apple Git-128)

Re: [PATCH] Adding target hook allows to reject initialization of register

[Richard Biener]

On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Some target like RISC-V allow to group vector register as a whole,
> and only operate part of it in fact, but the 'init-regs' pass will add initialization
> for uninitialized registers. Add this hook to reject this action for reducing instruction.

Are these groups "visible"?  That is, are the pseudos multi-reg
pseudos?  I wonder
if there's a more generic way to tame down initregs w/o introducing a new target
hook.

Btw, initregs is a red herring - it ideally should go away.  See PR61810.

So instead of adding to it can you see whether disabling the pass for RISC-V
works w/o fallout (and add a comment to the PR)?  Maybe some more RTL
literate (in particular DF literate) can look at the remaining issue.
Richard, did you
ever have a look into the "issue" that initregs covers up (whatever
that exactly is)?

Thanks,
Richard.

>         gcc/
>         * init-regs.c (initialize_uninitialized_regs): Call register_reject_init_p.
>         * target.def (register_reject_init_p): New hook.
>         * doc/tm.texi.in: Add TARGET_REGISTER_REJECT_INIT_P.
>         * doc/tm.texi: Regenerated.
> ---
>  gcc/doc/tm.texi    | 6 ++++++
>  gcc/doc/tm.texi.in | 2 ++
>  gcc/init-regs.c    | 5 +++++
>  gcc/target.def     | 8 ++++++++
>  4 files changed, 21 insertions(+)
>
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index a30fdcbbf3d6..83fd5496ca3f 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -12588,3 +12588,9 @@ Return an RTX representing @var{tagged_pointer} with its tag set to zero.
>  Store the result in @var{target} if convenient.
>  The default clears the top byte of the original pointer.
>  @end deftypefn
> +
> +@deftypefn {Target Hook} bool TARGET_REGISTER_REJECT_INIT_P (rtx @var{reg})
> +This target hook should return @code{true} if reject initialization for a uninitialized @var{reg}.
> +
> +The default value of this hook is @code{NULL}.
> +@end deftypefn
> diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> index 611fc500ac86..13174ce66d59 100644
> --- a/gcc/doc/tm.texi.in
> +++ b/gcc/doc/tm.texi.in
> @@ -8180,3 +8180,5 @@ maintainer is familiar with.
>  @hook TARGET_MEMTAG_EXTRACT_TAG
>
>  @hook TARGET_MEMTAG_UNTAGGED_POINTER
> +
> +@hook TARGET_REGISTER_REJECT_INIT_P
> diff --git a/gcc/init-regs.c b/gcc/init-regs.c
> index 72e898f3e334..51c0d669d30b 100644
> --- a/gcc/init-regs.c
> +++ b/gcc/init-regs.c
> @@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "system.h"
>  #include "coretypes.h"
>  #include "backend.h"
> +#include "target.h"
>  #include "rtl.h"
>  #include "tree.h"
>  #include "df.h"
> @@ -101,6 +102,10 @@ initialize_uninitialized_regs (void)
>                   rtx_insn *move_insn;
>                   rtx reg = DF_REF_REAL_REG (use);
>
> +                 if (targetm.register_reject_init_p
> +                     && targetm.register_reject_init_p (reg))
> +                   continue;
> +
>                   bitmap_set_bit (already_genned, regno);
>
>                   start_sequence ();
> diff --git a/gcc/target.def b/gcc/target.def
> index 7676d5e626e3..c2b54421618d 100644
> --- a/gcc/target.def
> +++ b/gcc/target.def
> @@ -4545,6 +4545,14 @@ by a subtarget.",
>   unsigned HOST_WIDE_INT, (void),
>   NULL)
>
> +/* Return true if reject initialization for a uninitialized register.  */
> +DEFHOOK
> +(register_reject_init_p,
> + "This target hook should return @code{true} if reject initialization for a uninitialized @var{reg}.\n\
> +\n\
> +The default value of this hook is @code{NULL}.",
> + bool, (rtx reg), NULL)
> +
>  /* Functions relating to calls - argument passing, returns, etc.  */
>  /* Members of struct call have no special macro prefix.  */
>  HOOK_VECTOR (TARGET_CALLS, calls)
> --
> 2.24.3 (Apple Git-128)
>

Re: [PATCH] Adding target hook allows to reject initialization of register

[Jojo R]

— Jojo
在 2021年8月10日 +0800 PM7:03，Richard Biener <richard.guenther@gmail.com>，写道：
> On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > Some target like RISC-V allow to group vector register as a whole,
> > and only operate part of it in fact, but the 'init-regs' pass will add initialization
> > for uninitialized registers. Add this hook to reject this action for reducing instruction.
>
> Are these groups "visible"? That is, are the pseudos multi-reg
> pseudos? I wonder
> if there's a more generic way to tame down initregs w/o introducing a new target
> hook.

Yes, it is visible. I make a simple demo as:

vuint8m1_t
foo (vuint8m1_t a, vuint8m2_t b, int vl)
{
  vuint8m2_t tmp;
  tmp = vset_v_u8m1_u8m2(tmp, 0, a);
  tmp = vadd_vv_u8m2 (tmp, b, vl);
  return vget_v_u8m2_u8m1(tmp, 0);
}

The intrinsic spec refer to:
https://github.com/riscv/rvv-intrinsic-doc/blob/master/rvv-intrinsic-api.md#vector-insertion-functions

The problematic intrinsic is vset_v_u8m1_u8m2() here,
Only half of it is operated, and

RTL dump from ‘266r.auto_inc_dec’ is :

(insn 11 8 12 2 (set (reg:VNx32QI 138 [ _10 ])
 (unspec:VNx32QI [
 (reg/v:VNx32QI 135 [ tmp ])
 (reg:SI 66 vl)
 ] UNSPEC_USEVL)) "riscv_vector.h":235:1 21133 {*movvnx32qi}
 (expr_list:REG_DEAD (reg/v:VNx32QI 135 [ tmp ])
 (nil)))

(insn 12 11 13 2 (set (subreg:VNx16QI (reg:VNx32QI 138 [ _10 ]) 0)
 (unspec:VNx16QI [
 (reg/v:VNx16QI 141 [ a ])
 (reg:SI 66 vl)
 ] UNSPEC_USEVL)) "riscv_vector.h":235:1 21132 {*movvnx16qi}
 (expr_list:REG_DEAD (reg/v:VNx16QI 141 [ a ])
 (expr_list:REG_DEAD (reg:SI 66 vl)
 (nil))))

RTL dump from ‘267r.init-regs’ is :

starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
scanning new insn with uid = 24.
scanning new insn with uid = 25.
scanning new insn with uid = 26.
scanning new insn with uid = 27.
adding initialization in foo of reg 135 at in block 2 for insn 11.
starting the processing of deferred insns
ending the processing of deferred insns

… …
>
> Btw, initregs is a red herring - it ideally should go away. See PR61810.
>
> So instead of adding to it can you see whether disabling the pass for RISC-V
> works w/o fallout (and add a comment to the PR)? Maybe some more RTL
> literate (in particular DF literate) can look at the remaining issue.
> Richard, did you
> ever have a look into the "issue" that initregs covers up (whatever
> that exactly is)?
>
> Thanks,
> Richard.
>
> > gcc/
> > * init-regs.c (initialize_uninitialized_regs): Call register_reject_init_p.
> > * target.def (register_reject_init_p): New hook.
> > * doc/tm.texi.in: Add TARGET_REGISTER_REJECT_INIT_P.
> > * doc/tm.texi: Regenerated.
> > ---
> > gcc/doc/tm.texi | 6 ++++++
> > gcc/doc/tm.texi.in | 2 ++
> > gcc/init-regs.c | 5 +++++
> > gcc/target.def | 8 ++++++++
> > 4 files changed, 21 insertions(+)
> >
> > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> > index a30fdcbbf3d6..83fd5496ca3f 100644
> > --- a/gcc/doc/tm.texi
> > +++ b/gcc/doc/tm.texi
> > @@ -12588,3 +12588,9 @@ Return an RTX representing @var{tagged_pointer} with its tag set to zero.
> > Store the result in @var{target} if convenient.
> > The default clears the top byte of the original pointer.
> > @end deftypefn
> > +
> > +@deftypefn {Target Hook} bool TARGET_REGISTER_REJECT_INIT_P (rtx @var{reg})
> > +This target hook should return @code{true} if reject initialization for a uninitialized @var{reg}.
> > +
> > +The default value of this hook is @code{NULL}.
> > +@end deftypefn
> > diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> > index 611fc500ac86..13174ce66d59 100644
> > --- a/gcc/doc/tm.texi.in
> > +++ b/gcc/doc/tm.texi.in
> > @@ -8180,3 +8180,5 @@ maintainer is familiar with.
> > @hook TARGET_MEMTAG_EXTRACT_TAG
> >
> > @hook TARGET_MEMTAG_UNTAGGED_POINTER
> > +
> > +@hook TARGET_REGISTER_REJECT_INIT_P
> > diff --git a/gcc/init-regs.c b/gcc/init-regs.c
> > index 72e898f3e334..51c0d669d30b 100644
> > --- a/gcc/init-regs.c
> > +++ b/gcc/init-regs.c
> > @@ -21,6 +21,7 @@ along with GCC; see the file COPYING3. If not see
> > #include "system.h"
> > #include "coretypes.h"
> > #include "backend.h"
> > +#include "target.h"
> > #include "rtl.h"
> > #include "tree.h"
> > #include "df.h"
> > @@ -101,6 +102,10 @@ initialize_uninitialized_regs (void)
> > rtx_insn *move_insn;
> > rtx reg = DF_REF_REAL_REG (use);
> >
> > + if (targetm.register_reject_init_p
> > + && targetm.register_reject_init_p (reg))
> > + continue;
> > +
> > bitmap_set_bit (already_genned, regno);
> >
> > start_sequence ();
> > diff --git a/gcc/target.def b/gcc/target.def
> > index 7676d5e626e3..c2b54421618d 100644
> > --- a/gcc/target.def
> > +++ b/gcc/target.def
> > @@ -4545,6 +4545,14 @@ by a subtarget.",
> > unsigned HOST_WIDE_INT, (void),
> > NULL)
> >
> > +/* Return true if reject initialization for a uninitialized register. */
> > +DEFHOOK
> > +(register_reject_init_p,
> > + "This target hook should return @code{true} if reject initialization for a uninitialized @var{reg}.\n\
> > +\n\
> > +The default value of this hook is @code{NULL}.",
> > + bool, (rtx reg), NULL)
> > +
> > /* Functions relating to calls - argument passing, returns, etc. */
> > /* Members of struct call have no special macro prefix. */
> > HOOK_VECTOR (TARGET_CALLS, calls)
> > --
> > 2.24.3 (Apple Git-128)

Re: [PATCH] Adding target hook allows to reject initialization of register

[Jojo R]

— Jojo
在 2021年8月10日 +0800 PM7:03，Richard Biener <richard.guenther@gmail.com>，写道：
> On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > Some target like RISC-V allow to group vector register as a whole,
> > and only operate part of it in fact, but the 'init-regs' pass will add initialization
> > for uninitialized registers. Add this hook to reject this action for reducing instruction.
>
> Are these groups "visible"? That is, are the pseudos multi-reg
> pseudos? I wonder
> if there's a more generic way to tame down initregs w/o introducing a new target
> hook.
>
> Btw, initregs is a red herring - it ideally should go away. See PR61810.
>
> So instead of adding to it can you see whether disabling the pass for RISC-V
> works w/o fallout (and add a comment to the PR)? Maybe some more RTL
> literate (in particular DF literate) can look at the remaining issue.

BTW, is there any side effect if I disable this init-regs pass ?
> Richard, did you
> ever have a look into the "issue" that initregs covers up (whatever
> that exactly is)?
>
> Thanks,
> Richard.
>
> > gcc/
> > * init-regs.c (initialize_uninitialized_regs): Call register_reject_init_p.
> > * target.def (register_reject_init_p): New hook.
> > * doc/tm.texi.in: Add TARGET_REGISTER_REJECT_INIT_P.
> > * doc/tm.texi: Regenerated.
> > ---
> > gcc/doc/tm.texi | 6 ++++++
> > gcc/doc/tm.texi.in | 2 ++
> > gcc/init-regs.c | 5 +++++
> > gcc/target.def | 8 ++++++++
> > 4 files changed, 21 insertions(+)
> >
> > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> > index a30fdcbbf3d6..83fd5496ca3f 100644
> > --- a/gcc/doc/tm.texi
> > +++ b/gcc/doc/tm.texi
> > @@ -12588,3 +12588,9 @@ Return an RTX representing @var{tagged_pointer} with its tag set to zero.
> > Store the result in @var{target} if convenient.
> > The default clears the top byte of the original pointer.
> > @end deftypefn
> > +
> > +@deftypefn {Target Hook} bool TARGET_REGISTER_REJECT_INIT_P (rtx @var{reg})
> > +This target hook should return @code{true} if reject initialization for a uninitialized @var{reg}.
> > +
> > +The default value of this hook is @code{NULL}.
> > +@end deftypefn
> > diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> > index 611fc500ac86..13174ce66d59 100644
> > --- a/gcc/doc/tm.texi.in
> > +++ b/gcc/doc/tm.texi.in
> > @@ -8180,3 +8180,5 @@ maintainer is familiar with.
> > @hook TARGET_MEMTAG_EXTRACT_TAG
> >
> > @hook TARGET_MEMTAG_UNTAGGED_POINTER
> > +
> > +@hook TARGET_REGISTER_REJECT_INIT_P
> > diff --git a/gcc/init-regs.c b/gcc/init-regs.c
> > index 72e898f3e334..51c0d669d30b 100644
> > --- a/gcc/init-regs.c
> > +++ b/gcc/init-regs.c
> > @@ -21,6 +21,7 @@ along with GCC; see the file COPYING3. If not see
> > #include "system.h"
> > #include "coretypes.h"
> > #include "backend.h"
> > +#include "target.h"
> > #include "rtl.h"
> > #include "tree.h"
> > #include "df.h"
> > @@ -101,6 +102,10 @@ initialize_uninitialized_regs (void)
> > rtx_insn *move_insn;
> > rtx reg = DF_REF_REAL_REG (use);
> >
> > + if (targetm.register_reject_init_p
> > + && targetm.register_reject_init_p (reg))
> > + continue;
> > +
> > bitmap_set_bit (already_genned, regno);
> >
> > start_sequence ();
> > diff --git a/gcc/target.def b/gcc/target.def
> > index 7676d5e626e3..c2b54421618d 100644
> > --- a/gcc/target.def
> > +++ b/gcc/target.def
> > @@ -4545,6 +4545,14 @@ by a subtarget.",
> > unsigned HOST_WIDE_INT, (void),
> > NULL)
> >
> > +/* Return true if reject initialization for a uninitialized register. */
> > +DEFHOOK
> > +(register_reject_init_p,
> > + "This target hook should return @code{true} if reject initialization for a uninitialized @var{reg}.\n\
> > +\n\
> > +The default value of this hook is @code{NULL}.",
> > + bool, (rtx reg), NULL)
> > +
> > /* Functions relating to calls - argument passing, returns, etc. */
> > /* Members of struct call have no special macro prefix. */
> > HOOK_VECTOR (TARGET_CALLS, calls)
> > --
> > 2.24.3 (Apple Git-128)

Re: [PATCH] Adding target hook allows to reject initialization of register

[Richard Sandiford]

Richard Biener <richard.guenther@gmail.com> writes:
> On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> Some target like RISC-V allow to group vector register as a whole,
>> and only operate part of it in fact, but the 'init-regs' pass will add initialization
>> for uninitialized registers. Add this hook to reject this action for reducing instruction.
>
> Are these groups "visible"?  That is, are the pseudos multi-reg
> pseudos?  I wonder
> if there's a more generic way to tame down initregs w/o introducing a new target
> hook.
>
> Btw, initregs is a red herring - it ideally should go away.  See PR61810.
>
> So instead of adding to it can you see whether disabling the pass for RISC-V
> works w/o fallout (and add a comment to the PR)?  Maybe some more RTL
> literate (in particular DF literate) can look at the remaining issue.
> Richard, did you
> ever have a look into the "issue" that initregs covers up (whatever
> that exactly is)?

No, sorry.  I don't really understand what it would be from the comment
in the code:

   [...] papers over some problems on the arm and other
   processors where certain isa constraints cannot be handled by gcc.
   These are of the form where two operands to an insn my not be the
   same.  The ra will only make them the same if they do not
   interfere, and this can only happen if one is not initialized.

That would definitely be an RA bug if true, since the constraints need
to be applied independently of dataflow information.  But the comment
and code predate LRA and maybe no-one fancied poking around in reload
(hard to believe).

I'd be very surprised if LRA gets this wrong.

Thanks,
Richard

Re: [PATCH] Adding target hook allows to reject initialization of register

[Richard Biener]

On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Richard Biener <richard.guenther@gmail.com> writes:
> > On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >> Some target like RISC-V allow to group vector register as a whole,
> >> and only operate part of it in fact, but the 'init-regs' pass will add initialization
> >> for uninitialized registers. Add this hook to reject this action for reducing instruction.
> >
> > Are these groups "visible"?  That is, are the pseudos multi-reg
> > pseudos?  I wonder
> > if there's a more generic way to tame down initregs w/o introducing a new target
> > hook.
> >
> > Btw, initregs is a red herring - it ideally should go away.  See PR61810.
> >
> > So instead of adding to it can you see whether disabling the pass for RISC-V
> > works w/o fallout (and add a comment to the PR)?  Maybe some more RTL
> > literate (in particular DF literate) can look at the remaining issue.
> > Richard, did you
> > ever have a look into the "issue" that initregs covers up (whatever
> > that exactly is)?
>
> No, sorry.  I don't really understand what it would be from the comment
> in the code:
>
>    [...] papers over some problems on the arm and other
>    processors where certain isa constraints cannot be handled by gcc.
>    These are of the form where two operands to an insn my not be the
>    same.  The ra will only make them the same if they do not
>    interfere, and this can only happen if one is not initialized.
>
> That would definitely be an RA bug if true, since the constraints need
> to be applied independently of dataflow information.  But the comment
> and code predate LRA and maybe no-one fancied poking around in reload
> (hard to believe).
>
> I'd be very surprised if LRA gets this wrong.

OK, we're wondering since quite some time - how about changing the
gate of initregs to optimize > 0 && !targetm.lra_p ()?  We'll hopefully
figure out the "real" issue the pass is papering over.  At the same time
we're leaving old reload (and likely unmaintianed) targets unaffected.

Richard.

> Thanks,
> Richard

Re: [PATCH] Adding target hook allows to reject initialization of register

[Richard Sandiford]

Richard Biener <richard.guenther@gmail.com> writes:
> On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford
> <richard.sandiford@arm.com> wrote:
>>
>> Richard Biener <richard.guenther@gmail.com> writes:
>> > On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
>> > <gcc-patches@gcc.gnu.org> wrote:
>> >>
>> >> Some target like RISC-V allow to group vector register as a whole,
>> >> and only operate part of it in fact, but the 'init-regs' pass will add initialization
>> >> for uninitialized registers. Add this hook to reject this action for reducing instruction.
>> >
>> > Are these groups "visible"?  That is, are the pseudos multi-reg
>> > pseudos?  I wonder
>> > if there's a more generic way to tame down initregs w/o introducing a new target
>> > hook.
>> >
>> > Btw, initregs is a red herring - it ideally should go away.  See PR61810.
>> >
>> > So instead of adding to it can you see whether disabling the pass for RISC-V
>> > works w/o fallout (and add a comment to the PR)?  Maybe some more RTL
>> > literate (in particular DF literate) can look at the remaining issue.
>> > Richard, did you
>> > ever have a look into the "issue" that initregs covers up (whatever
>> > that exactly is)?
>>
>> No, sorry.  I don't really understand what it would be from the comment
>> in the code:
>>
>>    [...] papers over some problems on the arm and other
>>    processors where certain isa constraints cannot be handled by gcc.
>>    These are of the form where two operands to an insn my not be the
>>    same.  The ra will only make them the same if they do not
>>    interfere, and this can only happen if one is not initialized.
>>
>> That would definitely be an RA bug if true, since the constraints need
>> to be applied independently of dataflow information.  But the comment
>> and code predate LRA and maybe no-one fancied poking around in reload
>> (hard to believe).
>>
>> I'd be very surprised if LRA gets this wrong.
>
> OK, we're wondering since quite some time - how about changing the
> gate of initregs to optimize > 0 && !targetm.lra_p ()?  We'll hopefully
> figure out the "real" issue the pass is papering over.  At the same time
> we're leaving old reload (and likely unmaintianed) targets unaffected.

Sounds good to me.

Thanks,
Richard

Re: [PATCH] Adding target hook allows to reject initialization of register

[Jojo R]

— Jojo
在 2021年8月11日 +0800 PM6:44，Richard Biener <richard.guenther@gmail.com>，写道：
> On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford
> <richard.sandiford@arm.com> wrote:
> >
> > Richard Biener <richard.guenther@gmail.com> writes:
> > > On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> > > <gcc-patches@gcc.gnu.org> wrote:
> > > >
> > > > Some target like RISC-V allow to group vector register as a whole,
> > > > and only operate part of it in fact, but the 'init-regs' pass will add initialization
> > > > for uninitialized registers. Add this hook to reject this action for reducing instruction.
> > >
> > > Are these groups "visible"? That is, are the pseudos multi-reg
> > > pseudos? I wonder
> > > if there's a more generic way to tame down initregs w/o introducing a new target
> > > hook.
> > >
> > > Btw, initregs is a red herring - it ideally should go away. See PR61810.
> > >
> > > So instead of adding to it can you see whether disabling the pass for RISC-V
> > > works w/o fallout (and add a comment to the PR)? Maybe some more RTL
> > > literate (in particular DF literate) can look at the remaining issue.
> > > Richard, did you
> > > ever have a look into the "issue" that initregs covers up (whatever
> > > that exactly is)?
> >
> > No, sorry. I don't really understand what it would be from the comment
> > in the code:
> >
> > [...] papers over some problems on the arm and other
> > processors where certain isa constraints cannot be handled by gcc.
> > These are of the form where two operands to an insn my not be the
> > same. The ra will only make them the same if they do not
> > interfere, and this can only happen if one is not initialized.
> >
> > That would definitely be an RA bug if true, since the constraints need
> > to be applied independently of dataflow information. But the comment
> > and code predate LRA and maybe no-one fancied poking around in reload
> > (hard to believe).
> >
> > I'd be very surprised if LRA gets this wrong.
>
> OK, we're wondering since quite some time - how about changing the
> gate of initregs to optimize > 0 && !targetm.lra_p ()? We'll hopefully
> figure out the "real" issue the pass is papering over. At the same time
> we're leaving old reload (and likely unmaintianed) targets unaffected.
>
Richard,

So this patch is not necessary ?

I need to disable this pass in my situation only ?
I am afraid some side effect in my projects without this init-regs pass … ...
> Richard.
>
> > Thanks,
> > Richard

Re: [PATCH] Adding target hook allows to reject initialization of register

[Richard Biener]

On Fri, Aug 13, 2021 at 3:59 AM Jojo R <rjiejie@linux.alibaba.com> wrote:
>
>
> — Jojo
> 在 2021年8月11日 +0800 PM6:44，Richard Biener <richard.guenther@gmail.com>，写道：
>
> On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford
> <richard.sandiford@arm.com> wrote:
>
>
> Richard Biener <richard.guenther@gmail.com> writes:
>
> On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
>
> Some target like RISC-V allow to group vector register as a whole,
> and only operate part of it in fact, but the 'init-regs' pass will add initialization
> for uninitialized registers. Add this hook to reject this action for reducing instruction.
>
>
> Are these groups "visible"? That is, are the pseudos multi-reg
> pseudos? I wonder
> if there's a more generic way to tame down initregs w/o introducing a new target
> hook.
>
> Btw, initregs is a red herring - it ideally should go away. See PR61810.
>
> So instead of adding to it can you see whether disabling the pass for RISC-V
> works w/o fallout (and add a comment to the PR)? Maybe some more RTL
> literate (in particular DF literate) can look at the remaining issue.
> Richard, did you
> ever have a look into the "issue" that initregs covers up (whatever
> that exactly is)?
>
>
> No, sorry. I don't really understand what it would be from the comment
> in the code:
>
> [...] papers over some problems on the arm and other
> processors where certain isa constraints cannot be handled by gcc.
> These are of the form where two operands to an insn my not be the
> same. The ra will only make them the same if they do not
> interfere, and this can only happen if one is not initialized.
>
> That would definitely be an RA bug if true, since the constraints need
> to be applied independently of dataflow information. But the comment
> and code predate LRA and maybe no-one fancied poking around in reload
> (hard to believe).
>
> I'd be very surprised if LRA gets this wrong.
>
>
> OK, we're wondering since quite some time - how about changing the
> gate of initregs to optimize > 0 && !targetm.lra_p ()? We'll hopefully
> figure out the "real" issue the pass is papering over. At the same time
> we're leaving old reload (and likely unmaintianed) targets unaffected.
>
> Richard,
>
> So this patch is not necessary ?
>
> I need to disable this pass in my situation only ?
> I am afraid some side effect in my projects without this init-regs pass … ...

Can you try disabling the pass on RISC-V?

Richard.

> Richard.
>
> Thanks,
> Richard

Re: [PATCH] Adding target hook allows to reject initialization of register

[Jojo R]

— Jojo
在 2021年8月16日 +0800 PM3:15，Richard Biener <richard.guenther@gmail.com>，写道：
> On Fri, Aug 13, 2021 at 3:59 AM Jojo R <rjiejie@linux.alibaba.com> wrote:
> >
> >
> > — Jojo
> > 在 2021年8月11日 +0800 PM6:44，Richard Biener <richard.guenther@gmail.com>，写道：
> >
> > On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford
> > <richard.sandiford@arm.com> wrote:
> >
> >
> > Richard Biener <richard.guenther@gmail.com> writes:
> >
> > On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >
> >
> > Some target like RISC-V allow to group vector register as a whole,
> > and only operate part of it in fact, but the 'init-regs' pass will add initialization
> > for uninitialized registers. Add this hook to reject this action for reducing instruction.
> >
> >
> > Are these groups "visible"? That is, are the pseudos multi-reg
> > pseudos? I wonder
> > if there's a more generic way to tame down initregs w/o introducing a new target
> > hook.
> >
> > Btw, initregs is a red herring - it ideally should go away. See PR61810.
> >
> > So instead of adding to it can you see whether disabling the pass for RISC-V
> > works w/o fallout (and add a comment to the PR)? Maybe some more RTL
> > literate (in particular DF literate) can look at the remaining issue.
> > Richard, did you
> > ever have a look into the "issue" that initregs covers up (whatever
> > that exactly is)?
> >
> >
> > No, sorry. I don't really understand what it would be from the comment
> > in the code:
> >
> > [...] papers over some problems on the arm and other
> > processors where certain isa constraints cannot be handled by gcc.
> > These are of the form where two operands to an insn my not be the
> > same. The ra will only make them the same if they do not
> > interfere, and this can only happen if one is not initialized.
> >
> > That would definitely be an RA bug if true, since the constraints need
> > to be applied independently of dataflow information. But the comment
> > and code predate LRA and maybe no-one fancied poking around in reload
> > (hard to believe).
> >
> > I'd be very surprised if LRA gets this wrong.
> >
> >
> > OK, we're wondering since quite some time - how about changing the
> > gate of initregs to optimize > 0 && !targetm.lra_p ()? We'll hopefully
> > figure out the "real" issue the pass is papering over. At the same time
> > we're leaving old reload (and likely unmaintianed) targets unaffected.
> >
> > Richard,
> >
> > So this patch is not necessary ?
> >
> > I need to disable this pass in my situation only ?
> > I am afraid some side effect in my projects without this init-regs pass … ...
>
> Can you try disabling the pass on RISC-V?
Okay, I will do the test on GCC version 10.2, is it ok ?
It will take a few days :)

Or which version do you suggest to do this ?
> Richard.
>
> > Richard.
> >
> > Thanks,
> > Richard

Re: [PATCH] Adding target hook allows to reject initialization of register

[Richard Biener]

On Wed, Aug 18, 2021 at 3:54 AM Jojo R <rjiejie@linux.alibaba.com> wrote:
>
>
> — Jojo
> 在 2021年8月16日 +0800 PM3:15，Richard Biener <richard.guenther@gmail.com>，写道：
>
> On Fri, Aug 13, 2021 at 3:59 AM Jojo R <rjiejie@linux.alibaba.com> wrote:
>
>
>
> — Jojo
> 在 2021年8月11日 +0800 PM6:44，Richard Biener <richard.guenther@gmail.com>，写道：
>
> On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford
> <richard.sandiford@arm.com> wrote:
>
>
> Richard Biener <richard.guenther@gmail.com> writes:
>
> On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
>
> Some target like RISC-V allow to group vector register as a whole,
> and only operate part of it in fact, but the 'init-regs' pass will add initialization
> for uninitialized registers. Add this hook to reject this action for reducing instruction.
>
>
> Are these groups "visible"? That is, are the pseudos multi-reg
> pseudos? I wonder
> if there's a more generic way to tame down initregs w/o introducing a new target
> hook.
>
> Btw, initregs is a red herring - it ideally should go away. See PR61810.
>
> So instead of adding to it can you see whether disabling the pass for RISC-V
> works w/o fallout (and add a comment to the PR)? Maybe some more RTL
> literate (in particular DF literate) can look at the remaining issue.
> Richard, did you
> ever have a look into the "issue" that initregs covers up (whatever
> that exactly is)?
>
>
> No, sorry. I don't really understand what it would be from the comment
> in the code:
>
> [...] papers over some problems on the arm and other
> processors where certain isa constraints cannot be handled by gcc.
> These are of the form where two operands to an insn my not be the
> same. The ra will only make them the same if they do not
> interfere, and this can only happen if one is not initialized.
>
> That would definitely be an RA bug if true, since the constraints need
> to be applied independently of dataflow information. But the comment
> and code predate LRA and maybe no-one fancied poking around in reload
> (hard to believe).
>
> I'd be very surprised if LRA gets this wrong.
>
>
> OK, we're wondering since quite some time - how about changing the
> gate of initregs to optimize > 0 && !targetm.lra_p ()? We'll hopefully
> figure out the "real" issue the pass is papering over. At the same time
> we're leaving old reload (and likely unmaintianed) targets unaffected.
>
> Richard,
>
> So this patch is not necessary ?
>
> I need to disable this pass in my situation only ?
> I am afraid some side effect in my projects without this init-regs pass … ...
>
>
> Can you try disabling the pass on RISC-V?
>
> Okay, I will do the test on GCC version 10.2, is it ok ?
> It will take a few days :)
>
> Or which version do you suggest to do this ?

Well, as recent as possible - I would at least suggest 11.2,
but trunk would be best of course.

Richard.

> Richard.
>
> Richard.
>
> Thanks,
> Richard