Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
people:holger [2007/08/20 06:53] holger |
people:holger [2007/08/20 11:37] (current) holger |
||
|---|---|---|---|
| Line 21: | Line 21: | ||
| Status: unfortunately no difference at all. local branch exists, may be included in the attr changes for completeness. | Status: unfortunately no difference at all. local branch exists, may be included in the attr changes for completeness. | ||
| * somewhere in between: install git, learn to use it, research documentation on attributes (useful link: http://www.ohse.de/uwe/articles/gcc-attributes.html) | * somewhere in between: install git, learn to use it, research documentation on attributes (useful link: http://www.ohse.de/uwe/articles/gcc-attributes.html) | ||
| + | |||
| Line 35: | Line 36: | ||
| * Revisit Compiler Options. Status: Found two or three more options that reduce codesize. Investigating the effects of -finline-limit (8 seems like the optimal setting right now), -fgcse-after-reload seems to help a bit too. Got gcc 4.2.1 to compile and testing the new options. status: partly merged. (gcc 4.2.1 compile fixes, makefile cleanups) mcb30 felt that module specific optimizations were unmaintainable. inline-limit might go in later. | * Revisit Compiler Options. Status: Found two or three more options that reduce codesize. Investigating the effects of -finline-limit (8 seems like the optimal setting right now), -fgcse-after-reload seems to help a bit too. Got gcc 4.2.1 to compile and testing the new options. status: partly merged. (gcc 4.2.1 compile fixes, makefile cleanups) mcb30 felt that module specific optimizations were unmaintainable. inline-limit might go in later. | ||
| * Break up string.c in used and unused functions. also set pure attributes. status: done, not yet merged. | * Break up string.c in used and unused functions. also set pure attributes. status: done, not yet merged. | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| * optimizing memset. status: should be optimal in size now (also all the other functions in string.h) checked in as "memset" branch. this is an overall win in codesize (most notably for undinet, multiboot and monojob). warnings mentioned here earlier have been successfully silenced, also the code saw a lot more optimizations (memmove optimization, memcpy break-even checked and adjusted, cx load trick for all possible functions and values). | * optimizing memset. status: should be optimal in size now (also all the other functions in string.h) checked in as "memset" branch. this is an overall win in codesize (most notably for undinet, multiboot and monojob). warnings mentioned here earlier have been successfully silenced, also the code saw a lot more optimizations (memmove optimization, memcpy break-even checked and adjusted, cx load trick for all possible functions and values). | ||
| * included attributes on hci subdir (branch for that is slightly incorrectly named "curses"). also split up curses a bit further, but only marginally (most of it isn't used anyway) - branch that includes this in addition to the former is "cursessplit" | * included attributes on hci subdir (branch for that is slightly incorrectly named "curses"). also split up curses a bit further, but only marginally (most of it isn't used anyway) - branch that includes this in addition to the former is "cursessplit" | ||
| - | * biggest win with attributes was not to inline certain functions (as earlier results on -fno-inline and -finline-limit suggested). investigated all the functions that turned out to decrease in size with a more aggressive inline-limit and found several cases where the effect could be pinpointed to a function or two. set these to noinline (because otherwise, gcc's default inline limit with -Os seems mostly fine - i think it just doesn't take the lower call overhead with regparm properly into account). most interesting result was that for minimal codesize with the new regparm calling conventions, we actually don't want to have the list functions static inline anymore (even the really simple __list_del is only marginally a win inlined, the others aren't). branch named "inline" committed. | + | * biggest win with attributes was not to inline certain functions (as earlier results on -fno-inline and -finline-limit suggested). investigated all the functions that turned out to decrease in size with a more aggressive inline-limit and found several cases where the effect could be pinpointed to a function or two. set these to noinline (because otherwise, gcc's default inline limit with -Os seems mostly fine - i think it just doesn't take the lower call overhead with regparm properly into account). most interesting result was that for minimal codesize with the new regparm calling conventions, we actually don't want to have the list functions static inline anymore (even the really simple __list_del is only marginally a win inlined, the others aren't). branch named "inline" committed (which is based on the memset branch because before that memset/memmove would also have been candidates for noinline) |
| * other than noinline in certain cases, attributes unfortunately turned out to be mostly insignificant for code size. nonnull helps only in special cases (by optimizing away any explicit pointer checks that might be inside), but as it gives us additional compile time checks, it's probably still a good idea (included them in the parts that were committed for other reasons, see above). pure mostly makes no difference either (haven't seen effects of more than +/- 2-3 bytes, seems to even out, and we don't have a lot of them - same). don't think i spotted a const function yet. | * other than noinline in certain cases, attributes unfortunately turned out to be mostly insignificant for code size. nonnull helps only in special cases (by optimizing away any explicit pointer checks that might be inside), but as it gives us additional compile time checks, it's probably still a good idea (included them in the parts that were committed for other reasons, see above). pure mostly makes no difference either (haven't seen effects of more than +/- 2-3 bytes, seems to even out, and we don't have a lot of them - same). don't think i spotted a const function yet. | ||
| - | ==== Still in progress ==== | ||
| - | * commit the malloc annotations (will probably use the strings branch for that, as it isn't merged yet) | + | * commited the malloc annotations (to strings branch, as that wasn't merged yet anyway) |
