All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2025-06-25  9:15 UTC|newest]

Thread overview: 24+ 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 ` 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   ` 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   ` Radim Krčmář
2025-06-19 19:03 ` [PATCH v2 3/2] RISC-V: sbi: remove sbi_ecall tracepoints Radim Krčmář
2025-06-19 19:03   ` Radim Krčmář
2025-06-23 22:54   ` Palmer Dabbelt
2025-06-23 22:54     ` Palmer Dabbelt
2025-06-24 13:09     ` Radim Krčmář
2025-06-24 13:09       ` Radim Krčmář
2025-06-25  7:51       ` Radim Krčmář
2025-06-25  7:51         ` Radim Krčmář
2025-06-25  8:34         ` David Laight [this message]
2025-06-25  8:34           ` David Laight
2025-06-26  8:10           ` Radim Krčmář
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-23 22:53   ` Palmer Dabbelt
2025-06-24  8:09   ` David Laight
2025-06-24  8:09     ` David Laight
2025-06-24 12:40     ` Radim Krčmář
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.