public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/106192] [11/12/13 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.cc:3522 Date: Tue, 05 Jul 2022 12:53:11 +0000 [thread overview] Message-ID: <bug-106192-4-4ZCi4PFuvj@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-106192-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106192 --- Comment #2 from Michael Matz <matz at gcc dot gnu.org> --- Unroll-and-jam simply unrolls the outer loop and merged all resulting inner-loop bodies. In this situation we have (before unroll-and-jam): outerloop(i_1) { _12 = i_1 <= 59 innerloop(i_1, j by 1) { .GOMP_SIMD_LANE (simduid.6_16(D), 0, _12); ... uninteresting things (j) ... } } Unroll-and-jam then simply does (that's the unrolling): outerloop(i by 2) { _12 = i_1 <= 59 innerloop(i_1, j by 1) { .GOMP_SIMD_LANE (simduid.6_16(D), 0, _12); ... uninteresting things (i, j) ... } i_2 = i_1 + 1 _15 = i_2 <= 59 innerloop(i_2, j by 1) { .GOMP_SIMD_LANE (simduid.6_16(D), 0, _15); ... uninteresting things (i + 1, j) ... } } and then fuses the two inner loops, which means that the instructions between them (the original pre-header of the inner loop) become replicated inside the new inner loop body (here, the loop-invariant condition): outerloop(i by 2) { _12 = i_1 <= 59 innerloop(i_1, j by 1) { .GOMP_SIMD_LANE (simduid.6_16(D), 0, _12); ... uninteresting things (i, j) ... i_2 = i_1 + 1 _15 = i_2 <= 59 .GOMP_SIMD_LANE (simduid.6_16(D), 0, _15); ... uninteresting things (i + 1, j) ... } } There is nothing which somehow would indicate that this is invalid, and I can't see why it should be. If GIMP_SIMD_LANE has properties that make this transformation invalid I would argue that those properties are correctly represented. One could of course hack bb_prevents_fusion_p or unroll_jam_possible_p to avoid this situation, but that would seem like a bad hack, as random other CFG transformation might introduce similar things: namely a GOMP_SIMD_LANE statement that's fed by an unhoisted loop-invariant condition. So, I'd argue the assert is too eager.
next prev parent reply other threads:[~2022-07-05 12:53 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-04 19:43 [Bug fortran/106192] New: " gscfq@t-online.de 2022-07-04 22:31 ` [Bug tree-optimization/106192] " pinskia at gcc dot gnu.org 2022-07-05 8:10 ` rguenth at gcc dot gnu.org 2022-07-05 12:53 ` matz at gcc dot gnu.org [this message] 2022-07-05 12:54 ` matz at gcc dot gnu.org 2022-07-07 12:46 ` [Bug tree-optimization/106192] [11/12/13 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.cc:3522 since r11-1650-g1dfa89b0355520ca marxin at gcc dot gnu.org 2023-05-29 10:07 ` [Bug tree-optimization/106192] [11/12/13/14 " jakub 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-106192-4-4ZCi4PFuvj@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).