From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by sourceware.org (Postfix) with ESMTPS id 24C373858C2C for ; Wed, 22 Dec 2021 10:26:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24C373858C2C Received: by mail-qv1-xf33.google.com with SMTP id kd9so1887280qvb.11 for ; Wed, 22 Dec 2021 02:26:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cV6u6zNJFmi+FcEIcrbzhQA/3CRHJwrpzNIL3f4EWmg=; b=q1FMoiMDhUgVTVLhnRaXfe7ZkoeD9LgvRsuAXRL/zUKMW9+9434RxjsxOiZPa/rW6c KFhSwT12lpPGL7G88Oda3BsMBp3a6rVLcdYFlqBPAI4ulJLZkshv5VU9FcBVc/ejhNjQ dxn5LFVbbPKjSLng56XNBBI30gvXuttsaFOUaacaBFyohS0ysytXbr8qVf669UXn25IX 6sdW0q5YIFq0fgrzYSgQtPyRo6RChxumXoGh63wpUj9vpEov10Q8gmKtGVK6u4Roswbh ft9P29icoMHut5zM4hAyvhQgykqKWlMbUJcKT8ur7Qcr4Gn061PV3dEOwbgGYrhbOCic caUg== X-Gm-Message-State: AOAM530f6ntLHUuA6kQzvD47T4PfcUtuhCmtv/emgpv0G0Bbg4L/bRJM 5Hz61fokBUKuMcrccFY+Javn0OapGFuqbPIWIBdIL7IA2d8= X-Google-Smtp-Source: ABdhPJzLe3e33BZQz8jbZuAs+d0uLujhoSfLNb0Fp1JFmutpwRV/PnRGo2GfUPjJgwRqYJQ0zXaSpvS/e5J4nQ9WK2k= X-Received: by 2002:a05:6214:301e:: with SMTP id ke30mr1849375qvb.2.1640168783684; Wed, 22 Dec 2021 02:26:23 -0800 (PST) MIME-Version: 1.0 References: <00f501d7f666$26b93cd0$742bb670$@nextmovesoftware.com> <005201d7f715$f6ec63a0$e4c52ae0$@nextmovesoftware.com> In-Reply-To: <005201d7f715$f6ec63a0$e4c52ae0$@nextmovesoftware.com> From: Uros Bizjak Date: Wed, 22 Dec 2021 11:26:11 +0100 Message-ID: Subject: Re: [PATCH] PR target/103773: Fix wrong-code with -Oz from pop to memory. To: Roger Sayle Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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-List-Received-Date: Wed, 22 Dec 2021 10:26:25 -0000 On Wed, Dec 22, 2021 at 10:26 AM Roger Sayle wrote: > > > Hi Uros, > Would you consider the following variant that disables this optimization when a > red zone is used by the current function? You're right that cfun's red_zone_size is > recalculated dynamically, but ix86_red_zone_used should be a better "gate" given > that this logic resides very late during compilation, in the output templates, where > whether or not a red zone is used is known. > > On CSiBE, disabling this optimization in non-leaf functions that use a red zone costs > 219 bytes, but remains a significant win over -Os. (Alas the absolute numbers aren't > comparable as this testing included the 0/-1 write to memory changes). > > Tested (overnight) on x86_64-pc-linux-gnu with make bootstrap and make -k check > with no new failures. > > 2021-12-22 Roger Sayle > > gcc/ChangeLog > PR target/103773 > * config/i386/i386.md (*movdi_internal): Only use short > push/pop sequence for register (non-memory) destinations > when the current function doesn't make use of a red zone. > (*movsi_internal): Likewise. > > gcc/testsuite/ChangeLog > PR target/103773 > * gcc.target/i386/pr103773.c: New test case. > > Please let me know what you think. I'll revert, if this tweak doesn't address > your concerns. Yes, using ix86_red_zone_used looks safe. OTOH, is there a reason the transformation is not implemented via peephole2 pass? IIRC, frame is stable after pro_and_epilogue_pass, and peephole2 pass is instanced well after register allocation. Uros.