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 middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu Date: Mon, 13 Feb 2023 14:33:48 +0000 [thread overview] Message-ID: <bug-108102-4-FTTrl2HBfh@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108102-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Stefan Schulze Frielinghaus <stefansf@gcc.gnu.org>: https://gcc.gnu.org/g:452db716d8debb6e09b85e4a0c0e73a047ed5c1d commit r13-5964-g452db716d8debb6e09b85e4a0c0e73a047ed5c1d Author: Stefan Schulze Frielinghaus <stefansf@linux.ibm.com> Date: Mon Feb 13 15:33:38 2023 +0100 IBM zSystems: Do not propagate scheduler state across basic blocks [PR108102] So far we propagate scheduler state across basic blocks within EBBs and reset the state otherwise. In certain circumstances the entry block of an EBB might be empty, i.e., no_real_insns_p is true. In those cases scheduler state is not reset and subsequently wrong state is propagated to following blocks of the same EBB. Since the performance benefit of tracking state across basic blocks is questionable on modern hardware, simply reset the state for each basic block. Fix also resetting f{p,x}d_longrunning. gcc/ChangeLog: PR target/108102 * config/s390/s390.cc (s390_bb_fallthru_entry_likely): Remove. (struct s390_sched_state): Initialise to zero. (s390_sched_variable_issue): For better debuggability also emit the current side. (s390_sched_init): Unconditionally reset scheduler state.
next prev parent reply other threads:[~2023-02-13 14:33 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-14 16:22 [Bug rust/108102] New: " doko at gcc dot gnu.org 2022-12-14 17:00 ` [Bug rust/108102] " jakub at gcc dot gnu.org 2022-12-15 10:20 ` marxin at gcc dot gnu.org 2022-12-23 18:27 ` stefansf at linux dot ibm.com 2022-12-23 18:33 ` [Bug middle-end/108102] " pinskia at gcc dot gnu.org 2022-12-23 20:58 ` stefansf at linux dot ibm.com 2022-12-23 21:06 ` pinskia at gcc dot gnu.org 2022-12-24 10:05 ` stefansf at linux dot ibm.com 2022-12-24 10:07 ` stefansf at linux dot ibm.com 2023-01-16 9:43 ` stefansf at linux dot ibm.com 2023-01-16 9:44 ` stefansf at linux dot ibm.com 2023-01-16 9:45 ` stefansf at linux dot ibm.com 2023-01-16 9:46 ` stefansf at linux dot ibm.com 2023-01-30 14:39 ` stefansf at linux dot ibm.com 2023-02-07 10:17 ` doko at gcc dot gnu.org 2023-02-07 10:28 ` stefansf at linux dot ibm.com 2023-02-13 14:33 ` cvs-commit at gcc dot gnu.org [this message] 2023-02-13 15:50 ` stefansf at linux dot ibm.com
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-108102-4-FTTrl2HBfh@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).