Use Unsafe.BitCastto cast Memory<T> and ReadOnlyMemory<T>

[xtqqczze]

No description provided.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[xtqqczze]

@MihuBot

[xtqqczze]

@MihuBot

[stephentoub]

Does this not result in worse code generation?

[xtqqczze]

Yes looks like code generation is worse: MihuBot/runtime-utils#855.

[xtqqczze]

I could revert to e09c892.

[stephentoub]

Why change anything?

[xtqqczze]

Code correctness.

[stephentoub]

Why change anything?

Code correctness.

But the code is correct as-is.

[AaronRobinsonMSFT]

Code correctness.

Why is BitCast more correct than As? The BitCast calls As, after it does some minor sanity checks that probably don't matter much in this case. Is the ReadUnaligned important here?

[tannergooding]

The BitCast calls As, after it does some minor sanity checks that probably don't matter much in this case.

You notably can't just look at the managed implementation, which is a fallback. The JIT specializes the implementation in most typical scenarios.

Why is BitCast more correct than As?

It isn't more or less correct. Unsafe.As is like reinterpret_cast in C++ while Unsafe.BitCast is like std::bit_cast.

The former forces the value to be "address taken" (which the JIT can often, but not always elide). It is also in many ways "less safe" because if the layouts of T and U aren't compatible it can lead to faults and other issues. You often need to pair it with Unsafe.ReadUnaligned in order for things to be safe/correct.

The latter avoids these issues and does it by doing an actual bitcast (copy) of the value. In many cases, especially when dealing with promotable/enregisterable values (especially primitives or primitive wrapper structs) this plays better with compiler optimizations. It is also typically easier for the JIT to rationalize when the copy can directly reuse the existing data, such as because the original value was last use.

There are pros/cons to each and which you want really depends on the exact scenario; but BitCast is ultimately a bit safer and the "better" choice to default to in many scenarios. I don't think it much matters to this particular scenario and would rather expect the right things to happen if we provided an internal constructor that does the direct field assignments instead (which is notably what Span and ReadOnlySpan do).

[xtqqczze]

an internal constructor that does the direct field assignments instead (which is notably what Span and ReadOnlySpan do).

@tannergooding I tried that approach in cefb56b but it resulted in substantial regressions: MihuBot/runtime-utils#855

[tannergooding]

I tried that approach in cefb56b but it resulted in substantial regressions: MihuBot/runtime-utils#855

In general we're trying to move away from unsafe code unless its absolutely necessary.

The regressions here might be something that is simple to handle in the JIT, in which case us fixing that would be preferred. At a glance, nothing here really looks "substantial"; rather its a regression of 2400 bytes across the entirety of the BCL (several in things like enumerators and other scenarios that are a bit less likely to occur in practice). The size regressions mostly look due to an unnecessary copy being made as part of the process, which is something that promotion should likely be handling so @jakobbotsch might be the right person to loop in.

Since span is doing the "right things" here, its possible that this is just a pessimization due to their being 3 fields or due to 1 of the fields being a GC ref.