Remove CORINFO_HELP_ASSIGN_BYREF ?

[EgorBo]

#128225 reminded me - can we delete this version of write barrier and use normal checked/unchecked? Maybe long-term even just leave the unchecked one and inline checks in JIT for the checked one?

Currently, we have 5 flavors:

CORINFO_HELP_ASSIGN_REF,
CORINFO_HELP_CHECKED_ASSIGN_REF,
CORINFO_HELP_ASSIGN_REF_ENSURE_NONHEAP,  // Debug only, do we use it?
CORINFO_HELP_ASSIGN_BYREF,
CORINFO_HELP_BULK_WRITEBARRIER,

CORINFO_HELP_ASSIGN_BYREF was beneficial for large struct copies with GC fields due to custom calling convention that bumps pointer, but it's no longer that important with the introduction of CORINFO_HELP_BULK_WRITEBARRIER

Opinions @jkotas @dotnet/jit-contrib?

[dotnet-policy-service]

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

[EgorBo]

Also, shouldn't JIT prefer unchecked WB here (it's in a class).
PS: if that makes sense, we can also introduce an unchecked version of the bulk barrier as well.

[jkotas]

CORINFO_HELP_ASSIGN_REF_ENSURE_NONHEAP

IIRC, it was used by JIT stress at some point. If we are not using it anymore, it is fine to delete it.

CORINFO_HELP_ASSIGN_BYREF

If the codediff numbers show that it is not a meaningful improvement anymore, deleting it is fine with me.

inline checks in JIT for the checked one?

This is code bloating optimization. We may do it for very hot code. I do not think we would want to do that by default, or for AOT where these checks would have to go through indirections.

we can also introduce an unchecked version of the bulk barrier as well.

I doubt that it is worth it. The extra work in checked bulk write barrier is fairly small compared to the work that it needs to do to perform the bulk update.