Revert to extend_from_slice's previous implementation

[bluss]

Go back to the old implementation of extend_from_slice. This resolves
a performance regression that was discovered in the new extend code
(TrustedLen specialization).

The new extend regularly optimizes well, but a slow case was found.

Fixes #38021

[rust-highfive]

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

[bluss]

r? @alexcrichton

We wouldn't want to have the complication of both code paths here, but this code is what has been confirmed to resolve the performance regression. There will be a new bug opened for the codegen issue with the extend/TrustedLen loop (#38175).

The extend/TrustedLen loop optimizes well in lots of cases, but apparently there are some where it doesn't. A close look shows that extend_from_slice here uses an indexed loop, while in the extend/TrustedLen case for a slice iterator it uses a loop where two different pointers are offset in lock step.

In pseudocode you can describe their difference like this:

extend_from_slice:
for i in 0..len {
    dst[i] = src[i];
}

extend/TrustedLen:
while src != src_end {
    *dst++ = *src++;
}

[bluss]

cc @eddyb You're one of the champions of the extend/TrustedLen formulation of the loop. And it works well in a lot of cases, but evidently not in #38021.

[alexcrichton]

Hm it's somewhat odd that we seems to always be playing games here with LLVM or some form of code golf to always give it just the right sequence for various operations. I wonder, would it be possible to start adding regression tests (perhaps codegen tests) for these sorts of operations?

It's also unfortunate that it seems like we have a litany of methods to do the same operation on Vec, but I guess that's only natural with a standard library type in the expanse of time...

I'm also always a fan of diagnosing these sorts of issues and filing upstream LLVM bugs if possible, that tends to have a nicer effect than fixing them one-off in the source (although it's not always possible though).

[bluss]

Yeah speaking of playing games with the optimizer, I'm doing just that with a thing that might fix extend without this PR... Pending some testing.

[bluss]

I've tried to work with the root cause here too, see the other issues. I've emailed the llvm devs so that I can file bugs in their ivory tower and just today (some days later) I got an account to do so.

[bluss]

The attempt in #38175 (comment) did not work out to resolve the extend_from_slice regression by itself; not sure why. So I don't have another working alternative to propose here.

[bluss]

@alexcrichton A tangent, but something I wanted to work on after this regression was resolved: Can we use specialization to improve performance of a regular user's "dev" profile build of their projects?

Consider for example Clone::clone for Vec<u8>. If we use more Rust code in libcollections for specializations, a function call like that can be made to emit much less code even in debug mode and at the same time be more efficient since it is using memcpy directly. Do you think it would be a viable thing to explore?

[bluss]

Superseded by new proposed fix #38182

[alexcrichton]

@bluss in general yeah we're happy using specialization for perf improvements. We want to avoid extending functionality for now (until specialization is stabilized), but the perf aspect seems ok.