Philipp Thomas wrote:
> > kernel/kernel.o: In function `check_free_space':
> > kernel/kernel.o(.text+0xb394): undefined reference to `memset'
> > make: *** [vmlinux] Error 1
> > [root@smitten]:/usr/src/linux#
>
> Let me guess: you're using a CVS version of gcc, right? Current CVS gcc has
> lowered the limit where it will stop creating inlined memcpy and start
> creating libcalls. All of the places I've found to date were either doing
> direct struct copying (via a = b) or passing structs by value.
All this fuss trying to get memcpy inlined.
If the GCC folks lowered the threshold for out of line memcpy, doesn't
that mean that out of line memcpy is _faster_ in those cases?
x86 has rep; mosvl and frankly that's the fastest for large memcpys on
the recent processors, and it's tiny, so GCC _should_ select it for all
large copies except when using -m486/586. If GCC isn't doing that then
it's a GCC bug.
But for -m486/586 compiles, GCC is choosing the _best_ code by calling
an out of line memcpy function for larger copies. Assuming the
threshold is set correctly.
Perhaps our kernel problem is that our idea of the correct threshold is
different to GCC's idea of it.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:26 EST