[Wasm RyuJit] asserts crossgenning wasm debug SPC

[AndyAyersMS]

Debug SPC Asserts

Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()'

Single method repro args:--singlemethodtypename "System.Array" --singlemethodname "Ctor" --singlemethodindex 2
C:\repos\runtime2\src\coreclr\jit\gentree.h:9528
Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()' in 'System.Array:Ctor(ptr,uint,ptr):System.Array' during 'Linear scan register alloc' (IL size 25; hash 0xfb8a8728; MinOpts)

In the above the IR node is

N006 (???,???) [000007] --CXG+-----                    t7 = *  CALL r2r_ind int    System.Runtime.CompilerServices.ObjectHandleOnStack:Create[System.__Canon](byref):System.Runtime.CompilerServices.ObjectHandleOnStack
                                                            /--*  t7     int
N007 (???,???) [000016] DACXG+-----                         *  STORE_LCL_VAR struct<System.Runtime.CompilerServices.ObjectHandleOnStack, 4> V10 tmp3

and we seem to have an assumption that if the source of a block store is TYP_INT then the source must be an INIT_VAL.

Assertion failed 'emitTypeSizes[TypeGet(type)] > 0'

Single method repro args:--singlemethodtypename "System.GC" --singlemethodname "GetGCMemoryInfo" --singlemethodindex 2
C:\repos\runtime2\src\coreclr\jit\emit.h:3925
Assertion failed 'emitTypeSizes[TypeGet(type)] > 0' in 'System.GC:GetGCMemoryInfo(int):System.GCMemoryInfo' during 'Generate code' (IL size 75; hash 0xec24fb45; MinOpts)

[AndyAyersMS]

FYI @dotnet/jit-contrib

[AndyAyersMS]

Debg SPC Wasm Validation Errors

If you can get past these asserts and use #125752 to get past the WASM_NYI, and are using @kg's test harness, you will then hit some validation errors as the Wasm engine tries to ingest our codegen.

(1) not enough arguments on the stack for memory.copy (need 3, got 2)

[CompileError: WebAssembly.compile(): Compiling function #42 failed: not enough arguments on the stack for memory.copy (need 3, got 2) @+2439733]

which seems to be from this single instance:

--singlemethodname=GetValue
--singlemethodtypename=System.Array
--singlemethodindex=3

Here's a bit of the Wasm stream...

#42 S_P_CoreLib_System_Array__GetValue ( i32, i32, i32, i32 ) -> i32 (327 byte(s))
@2439509  2000        get_local 0 ; i32 arg0
@2439511  41C000      i32_const 0x00000040 ; 64
@2439514  6B          i32_s
...
@2439726  2000        get_local 0 ; i32 arg0
@2439728  4104        i32_const 4
@2439730  6A          i32_add 
@2439731  4108        i32_const 8
@2439733  FC0A0000    memory_copy 

JIT IR here is

               [000101] D----------                  t101 =    LCL_ADDR  byref  V16 tmp8         [+0]
N001 (???,???) [000042] -c---+-----                   t42 =    LCL_VAR   struct<System.ReadOnlySpan`1, 8>(DA) V13 tmp5
                                                            /--*  t101   byref
                                                            +--*  t42    struct
N002 (???,???) [000070] sA---+-----                         *  STORE_BLK struct<System.ReadOnlySpan`1, 8> (copy) (memory.copy)

Looks like we are not properly handling a contained source in codegen?

(2) i64.shl[1] expected type i64, found i32.const of type i32

[CompileError: WebAssembly.compile(): Compiling function #134 failed: i64.shl[1] expected type i64, found i32.const of type i32 @+1214826]

This is from

--singlemethodtypename:System.Decimal 
--singlemethodname:.ctor 
--singlemethodindex:8

wasm is

IN00d4: 00021E      i32.load 0 0      ;; V12
IN00d5: 000221      i64.extend_s_i32
IN00d6: 000222      i32.const 32
IN00d7: 000224      i64.shl

and codegen is

Generating: N004 (???,???) [000040] -----+-----                   t40 =    LCL_VAR   int    V12 tmp7
IN00d3:             local.get 0
IN00d4:             i32.load 0 0      ;; V12
                                                                        /--*  t40    int
Generating: N005 (???,???) [000041] -----+-----                   t41 = *  CAST      long <- int
IN00d5:             i64.extend_s_i32
Generating: N006 (???,???) [000042] -----+-----                   t42 =    CNS_INT   int    32
IN00d6:             i32.const 32
                                                                        /--*  t41    long
                                                                        +--*  t42    int
Generating: N007 (???,???) [000043] -----+-----                   t43 = *  LSH       long
IN00d7:             i64.shl

Think this is just a semantic mismatch, in our trees the shift amount is probably always TYP_INT.

And indeed:

runtime/src/coreclr/jit/codegenwasm.cpp

Lines 1471 to 1473 in 0d2f781

	// TODO-WASM: Zero-extend the 2nd operand for shifts and rotates as needed when the 1st and 2nd operand are
	// different types. The shift operand width in IR is always TYP_INT; the WASM operations have the same widths
	// for both the shift and shiftee. So the shift may need to be extended (zero-extended) for TYP_LONG.

Fix will be something like:

@@ -1477,6 +1477,14 @@ void CodeGen::genCodeForShift(GenTree* tree)
     // different types. The shift operand width in IR is always TYP_INT; the WASM operations have the same widths
     // for both the shift and shiftee. So the shift may need to be extended (zero-extended) for TYP_LONG.

+    if (treeNode->TypeIs(TYP_LONG))
+    {
+        assert(treeNode->gtGetOp2()->TypeIs(TYP_INT));
+        // Zero-extend the shift amount to 64 bits for long shifts/rotates.
+        // Wasteful if the amount was a constant, perhaps we should contain it if so.
+        GetEmitter()->emitIns(INS_i64_extend_u_i32);
+    }
+

(3) call_indirect[2] expected type i64, found i32.load of type i32

[CompileError: WebAssembly.compile(): Compiling function #286 failed: call_indirect[2] expected type i64, found i32.load of type i32 @+1247187]

This is

--singlemethodtypename:System.Environment+ProcessCpuUsage
--singlemethodname:get_TotalTime
--singlemethodindex:1

also seen in

--singlemethodindex:3
--singlemethodtypename:System.GC
--singlemethodname:WaitForFullGCApproach

think it is this bit of wasm

@0305  2000           get_local 0 ; i32 arg0
@0307  2000           get_local 0 ; i32 arg0
@0309  4100           i32_const 0
@0311  2000           get_local 0 ; i32 arg0
@0313  280010         i32_load +16
@0316  2000           get_local 0 ; i32 arg0
@0318  280008         i32_load +8
@0321  4100           i32_const 0
@0323  280000         i32_load +0
@0326  11818080800000 call_indirect 1 tables[0] ; l(iill)

and this bit of IR

Generating: N001 (???,???) [000017] -----+-----                   t17 =    PHYSREG   int    $0
IN001e:             local.get 0
Generating: N002 (???,???) [000016] H----+-----                   t16 =    CNS_INT(h) int    0x420088 ftn
IN001f:             i32.const 0
Generating: N003 (???,???) [000019] -----+-----                   t19 =    LCL_FLD   int    V03 loc1         [+0]
IN0020:             local.get 0
IN0021:             i32.load 0 16      ;; V03
Generating: N004 (???,???) [000021] -----+-----                   t21 =    LCL_FLD   int    V04 tmp1         [+0]
IN0022:             local.get 0
IN0023:             i32.load 0 8      ;; V04
Generating: N001 (???,???) [000030] H----------                   t30 =    CNS_INT(h) int    0x420088 ftn
IN0024:             i32.const 0
                                                                        /--*  t30    int
Generating: N002 (???,???) [000031] n---G------                   t31 = *  IND       int
IN0025:             i32.load 0 0
                                                                        /--*  t17    int    wasm sp $0
                                                                        +--*  t16    int    r2r cell $1
                                                                        +--*  t19    int    arg2 $2
                                                                        +--*  t21    int    arg3 $3
                                                                        +--*  t31    int    control expr
Generating: N005 (???,???) [000008] --CXG+-----                    t8 = *  CALL r2r_ind long   System.TimeSpan:op_Addition(System.TimeSpan,System.TimeSpan):System.TimeSpan

TimeSpan is 8 bytes, so the call sig looks to be correct.

Not sure yet why we are passing those args as ints...

(4) i64.and[0] expected type i64, found i64.eq of type i32

--singlemethodtypename:System.Math
--singlemethodname:DivRem
--singlemethodindex:2

wasm is

@0292  2007           get_local 7 ; i64 local2
@0294  427F           i64_const 0xFFFFFFFFFFFFFFFF ; -1
@0296  51             i64_eq
@0297  2006           get_local 6 ; i64 local1
@0299  4280808080808080 ...
80807F                i64_const 0xFFFFFFFFFFFFFFC0 ; -64
@0310  51             i64_eq
@0311  83             i64_and

Wasm relops always produce i32 results. Should be a simple fix.

(5) i32.clz[0] expected type i32, found i64.load of type i64

--singlemethodtypename:System.Math
--singlemethodname:ILogB
--singlemethodindex:1

wasm is

@0555  2000           ......get_local 0 ; i32 arg0
@0557  290004         ......i64_load +4
@0560  67             ......i32_clz

Seems like it should also be as simple fix... need to dispatch based on source type, and then truncate the result to 32 bits.

[kg]

I'll take a look at the two block store issues.

[AndyAyersMS]

I have fixes for validation cases (2-5) above. Am going to keep pushing on validation for a bit before I PR these.

[AndyAyersMS]

With those the first 1530 or so of methods validate, but error case (3) starts to dominate and is painful to work around. Let me see if I can fix it.

Using the first repro, things look good heading into morph:

fgMorphTree BB01, STMT00002 (before)
               [000009] DAC-G------                         *  STORE_LCL_VAR struct<System.TimeSpan, 8> V05 tmp2         
               [000008] --C-G------                         \--*  CALL r2r_ind struct System.TimeSpan:op_Addition(System.TimeSpan,System.TimeSpan):System.TimeSpan
               [000003] ----------- arg0                       +--*  LCL_VAR   struct<System.TimeSpan, 8> V03 loc1         
               [000007] ----------- arg1                       \--*  LCL_VAR   struct<System.TimeSpan, 8> V04 tmp1         
Adding final args and determining ABI info for [000008]:
Argument 0 ABI info: [00..04) reg $0
Argument 1 ABI info: [00..08) reg $1
Argument 2 ABI info: [00..08) reg $2
Argument 3 ABI info: [00..04) reg $3
Args for call [000008] CALL after AddFinalArgsAndDetermineABIInfo:
CallArg[[000017].LCL_VAR int (By value), 1 segments: <[00..04) reg $0>, wellKnown[WasmShadowStackPointer]]
CallArg[[000003].LCL_VAR struct (By value), 1 segments: <[00..08) reg $1>]
CallArg[[000007].LCL_VAR struct (By value), 1 segments: <[00..08) reg $2>]
CallArg[[000016].CNS_INT int (By value), 1 segments: <[00..04) reg $3>, wellKnown[R2RIndirectionCell]]

TimeSpan is a struct that wraps a long so indeed is passed and returned by value for Wasm.

But then things go off the rails:

Morphing args for 8.CALL:
Struct argument V03: CallArg[[000003].LCL_VAR struct (By value), 1 segments: <[00..08) reg $1>]
fgTryMorphStructArg created tree:
               [000019] -----+-----                         *  LCL_FLD   int    V03 loc1         [+0]
Struct argument V04: CallArg[[000007].LCL_VAR struct (By value), 1 segments: <[00..08) reg $2>]
fgTryMorphStructArg created tree:
               [000021] -----+-----                         *  LCL_FLD   int    V04 tmp1         [+0]

Fix seems fairly simple, just use the seg type for passing "in register" structs for Wasm.

[AndyAyersMS]

More Debug SPC Wasm Validation Errors

Now hitting

(6) invalid numeric opcode: 0xfc41

--singlemethodtypename:System.Half
--singlemethodname:op_Explicit
--singlemethodindex:13

We think we are emitting i32.trunc_sat_f32_s which should be 0xfc00...

This is the case we noted earlier where representing opcodes the way we do leads to ambiguity as to whether this is a 1-byte or 2-byte opcode. Here we just emit the 0xFC.

runtime/src/coreclr/jit/instrswasm.h

Line 224 in aeffb4c

INST(i32_trunc_sat_f32_s, "i32.trunc_sat_f32_s", 0, IF_OPCODE, 0x00FC)

(7) invalid local index: 3

(with fixes for 2-5, bailouts for the asserts and (1), and a workaround for (6) we now have 11,000+ methods passing validation).

Dumping functions... #0 S_P_CoreLib_System_Runtime_CompilerServices_AsyncTaskMethodBuilder_1<System___Canon>__SetException ( i32, i32, i32, i32 ) -> none (136 byte(s))

@0277  2000           get_local 0 ; i32 arg0
@0279  4118           i32_const 0x00000018 ; 24
@0281  6B             i32_sub
@0282  2100           set_local 0 ; i32 arg0
@0284  2000           get_local 0 ; i32 arg0
@0286  2001           get_local 1 ; i32 arg1
@0288  360010         i32_store +16
@0291  2000           get_local 0 ; i32 arg0
@0293  2002           get_local 2 ; i32 arg2
@0295  36000C         i32_store +12
@0298  2000           get_local 0 ; i32 arg0
@0300  2003           get_local 3 ; i32 arg3
@0302  360008         i32_store +8
@0305  2000           get_local 0 ; i32 arg0
@0307  2004           get_local 4 ; INVALID local0
@0309  360004         i32_store +4
@0312  2000           get_local 0 ; i32 arg0

Not sure why it changed from 3 to 4, investigating...

Ah we have an incorrect sig here. There are 5 args but we type this as ( i32, i32, i32, i32 ) -> none. This method has a generic context argument, likely we're not accounting for it somewhere.

Guessing this is over on the JIT host side in WasmFuncType -- the method desc sig probably doesn't include the dictionary parameter for generic methods.