Fix a bunch of warnings (fixes #565)

[nox]

No description provided.

[eddyb]

I don't like this, it's not trivial to optimize like the current version. The only thing you can do better is dispatch to another macro or 4 impls on arrays of sizes 0 through 3.

[nox]

"It's not trivial to optimise" doesn't actually say anything about whether it is optimised or not, which sounds like FUD to me.

[eddyb]

@nox As discussed on IRC, it depends on loop unrolling, which is a tradeoff between speed and code size.
LLVM has heuristics for it which I don't know, but I believe atypical leading/trailing iterations may trigger it.

If you want to generate a memcpy, don't we have a copy_from method on slices?

[nox]

Amended with copy_from, thanks @eddyb!

[eddyb]

Wow, look at the Release mode LLVM IR or assembly for before and after this PR.
copy_from_slice (wink wink @ubsan) wins by being a single mov eax, dword ptr [rdi] instruction.

cc @pcwalton This looks like one of those oddities you've seen while reading Rust ASM. MIR trans doesn't help at all here, seems that LLVM just gives up on making it simple for itself.

[eddyb]

Oddly enough, running the worst one though opt again produces the best one. There might be a LLVM pass ordering issue.

[eddyb]

Looks like the super-ugly IR for the for_loop function in the testcase (that opt cleans up) may have a common root with rust-lang/rust#35662 (pointer ranges being optimized worse in LLVM 3.9).