From: Miles Bader <snogglethorpe@xxxxxxxxx>
On 4/28/05, Tom Lord <lord@xxxxxxx> wrote:
> Anyone care to make a case for `mem_cpy' in baz's hackerlab?
For the normal libc "memcpy", the non-overlapping constraint can be a
nice improvement when the compiler inlines the code -- there are many
cases where memcpy is used to copy a short constant-sized piece of
memory with known alignment, but otherwise arbitrary pointer values.
If overlap were allowed, the inlined code size would double, and
there'd be a basically unpredictable conditional branch, which.is
anathema on modern machines...
Do you have any data on how many of those cases rely on the programmer
providing the extra information available from using the cpy rather
than move interface? In some common cases, at least, the compiler
could figure that out for itself pretty easily. Of course, all the
usual economic arguments against supporting such "optimizations"
apply, regardless.
As for hackerlab, I think there is some value in maintaing a rough
correspondence with similar libc interfaces.
Just having `mem_move' counts as a rough correspondence, doesn't it?
-t
|
