From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DA5503858D39; Mon, 25 Mar 2024 16:59:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DA5503858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1711385969; bh=zZqSQwsvH9q7uX/jfclZSUY7DaXJk0xfdxWbUZJZTRM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JKAiM99AbvhvMrCm5oFPD30We3QEcokb6GNJRP4BniWmdPUfL7aTfWRJAr1giZrZk lKCuGjeNRTarvYYcrRCY07T3SVkxJKm45LKzFgTJADNAV6TqbaQoz8vnFfy+rBExx/ XMcIDcuMUWI07cWfKSuGG6SxXKW29dvU1ujdJLYE= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826 Date: Mon, 25 Mar 2024 16:59:28 +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: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D114415 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sayle at gcc dot gnu.org, | |uros at gcc dot gnu.org, | |vmakarov at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Seems it is lr_shrinkage pass where things go wrong. In bar0, all the 3 calls the function makes have 2 64-byte arguments (plus 64-byte return passed by hidden reference). -Oz apparently uses -mno-accumulate-outgoing-args, allocates some stack and then have (at least initially) before each of the 3 calls two spots which decrement %rsp by 64 = and after each call one spot which increments %rsp by 128. csa merges the first %rsp -=3D 64 with the previous much larger %rsp decrem= ent and in some cases the %rsp +=3D 128 with following %rsp -=3D 64. The function sets %r12 to be the REG_ARGS_SIZE 64 %rsp level and %rbx to be= the REG_ARGS_SIZE 128 %rsp level, i.e. %rbx =3D %r12 - 64. In asmcons pass, we still have before the call to bar1 %rsp -=3D 64; rep_mo= vsi (fills in the second argument); %rsp -=3D 64; rep_movsi (fills in the first argument). But then lr_shrinkage pass moves both the stack decrements after all the rep_movsi calls, so we then have: (insn 60 71 66 2 (parallel [ (set (reg/f:DI 7 sp) (plus:DI (reg/f:DI 7 sp) (const_int -64 [0xffffffffffffffc0]))) (clobber (reg:CC 17 flags)) ]) "pr114415.c":27:8 272 {*adddi_1} (expr_list:REG_UNUSED (reg:CC 17 flags) (expr_list:REG_ARGS_SIZE (const_int 64 [0x40]) (nil)))) (insn 66 60 72 2 (parallel [ (set (reg/f:DI 7 sp) (plus:DI (reg/f:DI 129) (const_int -64 [0xffffffffffffffc0]))) (clobber (reg:CC 17 flags)) ]) "pr114415.c":27:8 272 {*adddi_1} (expr_list:REG_DEAD (reg/f:DI 129) (expr_list:REG_UNUSED (reg:CC 17 flags) (expr_list:REG_ARGS_SIZE (const_int 128 [0x80]) (nil))))) and just set of %rdi and call to bar1. Now, as x86-64 has red zone, this in theory could still work fine (dunno if backend is supposed to have some barriers which prevent moving the rep movsl insns across it, unfortunately the fact that it uses some %rsp based addres= s is not visible directly in the insn due to CSE), but then comes peephole2 ;; With -Oz, transform mov $imm,reg to the shorter push $imm; pop reg. and converts the (set (reg:DI %rcx) (const_int 16)) insns to push/pop pair, which when the stack pointer is higher than it should have been causes clobbering of t= he value.=