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 bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
Date: Wed, 29 Nov 2023 08:18:21 +0000	[thread overview]
Message-ID: <bug-111601-4-TuPxt1GxEA@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-111601-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #25 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:9582538cf07d83d7e80553827de8b0f91e4705d8

commit r14-5955-g9582538cf07d83d7e80553827de8b0f91e4705d8
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Nov 29 09:14:03 2023 +0100

    fold-mem-offsets: Fix powerpc64le-linux profiledbootstrap [PR111601]

    The introduction of the fold-mem-offsets pass breaks profiledbootstrap
    on powerpc64le-linux.
    From what I can see, the pass works one basic block at a time and
    will punt on any non-DEBUG_INSN uses outside of the current block
    (I believe because of the
              /* This use affects instructions outside of CAN_FOLD_INSNS.  */
              if (!bitmap_bit_p (&can_fold_insns, INSN_UID (use)))
                return 0;
    test and can_fold_insns only set in do_analysis (when processing insns in
    current bb, cleared at the end) or results of get_single_def_in_bb
    (which are checked to be in the same bb).
    But, while get_single_def_in_bb checks for
      if (DF_INSN_LUID (def) > DF_INSN_LUID (insn))
        return NULL;
    The basic block in the PR in question has:
    ...
    (insn 212 210 215 25 (set (mem/f:DI (reg/v/f:DI 10 10 [orig:152 last_viable
] [152]) [2 *last_viable_336+0 S8 A64])
            (reg/f:DI 9 9 [orig:155 _342 ] [155])) "pr111601.ii":50:17 683
{*movdi_internal64}
         (expr_list:REG_DEAD (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
            (nil)))
    (insn 215 212 484 25 (set (reg:DI 5 5 [226])
            (const_int 0 [0])) "pr111601.ii":52:12 683 {*movdi_internal64}
         (expr_list:REG_EQUIV (const_int 0 [0])
            (nil)))
    (insn 484 215 218 25 (set (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
            (reg/f:DI 9 9 [orig:155 _342 ] [155])) "pr111601.ii":52:12 683
{*movdi_internal64}
         (nil))
    ...
    (insn 564 214 216 25 (set (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
            (plus:DI (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
                (const_int 96 [0x60]))) "pr111601.ii":52:12 66 {*adddi3}
         (nil))
    (insn 216 564 219 25 (set (mem/f:DI (reg/v/f:DI 10 10 [orig:152 last_viable
] [152]) [2 _343->next+0 S8 A64])
            (reg:DI 5 5 [226])) "pr111601.ii":52:12 683 {*movdi_internal64}
         (expr_list:REG_DEAD (reg:DI 5 5 [226])
            (nil)))
    ...
    and when asking for all uses of %r10 from def 564, it will see uses
    in 216 and 212; the former is after the += 96 addition and gets changed
    to load from %r10+96 with the addition being dropped, but there is
    the other store which is a use across the backedge and when reached
    from other edges certainly doesn't have the + 96 addition anywhere,
    so the pass doesn't actually change that location.

    This patch adds checks from get_single_def_in_bb to get_uses as well,
    in particular check that the (regular non-debug) use only appears in the
    same basic block as the definition and that it doesn't appear before it
(i.e.
    use across backedge).

    2023-11-29  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/111601
            * fold-mem-offsets.cc (get_uses): Ignore DEBUG_INSN uses. 
Otherwise,
            punt if use is in a different basic block from INSN or appears
before
            INSN in the same basic block.  Formatting fixes.
            (get_single_def_in_bb): Formatting fixes.
            (fold_offsets_1, pass_fold_mem_offsets::execute): Comment
formatting
            fixes.

            * g++.dg/opt/pr111601.C: New test.

  parent reply	other threads:[~2023-11-29  8:18 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap " doko at gcc dot gnu.org
2023-09-26 17:15 ` [Bug bootstrap/111601] " pinskia at gcc dot gnu.org
2023-10-17  2:11 ` bergner at gcc dot gnu.org
2023-10-18 13:31 ` doko at gcc dot gnu.org
2023-10-18 19:48 ` bergner at gcc dot gnu.org
2023-10-18 20:41 ` bergner at gcc dot gnu.org
2023-10-18 20:53 ` pinskia at gcc dot gnu.org
2023-10-18 21:26 ` bergner at gcc dot gnu.org
2023-10-19  6:23 ` rguenth at gcc dot gnu.org
2023-11-17  5:33 ` jeevitha at gcc dot gnu.org
2023-11-24 19:59 ` jakub at gcc dot gnu.org
2023-11-26 21:36 ` [Bug bootstrap/111601] [14 Regression] profilebootstrap " jakub at gcc dot gnu.org
2023-11-27 11:37 ` jakub at gcc dot gnu.org
2023-11-27 12:24 ` rguenther at suse dot de
2023-11-27 12:27 ` jakub at gcc dot gnu.org
2023-11-27 13:31 ` jakub at gcc dot gnu.org
2023-11-27 13:51 ` jakub at gcc dot gnu.org
2023-11-27 15:14 ` jakub at gcc dot gnu.org
2023-11-27 16:21 ` jakub at gcc dot gnu.org
2023-11-27 16:45 ` jakub at gcc dot gnu.org
2023-11-27 16:57 ` jakub at gcc dot gnu.org
2023-11-27 17:01 ` jakub at gcc dot gnu.org
2023-11-27 18:33 ` jakub at gcc dot gnu.org
2023-11-27 19:24 ` jakub at gcc dot gnu.org
2023-11-27 20:02 ` jakub at gcc dot gnu.org
2023-11-27 20:17 ` jakub at gcc dot gnu.org
2023-11-29  8:18 ` cvs-commit at gcc dot gnu.org [this message]
2023-11-29  8:31 ` jakub at gcc dot gnu.org
2023-11-30 17:20 ` jeevitha 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-111601-4-TuPxt1GxEA@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).