public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ewlu at rivosinc dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable
Date: Wed, 15 Nov 2023 18:10:08 +0000	[thread overview]
Message-ID: <bug-112531-4-ag1UzJeLbj@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-112531-4@http.gcc.gnu.org/bugzilla/>

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"

  parent reply	other threads:[~2023-11-15 18:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14 19:12 [Bug target/112531] New: " ewlu at rivosinc dot com
2023-11-14 22:13 ` [Bug target/112531] " juzhe.zhong at rivai dot ai
2023-11-15 10:28 ` rdapp at gcc dot gnu.org
2023-11-15 18:10 ` ewlu at rivosinc dot com [this message]
2023-11-15 19:51 ` rdapp at gcc dot gnu.org
2023-11-21 23:28 ` palmer at gcc dot gnu.org
2023-11-26  4:36 ` pinskia at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-112531-4-ag1UzJeLbj@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).