Mark FirstCharInUInt32IsAscii with aggressiveinlining

[EgorBo]

This small method pops up in CPU traces for MinimalApi benchmark.
With this change I see up ~5% improvement for a simple Utf8.FromUtf16 benchmark for small inputs (<32 bytes).

There are two problems here:

1. ILLink doesn't get rid of BitConverter.IsLittleEndian, see ILLink substitute BitConverter.IsLittleEndian as true constant #83169
2. JIT's inliner assigns big weights for ldsfld (it's afraid of potential helper calls)

I was playing with a fix for inliner but it needs a new JIT-EE API + diffs were huge and needs careful analysis. So for now let's slap an AggressiveInlining on it.

[ghost]

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

Issue Details

---

This small method pops in CPU traces for MinimalApi benchmark.
With this change I see up ~5% improvement for a simple Utf8.FromUtf16 benchmark for small inputs (<32 bytes).

There are two problems here:

1. ILLink doesn't get rid of BitConverter.IsLittleEndian, see ILLink substitute BitConverter.IsLittleEndian as true constant #83169
2. JIT's inliner assigns big weights for ldsfld (it's afraid of potential helper calls)

I was playing with a fix for inliner but it needs a new JIT-EE API + diffs were huge and needs careful analysis. So for now let's slap an AggressiveInlining on it.

Author:	EgorBo
Assignees:	EgorBo
Labels:	area-System.Text.Encoding
Milestone:	-

[stephentoub]

Does the JIT do any better by default if it's instead implemented as:

return BitConverter.IsLittleEndian ?
    (value & 0xFF80u) == 0 :
    (value & 0xFF800000u) == 0;

?

[EgorBo]

Sadly, no:

[stephentoub]

Elsewhere in corelib we'll use:

#if BIGENDIAN

Should we do the same thing here instead and not rely on the linker at all?

[EgorBo]

Probably? I think we'll fix that in JIT's inliner eventually so up to you whatever looks better in code