[PATCH] powerpc: Add gpr1 and fpu save/restore functions
Timothy Pearson
tpearson at raptorengineering.com
Tue Feb 13 05:07:03 AEDT 2024
----- Original Message -----
> From: "Segher Boessenkool" <segher at kernel.crashing.org>
> To: "Timothy Pearson" <tpearson at raptorengineering.com>
> Cc: "linuxppc-dev" <linuxppc-dev at lists.ozlabs.org>
> Sent: Monday, February 12, 2024 11:59:06 AM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
> On Mon, Feb 12, 2024 at 11:46:19AM -0600, Timothy Pearson wrote:
>> Interesting, that make sense.
>>
>> How should we proceed from the current situation? Bringing in libgcc seems
>> like a fairly invasive change,
>
> I have done it for *all* architectures some ten years ago. Never found
> any problem.
That makes sense, what I mean by invasive is that we'd need buy-in from the other
maintainers across all of the affected architectures. Is that likely to occur?
>> should we merge this to fix the current bug
>> (cannot build ppc64 kernel in size-optimized mode) and start discussion on
>> bringing in libgcc as the long-term fix across multiple architectures?
>>
>> My goal here is to not have to carry a downstream patch in perpetuity for
>> our embedded Linux firmware, which needs to be compiled in size-optimized
>> mode due to hardware Flash limitations.
>
> There are better options than -Os, fwiw. Some --param's give smaller
> *and* faster kernels. What exactly is best is heavily arch-dependent
> though (as well as dependent on the application code, the kernel code in
> this case) :-(
I've been through this a few times, and -Os is the only option that makes
things (just barely) fit unfortunately.
More information about the Linuxppc-dev
mailing list