From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) by sourceware.org (Postfix) with ESMTPS id A81A73858D35 for ; Sun, 25 Jun 2023 12:49:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A81A73858D35 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-il1-x129.google.com with SMTP id e9e14a558f8ab-345a31bda6cso3001235ab.1 for ; Sun, 25 Jun 2023 05:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687697390; x=1690289390; 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=ss530kx0d5xY7rvzIYueYgxuF3Mv/zutIndx+1BG0Gg=; b=EQSmz9JamgeP0j3VGCJQE/3OzpojUqpJIWQWC6Xa63NeXuSq7v3tYnDJasYzAV77/E Uq3DLAp2iDg2sxF8pBQaXsqjsB7JU/H+sf0mFg/Omyq+K0rIegxkZDU59Un+qPFezm7T hWel9LPscqCb69FqXHwi97E+TnnoG3E/hNTKpFoxgjfp0bOQW9qtVQlgPX7VKUvzv/dG jfJ3FAA9iIadtntnSphPe0X7tQcjB/Rcev68icH8H9aBkwuHyuzGDoHN1SCPCy8kOgAY WBRB5SiRxmi+dEM4DWmRssZFintW3iFmsDuwFR/SS9Zg1o/xtjE1cE/4I0q6TLXyIz3z h9Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687697390; x=1690289390; 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=ss530kx0d5xY7rvzIYueYgxuF3Mv/zutIndx+1BG0Gg=; b=LRRTJ22skuCMAqfwtP+sYW0nQGJoHQefmmHj3KNwifQfEIzSCJw6fN6kzFWyL19Yha 9n5A8jZXnlogps4Xe9WAbw/i4Ygj/PF53pJULLDSHQkwkpSj1gWGPombSly+Vr/RGygT A3N5JgD1uSDpgmvZUp1tI/KfZcECsqBAQXcUZxxQ1NGfYYa9niKfCH5nTj4uSWyP7q6L 5CwvnfJVeUFLYRiQhd40GPeyvj0jkY2l1ChbHEc6PPifW+YsUmSKdlkW+hALSBb5JIti rc3BLvv6nFHOqCYl7HMxeDy0czOH6zDXz0vKsvX83Hyabimo/jm/0sqRY9kHcFykYHdM 1qtg== X-Gm-Message-State: AC+VfDx8/gBcQ1sJKrb6GT24GrKWX8kui+nxIfsf+fz9j8zxXXlVwSmf js3HzMNX/ruU5C43HbLtL4o= X-Google-Smtp-Source: ACHHUZ4wE93uLaN3Pbth8Znctg7KZ4kVllgo9K4EBwobWWaNFCdy1CVP+3WKTPrwp2PSWhwTuz1NEQ== X-Received: by 2002:a92:d091:0:b0:345:6e6e:5351 with SMTP id h17-20020a92d091000000b003456e6e5351mr5141761ilh.22.1687697389607; Sun, 25 Jun 2023 05:49:49 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id y11-20020a62b50b000000b0064550f76efesm2239321pfe.29.2023.06.25.05.49.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Jun 2023 05:49:49 -0700 (PDT) Message-ID: <99ac9403-dc38-1f95-b2c1-0f24adb3e83a@gmail.com> Date: Sun, 25 Jun 2023 06:49:47 -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: Stefan O'Rear , "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> <7fb7d7d5-0e9a-d8b8-5dc6-7db946e67a00@gmail.com> <5b8d6f90-6668-84ac-53dc-5c5272d179ef@gmail.com> <4024e3a5-a2d1-4a66-abb4-481ea15013ec@app.fastmail.com> From: Jeff Law In-Reply-To: <4024e3a5-a2d1-4a66-abb4-481ea15013ec@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.6 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,URIBL_BLACK 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 6/24/23 19:40, Stefan O'Rear wrote: > On Sat, Jun 24, 2023, at 11:01 AM, Jeff Law via Gcc-patches wrote: >> On 6/21/23 02:14, Wang, Yanzhang wrote: >>> Hi Jeff, sorry for the late reply. >>> >>>> 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. >>> >>> If assembler will modify the $ra behavior, it seems the rules we defined in >>> the riscv.cc will be ignored. For example, the $ra saving generated by this >>> patch may be modified by the assmebler and all others depends on it will be >>> wrong. So implementing the long jump in the compiler is better. >> Basically correct. The assembler potentially clobbers $ra. That's why >> in the long jump patches $ra becomes a fixed register -- the compiler >> doesn't know when it's clobbered by the assembler. >> >> Even if this were done in the compiler, we'd still have to do something >> special with $ra. The point at which decisions about register >> allocation and such are made is before the point where we know the final >> positions of jumps/labels. It's a classic problem in GCC's design. > > Do you have a reference for more information on the long jump patches? I can extract the patch Andrew wrote if that would be helpful. > > I'm particularly curious about why $ra was selected as the temporary instead > of $t1 like the tail pseudoinstruction uses. $ra would be less disruptive from a code generation standpoint. Essentially whatever register is selected has to become a fixed register, meaning it's unavailable to the allocator. Thus $t1 would be a horrible choice. Ultimately this is defined by the assembler. jeff