public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc r14-69] LoongArch: Improve GAR store for va_list
@ 2023-04-19 10:17 Xi Ruoyao
0 siblings, 0 replies; only message in thread
From: Xi Ruoyao @ 2023-04-19 10:17 UTC (permalink / raw)
To: gcc-cvs
https://gcc.gnu.org/g:81c6501445fcddad653363f815cd04ca6fdb488e
commit r14-69-g81c6501445fcddad653363f815cd04ca6fdb488e
Author: Xi Ruoyao <xry111@xry111.site>
Date: Wed Mar 29 01:36:09 2023 +0800
LoongArch: Improve GAR store for va_list
LoongArch backend used to save all GARs for a function with variable
arguments. But sometimes a function only accepts variable arguments for
a purpose like C++ function overloading. For example, POSIX defines
open() as:
int open(const char *path, int oflag, ...);
But only two forms are actually used:
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
So it's obviously a waste to save all 8 GARs in open(). We can use the
cfun->va_list_gpr_size field set by the stdarg pass to only save the
GARs necessary to be saved.
If the va_list escapes (for example, in fprintf() we pass it to
vfprintf()), stdarg would set cfun->va_list_gpr_size to 255 so we
don't need a special case.
With this patch, only one GAR ($a2/$r6) is saved in open(). Ideally
even this stack store should be omitted too, but doing so is not trivial
and AFAIK there are no compilers (for any target) performing the "ideal"
optimization here, see https://godbolt.org/z/n1YqWq9c9.
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk
(GCC 14 or now)?
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_setup_incoming_varargs): Don't save more GARs than
cfun->va_list_gpr_size / UNITS_PER_WORD.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/va_arg.c: New test.
Diff:
---
gcc/config/loongarch/loongarch.cc | 4 +++-
gcc/testsuite/gcc.target/loongarch/va_arg.c | 24 ++++++++++++++++++++++++
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/gcc/config/loongarch/loongarch.cc b/gcc/config/loongarch/loongarch.cc
index 34532d82b9e..dfb731fca9d 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -764,7 +764,9 @@ loongarch_setup_incoming_varargs (cumulative_args_t cum,
loongarch_function_arg_advance (pack_cumulative_args (&local_cum), arg);
/* Found out how many registers we need to save. */
- gp_saved = MAX_ARGS_IN_REGISTERS - local_cum.num_gprs;
+ gp_saved = cfun->va_list_gpr_size / UNITS_PER_WORD;
+ if (gp_saved > (int) (MAX_ARGS_IN_REGISTERS - local_cum.num_gprs))
+ gp_saved = MAX_ARGS_IN_REGISTERS - local_cum.num_gprs;
if (!no_rtl && gp_saved > 0)
{
diff --git a/gcc/testsuite/gcc.target/loongarch/va_arg.c b/gcc/testsuite/gcc.target/loongarch/va_arg.c
new file mode 100644
index 00000000000..980c96d0e3d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/va_arg.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* Technically we shouldn't save any register for this function: it should be
+ compiled as if it accepts 3 named arguments. But AFAIK no compilers can
+ achieve this "perfect" optimization now, so just ensure we are using the
+ knowledge provided by stdarg pass and we won't save GARs impossible to be
+ accessed with __builtin_va_arg () when the va_list does not escape. */
+
+/* { dg-final { scan-assembler-not "st.*r7" } } */
+
+int
+test (int a0, ...)
+{
+ void *arg;
+ int a1, a2;
+
+ __builtin_va_start (arg, a0);
+ a1 = __builtin_va_arg (arg, int);
+ a2 = __builtin_va_arg (arg, int);
+ __builtin_va_end (arg);
+
+ return a0 + a1 + a2;
+}
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2023-04-19 10:17 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-19 10:17 [gcc r14-69] LoongArch: Improve GAR store for va_list Xi Ruoyao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).