public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tnfchris at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/113134] gcc does not version loops with side-effect early breaks Date: Wed, 27 Dec 2023 15:21:46 +0000 [thread overview] Message-ID: <bug-113134-4-Arr5OtNwr5@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-113134-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134 Tamar Christina <tnfchris at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2023-12-25 00:00:00 |2023-12-27 Summary|Middle end early break |gcc does not version loops |vectorization: Fail to |with side-effect early |vectorize a simple early |breaks |break code | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Tamar Christina <tnfchris at gcc dot gnu.org> --- So GCC's approach is much different than clang. I think this should be handled by IVcannon as it makes the vectorizer code much easier. At the moment the vectorizer assumes that any exit it sees are actually needed. So even if I relax my patch to allow this we still produce a pointless compare. Looking at IVcannon it does for a constant sized array: Loop 1 iterates 1001 times. Loop 1 iterates at most 999 times. Loop 1 likely iterates at most 999 times. Analyzing # of iterations of loop 1 exit condition [0, + , 1](no_overflow) <= 1000 bounds on difference of bases: 1000 ... 1000 result: # of iterations 1001, bounded by 1001 Removed pointless exit: if (i_13 > 1000) but for the example attached: Loop 1 iterates 1001 times. Loop 1 iterates at most 1001 times. Loop 1 likely iterates at most 1001 times. Analyzing # of iterations of loop 1 exit condition [1, + , 1](no_overflow) < N_13(D) bounds on difference of bases: 0 ... 2147483646 It has correctly determined that the loop bounds is at most 1001 but since N can be < 1001 it doesn't think the additional exit is useless. However like clang we can just version the loop. Unlike clang however we can probably do better. if N >= 1000 then we can enter the vector code without the additional exit, but if N < 1000 we can use my new pass. It's not hard to allow this through the pass, but I doubt this will be accepted in stage3.. For best result the loop should be versioned like clang does. Richi?
next prev parent reply other threads:[~2023-12-27 15:21 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-12-25 11:29 [Bug c/113134] New: Middle end early break vectorization: Fail to vectorize a simple early break code juzhe.zhong at rivai dot ai 2023-12-25 12:35 ` [Bug c/113134] " tnfchris at gcc dot gnu.org 2023-12-27 15:21 ` tnfchris at gcc dot gnu.org [this message] 2023-12-28 1:21 ` [Bug c/113134] gcc does not version loops with early break conditions that don't have side-effects juzhe.zhong at rivai dot ai 2023-12-28 3:48 ` tnfchris at gcc dot gnu.org 2023-12-28 3:55 ` juzhe.zhong at rivai dot ai 2023-12-28 4:02 ` tnfchris at gcc dot gnu.org 2023-12-28 4:05 ` tnfchris at gcc dot gnu.org 2023-12-28 4:23 ` juzhe.zhong at rivai dot ai 2023-12-28 4:30 ` tnfchris at gcc dot gnu.org 2023-12-28 4:35 ` juzhe.zhong at rivai dot ai 2023-12-28 4:45 ` tnfchris at gcc dot gnu.org 2023-12-28 4:46 ` juzhe.zhong at rivai dot ai 2023-12-28 4:49 ` tnfchris at gcc dot gnu.org 2023-12-28 4:51 ` juzhe.zhong at rivai dot ai 2023-12-28 4:53 ` tnfchris at gcc dot gnu.org 2023-12-28 5:08 ` tnfchris at gcc dot gnu.org 2023-12-28 9:11 ` juzhe.zhong at rivai dot ai 2023-12-28 21:20 ` [Bug tree-optimization/113134] " pinskia at gcc dot gnu.org 2024-01-08 8:11 ` rguenth at gcc dot gnu.org 2024-01-31 11:48 ` juzhe.zhong at rivai dot ai 2024-01-31 12:04 ` rguenth at gcc dot gnu.org 2024-02-02 3:38 ` juzhe.zhong at rivai dot ai 2024-02-02 8:49 ` juzhe.zhong at rivai dot ai
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-113134-4-Arr5OtNwr5@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).