public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dave.anglin at bell dot net" <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: Mon, 13 Nov 2023 15:06:18 +0000 [thread overview]
Message-ID: <bug-112415-4-imzLRde9xr@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 #47 from dave.anglin at bell dot net ---
On 2023-11-13 4:33 a.m., manolis.tsamis at vrull dot eu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #44 from Manolis Tsamis <manolis.tsamis at vrull dot eu> ---
> (In reply to John David Anglin from comment #39)
>> In the f-m-o pass, the following three insns that set call clobbered
>> registers r20-r22 are pulled from loop:
>>
>> (insn 186 183 190 29 (set (reg/f:SI 22 %r22 [478])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 388 [0x184]))) "../Python/compile.c":5964:9 120
>> {addsi3}
>> (nil))
>> (insn 190 186 187 29 (set (reg/f:SI 21 %r21 [479])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 392 [0x188]))) "../Python/compile.c":5964:9 120
>> {addsi3}
>> (nil))
>> (insn 194 191 195 29 (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":5964:9 120
>> {addsi3}
>> (nil))
>>
>> They are used in the following insns before call to compiler_visit_expr1:
>>
>> (insn 242 238 258 32 (set (mem:SI (reg/f:SI 22 %r22 [478]) [4 MEM[(int
>> *)prephit
>> mp_37 + 388B]+0 S4 A32])
>> (reg:SI 23 %r23 [orig:173 vect__102.2442 ] [173]))
>> "../Python/compile.c"
>> :5968:22 42 {*pa.md:2193}
>> (expr_list:REG_DEAD (reg:SI 23 %r23 [orig:173 vect__102.2442 ] [173])
>> (expr_list:REG_DEAD (reg/f:SI 22 %r22 [478])
>> (nil))))
>> (insn 258 242 246 32 (set (reg:SI 26 %r26)
>> (reg/v/f:SI 5 %r5 [orig:198 c ] [198]))
>> "../Python/compile.c":5969:15 42 {*pa.md:2193}
>> (nil))
>> (insn 246 258 250 32 (set (mem:SI (reg/f:SI 21 %r21 [479]) [4 MEM[(int
>> *)prephitmp_37 + 392B]+0 S4 A32])
>> (reg:SI 29 %r29 [orig:169 vect__102.2443 ] [169]))
>> "../Python/compile.c":5968:22 42 {*pa.md:2193}
>> (expr_list:REG_DEAD (reg:SI 29 %r29 [orig:169 vect__102.2443 ] [169])
>> (expr_list:REG_DEAD (reg/f:SI 21 %r21 [479])
>> (nil))))
>> (insn 250 246 254 32 (set (mem:SI (reg/f:SI 20 %r20 [480]) [4 MEM[(int
>> *)prephitmp_37 + 396B]+0 S4 A32])
>> (reg:SI 31 %r31 [orig:145 vect__102.2444 ] [145]))
>> "../Python/compile.c":5968:22 42 {*pa.md:2193}
>> (expr_list:REG_DEAD (reg:SI 31 %r31 [orig:145 vect__102.2444 ] [145])
>> (expr_list:REG_DEAD (reg/f:SI 20 %r20 [480])
>> (nil))))
>>
>> After the call, we have:
>>
>> (insn 1241 269 273 30 (set (reg/f:SI 22 %r22 [478])
>> (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
>> "../Python/compile.c":5970:20 -1
>> (nil))
>> (insn 273 1241 1242 30 (set (mem:SI (plus:SI (reg/f:SI 22 %r22 [478])
>> (const_int 388 [0x184])) [4 MEM[(int *)_107 + 388B]+0 S4
>> A32])
>> (reg:SI 14 %r14 [orig:167 vect_pretmp_36.2450 ] [167]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>> (insn 1242 273 277 30 (set (reg/f:SI 21 %r21 [479])
>> (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
>> "../Python/compile.c":5970:20 -1
>> (nil))
>> (insn 277 1242 1243 30 (set (mem:SI (plus:SI (reg/f:SI 21 %r21 [479])
>> (const_int 392 [0x188])) [4 MEM[(int *)_107 + 392B]+0 S4
>> A32])
>> (reg:SI 13 %r13 [orig:156 vect_pretmp_36.2451 ] [156]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>> (insn 1243 277 281 30 (set (reg/f:SI 20 %r20 [480])
>> (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
>> "../Python/compile.c":5970:20 -1
>> (nil))
>> (insn 281 1243 299 30 (set (mem:SI (plus:SI (reg/f:SI 20 %r20 [480])
>> (const_int 396 [0x18c])) [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))
>>
>> We have lost the offsets that were added initially to r20, r21 and r22.
>>
>> Previous ce3 pass had:
>>
>> (insn 272 269 273 30 (set (reg/f:SI 22 %r22 [478])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 388 [0x184]))) "../Python/compile.c":5970:20 120
>> {addsi3}
>> (nil))
>> (insn 273 272 276 30 (set (mem:SI (reg/f:SI 22 %r22 [478]) [4 MEM[(int
>> *)_107 + 388B]+0 S4 A32])
>> (reg:SI 14 %r14 [orig:167 vect_pretmp_36.2450 ] [167]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>> (insn 276 273 277 30 (set (reg/f:SI 21 %r21 [479])
>> (plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
>> (const_int 392 [0x188]))) "../Python/compile.c":5970:20 120
>> {addsi3}
>> (nil))
>> (insn 277 276 280 30 (set (mem:SI (reg/f:SI 21 %r21 [479]) [4 MEM[(int
>> *)_107 + 392B]+0 S4 A32])
>> (reg:SI 13 %r13 [orig:156 vect_pretmp_36.2451 ] [156]))
>> "../Python/compile.c":5970:20 42 {*pa.md:2193}
>> (nil))
>> (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))
>>
>> So, this is a f-m-o bug.
> Hi Dave,
>
> I don't see an f-m-o bug here. The offsets aren't lost, they're just moved in
> the corresponding memory loads/stores. If you look the stores in ce3 they
> don't have offsets whereas after f-m-o they have. E.g. in ce3: (insn 273 272
> 276 30 (set (mem:SI (reg/f:SI 22 %r22 [478]) ...) but in f-m-o it is (insn 273
> 1241 1242 30 (set (mem:SI (plus:SI (reg/f:SI 22 %r22 [478]) (const_int 388
> [0x184]) ...).
>
> This is the way that f-m-o works. It can also be seen in the f-m-o dumps, where
> offsets changes to memory ops are reported as 'Memory offset changed' and
> instructions which got their offset propagated (like insns 272, 276, 280) are
> reported as 'Instruction folded':
Hi Manolis,
If you look at the f-m-o transformation applied to insn 272 and insn 273, you
will see that
"reg/f:SI 22 %r22 [478]" is not dead after these insns. The transformation
changes the value
of r22 which is wrong without changing all uses of the register and adjusting
the other sets
for the register. It only changed the use in insn 273 and not the uses earlier
in the loop.
next prev parent reply other threads:[~2023-11-13 15:06 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
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 [this message]
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-imzLRde9xr@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).