Intrinsify Encoding.UTF8.GetByteCount for constant UTF-16 input

[PaulusParssinen]

I have been recently staring at a lot of UTF-8 <-> UTF-16 manipulation code (in Garnet and ILCompiler name mangling 😆) and thought that if UTF8EncodingSealed.ReadUTF8 is getting VN expansion when JIT can see the input is CNS, maybe it could be done for Encoding.UTF8.GetByteCount too, which is most commonly used to calculate the buffer for the following (Try)GetBytes call (or if the input fits to the existing buffer).

We of course have GetMaxByteCount for the fast calculation of upper-bound, but doing the str.Length * 3 makes the buffer lengths go over any stackalloc thresholds very quickly.

This is very much inspired after and in theme with #85328 (and then painfully hitting #93501 😢 )

[dotnet-policy-service]

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

[PaulusParssinen]

Correct area probably CodeGen-coreclr 😆

[huoyaoyuan]

For constant UTF-8 strings, is u8 string literal an option for you? If not, what's preventing it?

[PaulusParssinen]

u8 is always the better choice if available.

The ReadUTF8 expansion seems to be able to handle any object handle that is IsKnownImmutable e.g. frozen objects such as static readonly string fields. Also in my original plan of simplifying UTF-8 string builder with small custom interpolated string handler it is a problem because the string literals aren't passed as utf-8 RVA spans but as normal strings (we don't have dotnet/csharplang#7072 yet).

runtime/src/coreclr/jit/helperexpansion.cpp

Lines 1616 to 1617 in 426edd0

	// We mostly expect string literal objects here, but let's be more agile just in case
	if (!info.compCompHnd->isObjectImmutable(strObj))

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[EgorBo]

I think it should be fairly trivial to intrinsify GetByteCount indeed