Messages in this thread |  | | Date | Wed, 07 Nov 2001 15:00:23 +0100 | From | Martin Dalecki <> | Subject | Re: Using %cr2 to reference "current" |
| |
Alan Cox wrote:
> Im not sure how much the code change for function call patterns would be > but I doubt its so big for such little effort
Let numbers talk to us, or allow me to quote the georieously politically incorrect Dave: "Numbers talk - billshit walks!":
Without register passing, we have the following size situation:
text data bss dec hex filename 1332132 260804 288080 1881016 1cb3b8 vmlinux
With the following options enabled we get: -freg-struct-return -mrtd -mregparm=3
text data bss dec hex filename 1302372 260804 288080 1851256 1c3f78 vmlinux
Quite significant difference if you ask me!!!
With the following options enabled we get: -mrtd -mregparm=3
text data bss dec hex filename 1302404 260804 288080 1851288 1c3f98 vmlinux
Here it's just a few bytes here and there not really significant, becouse the kernel apparently doesn't use structs as return values frequently.
With the following options enabled we get: -mregparm=3
text data bss dec hex filename 1303476 260804 288080 1852360 1c43c8 vmlinux
So apparently the -mrtd options is quite significant as well.
With the following options enabled we get: -mregparm=2
text data bss dec hex filename 1307876 260804 288080 1856760 1c54f8 vmlinux
As expected the influence here isn't too significant.
So the conclusion is that apparetly the change in calling convention can result in a saving of about 2.3% in code size. This may not sound grat in relative numbers, but for a compiler designer this would already sound hilarious and in absolute numbers it's: 29760 bytes. Not withstanding the speed improvement...
Oh for compleatness sake, the compiler used was: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |