From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by sourceware.org (Postfix) with ESMTPS id 0585F38582B0 for ; Wed, 19 Oct 2022 17:15:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0585F38582B0 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-io1-xd2d.google.com with SMTP id n73so15028036iod.13 for ; Wed, 19 Oct 2022 10:15:51 -0700 (PDT) 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=e46v5gOJ0Wev+Dv4z7DVLxK3wt/7iGQf8gUE9Of8n5M=; b=csgqoefBNaARU8kyB64HwtIFcOizyA4Yq+7Cd681xGfAORdVp3jZ81MADfV504C+WR LSWeCqaZziIXUnLXgck8HV87fUkU6whQv7HhZmxne19pxstZirwQCuicrqdFX8sHuCFJ 6oboI5EYmOOI12aIGxDUEbvXNz+ZJtk2QnkbmOYO5nsXjxwynXhgfAtHzsI7QiT6tfyV CnLnQfPJkLo7vxPP+Ry1RhUL8MIUOGm2R5A9v8ePrBAkK1e4Ppu+6BrVbcnGGso7SmoW akSnsNfvttrjAorkpLm9P04HN0Kr3GeU9m6S8ZJm2VOhCN/PMPZXprJA58xEIRpf8oCg fqHw== 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=e46v5gOJ0Wev+Dv4z7DVLxK3wt/7iGQf8gUE9Of8n5M=; b=Qwdim+hcvzmB6KaCFqGudGMGZRGVPeP/4YC33buBXZXEiY80BRtZOdiu7+WlPlPwk1 ocw4HYvukQFQRYP87YtbDzgCEJgUzC6/1g86EUzV7K8zfW9hJNe83PdFjtaU9Jeen+Ue XJmooLycVZyXbCJps6aNlrgTWiKjyhekTWI2PgC/8S9J0IIyBC6Iyx7X/WOXqITT2HvU wmwAVDlgJwqcTDuobz3TZDkDWOA8QQkZ3pLD4x3k6hEKg5qTMeUZI/26fRT8826pII5D Z0AisIQP6mjO+WF05e51lke6CVgmqm8c/cCwdhMoq7LeXkSibuj9N+H1EfA/jbVGWB0w TsRg== X-Gm-Message-State: ACrzQf2iL/ePhascakGUzuXSO4aU4t/QqmQosgBmNkyR8qvB880ouakr 2zgRbirQyJqYpGxkPA44Rsc= X-Google-Smtp-Source: AMsMyM4KZAQ6oyAGFlfj3Ci3pYKXYZRPoEGZPudWdZJrHsiuN9f7UyzhJri229w6NY1Hok8dJAE00g== X-Received: by 2002:a05:6602:2c04:b0:6ab:d29a:7000 with SMTP id w4-20020a0566022c0400b006abd29a7000mr6179022iov.204.1666199751002; Wed, 19 Oct 2022 10:15:51 -0700 (PDT) Received: from [172.31.1.18] (65-130-77-9.slkc.qwest.net. [65.130.77.9]) by smtp.gmail.com with ESMTPSA id f39-20020a022427000000b00346a98b0a76sm2255592jaa.77.2022.10.19.10.15.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 10:15:50 -0700 (PDT) Message-ID: <08273c28-07ff-3170-679b-225d60a9ee2d@gmail.com> Date: Wed, 19 Oct 2022 11:15:49 -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: Palmer Dabbelt , jlaw@ventanamicro.com Cc: Vineet Gupta , gcc-patches@gcc.gnu.org, 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.1 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 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