Span<T>.Slice method is hitting asserts in JIT on Unix

[jkotas]

Assertion failed '((regMask & emitThisGCrefRegs) && (ins == INS_add)) || ((regMask & emitThisByrefRegs) && (ins == INS_add || ins == INS_sub))' in 'System.Span1[Byte][System.Byte]:Slice(int,int):struct:this' (IL size 44)`

[jkotas]

I am adding [MethodImpl(MethodImplOptions.NoOptimization)] workaround in dotnet/coreclr#7886 that should be removed once this is fixed.

[jkotas]

Note that even though this was hit by the new Span code, there is nothing Span-specific in the repro. This looks like a general codegen bug.

To repro:

• Revert dotnet/coreclr@4c5e979
• crossgen System.Private.CoreLib on Unix

[pgavlin]

cc @russellhadley

[sivarv]

The issue here is Jit-EE interface call getFieldType() is returning CORINFO_TYPE_NATIVEINT (instead of CORINFO_TYPE_BYREF) as the type of field ByReference<T>._value. As a result, when JIT struct promotes a var of ByReference<T>, it uses type int as the type of field of _value. This leads to incorrect gc-reporting and surfaces as an assert in emitter.

[sivarv]

Another related issue is that JIT-EE call getClassAttribs() on ByReference<T> struct is not returning CORINFO_FLG_CONTAINS_GC_PTR in the set of flags returned.

[jkotas]

getClassAttribs() on ByReference<T> struct is not returning CORINFO_FLG_CONTAINS_GC_PTR in the set of flags returned.

The contract of getClassAttribs() that we agreed on is that CORINFO_FLG_CONTAINS_STACK_PTR will signal to the JIT that the struct may contain byrefs. CORINFO_FLG_CONTAINS_GC_PTR is only set for structs that do contain regular references.

There is comment about it here: https://github.com/dotnet/coreclr/blob/master/src/jit/importer.cpp#L1492

[sivarv]

Ok. JIT has one more assert here: https://github.com/dotnet/coreclr/blob/master/src/jit/lclvars.cpp#L1595
that too needs to fixed to account for ByReference<T>

After making VM side fix to correctly report field type, you might encounter the above assert.

[kouvel]

It looks like getFieldType() for TypedReference's first field also returns ELEMENT_TYPE_I. Should that also be fixed?

[jkotas]

It looks like getFieldType() for TypedReference's first field also returns ELEMENT_TYPE_I.

The code to compensate for this has always been in the JIT. It is not needed to make things work, but it is not pretty that it is done differently for each type.