public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/113135] [14 regression] ICE when building unrar (error: PHI node with wrong VUSE on edge from BB 46)
Date: Fri, 12 Jan 2024 15:32:33 +0000	[thread overview]
Message-ID: <bug-113135-4-xLqT2f22HW@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-113135-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113135

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:6cb155a6cf314232248a12bdd395ed4151ae5a28

commit r14-7194-g6cb155a6cf314232248a12bdd395ed4151ae5a28
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Fri Jan 12 15:24:49 2024 +0000

    middle-end: make memory analysis for early break more deterministic
[PR113135]

    Instead of searching for where to move stores to, they should always be in
    exit belonging to the latch.  We can only ever delay stores and even if we
    pick a different exit than the latch one as the main one, effects still
    happen in program order when vectorized.  If we don't move the stores to
the
    latch exit but instead to whever we pick as the "main" exit then we can
    perform incorrect memory accesses (luckily these are trapped by
verify_ssa).

    We used to iterate over the conds and check the loads and stores inside
them.
    However this relies on the conds being ordered in program order. 
Additionally
    if there is a basic block between two conds we would not have analyzed it.

    Instead this now walks from the preds of the destination basic block up to
the
    loop header and analyzes every block along the way.  As a later
optimization we
    could stop as soon as we've seen all the BBs we have conds for.  For now
the
    header will always contain the first cond, but this can change when we
support
    arbitrary control flow.

    gcc/ChangeLog:

            PR tree-optimization/113135
            * tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
Rework
            dependency analysis.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/113135
            * gcc.dg/vect/vect-early-break_103-pr113135.c: New test.

      parent reply	other threads:[~2024-01-12 15:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-25 12:08 [Bug tree-optimization/113135] New: " sjames at gcc dot gnu.org
2023-12-25 12:09 ` [Bug tree-optimization/113135] " sjames at gcc dot gnu.org
2023-12-25 12:10 ` sjames at gcc dot gnu.org
2023-12-25 15:04 ` sjames at gcc dot gnu.org
2023-12-25 15:21 ` sjames at gcc dot gnu.org
2023-12-26 14:06 ` tnfchris at gcc dot gnu.org
2024-01-12 15:32 ` cvs-commit at gcc dot gnu.org [this message]

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-113135-4-xLqT2f22HW@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).