Correct, but I still think it's a bug. IMHO, it is OK to require -O
for kernel compiles, but it should be possible to compile user-level
programs without -O.
Agreed, but something like this probably belongs in libc.a, not only
inline in a header file during userlevel program compilation. The
inline declaration will operate as a typing declaration for the libc.a
real version instead of an inline definition as it does with -O turned
on.
Also, I'm not convinced that the __constant_c_memset is such a great
idea---it results in a 64-bit constant being loaded from memory, which
is potentially much slower on a cache-miss than the few instructions
that it takes to replicate the byte eight times (except for the
important special case where the constant is zero, of course).
I am, think about this, assuming a harvard architecture with data/inst
caches look at the following situation. Let's say for argument
purposes that all instructions are 32-bits in size (the common case
with risc chips both 32/64bit in nature). Let's also say that the
extra instructions generated to produce the byte replication is on the
order of two or more than the load from memory. Finally lets assume
that an instruction cache miss locks the entire pipeline until the
cache miss can be resolved. Under these circumstances the load from
memory is more efficient than the byte replication except of course
for the constant of zero even if the data cache is missed during the
operation.
This is very dependant upon the line size of the caches on the chip,
and whether the cache can strobe the 'needed' part of a line to
various stages of the pipe before the entire line is filled. (FWIW,
the MicroSparc processors do this by grabbing the needed line first,
strobing it into the necessary pipeline stage, then fetching the rest
of the line).
Later,
David S. Miller
davem@caip.rutgers.edu