[Bug target/112853] New: RISC-V: RVV: SPEC2017 525.x264 regression

[Bug target/112853] New: RISC-V: RVV: SPEC2017 525.x264 regression

[vineetg at gcc dot gnu.org]

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

            Bug ID: 112853
           Summary: RISC-V: RVV: SPEC2017 525.x264 regression
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vineetg at gcc dot gnu.org
                CC: juzhe.zhong at rivai dot ai, patrick at rivosinc dot com,
                    rdapp at gcc dot gnu.org
  Target Milestone: ---

As of commit 3d104d93a701 ("ARC: Consistent use of whitespace in assembler
templates.") x264 build for RVV is segfaulting.

```
QEMU_CPU=rv64,vlen=256,zba=true,zbb=true,zbs=true,zicond=true,vext_spec=v1.0,Zve32f=true,Zve64f=true
qemu-riscv64  ./ldecod_r_base.rivos_rv64-m64 -i BuckBunny.264 -o BuckBunny.yuv

Setting Default Parameters...
Parsing Configfile decoder.cfg

----------------------------- JM 17.1 (FRExt) -----------------------------
--------------------------------------------------------------------------
 Input H.264 bitstream                  : BuckBunny.264 
 Output decoded YUV                     : BuckBunny.yuv 
 Input reference file                   : test_rec.yuv 
--------------------------------------------------------------------------
POC must = frame# or field# for SNRs to be correct
--------------------------------------------------------------------------
  Frame          POC  Pic#   QP    SnrY     SnrU     SnrV   Y:U:V Time(ms)
--------------------------------------------------------------------------
 Input reference file                   : test_rec.yuv does not exist 
                                          SNR values are not available
Segmentation fault (core dumped)
```

It was fine at my prev checkpoint: 
2023-11-22 6f59f959e751 hppa: Define MAX_FIXED_MODE_SIZE

Built with following flags

-Ofast -fno-lto -static -march=rv64gcv_zba_zbb_zbc_zbs_zicond -ftree-vectorize
--param=riscv-autovec-preference=scalable

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[vineetg at gcc dot gnu.org]

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

--- Comment #1 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
Currently bisecting.

The issue happens at an indexed load insn:

=> 0x6f656 <intrapred_16x16_normal+668>:        vluxei64.v      v2,(a3),v2

The src reg v2 is different in good vs. failing case

bad case
----------
info reg v2
     b = {0xc0, 0xcf, 0xb6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x40, 0xc5, 0xb6, 0x0
<repeats 21 times>}}

good case
---------
     b = {0xc0, 0xcf, 0xb6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x40, 0xc5, 0xb6, 0x0,
0x0, 0x0, 0x0, 0x0, 0xc0, 0xcf, 0xb6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x40, 0xb0,
0xb6, 0x0, 0x0, 0x0, 0x0, 0x0}}

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[vineetg at gcc dot gnu.org]

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

--- Comment #2 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
Bisected to

commit 97ddebb6b4f6b132b0a8072b26d030077b418963
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date:   Thu Nov 23 18:55:03 2023 +0800

    RISC-V: Refine some codes of riscv-v.cc[NFC]

    This patch is NFC patch to refine unreasonable codes I notice.

    Tested on zvl128b/zvl256b/zvl512b/zvl1024b no regression.

    Committed.

    gcc/ChangeLog:

            * config/riscv/riscv-v.cc (emit_vlmax_gather_insn): Refine codes.
            (emit_vlmax_masked_gather_mu_insn): Ditto.
            (modulo_sel_indices): Ditto.
            (expand_vec_perm): Ditto.
            (shuffle_generic_patterns): Ditto.

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[juzhe.zhong at rivai dot ai]

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

--- Comment #3 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Confirm. I will have a look at it.

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[juzhe.zhong at rivai dot ai]

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

--- Comment #4 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Could you give me a test ?

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[rdapp at gcc dot gnu.org]

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

--- Comment #5 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Can confirm.  The scalable build works with qemu vlen=128 but fails with
vlen=256.  That's a good data point as I'm not sure we're already covering this
with the current runs?

I'm going to start a testsuite run with -march=rv64gcv_zvl128b and qemu
vlen=256 to look for fallout.  Maybe this will already give us a clue before
extracting an x264 test case.

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[rdapp at gcc dot gnu.org]

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

--- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I indeed see more failures with _zvl128b, vlen=256 (than with _zvl128b,
vlen=128):

FAIL: gcc.dg/vect/pr66251.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr66251.c execution test
FAIL: gcc.dg/vect/pr66253.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr66253.c execution test
FAIL: gcc.dg/vect/slp-46.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/slp-46.c execution test
FAIL: gcc.dg/vect/vect-alias-check-10.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-alias-check-10.c execution test
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-alias-check-11.c execution test
FAIL: gcc.dg/vect/vect-alias-check-12.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-alias-check-12.c execution test
FAIL: gcc.dg/vect/vect-alias-check-18.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-alias-check-18.c execution test

FAIL: gfortran.dg/array_constructor_4.f90   -O1  execution test
FAIL: gfortran.dg/associate_18.f08   -O1  execution test
FAIL: gfortran.dg/vector_subscript_8.f90   -O1  execution test
FAIL: gfortran.dg/vector_subscript_8.f90   -O2  execution test
FAIL: gfortran.dg/vector_subscript_8.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/vector_subscript_8.f90   -O3 -g  execution test

FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution,  -O1
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution,  -O2
-fbounds-check
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution,  -O2
-fomit-frame-pointer -finline-functions
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution,  -O3 -g

Maybe those can give a hint.

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[rdapp at gcc dot gnu.org]

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

--- Comment #7 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Ah, forgot three tests:

FAIL: gcc.dg/vect/bb-slp-cond-1.c execution test
FAIL: gcc.dg/vect/bb-slp-pr101668.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/bb-slp-pr101668.c execution test

On vlen=512

gfortran.dg/array_constructor_4.f90
gfortran.dg/vector_subscript_8.f90
gfortran.fortran-torture/execute/in-pack.f90

are gone again, the rest is similar.  Are those the unstable ones?

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[rdapp at gcc dot gnu.org]

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

--- Comment #8 from Robin Dapp <rdapp at gcc dot gnu.org> ---
With Juzhe's latest fix that disables VLS modes >= 128 bit for zvl128b x264
runs without issues here and some of the additional execution failures are
gone.

Will post the current comparison later.

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

https://gcc.gnu.org/g:d9dd06ad51b7479f09acb88adf404664a1e18b2a

commit r14-6404-gd9dd06ad51b7479f09acb88adf404664a1e18b2a
Author: Robin Dapp <rdapp@ventanamicro.com>
Date:   Fri Dec 8 12:50:01 2023 +0100

    RISC-V: Recognize stepped series in expand_vec_perm_const.

    We currently try to recognize various forms of stepped (const_vector)
    sequence variants in expand_const_vector.  Because of complications with
    canonicalization and encoding it is easier to identify such patterns
    in expand_vec_perm_const_1 already where perm.series_p () is available.

    This patch introduces shuffle_series as new permutation pattern and
    tries to recognize series like [base0 base1 base1 + step ...].  If such
    a series is found the series is expanded by expand_vec_series and a
    gather is emitted.

    On top the patch fixes the step recognition in expand_const_vector
    for stepped series where such a series would end up before.

    This fixes several execution failures when running code compiled for a
    scalable vector size of 128 on a target with vlen = 256 or higher.
    The problem was only noticed there because the encoding for a reversed
    [2 2]-element vector ("3 2 1 0") is { [1 2], [0 2], [1 4] }.

    Some testcases that failed were:
    vect-alias-check-18.c
    vect-alias-check-1.F90
    pr64365.c

    On a 128-bit target, only the first two elements are used.  The
    third element causing the complications only comes into effect at
    vlen = 256.

    With this patch the testsuite results are similar with vlen = 128,
    vlen = 256 as well as vlen = 512 (apart from the fixed-vlmax tests of
    course).

    gcc/ChangeLog:

            PR target/112853

            * config/riscv/riscv-v.cc (expand_const_vector):  Fix step
            calculation.
            (modulo_sel_indices): Also perform modulo for variable-length
            constants.
            (shuffle_series): Recognize series permutations.
            (expand_vec_perm_const_1): Add shuffle_series.

[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression

[rdapp at gcc dot gnu.org]

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

--- Comment #10 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I just realized that I forgot to post the comparison recently.  With the patch
now upstream I don't see any differences for zvl128b and different vlens
anymore.  What I haven't fully tested yet is zvl256b or higher with various
vlens.