Unexpected type in load/store primitive

[erozenfeld]

We hit this NYI in the following CoreCLR tests (all of the failures are when jitting IL_STUB_Array_Get):

JIT\Methodical\Arrays\lcs_dbglcsmixed
JIT\Methodical\Arrays\lcs_dbglcsvalbox
JIT\Methodical\Arrays\lcs_rellcsmixed
JIT\Methodical\Arrays\lcs_rellcsvalbox
JIT\Methodical\Arrays\lcs_speed_dbglcsmixed
JIT\Methodical\Arrays\lcs_speed_dbglcsvalbox
JIT\Methodical\Arrays\lcs_speed_rellcsmixed
JIT\Methodical\Arrays\lcs_speed_rellcsvalbox

[AndyAyersMS]

I'll take a look.

[AndyAyersMS]

Fyi, the actual test cases are under Arrays\lcs, eg Arrays\lcs_dbglcsmixed, etc. In this case, we see the following stub IL:

0x93  : 152: ldflda     0x4000001
0x98  : 154: ldc.i4.s   0x28
0x9a  : 155: add
0x9b  : 156: ldloc.0
0x9c  : 157: ldc.i4.8
0x9d  : 158: mul
0x9e  : 159: add
0x9f  : 160: ldind.ref

so we're indexing somewhere into this MD array and claiming the resulting address points at an object. LLILC is hoping that the address will have the right reference type here.

  %106 = bitcast %"System.Object[,,,]" addrspace(1)* %104 to i8 addrspace(1)*
  %107 = getelementptr inbounds i8, i8 addrspace(1)* %106, i64 8
  %108 = getelementptr inbounds i8, i8 addrspace(1)* %107, i32 40
  %109 = load i32, i32* %loc0, align 8
  %110 = mul i32 %109, 8
  %111 = getelementptr inbounds i8, i8 addrspace(1)* %108, i32 %110

but given the raw pointer math we've dropped down to byte addressing. This triggers an assert in getTypedAddress.

Note we don't see the assert in the parallel store case because when we store a reference we go via a helper to handle the write barrier, and nothing bothers to match up the pointer referent type with the type being stored.

The fix is likely to relax the logic somewhere along the line. LDIND.REF must assume its address is a pointer to an object pointer. However getTypedAddress is perhaps to low level and the fix should be in loadPrimitiveType.