lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250625093415.53fd21cf@pumpkin>
Date: Wed, 25 Jun 2025 09:34:15 +0100
From: David Laight <david.laight.linux@...il.com>
To: Radim Krčmář <rkrcmar@...tanamicro.com>
Cc: "Palmer Dabbelt" <palmer@...belt.com>,
 <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>, "Paul
 Walmsley" <paul.walmsley@...ive.com>, <aou@...s.berkeley.edu>, "Alexandre
 Ghiti" <alex@...ti.fr>, "Atish Patra" <atishp@...osinc.com>,
 <ajones@...tanamicro.com>, <cleger@...osinc.com>,
 <apatel@...tanamicro.com>, <thomas.weissschuh@...utronix.de>, "Jeff Law"
 <jlaw@...tanamicro.com>
Subject: Re: [PATCH v2 3/2] RISC-V: sbi: remove sbi_ecall tracepoints

On Wed, 25 Jun 2025 09:51:45 +0200
Radim Krčmář <rkrcmar@...tanamicro.com> wrote:

> 2025-06-24T15:09:09+02:00, Radim Krčmář <rkrcmar@...tanamicro.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ