libc: omit memcpy, memmove and memset

[thestinger]

LLVM provides these functions as intrinsics, and will generate calls to
libc when appropriate. They are exposed in the ptr module as
copy_nonoverlapping_memory, copy_memory and set_memory.

@graydon: r?

[brson]

r-. I don't understand the motivation here. There's no harm in having these available. Furthermore, we should not be counting on llvm to 'generate calls to libc when appropriate'. It is essentially never appropriate for llvm to emit foreign function calls on its own because Rust has special requirements dealing with stack growth. If LLVM is doing this for memcpy and friends then we should stop it.

[thestinger]

@brson: it's doing it for memcpy, memmove, memset, fmod, and likely others and I don't think it can be stopped. We could provide our own implementation of the standard C library (at least those functions).

The reasoning behind removing them is that they should never be used directly - LLVM will make a performance decision about generating code or a call with the intrinsic, and it gives it good alignment information.

[brson]

Urgh. I can kind of see why you would want this and why it's ok for LLVM to emit calls to these (they are already #[rust_stack]), but I strongly think we should be in control of all the FFI calls and not let LLVM do those transformations. Foreign calls emitted directly by LLVM have bitten us before.

Leaving three of the most common libc functions out of the libc module seems surprising. Maybe we could redefine them to use the appropraite rust functions, in turn delegating to the intrinsics.

[thestinger]

@brson: perhaps we could just document that equivalent functions are in the ptr module, they're better because they work on chunks aligned to the type and not bytes even without being fully inlined to where they can see the type's allocation on the heap/stack