[Bug c/113014] New: RISC-V: Redundant zeroing instructions in reduction

[Bug c/113014] New: RISC-V: Redundant zeroing instructions in reduction

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

            Bug ID: 113014
           Summary: RISC-V: Redundant zeroing instructions in reduction
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

#define DEF_REDUC_PLUS(TYPE)                                                  
\
  TYPE __attribute__ ((noinline, noclone))                                    
\
  reduc_plus_##TYPE (TYPE *__restrict a, int n)                               
\
  {                                                                           
\
    TYPE r = 0;                                                               
\
    for (int i = 0; i < n; ++i)                                               
\
      r += a[i];                                                              
\
    return r;                                                                 
\
  }

#define TEST_PLUS(T) T (int) T (float)

TEST_PLUS (DEF_REDUC_PLUS)

-fno-vect-cost-model:

        li      a5,0             ---> redundant instruction
        vsetivli        zero,1,e32,m1,ta,ma
        vmv.s.x v2,a5

It should be vmv.s.x v2,zero instead.

I realize this is because this commit:
https://hub.fgit.cf/gcc-mirror/gcc/commit/6223ea766daf7c9155106b9784302442e2ff98d3

we change define_expand into define_insn_and_split, since split1 is after
combine pass.

we missed optimization of (vec_duplicate:const0_rtx) into (const_vector:0).

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

--- Comment #1 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Richard S has a late combine PASS which is going to be merged in GCC-14.

Since we generate this following RTL int split1:

(insn 48 24 49 5 (set (reg:SI 149)
        (const_int 0 [0])) -1
     (nil))

(insn 49 48 50 5 (set (reg:RVVM1SI 148)
        (if_then_else:RVVM1SI (unspec:RVVMF32BI [
                    (const_vector:RVVMF32BI [
                            (const_int 1 [0x1])
                            repeat [
                                (const_int 0 [0])
                            ]
                        ])
                    (const_int 1 [0x1])
                    (const_int 2 [0x2]) repeated x2
                    (const_int 0 [0])
                    (reg:SI 66 vl)
                    (reg:SI 67 vtype)
                ] UNSPEC_VPREDICATE)
            (vec_duplicate:RVVM1SI (reg:SI 149))
            (unspec:RVVM1SI [
                    (reg:SI 0 zero)
                ] UNSPEC_VUNDEF))) -1
     (nil))

I suspect late-combine PASS can combine it into:

(insn 49 48 50 5 (set (reg:RVVM1SI 148)
        (if_then_else:RVVM1SI (unspec:RVVMF32BI [
                    (const_vector:RVVMF32BI [
                            (const_int 1 [0x1])
                            repeat [
                                (const_int 0 [0])
                            ]
                        ])
                    (const_int 1 [0x1])
                    (const_int 2 [0x2]) repeated x2
                    (const_int 0 [0])
                    (reg:SI 66 vl)
                    (reg:SI 67 vtype)
                ] UNSPEC_VPREDICATE)
            (CONST_VECTOR: 0)
            (unspec:RVVM1SI [
                    (reg:SI 0 zero)
                ] UNSPEC_VUNDEF))) -1
     (nil))

that is: combine

(set(reg0) (0)) and (vec_duplicate:reg0) 

into:

(CONST_VECTOR:0)

after split1 by late-combine PASS.

I am not sure.

Hi,Robin. Could you confirm it for me ?

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

[rdapp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

--- Comment #2 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Yes, that's right.

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

--- Comment #3 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Robin Dapp from comment #2)
> Yes, that's right.

It seems that I don't need to optimize it since we will eventually have
late-combine.

Could you tell what status of late-combine PASS ?

Will it be landed on GCC-14?

Btw, I want this PASS, so that we can do vv->vx transformation.

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

[rdapp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014

--- Comment #4 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Richard has posted it and asked for reviews.  I have tested it and we have
several testsuite regressions with it but no severe ones.  Most or all of them
are dump fails because we combine into vx variants that would be vv variants
before.
I replied to Richard's post mentioning that we would very much like to see that
go in because it helps us generate the code we want.
To me it appears very likely that it will land.