From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by sourceware.org (Postfix) with ESMTPS id 41373389839C for ; Sun, 13 Nov 2022 01:32:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 41373389839C 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-oa1-x30.google.com with SMTP id 586e51a60fabf-12c8312131fso9200947fac.4 for ; Sat, 12 Nov 2022 17:32:36 -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=TWmPN9DYYCG5b5/MJ5WWxyumVe+U20WtW0M1MWydyYo=; b=aOHVTQp1j1FCrDdb1/Yh0Ti5j7JRXW1QNdCkvArsS4ZOCeankZN7pTXbFH5oKk6x+b l9ZT5C45rwig5OyI08g7WQMiz5DqVUvAk+mWbkoAq8PYnUlfLV1Of1d1STLywHKtMdbX RqPEMIG1topb3eQXaNj4LVztK6ov0pgFMR1lLTz3x/kf+IvsV2ySdNXkd9kVc3LLOCA1 rjdY/jCeQnm9FScEKymZ8A1t/3J0xILDXsCDbjO59Xr6TPcDre016Se5W9gQlmGeEMXe mx9Cr+WBpnjO8WCt+XofAMnhd6BH/p28aSfh8uQW0I73Za03e+JzVP1IxFb/r31+wt31 EDhA== 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=TWmPN9DYYCG5b5/MJ5WWxyumVe+U20WtW0M1MWydyYo=; b=V6vqruYywAhyeJblx1Wh47vZq3UK2OpbhLuVoOHQphIJVqbteYhmdStUhwaXEZ53gk /PeVWVNCShUqRK9I22G9GrU7SpRCIMTtPd/aCVmL+bC3sN1wFk4A45KIW7eL9I+rpLBi /8n8a02Q9edxBApB4UyWwBOsKXJ+QtklLBx1Dmzhz+Z9N1Uf4gNpCqMitx69eAex/n3b xUvwkgxtyBxbqcZMyzP7VG7CJW52vQ8ePPOvgfyWrwB60maVzhbg8bYLCTqKO42ETHko aqB2LucgCRhfk73BJ2DfxoYx6iwr5k24ur3qYwzqFsO2G1F8nlTH6KIoVTgLYt3J7L+g yXqA== X-Gm-Message-State: ANoB5pm51Xw/E5Mzg44MzWa08pyigdNrE/tVIWSqCFpPA2pmrPBzZuaO qFMYHBfCyX7oV5eFQKRdG8M= X-Google-Smtp-Source: AA0mqf4c0sea7nEwhEcGLi7KNuFgTqbg7Eu9y7jONQcBDMyNlwYxoMgTsTLVOBAK51XDIZQUIrmQ5g== X-Received: by 2002:a05:6870:1495:b0:13a:f2d0:e7b4 with SMTP id k21-20020a056870149500b0013af2d0e7b4mr3975282oab.262.1668303155441; Sat, 12 Nov 2022 17:32:35 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id b7-20020a056870470700b0011f00b027bdsm3220923oaq.45.2022.11.12.17.32.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Nov 2022 17:32:34 -0800 (PST) Message-ID: <111429e6-460c-5d83-ace5-8948b0c75363@gmail.com> Date: Sat, 12 Nov 2022 18:32:32 -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: Palmer Dabbelt , jlaw@ventanamicro.com Cc: gcc-patches@gcc.gnu.org, Vineet Gupta , Kito Cheng , philipp.tomsich@vrull.eu References: 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.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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/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. Jeff