[Bug target/113312] Add __attribute__((no_callee_saved_registers)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312 --- Comment #25 from Xin Li --- (In reply to Xin Li from comment #22) > Per Peter's suggestion, I added __attribute__((no_callee_saved_registers)) > to a linux source tree containing FRED patches: > https://github.com/xinli-intel/linux-fred-public/commit/ > 12c38143a5c33e89f2b3d8906629dd4f23f8d79c It's better to refer to branch 'gcc-no_callee_saved_registers' instead: https://github.com/xinli-intel/linux-fred-public/commits/gcc-no_callee_saved_registers/
[Bug target/113312] Add __attribute__((no_callee_saved_registers)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #24 from Xin Li ---
(In reply to H.J. Lu from comment #23)
> (In reply to Xin Li from comment #22)
> > Per Peter's suggestion, I added __attribute__((no_callee_saved_registers))
> > to a linux source tree containing FRED patches:
> > https://github.com/xinli-intel/linux-fred-public/commit/
> > 12c38143a5c33e89f2b3d8906629dd4f23f8d79c. And I compiled the linux code
> > with a gcc built from
> > https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13.
> >
> > Following are my observations:
> > 1) the generated kernel boots fine on both FRED Simics model and bare metal.
> > 2) the asm code generated for fred_entry_from_{user,kernel}() are the same,
> > i.e., __attribute__((no_callee_saved_registers)) makes no difference (Peter
> > said the FRED dispatch points simply do not have significant register
> > pressure – intentionally).
> > 3) other functions with __attribute__((no_callee_saved_registers)) do get
> > rid of pushing/popping clobbered registers, and cause no issues because they
> > are top-level functions, only invoked by tail call, meaning the following
> > case won't happen:
> >
> > :
> > ...
> > mov (%rbx), %r13
> > call foo
> > mov %rax, (%r13)
> > ...
> >
> > otherwise foo() is NOT a top-level function.
>
> Do these mean that __attribute__((no_callee_saved_registers)) works for you?
Yes, it works as expected.
> BTW, my patches also avoid saving callee-saved registers in
> __attribute__((noreturn))
> functions.
I also checked do_exit, which is the same as what you posted.
[Bug target/113312] Add __attribute__((no_callee_saved_registers)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
Xin Li changed:
What|Removed |Added
CC||xin at zytor dot com
--- Comment #22 from Xin Li ---
Per Peter's suggestion, I added __attribute__((no_callee_saved_registers)) to a
linux source tree containing FRED patches:
https://github.com/xinli-intel/linux-fred-public/commit/12c38143a5c33e89f2b3d8906629dd4f23f8d79c.
And I compiled the linux code with a gcc built from
https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13.
Following are my observations:
1) the generated kernel boots fine on both FRED Simics model and bare metal.
2) the asm code generated for fred_entry_from_{user,kernel}() are the same,
i.e., __attribute__((no_callee_saved_registers)) makes no difference (Peter
said the FRED dispatch points simply do not have significant register pressure
– intentionally).
3) other functions with __attribute__((no_callee_saved_registers)) do get rid
of pushing/popping clobbered registers, and cause no issues because they are
top-level functions, only invoked by tail call, meaning the following case
won't happen:
:
...
mov (%rbx), %r13
call foo
mov %rax, (%r13)
...
otherwise foo() is NOT a top-level function.
