From: David Laight <david.laight.linux@gmail.com>
To: "Radim Krčmář" <rkrcmar@ventanamicro.com>
Cc: "Palmer Dabbelt" <palmer@dabbelt.com>,
<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
<aou@eecs.berkeley.edu>, "Alexandre Ghiti" <alex@ghiti.fr>,
"Atish Patra" <atishp@rivosinc.com>, <ajones@ventanamicro.com>,
<cleger@rivosinc.com>, <apatel@ventanamicro.com>,
<thomas.weissschuh@linutronix.de>,
"Jeff Law" <jlaw@ventanamicro.com>
Subject: Re: [PATCH v2 3/2] RISC-V: sbi: remove sbi_ecall tracepoints
Date: Wed, 25 Jun 2025 09:34:15 +0100 [thread overview]
Message-ID: <20250625093415.53fd21cf@pumpkin> (raw)
In-Reply-To: <DAVG8M70SJ4Q.ZSTC5VSJWGSK@ventanamicro.com>
On Wed, 25 Jun 2025 09:51:45 +0200
Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
> 2025-06-24T15:09:09+02:00, Radim Krčmář <rkrcmar@ventanamicro.com>:
> > For another example, let's have the following function:
> >
> > struct sbiret some_sbi_ecall(uintptr_t a0, uintptr_t a1)
> > {
> > return sbi_ecall(123, 456, a0, a1);
> > }
> >
...
>
> GCC 15.1 still leaves "mv" outside the branch, but at least seems to be
> on the right track (undesired overhead is marked with leading stars):
>
> 0xffffffff800236e8 <+0>: addi sp,sp,-48
> 0xffffffff800236ea <+2>: sd s0,32(sp)
> 0xffffffff800236ec <+4>: sd ra,40(sp)
> 0xffffffff800236ee <+6>: addi s0,sp,48
> * 0xffffffff800236f0 <+8>: mv a4,a0
> * 0xffffffff800236f2 <+10>: mv a5,a1
> 0xffffffff800236f4 <+12>: nop
> * 0xffffffff800236f8 <+16>: mv a0,a4
> * 0xffffffff800236fa <+18>: mv a1,a5
> 0xffffffff800236fc <+20>: li a7,123
> 0xffffffff80023700 <+24>: li a6,456
> 0xffffffff80023704 <+28>: ecall
> * 0xffffffff80023708 <+32>: mv a5,a0
> * 0xffffffff8002370a <+34>: mv a2,a1
> 0xffffffff8002370c <+36>: nop
> 0xffffffff80023710 <+40>: ld ra,40(sp)
> 0xffffffff80023712 <+42>: ld s0,32(sp)
> * 0xffffffff80023714 <+44>: mv a0,a5
> * 0xffffffff80023716 <+46>: mv a1,a2
> 0xffffffff80023718 <+48>: addi sp,sp,48
> 0xffffffff8002371a <+50>: ret
> [Tracing goes to +126]
How much do a few register moves/spills matter compared to the
cost of the called code?
There will but much worse things out there if you look.
David
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-06-25 9:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 19:03 [PATCH v2 0/2] RISC-V: turn sbi_ecall into a variadic macro Radim Krčmář
2025-06-19 19:03 ` [PATCH v2 1/2] RISC-V: sbi: turn sbi_ecall into " Radim Krčmář
2025-06-19 19:03 ` [PATCH v2 2/2] RISC-V: make use of variadic sbi_ecall Radim Krčmář
2025-06-19 19:03 ` [PATCH v2 3/2] RISC-V: sbi: remove sbi_ecall tracepoints Radim Krčmář
2025-06-23 22:54 ` Palmer Dabbelt
2025-06-24 13:09 ` Radim Krčmář
2025-06-25 7:51 ` Radim Krčmář
2025-06-25 8:34 ` David Laight [this message]
2025-06-26 8:10 ` Radim Krčmář
2025-06-23 22:53 ` [PATCH v2 0/2] RISC-V: turn sbi_ecall into a variadic macro Palmer Dabbelt
2025-06-24 8:09 ` David Laight
2025-06-24 12:40 ` Radim Krčmář
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250625093415.53fd21cf@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=atishp@rivosinc.com \
--cc=cleger@rivosinc.com \
--cc=jlaw@ventanamicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rkrcmar@ventanamicro.com \
--cc=thomas.weissschuh@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox