From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 0B63E3857351 for ; Wed, 2 Nov 2022 15:06:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B63E3857351 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-pl1-x62f.google.com with SMTP id g24so16850208plq.3 for ; Wed, 02 Nov 2022 08:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; 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=igHRMWg+lF3otNWHu+gVBQ/GS2RtTVEDFFDb42iQcog=; b=KJ6TXkeavVEIRB4wpCU3cH2zzMuqwpef4dAbT4LNAKXiYQiydCVmiSr+YojP9qfa6l NXLSfr23fIl0Hjpp9+UGYaKEKnsXJqlaXHe5D0YrC44woBpQtEjkpZZsWDvqfjpCUhqc EDlNBH/Vh3oSQEEnJ7BCf+NAb4OpZyB1kuTK6uptO+Yn66C+Ar1CRcWp3ZjYYouMJT+Y LcKz2ZBhznVd19ohVpo7LvwDpQXEAXOqNUlMIcARbrpU/JuN8UCZZVVEiBWkoeK02xK/ UmOBwzVTMBVxDqMi+aEehHrlV41rOrIsPYhniKOPxWSoqV0ePf+Ec9gh1LB1Hnc1Jr69 6KAg== 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=igHRMWg+lF3otNWHu+gVBQ/GS2RtTVEDFFDb42iQcog=; b=ughcChkJn2oUJHgegAFff0ivou+4Kacfgh1HCx8qWC8POZ4W+rgiuEwB4hp3iI6QC0 gEjC8lh8nmOFS41wLw249wzUVuB29BMRfhBZgfEk2OGcs4U6ec6/q8hYKDCl+fKw8X+d Ai0NyYBkj1shee7sbV/tLIiiEV5xBb9xWzoOTnfCsb+jLhYJYeDQ67fYXhhaV8k7Nrjr 7/s6EIIRBCZ+hnPPrIvP8Ffk99Wgdn6Hptdv3cyZ1yzkco43kZRKJazOw6ccXLAGLMQh wFZNvkWz2nHeWLvWZlPOJI/fci+txOP4UCnCxeFq4o9/0OL4FLqfLawaPG+I/y2ZBDHa he/Q== X-Gm-Message-State: ACrzQf1hExyKIRhcRhAR+YVSSrxjAJziSUbC3jI7Ah7iQgb23ZmmRs1g o7Ou8WUlfl74CybUi0wrQODGkg== X-Google-Smtp-Source: AMsMyM7lKyggh9QCgWiSqRdjjHvMwAfNtYIiVGqOxa3UIxsrEXf8PVxv3XZW+QnCfnoHJu8kLsuWVA== X-Received: by 2002:a17:90a:d084:b0:213:8cf1:4d34 with SMTP id k4-20020a17090ad08400b002138cf14d34mr26715621pju.150.1667401599046; Wed, 02 Nov 2022 08:06:39 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id y4-20020aa79e04000000b0056c0d129edfsm8528871pfq.121.2022.11.02.08.06.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Nov 2022 08:06:38 -0700 (PDT) Message-ID: <4afcf3c0-690c-1168-b5e2-b6542b85d8e9@ventanamicro.com> Date: Wed, 2 Nov 2022 09:06:36 -0600 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 , Palmer Dabbelt Cc: gcc-patches@gcc.gnu.org, Vineet Gupta , Kito Cheng , philipp.tomsich@vrull.eu References: <2e2ca1dc-902e-23ca-babf-11a4978530ef@ventanamicro.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=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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/2/22 07:54, Manolis Tsamis wrote: > > I've revisited this testcase and I think it's not possible to make it > work with the current implementation. > It's not possible to trigger shrink wrapping in this case since the > wrapping of registers is guarded by > if (SMALL_OPERAND (offset)) { bitmap_set_bit (components, regno); } > Hence if a long stack is generated we get no shrink wrapping. > > 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. Jeff