From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 3F5B13858D1E for ; Mon, 26 Jun 2023 16:51:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F5B13858D1E 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-pf1-x432.google.com with SMTP id d2e1a72fcca58-668711086f4so2287574b3a.1 for ; Mon, 26 Jun 2023 09:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687798307; x=1690390307; 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=gXomLm27zrUQv7nqJzEBJci/eGJ3L2cRLBjHhxqROkY=; b=avhjDugCzrj23Rn10dey+UVfZD7E0MY1m200jHMxX+A0sIBL80mp6WfYYEFs8vkPou OlkqeJ3uEpwHD7Vi0cCaV00K6dtF3hvlZAOkPf2Yr8CLZuZkw2qfz0tychJi+C+kCVMv PW/kmE3Eb5WYLY6hlr6Vj8d2rFMYTAmTkbtzYYjMdCnXmHsVI8BaRthf+Cmmpgsr0vjD Z0IP/zj7W7tn8PPqflxI+BfdzW9ye9yYq+FApHTAVERvY4ducyu93YatsjENq0nBsrr/ h+p7GUrIQUahbVIQoMFIps3oZGVlVf92K2HzyJbLeS5bqTI+av2bqDDi5kcYRU4k9xLU jSGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687798307; x=1690390307; 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=gXomLm27zrUQv7nqJzEBJci/eGJ3L2cRLBjHhxqROkY=; b=a4z1t6zbyuqwKOJchOjAaKp6IpUIeN9g1gv8/7E/D36sC6y4DtGHwBtO7HnZdtwE/W eBwJF906k4OLNh8/l3W3Wi2cdPfmadSQDrCMAXA7ElJs1+Krof1gxEpoFRfon+e9Ru9a R6hXpp+VsrkQQsrgoRMUwwFfOT6rrTsvljPy00HTgoeliurnONXIX76UaqESOSqImZ3y KsnYD/mwCCyKswBTSx677DzX0zoI/uQzIwU0f9MPFkQbS363DWBTbMa3XmDyRxbOaOgm kX1bHqHr1raHVqc+g1+DrBPJZkYgOwym6UVJdD1yXwBuCE7fJWxKwxDngDNX7JGVlAZ5 s2mw== X-Gm-Message-State: AC+VfDxj2v+NcBFOwN+HQ+DCRrXgmZTziDF1zUveb1hASLs6WeCmoRTo TdGigNRMg7w3i0YS6PDkVvY= X-Google-Smtp-Source: ACHHUZ6r/+QYffy4NkMrpQITTWh+bX/YR/d6YDUeKKlvBN2+Pe1iv/8vItg5Mt6ZKjUj8PAAHNEgfw== X-Received: by 2002:a05:6a00:218e:b0:667:d0ff:6a0f with SMTP id h14-20020a056a00218e00b00667d0ff6a0fmr32856884pfi.5.1687798306996; Mon, 26 Jun 2023 09:51:46 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id z19-20020aa785d3000000b00679efed4108sm1318577pfn.33.2023.06.26.09.51.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jun 2023 09:51:46 -0700 (PDT) Message-ID: <55edb915-19de-b7d8-4d20-c79d7ef990a2@gmail.com> Date: Mon, 26 Jun 2023 10:51:45 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support. Content-Language: en-US To: Kito Cheng Cc: "Li, Pan2" , Stefan O'Rear , "Wang, Yanzhang" , "gcc-patches@gcc.gnu.org" , "juzhe.zhong@rivai.ai" , "kito.cheng@sifive.com" References: <20230602070726.3807539-1-yanzhang.wang@intel.com> <7fb7d7d5-0e9a-d8b8-5dc6-7db946e67a00@gmail.com> <5b8d6f90-6668-84ac-53dc-5c5272d179ef@gmail.com> <4024e3a5-a2d1-4a66-abb4-481ea15013ec@app.fastmail.com> <99ac9403-dc38-1f95-b2c1-0f24adb3e83a@gmail.com> <9be7090c-bef3-40b9-be6e-d4c61e10eb27@app.fastmail.com> <3d60b047-3061-701d-faea-0149c63cdeb1@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 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,T_SCC_BODY_TEXT_LINE 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 6/26/23 08:50, Kito Cheng wrote: > LLVM will try to find scratch register even after RA to resolve the long > jump issue. so maybe we could consider similar approach? And I guess the > most complicate part would be the scratch register is not found, and > require spill/reload after RA. Right. And the spill/reload after RA is ta problem unless you pre-allocate the space. Of course in a function near 1M in size, odds are there were some calls in there and thus $ra would be saved. In the exceedingly rare case where it wasn't, allocating a single stack slot isn't going to be a major performance driver. There's other things you can do as well. Register scavenging, jump trampolines, etc. Examples of both exist. The point I'm trying to make is that I suspect we're better off burning $ra right now to address the correctness issue, then coming back to one of the schemes noted above when the cost/benefit analysis shows it's a reasonably high priority relative to other optimizations we could be doing. Jeff