From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 499B63858D35 for ; Mon, 26 Jun 2023 14:30:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 499B63858D35 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-pl1-x62a.google.com with SMTP id d9443c01a7336-1b7f2239bfdso16187075ad.1 for ; Mon, 26 Jun 2023 07:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687789829; x=1690381829; 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=fv8NjDWF1vdomdDwDmJfRzd3HSQGLPGIkhDvsnHpdMY=; b=EOqPhSZ5cWzu78byrylVBz2kAmsqr4xcc+3IvY360MzGkk/Zf3pnYXOrGw/eigW3cK FsQQtJFwgWsqIPyeFnLDXPz/6BXPxEoXMrJJaAXkl1Ktd9JNsMlxRfZKdPgFWzjUc16e x9torKPYwOz5oyXef5Vu/Y2cu168Ou0s1ZAbgEgR40X/sdXDi+g5dzNMT3MxB73v+6h5 sX7bW/VRbFroG/Z8JTMKPgW1/EIgBMpf3/QNUabmlSu5LvnUCCOBPKdbIxEOTpT1xcap 8uuNptO0/VBeDKo4TCcxkGIJGnfZcZP6XTx1mzy+1SEi4DVabn+L8XEBX9wGExmQQdq+ 6guw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687789829; x=1690381829; 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=fv8NjDWF1vdomdDwDmJfRzd3HSQGLPGIkhDvsnHpdMY=; b=KCwk7mPwF6vr9QVOgwFsXmamXAHvNVl2tiZa7zAlnye0BA7EFLeZbCCxsw6i6CoCUs vr+JrwslSx+EQuwgSR7T0XiVRBAidDoI2tnYyEdQhE6KxqeRDU73CsAUCKTfIFRoIVOb ++fCjlDP/irI+wd3TLR0kxaZwfz1OWvpKRTcrlzPNUxziXz3USxrXubh9vKrCZe6kd7Z B2kl3Q/vaQo5kccm83ihYGcG+30UDChy+gdes513xl+f/JB9bV/PXfPz/OV6UYEbvaKN QgnrY4f9mIozQIYE0X8TF4laGKbXM8wvpiqFzuizuJ/pPZbU6gEAV8FldC8z+DHaOJLS d9kw== X-Gm-Message-State: AC+VfDyyYWI/u4/q+ZGTbEn4+9hs+TZNuBlVHT4pQFGHq7vs7jcJIZM0 qndFFlmMSIwzD57vX/TNQjw= X-Google-Smtp-Source: ACHHUZ4xHH990nTh7WHdKn7XUBtN9w9tCbQpleKytyYgWQlCJRf329uv2JrRsVqBtm64aYSsbZQELw== X-Received: by 2002:a17:903:25c1:b0:1b6:6f12:502e with SMTP id jc1-20020a17090325c100b001b66f12502emr6961459plb.49.1687789829022; Mon, 26 Jun 2023 07:30:29 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id z22-20020a1709028f9600b001b7dfbd4df3sm4177612plo.16.2023.06.26.07.30.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jun 2023 07:30:28 -0700 (PDT) Message-ID: <3d60b047-3061-701d-faea-0149c63cdeb1@gmail.com> Date: Mon, 26 Jun 2023 08:30:26 -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> <99ac9403-dc38-1f95-b2c1-0f24adb3e83a@gmail.com> <9be7090c-bef3-40b9-be6e-d4c61e10eb27@app.fastmail.com> From: Jeff Law In-Reply-To: <9be7090c-bef3-40b9-be6e-d4c61e10eb27@app.fastmail.com> 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/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=ra has a hint effect on the return address > stack (call, return, or coroutine swap); a jalr which is intended to be treated > as a plain jump must have rs1!=ra, rs1!=t0. I'm well aware of these concerns. We support disambiguating various jump forms to facilitate different branch predictors. jeff