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?

  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: 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).