From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id 9536B3858C52 for ; Wed, 2 Nov 2022 14:13:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9536B3858C52 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-lf1-x12c.google.com with SMTP id j16so28414114lfe.12 for ; Wed, 02 Nov 2022 07:13:36 -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=0fmPpC4mQdTUSt1dlz/xvDRYIZfz8Dgmhryu3HGrj3k=; b=sA+BO5ayhEabJmVbthHYTV8jZsiQVJkZeGZi603WF3AADuecPly7MXuhMGeYZuqJ7h akPCdIO+cyCxWKsyP/wAIq7wWsDayiGPVRgG6rwQ0mgseF8G+SqFeK7hcd2krOHTjQj6 1+4NaXJEc++0PPXxy0eaoYlCxxPXiX2PHDZu2EVdzSJ9NL3xk+C81a3Bc6nSxMv4s3pc 6HQjRU8cuYVMCw0AhYX9oL0Hajf1OCKs/avCaoczVqlxyjscHK5Hn95Q1ftWKt2teu5z 6ALBmALs8n6jA1Ryl+lq6/MEpZjhREd85CynmmScBEyOvvX1XqhrIMvVy4sjSHRdHX9O BrfA== 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=0fmPpC4mQdTUSt1dlz/xvDRYIZfz8Dgmhryu3HGrj3k=; b=w+/MLsjhOfUvhimFaoFQdgV0Z3xVUJxOHwWI7Sv2XoXjr6Di5uUO4DSa38WjqJGj9A RIYO60zggf4QdKkcyQU3P0uyFSCWuCzRr5WHMmG3ssS5vtN5DNYnFjFZgLfbYiV3Vn5Q TJymdLnBTeJrm7LksJXkH782NQhcQT4SDU3yrAe8OpInjAAEI18i22FS3DbHS3R9Mxp7 ugqBTDSoSh+fVLzQmsax4C4dUMyS3qCBevaUGMpvUA4UuUG5nawNvqZL3eo37Uv+GW2l tran6N8EL+SKT+BgZqeCWbhZldJ0NRIZRMOfC5auYMQY05vSM2aAUHBg9MgTI0W+LAT0 NcDw== X-Gm-Message-State: ACrzQf1HfVF/KWOFdU6VH72q0LviK2GURayLP2u6SIMhLPVgrq7HRAS3 +d+ZqYaXhWNgI9nQxo5bY/TxrbJ+l94B2xf0MXmxaQ== X-Google-Smtp-Source: AMsMyM4+M0dj6tD6rdqSv++QRGbY/PGTV8zX4BbsYrjQSyXxL9C9ZsN0jWnek7UnBYr3woB7QG5+k3MHuVLBQzkBlT8= X-Received: by 2002:a05:6512:1195:b0:4af:aa4d:195 with SMTP id g21-20020a056512119500b004afaa4d0195mr9828122lfr.112.1667398415055; Wed, 02 Nov 2022 07:13:35 -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: Wed, 2 Nov 2022 16:12:58 +0200 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=-1.9 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. > > Jeff I think I miscommunicated the issue previously because my understanding of libcalls wasn't very solid. The guard is against the save/restore libcalls specifically; other than that shrink wrapping and libcalls are fine.I think it makes sense to leave this check because the prologue/epilogue does something similar when using libcall save/restore: frame->mask = 0; /* Temporarily fib that we need not save GPRs. */ Since shrink wrap components are marked by testing frame->mask then no registers should be wrapped with the libcall save/restore if I understand correctly. Nonetheless, I tested what happens if this guard condition is removed and the result is that a RISCV test fails (riscv/pr95252.c). In that case a unnecessary save/restore of a register is emitted together with inconsistent cfi notes that make dwarf2cfi abort. To conclude, I believe that this makes the code in the commit fine since it only guards against the libcall save/restore case. But I may be still missing something about this. Manolis