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] New: [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable Date: Tue, 14 Nov 2023 19:12:57 +0000 [thread overview] Message-ID: <bug-112531-4@http.gcc.gnu.org/bugzilla/> (raw) 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.
next reply other threads:[~2023-11-14 19:12 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-14 19:12 ewlu at rivosinc dot com [this message] 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 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@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: linkBe 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).