From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 9F3D53858CDB for ; Thu, 23 Mar 2023 19:08:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9F3D53858CDB Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1679598491; bh=ehAlvwv8x9wUrSKbHrpF3FJ14qLd0MMIOn1XDlFNuL4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=m5CW3Q3sSH90nxpFhgtSTa2Xra1Kpd1cTzWyTGFerSzsrXEjso2kAKd8RJyhC3TC4 gHCb4IMzejDVQlD/98cDQz26Q+edOMQH4CI6yI30DvnbfIr4pvAcZH2nwyp6m9XcAW d0kwGayyHe7/fiSiirBV4RdBCVp/f0hzVMye9d0o= Received: from localhost.localdomain (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id E2E8865A83; Thu, 23 Mar 2023 15:08:10 -0400 (EDT) Message-ID: <736fc1a007e8296612601bb53b3880f89e88c60e.camel@xry111.site> Subject: Re: [PATCH] LoongArch: Add Syscall Assembly Implementation From: Xi Ruoyao To: Adhemerval Zanella Netto , Andreas Schwab , caiyinyu Cc: libc-alpha@sourceware.org Date: Fri, 24 Mar 2023 03:08:09 +0800 In-Reply-To: References: <20230323084013.1100656-1-caiyinyu@loongson.cn> <8a4e2e72-9daf-d264-f49d-719daa2407b5@loongson.cn> <80f6afc82e1b03d69a744e1707131f27995db455.camel@xry111.site> <715a25cdd0fb53c8948e0d782d2149a68a62cbb7.camel@xry111.site> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.0 MIME-Version: 1.0 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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 Thu, 2023-03-23 at 15:40 -0300, Adhemerval Zanella Netto wrote: >=20 > On 23/03/23 15:26, Xi Ruoyao wrote: > >=20 > > LoongArch has a TARGET_SETUP_INCOMING_VARARGS but it does not use the > > information from stdarg pass.=C2=A0 I can fix it, but even with the fix= GCC > > would still save 7 registers (now GCC trunk saves 9 registers, the fix > > would make some improvement but no much). > >=20 > > And the issue seems not trivial to fix.=C2=A0 On x86_64, all of GCC, Cl= ang, > > and MSVC will save some registers if va_arg is used.=C2=A0 I've not fou= nd any > > compiler which can avoid saving the va_arg GARs unnecessarily yet: > >=20 > > https://godbolt.org/z/n1YqWq9c9 > >=20 > > Now to me it seems a bad idea to use va_arg in syscall.c. > >=20 >=20 > I think it was the natural way to express kernel communication mechanism > that indeed takes variadic arguments.=C2=A0=C2=A0 And since it is older t= han Linux > (man-pages stated it was from 4BSD), it also mean that you don't bind a > maximum limit or arguments (although on Linux and BSD does have a pratica= l > limit). Well, my statement is only for Linux and a modern architecture with enough GARs. > We can maybe add a implementation that uses named args (which extra > boilerplate to architectures that accepts 7 arguments instead of usual > 6); and just enable it if a per-architecture flag is set meaning that > for that specific ABI the variadic is essentially the same as named > functions calls.=C2=A0 Something like: >=20 > long int > syscall (long int number,=20 > #if __ASSUME_SYSCALL_NAMED_WORKS > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 long int a0, long int a1= , long int a2, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 long int a3, long int a4= , long int a5 > #else > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... > #endif /* snip */ > It might need some more hacks to hide the syscall prototype. I've already tried something similar on my box (I named the macro "SYSCALL_VA_ARG_NOT_NEEDED"); it looks like we don't need to hide the syscall prototype: unistd.h is not in misc/syscall.o.d. The disassemble of misc/syscall.o looks perfect when I defined the macro in sysdep/unix/sysv/linux/loongarch/sysdep.h: 0000000000000000 : 0: 0015008b move $a7, $a0 4: 001500a4 move $a0, $a1 8: 001500c5 move $a1, $a2 c: 001500e6 move $a2, $a3 10: 00150107 move $a3, $a4 14: 00150128 move $a4, $a5 18: 00150149 move $a5, $a6 1c: 002b0000 syscall 0x0 20: 15ffffec lu12i.w $t0, -1(0xfffff) 24: 68000984 bltu $t0, $a0, 8(0x8) # 2c 28: 4c000020 jirl $zero, $ra, 0 2c: 1a00000c pcalau12i $t0, 0 30: 00111004 sub.w $a0, $zero, $a0 34: 28c0018c ld.d $t0, $t0, 0 38: 38180984 stx.w $a0, $t0, $tp 3c: 02bffc04 addi.w $a0, $zero, -1(0xfff) 40: 4c000020 jirl $zero, $ra, 0 --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University