From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 74DA13858C62 for ; Thu, 8 Jun 2023 15:05:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 74DA13858C62 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-x42b.google.com with SMTP id d2e1a72fcca58-653436fcc1bso472266b3a.2 for ; Thu, 08 Jun 2023 08:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686236706; x=1688828706; 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=ZfxxN5c/XfFIrY2V8TwsxyTuKPuZ3FwWbHSgyUA/oyE=; b=RKzXeIFXff8XXkTS55JXC8msq8MHUjQjbt+D5k90fmzZ7ckRVQpLxNwgtVo8eUxdkx MnGUU57pRBaUlhkIhjtpaHzNGSo5mUaYsUwl12vqvdJME7RZgd0WxnlWYKd/6GVB643E djGbmnHnZrSDVOkSGp+afN+8p15VKKyJhvNFhqB9dsThTeZTVm4o0Z/km9sveS0tkb1R 9SalOdVK421CisXTosNh/Pnt4uWoFqOVvo3anLyKEf665tgOOKuBTR+mUkFmaeQ/Qao5 Doi1HVq2/5Jbk5IA3UN/Wruxxjo0QBBCwQPralgyGL7FoyU6veWGoNjBp7EnQVVTpvNy fsQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686236706; x=1688828706; 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=ZfxxN5c/XfFIrY2V8TwsxyTuKPuZ3FwWbHSgyUA/oyE=; b=h9kwQQcrsHlQWIbnxf5gV+HHaW950HB0MJ/50E48TEz+nMi0jDsfJafKy17+8A+apL V7QU4DfKNz6rTSvaYH3b+Lvfn67izBh/AgTzyEFDwmPSwp1wgR5eBBfYOGeSISJp9feQ /Wc4M2a9fB0Jayn3L71q8H95xhL7tGEfsL4ErUIJA84h5WebSxD1caPkWobqctrPt2GI XuX4svZrAfjzb1FPFT05fywGz/dJ3MeFEQyripgwG2pqYF/SJIFKARuPqRLfOIddJoUw dsaEsOWHxKnCx+U2pSqIu4yj/joijv8dR1PnKDnHD6gVQEyd4XpKIPF6nM8/IO58ISZ6 W4wQ== X-Gm-Message-State: AC+VfDwDcS5h8xb5KvIUo9LnyF1jhD55NKIdEChNacgLjL82zc+z6WPx AJNiEeGFhVTslR/S+HjOvbI= X-Google-Smtp-Source: ACHHUZ6jLa6Db9Sgng88zHVumC6pB6g1ykWRkOi0tn02S9q5csAfvkMsAXx+nZJJupsKnSJctrGStA== X-Received: by 2002:a05:6a00:3982:b0:650:6e3e:a8e3 with SMTP id fi2-20020a056a00398200b006506e3ea8e3mr5074845pfb.26.1686236706324; Thu, 08 Jun 2023 08:05:06 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id j1-20020aa78001000000b00634dde2992bsm1215885pfi.132.2023.06.08.08.05.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jun 2023 08:05:05 -0700 (PDT) Message-ID: <7fb7d7d5-0e9a-d8b8-5dc6-7db946e67a00@gmail.com> Date: Thu, 8 Jun 2023 09:05:04 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support. Content-Language: en-US To: "Wang, Yanzhang" , "gcc-patches@gcc.gnu.org" Cc: "juzhe.zhong@rivai.ai" , "kito.cheng@sifive.com" , "Li, Pan2" References: <20230602070726.3807539-1-yanzhang.wang@intel.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/6/23 21:50, Wang, Yanzhang wrote: > Hi Jeff, > > Thanks your comments. I have few questions that I don't quite understand. > >> One of the things that needs to be upstreamed is long jump support within >> a function. Essentially once a function reaches 1M in size we have the >> real possibility that a direct jump may not reach its target. >> >> To support this I expect that $ra is going to become a fixed register (ie, >> not available to the register allocator as a temporary). It'll be used >> as a scratch register for long jump sequences. >> >> One of the consequences of this is $ra will need to be saved in leaf >> functions that are near or over 1M in size. >> >> Note that at the time when we have to lay out the stack, we do not know >> the precise length of the function. So there's a degree of "fuzz" in the >> decision whether or not to save $ra in a function that is close to the 1M >> limit. > > Do you mean that, long jump to more than 1M offset will need multiple jal > and each jal will save the $ra ? Long jumps are implemnted as an indirect jump which needs a scratch register to hold the high part of the jump target address. > > If yes, I'm confused about what's the influence of the $ra saving for > function prologue. We will save the fp+ra at the prologue, the next $ra > saving seems will not modify the $ra already saved. The long branch handling is done at the assembler level. So the clobbering of $ra isn't visible to the compiler. Thus the compiler has to be extremely careful to not hold values in $ra because the assembler may clobber $ra. This ultimately comes back to the phase ordering problem. At register allocation time we don't know if we need long jumps or not. So we don't know if $ra is potentially clobbered by the assembler. A similar phase ordering problems exists in the prologue/epilogue generation. The other approach to long branch handling would be to do it all in the compiler. I would actually prefer this approach, but it's not likely to land in the near term. > > I think it's yes (not valid) when we want to get the return address to parent > function from $ra directly in the function body. But we can get the right > return address from fp with offset if we save them at prologue, is it right ? Right. You'll be able to get the value of $ra out of the stack. > >> Meaning that what you really want is to be using -fno-omit-frame-pointer >> and for $ra to always be saved in the stack, even in a leaf function. > > This is also another solution but will change the default behavior of > -fno-omit-frame-pointer. That's OK. While -f options are target independent options, targets are allowed to adjust certain behaviors based on those options. If you're not going to use dwarf, then my recommendation is to ensure that the data you need is *always* available in the stack at known offsets. That will mean your code isn't optimized as well. It means hand written assembly code has to follow the conventions, you can't link against libraries that do not follow those conventions, etc etc. But that's the price you pay for not using dwarf (or presumably ORC/SFRAME which I haven't studied in detail). Jeff Jeff