[Bug target/112531] New: [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[Bug target/112531] New: [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[ewlu at rivosinc dot com]

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

            Bug ID: 112531
           Summary: [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors
                    with --param=riscv-autovec-preference=scalable
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

As reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311#c8

The following errors are found on trunk
                === gcc: Unexpected fails for rv64gcv lp64d medlow ===
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"

I have bisected it down to this commit r14-701-gb75c9e10379 introducing the
errors.

I have isolated the cause to specifically the change in the expand pass by
running the testsuite with just the refactor (reverting the change to
autovec.md) and saw no change in testsuite results.

Compilation command: 
./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/ 
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/gcc.dg/unroll-8.c 
-march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output  -O2
-fdump-rtl-loop2_unroll-details-blocks -funroll-loops -ffat-lto-objects -S   -o
unroll-8.s --param=riscv-autovec-preference=scalable --fdump-rtl-all
--fdump-tree-all

Observations:
Adding the new define expand pattern changes unroll-8.s to output vector
instructions. Previously only scalar output was generated (previous commit:
r14-700-gaf595613acb.)

The first difference in dump file outputs occurs with the tree dump 172t.vect
where vector variables are added. This is confusing to me since I expected the
first change to be with the rtl expand pass. I believe this may be the cause of
the problem since the optimized tree dump has 

# loop_len_16 = PHI <_31(4), _27(3)>

which affects the analysis of the operands in the loop2_unroll pass.

Analyzing operand (reg:DI 137 [ loop_len_16 ]) of insn (jump_insn 56 54 81 10
(set (pc)
        (if_then_else (ne (reg:DI 137 [ loop_len_16 ])
                (const_int 0 [0]))
            (label_ref:DI 81)
            (pc))) 242 {*branchdi}
     (int_list:REG_BR_PROB 894784862 (nil))
 -> 81)
Checking get reaching def
has more than one reaching def
  not simple.
loop number: 1  Failed to analyze op0: (reg:DI 137 [ loop_len_16 ]) 
Loop 1 is not simple.
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/gcc.dg/unroll-8.c:8:9: note:
considering unrolling loop 1 at BB 6
;; Not unrolling loop, user didn't want it unrolled
starting the processing of deferred insns

loop_len_16 now has multiple reaching definitions since it is the output of a
phi function.

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[juzhe.zhong at rivai dot ai]

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

JuzheZhong <juzhe.zhong at rivai dot ai> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |juzhe.zhong at rivai dot ai

--- Comment #1 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
This FAIL is reasonable. So we can ignore it.

The vectorized code will fail at this dump check like ARM SVE:
https://godbolt.org/z/dbsKb7bxY

Or you can fix testcase like AMDGCN:

disable vectorization:

/* { dg-additional-options "-fno-tree-vectorize" { target amdgcn-*-* } } */

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[rdapp at gcc dot gnu.org]

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

--- Comment #2 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Yes, I'd also argue in favor of -fno-tree-vectorize here.

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[ewlu at rivosinc dot com]

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

--- Comment #3 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to JuzheZhong from comment #1)
> This FAIL is reasonable. So we can ignore it.
> 
> The vectorized code will fail at this dump check like ARM SVE:
> https://godbolt.org/z/dbsKb7bxY
> 
> Or you can fix testcase like AMDGCN:
> 
> disable vectorization:
> 
> /* { dg-additional-options "-fno-tree-vectorize" { target amdgcn-*-* } } */

Should we add this for all of the failures that also occur on arm? That would
be

FAIL: gcc.dg/signbit-2.c scan-tree-dump optimized "\\s+>\\s+{ 0(, 0)+ }"
FAIL: gcc.dg/signbit-2.c scan-tree-dump-not optimized "\\s+>>\\s+31"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"
FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/tree-prof/val-prof-1.c scan-tree-dump optimized "if \\(n_[0-9]* !=
257\\)"
FAIL: gcc.dg/tree-prof/val-prof-3.c scan-tree-dump optimized "if \\(_[0-9]* \\<
n_[0-9]*"
FAIL: gcc.dg/tree-prof/val-prof-4.c scan-tree-dump optimized "if \\(n_[0-9]*
\\>"
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: loop with
[0-9]+ iterations completely unrolled"
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo"
FAIL: gcc.dg/tree-ssa/gen-vect-34.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded by 254"
FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254"
XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Combination" 1
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3
times." 1
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Combination" 2
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3
times." 1
FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing predictive
commoning without unrolling"
FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized
"(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+
(?:vect_)?sum_[\\d._]+|(?:vect_)?sum_[\\d._]+ \\+ (?:vect_)?_[\\d._]+)" 1
FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts " 
Type:\\tREFERENCE ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts " 
Type:\\tREFERENCE ADDRESS\n" 2
FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness wrto loop
niter:\tNo-overflow"
FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts "  Type:\\tREFERENCE
ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths "join
point for if-convertable half-diamond" 1
XPASS: gcc.dg/tree-ssa/ssa-fre-3.c scan-tree-dump fre1 "Replaced \\(int\\)
aa_.*with a_"
FAIL: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times optimized
"Invalid sum" 0

The only dump fails I have been able to confirm on riscv that do not exist on
arm (so far) would be these two:
FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Conditional
combines static and invariant" 1
FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Will duplicate
bb" 2
as seen here https://godbolt.org/z/Yc5aas954

I have yet to confirm these fails on ARM due to compilation failures on
godbolt.
FAIL: gcc.dg/vect/pr103116-1.c -flto -ffat-lto-objects  scan-tree-dump vect
"Data access with gaps requires scalar epilogue loop"
FAIL: gcc.dg/vect/pr103116-1.c scan-tree-dump vect "Data access with gaps
requires scalar epilogue loop"
FAIL: gcc.dg/vect/pr103116-2.c -flto -ffat-lto-objects  scan-tree-dump vect
"peeling for gaps insufficient for access"
FAIL: gcc.dg/vect/pr103116-2.c scan-tree-dump vect "peeling for gaps
insufficient for access"

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[rdapp at gcc dot gnu.org]

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

--- Comment #4 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Personally, I don't mind having some FAILs as long as we know them and
understand the reason for them.   I wouldn't insist on "fixing" them but don't
mind if others prefer to have the results "clean".  Probably a matter of taste.

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[palmer at gcc dot gnu.org]

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

palmer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-11-21
     Ever confirmed|0                           |1
                 CC|                            |palmer at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

--- Comment #5 from palmer at gcc dot gnu.org ---
(In reply to Robin Dapp from comment #4)
> Personally, I don't mind having some FAILs as long as we know them and
> understand the reason for them.   I wouldn't insist on "fixing" them but
> don't mind if others prefer to have the results "clean".  Probably a matter
> of taste.

IIUC every target still has some FAILs, so it's kind of just par for the
course.  That said, if we're going to put the work into root causing the
failure far enough to determine it's invalid then we're most of the way to just
making the failure disappear.  I guess it's a little more work upfront, but
otherwise everyone has to maintain some list of "tests that FAIL, but we're
ignoring".  We had some of that in the riscv-gnu-toolchain allowlist, but even
then it becomes clunky to maintain.

So I think we're unlikely to ever get them all, but at least for the ones that
are somewhat easy to root cause I think we might as well just fix them.  I just
sent along a fix for this one:
https://inbox.sourceware.org/gcc-patches/20231121232704.12336-5-palmer@rivosinc.com/

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|riscv                       |riscv aarch64-*-*
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have the same failure on aarch64 with -march=armv9-a+sve:
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"


https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637835.html