* Jeff Garzik (jgarzik@mandrakesoft.com) [20000617 01:04]:
> struct_cpy is a macro (at least on x86), so it should be easy to put
> special inlining or other compiler rules in there... or make it a macro
> which points to static inline __struct_cpy. Having the code use
> struct_cpy for these cases allows fine tuning of this particular case.
As I've dealt with that "feature" more often then I'd like, let me add to
this discussion.
When Jan Hubika implemented the built in string functions, he also lowered
the threshold up to which the compiler will generate the inlined versions.
As the compiler isn't told that it's actually working in a free standing
environment, it's perfectly valid that it generates libcalls for those cases
where the amount of bytes to be copied exceeds its hard coded limits.
IMHO that struct_cpy macro is a case of being overly clever, given the
number of cases I found where it would have had to be used and wasn't and
also given that no other arch uses a similiar macro.
So I'm fully agreeing with Richard that the only real sane thing to do is to
provide a non inlined memcpy in arch/i386/lib. BTW, Linus already wrote me
that he'd accept a patch providing just that.
Philipp
-- Philipp Thomas <pthomas@suse.de> Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany#define NINODE 50 /* number of in core inodes */ #define NPROC 30 /* max number of processes */ -- Version 7 UNIX for PDP 11, /usr/include/sys/param.h
- 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 : Fri Jun 23 2000 - 21:00:14 EST