Make u64::midpoint auto-vectorize

[programmerjake]

As reported on Zulip, change u64::midpoint so it doesn't use u128 internally so it auto-vectorizes. I also added a codegen test.

I did not use a LLM to make this.

[rustbot]

r? @mati865

rustbot has assigned @mati865.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 76 candidates
• Random selection from 23 candidates

[programmerjake]

r? libs

[Urgau]

I looked at other targets than x86_64 and they all seems to generate the same assembly for the scalar one, which is surprising (in a good way) since when I added those midpoint operations going through u128 for u64 produced better assembly on pretty much every target. Glad that it's no longer a problem.

[Mark-Simulacrum]

Should we check whether it's still beneficial to go through wider types on other unsigned(?) integers (e.g., i8/i16/i32)?

The actual diff here is:

-((self as u128 + rhs as u128) / 2) as u64
+((self ^ rhs) >> 1) + (self & rhs)

It'd be useful to add documentation on midpoint_impl! describing how to choose between going through the widening path vs. using the bitshift path. From this PR it sounds like either is always(?) correct so presumably we're choosing based on better LLVM integration? If so, do we know if there's any pattern recognition we should be aiming for in LLVM's optimization passes with the IR we generate or tests we can add (e.g., like the codegen test here but for other widths).

@rustbot author