From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 58D3239540B5 for ; Thu, 17 Nov 2022 02:09:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 58D3239540B5 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1036.google.com with SMTP id o7so386325pjj.1 for ; Wed, 16 Nov 2022 18:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kHcStLQClxeLmfESrJI1+r++tBeF/9244gKVKJv3xAM=; b=UHngfLPXrixrksAGbfAxoSGcRi29lsYYAdwMmCNv9OA8yqv0JibK1h3SfRwrEEaCOx 4LGOL/JWdShR9XVCeSJd0yxKe6QbNqYnDR+ywQlEZi9wHzSN26TU9c+QVg7/UoFc37tO f00HVCBQEXvie/TTxM8V8OLj9g/QoLlX801cZSA05sfOtpBqG06209A2A0c0HweOOkfz tx1Htga6u2Z7dfn56isZw5k5RJUxGrG4f3jCg4W31kClsdNbE3BHCe7ahS3fP4Tl/yue LxRn+SDt82NXjqPvXRrd4bxgUzHeIu5jDX1JJDVmMhbf60bgTv3LP1+N3kkyw2fNDasV 5Q2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kHcStLQClxeLmfESrJI1+r++tBeF/9244gKVKJv3xAM=; b=jO7+CbmdtqBaPva4fX5EUJ0wRwKGfDFYQYB3YYxHlyhYopZXNbKkg2WXwNG+daxKS0 izjbFGjTnUjHnqpbhw3G1S3QlU2caF/6OWHae7Kbalt1naMDHhn9GSHw/Py6+NRZ1PXE gwJ99qT3OUn7WnxcOBJJPOug8N4WAadCzIUetAW3KxZAcE7DSLtYAx49mrxAuMsRfv9Q Sj0gL3lF0WIqLnFVkIvwdExd7XAKPngNbQmjLEQ15Es2tjmTKSQx7dvdLOCWEwc6d8DT BbW0q0U1zQzqaKfr+FvPrqLQwOcL2q+wtSlCE+Sp/CvMFffiBeXkn8t6iBC3bqPd7Jb/ hwpA== X-Gm-Message-State: ANoB5plN3B1lChFSgK1s+tVdnYyVcT33Q7zSsiYTYwMp4l3Jew2pdvUN B6KtU40+cUG0dxCKWh5x5eU= X-Google-Smtp-Source: AA0mqf65fnZRlAwJdM3eZJC6Jmt7de2qhPoAL3hSwDrXfPA7dMoG3TI56IeL8iALlLV+Y4miYC5UcQ== X-Received: by 2002:a17:902:c385:b0:186:fe2e:7eb0 with SMTP id g5-20020a170902c38500b00186fe2e7eb0mr694501plg.55.1668650963188; Wed, 16 Nov 2022 18:09:23 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id t15-20020a170902e84f00b001885dbe31dfsm13090166plg.178.2022.11.16.18.09.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Nov 2022 18:09:22 -0800 (PST) Message-ID: <802c4244-a6a2-974b-558e-223dd2909791@gmail.com> Date: Wed, 16 Nov 2022 19:09:20 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] Enable shrink wrapping for the RISC-V target. Content-Language: en-US To: Manolis Tsamis Cc: Palmer Dabbelt , jlaw@ventanamicro.com, gcc-patches@gcc.gnu.org, Vineet Gupta , Kito Cheng , philipp.tomsich@vrull.eu References: <111429e6-460c-5d83-ace5-8948b0c75363@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,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 List-Id: 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. jeff