compiler-rt: memmove optimisation

[dweiller]

This PR seeks to improve memmove performance and fix some issues with generated code size of the current compiler-rt memmove.

I haven't yet benchmarked this implementation, though I expect the impact to be similar to #18912.

Here is a table of code sizes for ReleastFast (targets chosen somewhat randomly, feel free to suggest additions/removals from the list):

target	cpu	master (B)	3642e26 (B)
thumb-freestanding-eabihf	cortex_m3	16362	438
thumb-freestanding-eabihf	cortex_m4	16362	438
thumb-freestanding-eabihf	cortex_m33	16362	438
thumb-freestanding-eabihf	cortex_m52	2644	420
aarch64-linux	cortex_a53	1472	380
aarch64-linux	cortex_a75	832	568
aarch64-linux	cortex_x1	836	584
aarch64-linux	cortex_x4	832	584
x86_64-linux	x86_64	1402	564
x86_64-linux	x86_64_v2	1402	564
x86_64-linux	x86_64_v3	1348	826
x86_64-linux	x86_64_v4	1348	826

I've marked this a ready for review as I'm not sure when I'll get to benchmarking in earnest and I think this should be merged before 0.14. I think there's no problem merging this as-is (modulo any reviews) and doing the following todos in a follow-up post 0.14 if I don't get it done before hand.

Resolves #22603 (at least for the target discussed there, but presumably for any others as well).

Todo:

• benchmark memmove implementation
• investigate sharing parts of implementation with memcpy

[andrewrk]

maybe just put them back in the same file, like it was before?

[dweiller]

I could, especially if it ends up making sense to share significant parts of their implementations. I was actually planning to move Element into common.zig (with a more descriptive name) since memset is going to want it as well.

[dweiller]

I've move Element's definition to PreferredLoadStoreElement in common.zig - I anticipate using it in memset and possibly memcmp in the future.

[alexrp]

Are you aiming to get this one in for 0.14.0?

[dweiller]

Are you aiming to get this one in for 0.14.0?

Yes, I'd say it's basically mergable as is (there's one or two small things I can think of that I'd change first), which would fix the code size issue we currently have, The thing that will take more time is benchmarking and fine-tuning things based on benchmarks; that might leave things a bit close to the release date. Benchmarking could always be spun off into followup work if we're happy to merge without proper benchmarking.