From patchwork Thu Feb 23 09:37:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Max Filippov X-Patchwork-Id: 1746694 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=INbs3s1x; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4PMnyF3b9Gz2462 for ; Thu, 23 Feb 2023 20:38:13 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5FB79385B50C for ; Thu, 23 Feb 2023 09:38:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5FB79385B50C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677145091; bh=tBMFe84AF4L3yTK0LFAWhdf6zsdTwgwuJ575Oh/NfWk=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=INbs3s1xF7NW80dsssTljI9bK24soZPYl+yKywF2M6G5Iix0cILC2jMhcZTi4PN3K GhVCvZykl8Wn4V9UGf8U9g2N0nuHtpq0GmBVYObLyf1Wa4G5J0T55aCePfOLUMA9nB mGoKFLbdsMMDa/bvtcTllqW0+ONMHU/VaN/yAY3M= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id A2C443858C2C for ; Thu, 23 Feb 2023 09:37:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A2C443858C2C Received: by mail-pj1-x1030.google.com with SMTP id k21-20020a17090aaa1500b002376652e160so988964pjq.0 for ; Thu, 23 Feb 2023 01:37:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tBMFe84AF4L3yTK0LFAWhdf6zsdTwgwuJ575Oh/NfWk=; b=lRkx2wdLvs36ndBXHpWT6X4AnioqfHy7qllKNx6LZD1sjJtWzlEjWdt1hft455Yc9j ugOkh/A0dzpKZWOfMOIa8grqcSu2IS27tlN/A63FOlBzgtN5kUZtQhXZYbx4xPWhqy2S HXUluhGmaJ7C3DchPG0oFjHTMfztuKye7mMsxGKw5Lg1j3/yfQxwX/mlcEYIB+TLzz5+ 8JPFkGz8tWXLYPZjzYqMTVlroP96ECF1ea5u7/Hl1+ftt7D1E1j43K2bUtdYLUg5J79s fb73h8wpb13pB8bYpktiftwNaYtwNtugNACMw7//7Q8/dzChTgeMHJRwb3AI6XEV27Nx 8j3w== X-Gm-Message-State: AO0yUKX7Vz9L/2ZBIf4XKmBUOO29qEtu0H1F9q4rPizRgPR3rAZgyA9J kJ3aVcjCS0KuasC08Y3ErRXWyJ91jhU= X-Google-Smtp-Source: AK7set+vCKvzRillM93LBY12Hp91IutoV5vr23FmHyL4z9FQxVk42Zib+c1kYQqreQQ9eG1vM0auUw== X-Received: by 2002:a17:902:e80f:b0:19a:9890:eac6 with SMTP id u15-20020a170902e80f00b0019a9890eac6mr14106821plg.24.1677145069570; Thu, 23 Feb 2023 01:37:49 -0800 (PST) Received: from octofox.hsd1.ca.comcast.net ([2601:641:401:1d20:b799:4456:f689:2be5]) by smtp.gmail.com with ESMTPSA id d5-20020a170902c18500b00198e12c499dsm6354858pld.282.2023.02.23.01.37.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 01:37:49 -0800 (PST) To: gcc-patches@gcc.gnu.org Cc: Takayuki 'January June' Suwa , Max Filippov Subject: [COMMITTED 2/2] xtensa: fix PR target/108876 Date: Thu, 23 Feb 2023 01:37:26 -0800 Message-Id: <20230223093726.3258958-2-jcmvbkbc@gmail.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230223093726.3258958-1-jcmvbkbc@gmail.com> References: <20230223093726.3258958-1-jcmvbkbc@gmail.com> MIME-Version: 1.0 X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, GIT_PATCH_0, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Max Filippov via Gcc-patches From: Max Filippov Reply-To: Max Filippov Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call insn included (use (reg:SI A0_REG)) to fix the problem, which added a USE chain unconditionally to the data flow of register A0 during the sibling call. As a result, df_regs_ever_live_p (A0_REG) returns true, so even if register A0 is not used outside of the sibling call insn, saves and restores to stack slots are emitted in pro/epilogue, and finally code size increases. (This is why I never included (use A0) in sibling calls) /* example */ extern int foo(int); int test(int a) { return foo(a * 3 + 1); } ;; before test: addi sp, sp, -16 ;; unneeded stack frame allocation (induced) s32i.n a0, sp, 12 ;; unneeded saving of register A0 l32i.n a0, sp, 12 ;; unneeded restoration of register A0 addx2 a2, a2, a2 addi.n a2, a2, 1 addi sp, sp, 16 ;; unneeded stack frame freeing (induced) j.l foo, a9 ;; sibling call (truly needs register A0) The essential cause is that we emit (use A0) *before* the insns that does the stack pointer adjustment during epilogue expansion, so the liveness of register A0 ends early, so register A0 is reused afterwards. This patch fixes the problem and avoids such regression by doing the emit of (use A0) in the sibling call epilogue expansion at the end. ;; after test: addx2 a2, a2, a2 addi.n a2, a2, 1 j.l foo, a9 >From RTL-pass "315r.rnreg" by "gfortran -O3 -funroll-loops -mabi=call0 -S -da gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90": ;; Function selector_init (__selectors_MOD_selector_init, funcdef_no=2, decl_uid=987, cgraph_uid=3, symbol_order=4) ... (insn 3807 3806 3808 121 (set (reg:SI 15 a15) (mem/c:SI (plus:SI (reg/f:SI 1 sp) (const_int 268 [0x10c])) [31 S4 A32])) "gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53 {movsi_internal} (nil)) (insn 3808 3807 3809 121 (set (reg:SI 7 a7) (const_int 288 [0x120])) "gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53 {movsi_internal} (nil)) (insn 3809 3808 3810 121 (set (reg/f:SI 1 sp) (plus:SI (reg/f:SI 1 sp) (reg:SI 7 a7))) "gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 1 {addsi3} (expr_list:REG_DEAD (reg:SI 9 a9) (nil))) (insn 3810 3809 721 121 (use (reg:SI 0 a0)) "gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1 (expr_list:REG_DEAD (reg:SI 0 a0) (nil))) (call_insn/j 721 3810 722 121 (call (mem:SI (symbol_ref:SI ("free") [flags 0x41] ) [0 __builtin_free S4 A32]) (const_int 0 [0])) "gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 discrim 1 106 {sibcall_internal} (expr_list:REG_DEAD (reg:SI 2 a2) (expr_list:REG_CALL_DECL (symbol_ref:SI ("free") [flags 0x41] ) (expr_list:REG_EH_REGION (const_int 0 [0]) (nil)))) (expr_list:SI (use (reg:SI 2 a2)) (nil))) (IMHO the "rnreg" pass doesn't take REG_ALLOC_ORDER into account; it just seems to allocate registers in fixed_regs index order, which may have hurt register A0 that became allocatable in the recent patch) gcc/ChangeLog: PR target/108876 * config/xtensa/xtensa.cc (xtensa_expand_epilogue): Emit (use (reg:SI A0_REG)) at the end in the sibling call (i.e. the same place as (return) in the normal call). --- gcc/config/xtensa/xtensa.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc index d0320efe21d4..b80eef5c19ef 100644 --- a/gcc/config/xtensa/xtensa.cc +++ b/gcc/config/xtensa/xtensa.cc @@ -3548,8 +3548,6 @@ xtensa_expand_epilogue (bool sibcall_p) gen_frame_mem (SImode, x)); } } - if (sibcall_p) - emit_use (gen_rtx_REG (SImode, A0_REG)); if (cfun->machine->current_frame_size > 0) { @@ -3575,7 +3573,9 @@ xtensa_expand_epilogue (bool sibcall_p) EH_RETURN_STACKADJ_RTX)); } cfun->machine->epilogue_done = true; - if (!sibcall_p) + if (sibcall_p) + emit_use (gen_rtx_REG (SImode, A0_REG)); + else emit_jump_insn (gen_return ()); }