We have a number of functions which return small structures (such as
pte_t). It seems that the kernel is not compiled with
-freg-struct-return, so all these small structures are being returned
via the stack, even though they would fit into registers.
Is there a reason for this? Would -freg-struct-return be preferred? It
would make a good compliment to -mregparm.
J
On Wed, 2007-02-21 at 17:28 -0800, Jeremy Fitzhardinge wrote:
> We have a number of functions which return small structures (such as
> pte_t). It seems that the kernel is not compiled with
> -freg-struct-return, so all these small structures are being returned
> via the stack, even though they would fit into registers.
>
> Is there a reason for this? Would -freg-struct-return be preferred? It
> would make a good compliment to -mregparm.
Do we know how many gcc bugs this has? (regparm used to have many)
other than that.. sounds like a win...
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Arjan van de Ven wrote:
> Do we know how many gcc bugs this has? (regparm used to have many)
> other than that.. sounds like a win...
>
The documentation suggests that its the preferred mode of operation, and
that its the default on platforms where gcc is the primary compiler. So
the fact that it isn't for Linux suggests either an oversight or that it
is actually broken...
Do we have much assembler which cares about the struct return calling
convention? If not, it should be a fairly easy test.
J
> Do we have much assembler which cares about the struct return calling
> convention? If not, it should be a fairly easy test.
is there an attribute to turn it off? because if so we should just make
that part of "asmlinkage".... (not that I know much code using structs
in asm)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Arjan van de Ven wrote:
>> Do we have much assembler which cares about the struct return calling
>> convention? If not, it should be a fairly easy test.
>>
>
> is there an attribute to turn it off? because if so we should just make
> that part of "asmlinkage".... (not that I know much code using structs
> in asm)
>
There doesn't appear to be; just -freg-struct-return and
-fpcc-struct-return.
J
* Arjan van de Ven <[email protected]> wrote:
> > Do we have much assembler which cares about the struct return
> > calling convention? If not, it should be a fairly easy test.
>
> is there an attribute to turn it off? because if so we should just
> make that part of "asmlinkage".... (not that I know much code using
> structs in asm)
i dont know of any such code - asmlinkage is 'long' or pointer based.
Ingo
Subject: [patch] x86: add -freg-struct-return to CFLAGS
From: Ingo Molnar <[email protected]>
Jeremy Fitzhardinge suggested the use of -freg-struct-return, which does
structure-returns (such as when using pte_t) in registers instead of on
the stack.
that is indeed so, and this option reduced the kernel size a bit:
text data bss dec hex filename
4799506 543456 3760128 9103090 8ae6f2 vmlinux.before
4798117 543456 3760128 9101701 8ae185 vmlinux.after
the resulting kernel booted fine on my testbox. Lets go for it.
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/i386/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/i386/Makefile
===================================================================
--- linux.orig/arch/i386/Makefile
+++ linux/arch/i386/Makefile
@@ -31,7 +31,7 @@ LDFLAGS_vmlinux := --emit-relocs
endif
CHECKFLAGS += -D__i386__
-CFLAGS += -pipe -msoft-float -mregparm=3
+CFLAGS += -pipe -msoft-float -mregparm=3 -freg-struct-return
# prevent gcc from keeping the stack 16 byte aligned
CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2)
On Thu, Feb 22, 2007 at 12:09:04AM -0800, Jeremy Fitzhardinge wrote:
> Arjan van de Ven wrote:
> > Do we know how many gcc bugs this has? (regparm used to have many)
> > other than that.. sounds like a win...
> >
>
> The documentation suggests that its the preferred mode of operation, and
> that its the default on platforms where gcc is the primary compiler. So
> the fact that it isn't for Linux suggests either an oversight or that it
> is actually broken...
It is used for Linux on many architectures (x86_64, sparc64, ia64,
ppc{,64}, arm, sh, m68k to name just a few), but it is an ABI decision,
so e.g. on i386 is not used by default as the ABI mandates structs/unions
are returned in memory.
Jakub
On Thu, Feb 22, 2007 at 12:09:04AM -0800, Jeremy Fitzhardinge wrote:
> Arjan van de Ven wrote:
> > Do we know how many gcc bugs this has? (regparm used to have many)
> > other than that.. sounds like a win...
> >
>
> The documentation suggests that its the preferred mode of operation, and
> that its the default on platforms where gcc is the primary compiler. So
> the fact that it isn't for Linux suggests either an oversight or that it
> is actually broken...
>
> Do we have much assembler which cares about the struct return calling
> convention? If not, it should be a fairly easy test.
I didn't think we had any that returned structures.
-Andi
On Thu, Feb 22, 2007 at 09:38:22AM +0100, Ingo Molnar wrote:
> Subject: [patch] x86: add -freg-struct-return to CFLAGS
> From: Ingo Molnar <[email protected]>
>
> Jeremy Fitzhardinge suggested the use of -freg-struct-return, which does
> structure-returns (such as when using pte_t) in registers instead of on
> the stack.
>
> that is indeed so, and this option reduced the kernel size a bit:
>
> text data bss dec hex filename
> 4799506 543456 3760128 9103090 8ae6f2 vmlinux.before
> 4798117 543456 3760128 9101701 8ae185 vmlinux.after
>
> the resulting kernel booted fine on my testbox. Lets go for it.
Ok I added it for now. Let's see what happens.
I guess people maintaining external Makefiles without Kbuild
are in for a nasty surprise again though. Cannot be avoided unfortunately.
-Andi
> I guess people maintaining external Makefiles without Kbuild
> are in for a nasty surprise again though.
that 1) shouldn't be needed at all for 2.6 and 2) is fragile as heck no
matter, I don't think anyone still is doing that... I sure hope that if
anyone still does it that they have no users at all, for the sake of the
users :)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Andi Kleen wrote:
>
> I didn't think we had any that returned structures.
>
Sometimes returning small structures is really nice. If you can pass
them in registers, it's often generates the fastest possible code; much
better than using a pointer.
-hpa
H. Peter Anvin wrote:
> Sometimes returning small structures is really nice. If you can pass
> them in registers, it's often generates the fastest possible code;
> much better than using a pointer.
Yes, but specifically, are there any pieces of assembler which return
structures? It appears there are none (since Ingo got a booting
kernel), but there might be something obscure in some corner.
J
On Thu, Feb 22, 2007 at 09:38:22AM +0100, Ingo Molnar wrote:
>...
> --- linux.orig/arch/i386/Makefile
> +++ linux/arch/i386/Makefile
> @@ -31,7 +31,7 @@ LDFLAGS_vmlinux := --emit-relocs
> endif
> CHECKFLAGS += -D__i386__
>
> -CFLAGS += -pipe -msoft-float -mregparm=3
> +CFLAGS += -pipe -msoft-float -mregparm=3 -freg-struct-return
>
> # prevent gcc from keeping the stack 16 byte aligned
> CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2)
Why is this i386 specific?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Feb 22, 2007 at 09:39:04AM -0800, Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
> > Sometimes returning small structures is really nice. If you can pass
> > them in registers, it's often generates the fastest possible code;
> > much better than using a pointer.
>
> Yes, but specifically, are there any pieces of assembler which return
> structures? It appears there are none (since Ingo got a booting
> kernel), but there might be something obscure in some corner.
When I did the x86-64 port I went over all assembler and I can't remember
anything that did that. Of course there might be out of tree drivers
that do, but they just have to fix it up.
BTW would it make sense to have a special announcement list for such changes?
-Andi
Andi Kleen wrote:
> On Thu, Feb 22, 2007 at 09:39:04AM -0800, Jeremy Fitzhardinge wrote:
>> H. Peter Anvin wrote:
>>> Sometimes returning small structures is really nice. If you can pass
>>> them in registers, it's often generates the fastest possible code;
>>> much better than using a pointer.
>> Yes, but specifically, are there any pieces of assembler which return
>> structures? It appears there are none (since Ingo got a booting
>> kernel), but there might be something obscure in some corner.
>
> When I did the x86-64 port I went over all assembler and I can't remember
> anything that did that. Of course there might be out of tree drivers
> that do, but they just have to fix it up.
>
> BTW would it make sense to have a special announcement list for such changes?
>
To some degree linux-arch would be a good list for it, but it's closed,
even to monitor.
-hpa
On Feb 22 2007 19:36, Andi Kleen wrote:
>
>BTW would it make sense to have a special announcement list for such changes?
A changelog in the kernel tree would be helpful. A real changelog that is,
not that info blob located at /Documentation/Changes.
Jan
--
Jan Engelhardt wrote:
> On Feb 22 2007 19:36, Andi Kleen wrote:
>> BTW would it make sense to have a special announcement list for such changes?
>
> A changelog in the kernel tree would be helpful. A real changelog that is,
> not that info blob located at /Documentation/Changes.
>
I presume you're talking about a BSD-style ChangeLog. I've always found
those utterly useless, since they're basically the equivalent of SCM
history but without any of the abilities to sort, filter, etc, thus
making it utterly impossible to find anything. They're a pain to
maintain (they inherently *always* cause merge failures) and add very
little.
-hpa
Adrian Bunk wrote:
> On Thu, Feb 22, 2007 at 09:38:22AM +0100, Ingo Molnar wrote:
>> ...
>> --- linux.orig/arch/i386/Makefile
>> +++ linux/arch/i386/Makefile
>> @@ -31,7 +31,7 @@ LDFLAGS_vmlinux := --emit-relocs
>> endif
>> CHECKFLAGS += -D__i386__
>>
>> -CFLAGS += -pipe -msoft-float -mregparm=3
>> +CFLAGS += -pipe -msoft-float -mregparm=3 -freg-struct-return
>>
>> # prevent gcc from keeping the stack 16 byte aligned
>> CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2)
>
> Why is this i386 specific?
>
Because virtually all other architectures have it as their ABI default,
anyway, and ABI selection should be per architecture.
-hpa
> To some degree linux-arch would be a good list for it, but it's closed,
> even to monitor.
linux-arch is only for architecture code, but yes it serves a similar
purpose. But it's very specialized. What is discussed there is unlikely
to be of much interest to most people.
I was thinking of a relatively low volume list where quick notes for
any general interfaces changes that likely needs adaptions in a wide range of
code could be sent. Then even people who cannot follow l-k or git due
to volume could subscribe to that and adapt their code as needed.
-Andi