[clr-interp] Implement support for multi-dimensional array get and set accessors

[kotlarmilos]

Description

This PR adds support for multi-dimensional array get and set accessors.

Changes

• Implemented LDELEMA_MD
• Implemented MDArray.Get as a LDELEMA_MD + LDOBJ
• Implemented MDArray.Set as a LDELEMA_MD + STOBJ

[dotnet-policy-service]

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

[jkotas]

This needs to do the same array covariance type checks as single-dimensional arrays.

For example, the following should fail with ArrayTypeMismatchException

string[,] a = new string[1,1];
object[,] ao = a;

ref object r = ref ao[0,0];
Console.WriteLine(r);

[jkotas]

Multi-dimensional array get and set accessors are regular methods that you should be able to just call and the runtime will provide implementations for them. The special opcodes to implement them are an optimization. I do not have a problem with building this optimization, just want to make sure that it is intentional.

[jkotas]

Implemented MDArray.Get as a LDELEMA_MD + LDOBJ
Implemented MDArray.Set as a LDELEMA_MD + STOBJ

This won't work for array of object references due to co-variance.

[kotlarmilos]

Multi-dimensional array get and set accessors are regular methods that you should be able to just call and the runtime will provide implementations for them. The special opcodes to implement them are an optimization. I do not have a problem with building this optimization, just want to make sure that it is intentional.

Thanks. At first, I thought this was an intrinsic (a method without metadata), since m_compHnd->getMethodNameFromMetadata returned null. This PR introduces a fast path while fcalls will be added in #115916.

[jkotas]

This PR introduces a fast path while fcalls will be added in #115916.

Why do we need both? If you add the intrinsic expansion, we won't need the handle these as calls.

Nit: These are not fcalls. It is one method implemented in IL calling another method implemented in IL.

[kotlarmilos]

This PR introduces a fast path while fcalls will be added in #115916.

Why do we need both? If you add the intrinsic expansion, we won't need the handle these as calls.

Nit: These are not fcalls. It is one method implemented in IL calling another method implemented in IL.

Are there any scenarios that the intrinsic expansion doesn’t support? For example, you mentioned the covariance check in this and previous PRs which I wasn’t aware of.

/cc: @kg

[jkotas]

Are there any scenarios that the intrinsic expansion doesn’t support?

There is no functional difference between the two. Intrinsic expansion is just a performance optimization.

You can do method calls for all cases, you can do intrinsic expansion for all cases, or you can do a mix of both (it is what the optimizing JIT does - it does the intrinsic expansion but only when optimizations are on and only for the simple cases.)

[jkotas]

If I were to choose, I would do just calls for now (ie what #115916 does).

[kotlarmilos]

Ok, we can review this once we introduce optimizations. Closing this in favor of #115916