From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 8E2B1385841C for ; Thu, 3 Nov 2022 00:26:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E2B1385841C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pl1-x636.google.com with SMTP id c2so388744plz.11 for ; Wed, 02 Nov 2022 17:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=IJYIILSTtUjBgpx2f0oixvAwDieEJgeChYArT1c7ZXo=; b=RnCJylbm2QLLTJG2PG/jpmVzoszCgZcZLCZDZvHr7L+2xP0uXW2LKRK6hzWjulkLFD Vj/xZ4Vziy2DD1JuYrmmhgCRLRrxWpscsRkTEdgEAvrORbRJtQ8uWayMUxjPyWQUy34p 4tLRibO6B7uCPoQKxKDN+sCr2DzkK6z379ZE5tEOKyG2TKB8S5EEfiOaRO83F5+vI2Zy H0n3RY5SopmJ/kn65WTuS/E/PP6uuYgpY13rNbWvCb/P9znEk/Yg/oWSMFhp+9iIamWl sXUl4J+sX5mf0GTnvzn1LqvSybtZlUVQCJfA6UEYBWU6Q4B0wdZ+1W0edbEcEQgzMlal 2sxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IJYIILSTtUjBgpx2f0oixvAwDieEJgeChYArT1c7ZXo=; b=IegfzFkFm0TJ1M/nXIpZ6Ve1ARQs7TnnECX2HtcKD7SM+bF4h9ReYzRVhKGeB+ZvM6 K/Db6Lp0NKFgjr6nxi4rEg1Ne5Lbz8oIihI7lOZSPCC8KdavYQaZNmp8bkOLXTdIX/Ju AGWMwVzaKeGn6o5nVnE174Odd+5McMVPoEZrGoeQ/T2spRvhDn3TiE03NCHe4Jkp8hh+ tzVGFDJui4TFd73mqIy+SzD4AtD0xJ6C6QR5YYIJCJx4uqEbL8pSWXMeGxk74mw224g0 NQjYwq0miuamJkvSmieiO7O1flnSSaV+OPvaZTK407jMaZ3C0b8PGVV3FJNEyotf0kdi dgCA== X-Gm-Message-State: ACrzQf3/AkCnN8JR2SrMyTH/+uJZkO3QS32DKc5vcD1qVtURzSFMfJyA dKrPD2i1hZyWrFXzLfb/bG2lDQ== X-Google-Smtp-Source: AMsMyM5IkSB3CtbConZekkeyhg/g+PxWKRaAk/EA7TEAB+dTXgSbV+Uwbj9WNayECTqdqCkPLaGE+w== X-Received: by 2002:a17:902:bb90:b0:187:2f46:41a0 with SMTP id m16-20020a170902bb9000b001872f4641a0mr13929600pls.108.1667435180294; Wed, 02 Nov 2022 17:26:20 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id w66-20020a628245000000b0056bc67f9da8sm9039629pfd.63.2022.11.02.17.26.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 17:26:19 -0700 (PDT) Date: Wed, 02 Nov 2022 17:26:19 -0700 (PDT) X-Google-Original-Date: Wed, 02 Nov 2022 17:26:20 PDT (-0700) Subject: Re: [PATCH] Enable shrink wrapping for the RISC-V target. In-Reply-To: <4afcf3c0-690c-1168-b5e2-b6542b85d8e9@ventanamicro.com> CC: manolis.tsamis@vrull.eu, Vineet Gupta , gcc-patches@gcc.gnu.org, Kito Cheng , philipp.tomsich@vrull.eu From: Palmer Dabbelt To: jlaw@ventanamicro.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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 Wed, 02 Nov 2022 08:06:36 PDT (-0700), jlaw@ventanamicro.com wrote: > > 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. Ah, sorry, I must have just missed that when reading the code. In that case we're essentailly just doing what the other port was, so we're safe. >> 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.