public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "danglin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94 Date: Sun, 12 Nov 2023 15:05:22 +0000 [thread overview] Message-ID: <bug-112415-4-qaGuOLXWL6@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-112415-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #40 from John David Anglin <danglin at gcc dot gnu.org> --- Jeff, I don't think these split instructions make a lot of sense on PA-RISC. (insn 280 277 281 30 (set (reg/f:SI 20 %r20 [480]) (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]) (const_int 396 [0x18c]))) "../Python/compile.c":5970:20 120 {addsi3} (nil)) (insn 281 280 284 30 (set (mem:SI (reg/f:SI 20 %r20 [480]) [4 MEM[(int *)_107 + 396B]+0 S4 A32]) (reg:SI 12 %r12 [orig:134 vect_pretmp_36.2452 ] [134])) "../Python/compile.c":5970:20 42 {*pa.md:2193} (nil)) They increase code size and register pressure. That may lead to unnecessary spills and longer branches. They increase probability of problems like the one in this PR. I suspect the two instructions generated are actually slower than one with a nonzero memory offset. It's not clear that memory accesses with a zero offset are faster than ones with nonzero offsets. Integer loads and stores on pa support fairly large offsets. I think we need to look at why this happens frequently. Thoughts?
next prev parent reply other threads:[~2023-11-12 15:05 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-06 21:00 [Bug rtl-optimization/112415] New: [14 regression] Python 3.11 miscompiled " sjames at gcc dot gnu.org 2023-11-06 21:00 ` [Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA " sjames at gcc dot gnu.org 2023-11-06 21:01 ` sjames at gcc dot gnu.org 2023-11-06 21:03 ` pinskia at gcc dot gnu.org 2023-11-06 21:31 ` dave.anglin at bell dot net 2023-11-06 22:09 ` sjames at gcc dot gnu.org 2023-11-06 22:11 ` sjames at gcc dot gnu.org 2023-11-06 22:20 ` law at gcc dot gnu.org 2023-11-06 22:33 ` dave.anglin at bell dot net 2023-11-06 22:49 ` sjames at gcc dot gnu.org 2023-11-06 23:11 ` sjames at gcc dot gnu.org 2023-11-06 23:18 ` dave.anglin at bell dot net 2023-11-07 14:08 ` manolis.tsamis at vrull dot eu 2023-11-07 21:12 ` sjames at gcc dot gnu.org 2023-11-08 1:36 ` sjames at gcc dot gnu.org 2023-11-08 2:24 ` dave.anglin at bell dot net 2023-11-08 10:09 ` manolis.tsamis at vrull dot eu 2023-11-08 14:42 ` jeffreyalaw at gmail dot com 2023-11-08 18:59 ` dave.anglin at bell dot net 2023-11-08 19:07 ` pinskia at gcc dot gnu.org 2023-11-08 19:16 ` law at gcc dot gnu.org 2023-11-08 19:40 ` dave.anglin at bell dot net 2023-11-08 23:33 ` pinskia at gcc dot gnu.org 2023-11-08 23:40 ` danglin at gcc dot gnu.org 2023-11-08 23:51 ` sjames at gcc dot gnu.org 2023-11-09 0:00 ` dave.anglin at bell dot net 2023-11-09 0:02 ` sjames at gcc dot gnu.org 2023-11-09 0:07 ` law at gcc dot gnu.org 2023-11-09 0:08 ` dave.anglin at bell dot net 2023-11-09 0:23 ` dave.anglin at bell dot net 2023-11-09 18:04 ` danglin at gcc dot gnu.org 2023-11-09 19:17 ` danglin at gcc dot gnu.org 2023-11-09 20:28 ` law at gcc dot gnu.org 2023-11-09 20:41 ` dave.anglin at bell dot net 2023-11-09 23:41 ` danglin at gcc dot gnu.org 2023-11-11 19:40 ` danglin at gcc dot gnu.org 2023-11-11 19:51 ` sjames at gcc dot gnu.org 2023-11-11 20:00 ` danglin at gcc dot gnu.org 2023-11-11 20:06 ` danglin at gcc dot gnu.org 2023-11-11 20:19 ` sjames at gcc dot gnu.org 2023-11-11 21:54 ` danglin at gcc dot gnu.org 2023-11-12 15:05 ` danglin at gcc dot gnu.org [this message] 2023-11-12 15:54 ` law at gcc dot gnu.org 2023-11-12 23:59 ` danglin at gcc dot gnu.org 2023-11-13 0:24 ` law at gcc dot gnu.org 2023-11-13 9:33 ` manolis.tsamis at vrull dot eu 2023-11-13 9:37 ` manolis.tsamis at vrull dot eu 2023-11-13 13:20 ` manolis.tsamis at vrull dot eu 2023-11-13 15:06 ` dave.anglin at bell dot net 2023-11-13 15:26 ` manolis.tsamis at vrull dot eu 2023-11-13 21:46 ` danglin at gcc dot gnu.org 2023-11-16 17:43 ` cvs-commit at gcc dot gnu.org 2023-11-27 20:55 ` sjames at gcc dot gnu.org 2023-11-28 12:39 ` manolis.tsamis at vrull dot eu 2024-03-18 0:22 ` cvs-commit at gcc dot gnu.org 2024-03-18 0:39 ` danglin at gcc dot gnu.org 2024-03-22 13:34 ` law 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-112415-4-qaGuOLXWL6@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).