From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id E233E385277D for ; Thu, 20 Oct 2022 07:43:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E233E385277D 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-x22c.google.com with SMTP id by36so25201646ljb.4 for ; Thu, 20 Oct 2022 00:43:16 -0700 (PDT) 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=Pezv5IcyYBAsnBJnMq9j88NLceWI1NkgRJxRCLLVRcw=; b=fiZDpMz5WqL3raqKxYXgbjkpx47eL8094fOqEz1O5BhNgBTyIf0+Cdl0ejVVlcEtn4 lu6sdPnsSE7Fqg6lJkqyfeJdgaUYMzPWSW9wnKQ6S48N72GK8qkC5MuMM6o2z9wSC/9p XLjMY4SbjBSSnOrivOf6RppQQ+8A86ch5sLQYEtkGVHpnMY3PBjDr1Obo/kWorqRtTY6 tAAj1VF/tFhvFhXRqTVlCvah3p0s2vUWpQGLsyaMyaiFLYb08a39xvHnkZ1q1bYwLBy4 POBFAOmxEU3IJ57gkC8pwKM0HM3klP2E7wguAv/3vwbeFSMOf1dct2pHJwQRiGDmYzKu 4zlg== 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=Pezv5IcyYBAsnBJnMq9j88NLceWI1NkgRJxRCLLVRcw=; b=thCXWeCj3B+suQ5AXuYb4428WcI7l9A34WmGAt2zRAtvGUprargAS9tDyQD8dm0m19 eLscHFVxSMBQN1IUIIPhN/4WfAbl27VuGvHyHkBQOoajKsdvG//2O8+Jc2SqMaBLAiCl TzyHjGJ3RcRqZS+W/lJ+GjPHIRqdckcnmYzbkUS0pipR8jet9gZYmxHGL2+USYisoAFL tuOQ45X6ssmw712pTP7G21q/XQO67l8lcSfLcJyK3Y5WuRChCFFV9cbgINL9yjpdA/Of isxC12tC9E9B/EbexBMXk4t6YziXQA8xmHZ0cIY2GQEvJqSWQS8kmJkz7nKkhaPBV4KD ZUbg== X-Gm-Message-State: ACrzQf1fiaaFdpbMJZFRWPK9+6UTgBGZwShJ0jg99bhIGPTZZcH7MRom MDjyqYR7NSOq0jqNtTGjml/X8hncXWYlQKU0im65oQ== X-Google-Smtp-Source: AMsMyM7QibRZqzFpdOW+mX+cX0H6E+0GAcaFTvSX9k2XosfsQmX/Q5+LbXy1v4MLt3mmIqmgIjupGJD9dvOvAMmJa4c= X-Received: by 2002:a2e:7818:0:b0:26d:fdb9:46b7 with SMTP id t24-20020a2e7818000000b0026dfdb946b7mr4310223ljc.298.1666251795262; Thu, 20 Oct 2022 00:43:15 -0700 (PDT) MIME-Version: 1.0 References: <08273c28-07ff-3170-679b-225d60a9ee2d@gmail.com> In-Reply-To: <08273c28-07ff-3170-679b-225d60a9ee2d@gmail.com> From: Manolis Tsamis Date: Thu, 20 Oct 2022 10:42:39 +0300 Message-ID: Subject: Re: [PATCH] Enable shrink wrapping for the RISC-V target. To: Jeff Law Cc: Palmer Dabbelt , jlaw@ventanamicro.com, gcc-patches@gcc.gnu.org, Vineet Gupta , Kito Cheng , philipp.tomsich@vrull.eu Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,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: On Wed, Oct 19, 2022 at 8:16 PM Jeff Law via Gcc-patches wrote: > > > On 10/18/22 11:35, Palmer Dabbelt wrote: > > > >> I would have expected things to work fine with libcalls, perhaps with > >> the exception of the save/restore libcalls. So that needs deeper > >> investigation. > > > > The save/restore libcalls only support saving/restoring a handful of > > register configurations (just the saved X registers in the order > > they're usually saved in by GCC). It should be OK for correctness to > > over-save registers, but it kind of just un-does the shrink wrapping > > so not sure it's worth worrying about at that point. > > > > There's also some oddness around the save/restore libcall ABI, it's > > not the standard function ABI but instead a GCC-internal one. IIRC it > > just uses the alternate link register (ie, t0 instead of ra) but I may > > have forgotten something else. > > I hadn't really dug into it -- I was pretty sure they weren't following > the standard ABI based on its name and how I've used similar routines to > save space on some targets in the past. So if we're having problems > with shrink-wrapping and libcalls, those two might be worth investigating. > > > But I think the most important takeaway is that shrink wrapping should > work with libcalls, there's nothing radically different about libcalls > that would make them inherently interact poorly with shrink-wrapping. > So that aspect of the shrink-wrapping patch needs deeper investigation. > Based on the feedback from both of you that shrink wrapping and libcall save/restore should work fine I'll try to lift that restriction again and investigate further what happens. Manolis > Jeff