From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) by sourceware.org (Postfix) with ESMTPS id 468333858D20 for ; Mon, 26 Jun 2023 14:50:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 468333858D20 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-vk1-xa31.google.com with SMTP id 71dfb90a1353d-471b3f3b989so912167e0c.3 for ; Mon, 26 Jun 2023 07:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687791037; x=1690383037; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Gwqzalb1r2HJ+mpPELuAkOMmgM1k1bRNtrG3z8bKPJg=; b=JlrheNngMgZAaYb2tY2E7AAMucMwF+sU8a4ZTS5qSF7OgRALMATYSmhP9ehOAdGON/ fkVp1NljTjMQp5UWpzgTUEHP+ci9aIW06HsYn9Iv+T6D0boi85kpTVT1AQdkJ4C7dx+S HkXu5FLHFgMJnCFsyOh2XqtSptdojjsSSc9TmUPIR1lCqXJBtmgcGNxUlwf2pJtv17Ie +wG7th/SNFVOBSUJQPLE6o9ucJE4kjBi5gYoVPMzF1YljmESx+71Q9i8xkYTvGj+jWSq dHdoUBdTs/kTsOfaV75xw61DU7+cAo5xe32KICR11yrFnHBz0fGqim7EGg9lwq7ahQzs 3Sfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687791037; x=1690383037; 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=Gwqzalb1r2HJ+mpPELuAkOMmgM1k1bRNtrG3z8bKPJg=; b=MBCtb3J1/LLF9lRdoEYLwIFbnqS/QrQEeCfUmwP0PulwhKykEJVG5SjlPlAHRg2DlI nTowupIuOTec2BZBdtCqqBLxCpmm6WkFVItdMMbB+N8pZlRT1pUp0Z2UoH6joLkpiSl8 h4HUeBetZ1dO3IqO0ksIzE5Gr+6Xyx93nsCPR2arF4DMyJuaOgJ8sAlxD/ILf7615kim 0gzyP9OmpsvKRz2o4o84Sz/l2ZBDyrrCypouEuXxr3PZ65OtsC/12SUU6aWRsXkFkCMb YY0ZBIFwrWdnKOUt+94iRpYvn653T14LGdsDt01C7AQl2dtoOIbvYJC0euFMjq10Ib9q M3ug== X-Gm-Message-State: AC+VfDxOrZjtUzNtdag0F5Olj5b1SuHFs5Gws6SKRonW8JUEM1esRJG2 y+seHOpXJTDPbi2C/bkvUtkzEC3VXLVAoeKzTgY= X-Google-Smtp-Source: ACHHUZ44gh7tX5J1eGDvDWhKpTnJ3g8ZCOSa64MQrbdxNx+3ug52wyVBqk3SZz2VSb0RzVuW1gxI6IARfC6Dbv8iYMk= X-Received: by 2002:a67:f50b:0:b0:443:6e56:573 with SMTP id u11-20020a67f50b000000b004436e560573mr580415vsn.35.1687791037401; Mon, 26 Jun 2023 07:50:37 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <3d60b047-3061-701d-faea-0149c63cdeb1@gmail.com> From: Kito Cheng Date: Mon, 26 Jun 2023 22:50:26 +0800 Message-ID: Subject: Re: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support. To: Jeff Law Cc: "Li, Pan2" , "Stefan O'Rear" , "Wang, Yanzhang" , "gcc-patches@gcc.gnu.org" , "juzhe.zhong@rivai.ai" , "kito.cheng@sifive.com" Content-Type: multipart/alternative; boundary="0000000000003d500d05ff0979af" X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,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: --0000000000003d500d05ff0979af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Jeff Law via Gcc-patches =E6=96=BC 2023=E5=B9=B46= =E6=9C=8826=E6=97=A5 =E9=80=B1=E4=B8=80=EF=BC=8C22:31=E5=AF=AB=E9=81=93=EF= =BC=9A > > > On 6/25/23 12:45, Stefan O'Rear wrote: > > > > > To clarify: are you proposing to make ra (or t1 in the hypothetical) a > fixed > > register for all functions, or only those heuristically identified as > potentially > > larger than 1MiB? And would this extend to forcing the creation of > stack frames > > for all functions, including very small functions? I am concerned this > would > > result in a substantial performance regression.For the case Yanzhang is > discussing (firmware and such), yes. And > that's simply the cost they're going to have to pay for wanting > consistent backtraces without utilizing dwarf unwind info, sframe or orc. > > Normal builds won't be using those options and thus won't suffer from > those performance penalties. > > > > > Without seeing the patch I can't know if I'm missing something obvious > but I > > would say t1 has three advantages: > > > > 1. Consistency with tail, possibly simpler implementation. > And as I've already stated, this sequence is defined by the assembler. > While I do want to revisit a compiler only solution, it's way down on my > list of things to improve if I do a cost/benefit analysis. If someone > wants to take a stab at it, I'm all for it. But it's not a simple > problem due the phase ordering issues. > > > > > 2. Very few functions use all seven t-registers. qemu linux-user in > 2016 had an > > off-by-one bug that corrupted t6 in sigreturn and it took months for > anyone to > > notice. By contrast, ra has live data in every non-_Noreturn function. > That's a terrible way to evaluate the impact. The right way is to use > real benchmarks. Not synthetic benchmarks. Not indirect observations > that require triggering a bug in a sigreturn path. Build and run a real > benchmark. > > > > > > > 3. Any jalr instruction which has rs1=3Dra has a hint effect on the ret= urn > address > > stack (call, return, or coroutine swap); a jalr which is intended to be > treated > > as a plain jump must have rs1!=3Dra, rs1!=3Dt0. > I'm well aware of these concerns. We support disambiguating various > jump forms to facilitate different branch predictors. > > jeff > --0000000000003d500d05ff0979af--