public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "luoxhu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits Date: Fri, 26 Mar 2021 12:27:10 +0000 [thread overview] Message-ID: <bug-99718-4-A801XIqwMG@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99718-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #15 from luoxhu at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #14) > You still have: > if (VECTOR_MEM_VSX_P (mode)) > { > if (!CONST_INT_P (elt_rtx)) > { > if ((TARGET_P9_VECTOR && TARGET_POWERPC64) || width == 8) > return ..._p9 (...); > else if (TARGET_P8_VECTOR) > return ..._p8 (...); > } > > if (mode == V2DFmode) > insn = gen_vsx_set_v2df (target, target, val, elt_rtx); > > else if (mode == V2DImode) > insn = gen_vsx_set_v2di (target, target, val, elt_rtx); > > else if (TARGET_P9_VECTOR && TARGET_POWERPC64) > { > ... > } > if (insn) > return; > } > > gcc_assert (CONST_INT_P (elt_rtx)); > > while the vector.md condition is VECTOR_MEM_ALTIVEC_OR_VSX_P (<MODE>mode), > i.e. true for TARGET_ALTIVEC for many modes already (V4SI, V8HI, V16QI, V4SF > and > for TARGET_VSX also V2DF and V2DI, right). > I somehow don't see how this can work properly. > Looking at vsx_set_v2df and vsx_set_v2di, neither of them will handle > non-constant elt_rtx (it ICEs on anything but const0_rtx and const1_rtx). > > So, questions: > 1) does the rs6000_expand_vector_set_var_p9 routine for width == 8 (i.e. > V2DImode or V2DFmode?) > handle everything, even when TARGET_P9_VECTOR or TARGET_POWERPC64 is not > true, plain old VSX? Yes. V2DI/V2DF for P8 {BE,LE} {m32,m64} will call rs6000_expand_vector_set_var_p9 instead of xxx_p8. Do you mean Power7 for the plain old VSX? I verified the pr98914.c on Power7, it exactly ICEs on "gcc_assert (CONST_INT_P (elt_rtx));" for both m64 and m32. This is still not fixed by the patch in #c11 yet. For builtin call in rs6000-c.c:altivec_build_resolved_builtin, it is guarded by TARGET_P8_VECTOR, so Power7 doesn't generate IFN VEC_INSERT before. This ICE also comes from internal optimization gimple-isel.c:gimple_expand_vec_set_expr, can_vec_set_var_idx_p doesn't return false due to VECTOR_MEM_ALTIVEC_OR_VSX_P is true when Power7 VSX, change the "if (VECTOR_MEM_VSX_P (mode))" to "if (VECTOR_MEM_ALTIVEC_OR_VSX_P (mode))" in rs6000.c:rs6000_expand_vector_set and remove TARGET_P8_VECTOR in the else branch could fix the ICE on P7 {m32,64}, so this means even P7 VSX could benefit from this optimization, which is different from what discussed before. > 2) what happens if TARGET_P8_VECTOR is false and TARGET_VSX is true and mode > is other than V2DI/V2DF? If I read the code right, it will fall through to > gcc_assert (CONST_INT_P (elt_rtx)); Same like 1)? > 3) what happens if !TARGET_VSX (more specifically, when VECTOR_MEM_VSX_P > (mode) is false. > I see there just the assertion that would fail right away. > Perhaps I'm missing something obvious and those cases are impossible, but if > that is the case, it would still be better to add further assertion at least > to the if (...) else if (...) as else gcc_assert ... Thanks for pointing out, the "gcc_assert (CONST_INT_P (elt_rtx));" should be moved into the "if (!CONST_INT_P (elt_rtx))" condition like you said. gen_vsx_set_v2df and gen_vsx_set_v2di are supposed to handle only const elt_rtx.
next prev parent reply other threads:[~2021-03-26 12:27 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-22 16:32 [Bug target/99718] New: " seurer at gcc dot gnu.org 2021-03-23 2:00 ` [Bug target/99718] " luoxhu at gcc dot gnu.org 2021-03-23 7:26 ` rguenth at gcc dot gnu.org 2021-03-23 7:26 ` rguenth at gcc dot gnu.org 2021-03-23 12:44 ` jakub at gcc dot gnu.org 2021-03-24 1:57 ` luoxhu at gcc dot gnu.org 2021-03-24 20:02 ` segher at gcc dot gnu.org 2021-03-25 15:58 ` jakub at gcc dot gnu.org 2021-03-25 16:31 ` segher at gcc dot gnu.org 2021-03-25 16:37 ` dje at gcc dot gnu.org 2021-03-25 16:38 ` dje at gcc dot gnu.org 2021-03-25 16:55 ` jakub at gcc dot gnu.org 2021-03-26 5:37 ` luoxhu at gcc dot gnu.org 2021-03-26 5:38 ` luoxhu at gcc dot gnu.org 2021-03-26 6:14 ` luoxhu at gcc dot gnu.org 2021-03-26 8:22 ` jakub at gcc dot gnu.org 2021-03-26 12:27 ` luoxhu at gcc dot gnu.org [this message] 2021-03-26 13:26 ` jakub at gcc dot gnu.org 2021-03-26 22:39 ` segher at gcc dot gnu.org 2021-03-26 22:51 ` segher at gcc dot gnu.org 2021-03-27 3:42 ` luoxhu at gcc dot gnu.org 2021-03-30 13:57 ` cvs-commit at gcc dot gnu.org 2021-03-31 0:55 ` luoxhu 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-99718-4-A801XIqwMG@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).