Partially depessimize userspace memmove, memcpy and bcopy

[mjg]

Summary

The current routines are extremely crude and trivially can get the same benefit as kernel variants (pre-ERMS) in https://svnweb.freebsd.org/base?view=revision&revision=334537

The forward jump overhead when it is needed is pretty much negligible compared to the extra rep spinning up.

Note that decent versions of these routines would be very different than kernel ones as they should possibly use simd, either way there is no point trying to move them all into a shared file.

memset requires a little bit more work and will be dealt with separately

Test Plan

ran buildworld and kyua tests. intentionally reverting conditions in either forward or backwards case brings instant failures.

[kib]

Is the same change useful for 'copy backward' part ?

I think i386 should be synced with the amd64 change.

[mjg]

• also modify copying backwards. did not do it for simplicity, this already has to be reworked.

I don't have any i386 hardware to benchmark on and without it I prefer to not speculate. If there is a 'building to run on amd64' flag I can test for, I'm happy to add it ifdef-ed.

[kib]

In D17167#365955, @mjg wrote:

• also modify copying backwards. did not do it for simplicity, this already has to be reworked.

I don't have any i386 hardware to benchmark on and without it I prefer to not speculate. If there is a 'building to run on amd64' flag I can test for, I'm happy to add it ifdef-ed.

You do have i386 hardware, it is the same machine as you use for amd64 testing. But I do not even propose to boot i386 kernel, just test using the lib32 libraries, 'cc -m32 ... '. I do not see a need to for ifdef for that change on i386. IMO, the main target for userspace i386 is amd64 host.

[mjg]

• cover i386, installed the 32-bit world and chrooted inside, works fine

[kib]

Please renumber local labels so that they are in order of appearance. You can do it as a follow-up commit.