From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 68533398641C for ; Thu, 17 Nov 2022 11:59:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 68533398641C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-lj1-x22a.google.com with SMTP id d3so2434332ljl.1 for ; Thu, 17 Nov 2022 03:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DHpGs7AyVj06oSM89Ga6QxeJhT2dXeOEi1u+C6xmKZ4=; b=YJHSiHk05NT6CRcS+VSSnIhVGGFnvoAING3CuWkPesY0uL7mWbSHtnFUfWXsbBefXs IhUWWW81U4GwwUQezNyECdjJ3C113lTukHWHSSlwuxb2Jh+PcAO9lzpn0TlhEuRgiTo5 P6WpJWOFrI31nMioxM5dYfLcXylygPz5HODF821XMIanK1a/X6Wiug7xiiish/Eej8g5 0j8VDg//+CK5bgOXjtQUri7/XOokUdZGNtvfxB6uXhyKV7QmdkDQCsa8VXcnNe7zIozR Tkle9FVwS6uxpNj8a+LiPNpr06rSITB28BIyuzx4PmLl6KGGKPK1+tlmU0ePVTRgvqY9 v1Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DHpGs7AyVj06oSM89Ga6QxeJhT2dXeOEi1u+C6xmKZ4=; b=gEr25f9Z9+HhljtV3hl5tSp2bviYWTRyyapTPh21X5hVHIgpKnc19uF394GHO4xzDP P6inwiMAc+Aq3rfLi6dBjwmyhWy5iA06ArSMyLN54tMwq2elDB+kjLRVrbZzmaDS800m gUxG+xzMjn7gLWP8puruj9FRkruGTDIBszf234TmAOmZBNQhnOf3Fyb4jTvQs8y2Ior1 SmW8vVUQ0SSSjgUpebdvFTZQdgxHf254xW2dN3vfwkHV9vHtU2t4t3HPinD9v++ikukX sfE53s7v4L+u5tJcIfHSqgQOyz+HAO0uSWHgqlhNy7UCkCDapgU++kjOMMJ20oqVIe1T 0JBg== X-Gm-Message-State: ANoB5pnU27PqDFqtJ+wfMkzO5dN8srfnIbRSfPW1zZ7iqgQgJgoWzX1A zc0LCD1N/PrdFBd8dHuEX5USjQeyPiYJKFlvccM3AQ== X-Google-Smtp-Source: AA0mqf7b1Fgy1RwlbsZ9GqmvHIAeA8aHwk2pPEQ8rAmKe+GX71euxg6nDO0gREOCDnAU61zbYsjXH/Vebxy2GDzs8rg= X-Received: by 2002:a2e:8e63:0:b0:26e:6c5:2a6c with SMTP id t3-20020a2e8e63000000b0026e06c52a6cmr962300ljk.36.1668686370509; Thu, 17 Nov 2022 03:59:30 -0800 (PST) MIME-Version: 1.0 References: <111429e6-460c-5d83-ace5-8948b0c75363@gmail.com> <802c4244-a6a2-974b-558e-223dd2909791@gmail.com> In-Reply-To: From: Philipp Tomsich Date: Thu, 17 Nov 2022 12:59:19 +0100 Message-ID: Subject: Re: [PATCH] Enable shrink wrapping for the RISC-V target. To: Manolis Tsamis Cc: Jeff Law , Palmer Dabbelt , jlaw@ventanamicro.com, gcc-patches@gcc.gnu.org, Vineet Gupta , Kito Cheng Content-Type: multipart/alternative; boundary="0000000000005b242405eda952cb" X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,JMQ_SPF_NEUTRAL,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000005b242405eda952cb Content-Type: text/plain; charset="UTF-8" v3 committed to master. Thanks! Philipp. On Thu, 17 Nov 2022 at 11:55, Manolis Tsamis wrote: > On Thu, Nov 17, 2022 at 4:09 AM Jeff Law wrote: > > > > > > On 11/16/22 03:26, Manolis Tsamis wrote: > > > On Sun, Nov 13, 2022 at 3:33 AM Jeff Law via Gcc-patches > > > wrote: > > >> > > >> On 11/7/22 15:07, Palmer Dabbelt wrote: > > >>> On Thu, 03 Nov 2022 15:23:28 PDT (-0700), jlaw@ventanamicro.com > wrote: > > >>>> On 11/2/22 18:26, Palmer Dabbelt wrote: > > >>>>>>> I also tried to remove that restriction but it looks like it > can't > > >>>>>>> work because we can't create > > >>>>>>> pseudo-registers during shrink wrapping and shrink wrapping can't > > >>>>>>> work either. > > >>>>>>> > > >>>>>>> I believe this means that shrink wrapping cannot interfere with a > > >>>>>>> long > > >>>>>>> stack frame > > >>>>>>> so there is nothing to test against in this case? > > >>>>>> It'd be marginally better to have such a test case to ensure we > don't > > >>>>>> shrink wrap it -- that would ensure that someone doesn't > accidentally > > >>>>>> introduce shrink wrapping with large offsets. Just a bit of > future > > >>>>>> proofing. > > >>>>> If there's passing test cases that fail with that check removed > then > > >>>>> it's probably good enough, though I think in this case just having > a > > >>>>> comment there saying why the short-stack check is necessary should > be > > >>>>> fine. > > >>>> I can live with this. > > >>> Which one (or either)? I'm fine with either option, just trying to > > >>> avoid another re-spin as this one is a bit vague. > > >> Sorry I wasn't clear. Either is fine with me. > > >> > > > Since all issues/concerns around this are resolved, is the v2 of this > patch > > > good for merging? > > > > > > Link for v2 patch is > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603822.html > > > > You just need to add a comment to get_separate_components indicating > > that the SMALL_OPERAND_P check is required as we do not support > > shrink-wrapping with large stack frames. > > > > > > OK with that comment. Just post the final version and commit, no need > > to wait for another review. > > > Final version (v3) for commiting is here > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606523.html > > Thanks > > > > jeff > > > --0000000000005b242405eda952cb--