From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6C6203858418; Thu, 19 Oct 2023 07:27:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6C6203858418 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1697700449; bh=AkdTq0sLz9/Yp/owOoGaqwybzgcxMMipjFt1t33CGPc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Bm5Kl05laDbBTpD4heerdsmiS9z/kGyqyOoEPeTiIgWotNfJfV4kfxGlj8YfFJ+fk VEsOToCv50WLYoNTAgvLTSbitgS1FVllZiDE/UqHMcz4dowIuZFP3gcJUD1FNO+tJr QKJ7Qa9g0kqqErSHhHhwsqXtTxTYXsKs7vi3nv+w= From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3 Date: Thu, 19 Oct 2023 07:27:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.2.0 X-Bugzilla-Keywords: needs-bisection X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111591 --- Comment #21 from Kewen Lin --- For optimized IR: a$raw$3_220 =3D D.39813.rawD.30221[3]; vect_a_raw_4_70.539_1584 =3D MEM [(short intD.20 *)&D.39813 + 8B]; _1640 =3D a$raw$0_221 & 255; _1649 =3D a$raw$1_74 & 255; _1658 =3D a$raw$2_264 & 255; _52 =3D a$raw$3_220 & 255; vD.39776 =3D bD.39739; // involved decl1 MEM [(charD.5 * {ref-all})&b00D.39742] =3D MEM [(charD.5 * {ref-all})&vD.39776]; vD.39776 =3D{v} {CLOBBER(eol)}; vD.39779 =3D b00D.39742; // involved decl2 raw_u_1614 =3D vD.39779.rawD.30221[0]; _1615 =3D raw_u_1614 << 8; vD.39779.rawD.30221[0] =3D _1615; raw_u_1622 =3D vD.39779.rawD.30221[1]; _1623 =3D raw_u_1622 << 8; vD.39779.rawD.30221[1] =3D _1623; ... Partition 1: size 16 align 16 D.39819 vD.39749 vD.39756 vD.39764 aD.39773=20= =20=20=20=20=20=20 vD.39779 vD.39735 vD.39736 aD.39630 vD.39636=20= =20=20=20=20=20=20 aD.39640 vD.39753 vD.39761 vD.39776 vD.39782 vD.39776 and vD.39779 are coalesced. It's expanded as: vD.39776 =3D bD.39739;=20=20=20=20 (insn 383 382 384 (set (reg:V2DI 616) (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars) (const_int 48 [0x30])) [7 MEM[(struct Vec128D.30433 *)_1274= ]+0 S16 A128])) -1 (nil)) (insn 384 383 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars) (const_int 16 [0x10])) [7 MEM[(struct Vec128D.30433 *)_10]+0 S16 A128]) (reg:V2DI 616)) -1 (nil)) MEM [(charD.5 * {ref-all})&b00D.39742] =3D MEM [(charD.5 * {ref-all})&vD.39776]; (insn 385 384 386 (set (reg:V2DI 617) (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars) (const_int 16 [0x10])) [0 MEM [(cha= rD.5 * {ref-all})_10]+0 S16 A128])) "test.cc":14:19 -1 (nil)) (insn 386 385 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars) (const_int 80 [0x50])) [0 MEM [(cha= rD.5 * {ref-all})_1277]+0 S16 A128]) (reg:V2DI 617)) "test.cc":14:19 -1 (nil)) vD.39776 =3D{v} {CLOBBER(eol)}; vD.39779 =3D b00D.39742; (insn 387 386 388 (set (reg:V2DI 618) (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars) (const_int 80 [0x50])) [5 MEM[(struct Vec128D.30212 *)_1277= ]+0 S16 A128])) -1 (nil)) (insn 388 387 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars) (const_int 16 [0x10])) [5 MEM[(struct Vec128D.30212 *)_10]+0 S16 A128]) (reg:V2DI 618)) -1 (nil)) raw_u_1614 =3D vD.39779.rawD.30221[0]; _1615 =3D raw_u_1614 << 8; vD.39779.rawD.30221[0] =3D _1615; ;; v.raw[0] =3D _1615; (insn 389 388 390 (set (reg:HI 619) (mem/c:HI (plus:DI (reg/f:DI 112 virtual-stack-vars) (const_int 16 [0x10])) [4 MEM[(struct Vec128D.30212 *)_10].rawD.30221[0]+0 S2 A128])) "test.cc":218:14 -1 (nil)) (insn 390 389 391 (set (reg:SI 620) (ashift:SI (subreg:SI (reg:HI 619) 0) (const_int 8 [0x8]))) "test.cc":218:14 -1 (nil)) (insn 391 390 0 (set (mem/c:HI (plus:DI (reg/f:DI 112 virtual-stack-vars) (const_int 16 [0x10])) [4 MEM[(struct Vec128D.30212 *)_10].rawD.30221[0]+0 S2 A128]) (subreg:HI (reg:SI 620) 2)) "test.cc":218:14 -1 (nil)) =3D=3D=3D=3D=3D=3D=3D=3D=3D Later, insn 388 gets removed (also insn 387 and 385), as the store value is exactly the same as what insn 384 has. And the scheduler doesn't consider t= here is a dependence between insn 389 and insn 384 then results in unexpected mo= ve. Hi Richi, do you think that this is exactly duplicated of known -fstack-reu= se issue?=