JIT ARM32: Assertion failed 'size == EA_4BYTE' during 'Generate code'

[jakobbotsch]

Description

The following program hits a JIT assert when compiled with optimizations on.

Reproduction Steps

// Generated by Fuzzlyn v1.5 on 2021-10-24 15:05:24
// Run on Arm Linux
// Seed: 12233313255942773337
// Reduced from 205.3 KiB to 0.5 KiB in 00:03:57
// Hits JIT assert in Release:
// Assertion failed 'size == EA_4BYTE' in 'S0:M21():ushort:this' during 'Generate code' (IL size 20)
// 
//     File: /__w/1/s/src/coreclr/jit/emitarm.cpp Line: 2912
// 
public struct S0
{
    public bool F1;
    public ushort F2;
    public sbyte F3;
    public ushort M21()
    {
        var vr2 = Program.s_6;
        Program.M25(vr2, 0, this);
        return 1;
    }
}

public class Program
{
    public static S0 s_6;
    public static S0[][] s_90 = new S0[][]{new S0[]{new S0()}};
    public static void Main()
    {
        var vr6 = s_90[0][0].M21();
    }

    public static void M25(S0 argThis, ulong arg0, S0 arg1)
    {
        var vr5 = s_6.F1;
    }
}

Expected behavior

No assert hit.

Actual behavior

We hit the assert.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

cc @dotnet/jit-contrib

[ghost]

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

Issue Details

---

Description

The following program hits a JIT assert when compiled with optimizations on.

Reproduction Steps

// Generated by Fuzzlyn v1.5 on 2021-10-24 15:05:24
// Run on Arm Linux
// Seed: 12233313255942773337
// Reduced from 205.3 KiB to 0.5 KiB in 00:03:57
// Hits JIT assert in Release:
// Assertion failed 'size == EA_4BYTE' in 'S0:M21():ushort:this' during 'Generate code' (IL size 20)
// 
//     File: /__w/1/s/src/coreclr/jit/emitarm.cpp Line: 2912
// 
public struct S0
{
    public bool F1;
    public ushort F2;
    public sbyte F3;
    public ushort M21()
    {
        var vr2 = Program.s_6;
        Program.M25(vr2, 0, this);
        return 1;
    }
}

public class Program
{
    public static S0 s_6;
    public static S0[][] s_90 = new S0[][]{new S0[]{new S0()}};
    public static void Main()
    {
        var vr6 = s_90[0][0].M21();
    }

    public static void M25(S0 argThis, ulong arg0, S0 arg1)
    {
        var vr5 = s_6.F1;
    }
}

Expected behavior

No assert hit.

Actual behavior

We hit the assert.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

cc @dotnet/jit-contrib

Author:	jakobbotsch
Assignees:	-
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-

[echesakov]

I can take a look at this

[echesakov]

This issue could be reproduced using a simplified version of the original program

using System.Runtime.CompilerServices;

public struct S0
{
    public ushort F1;
    public ushort F2;
    public byte F3;

    public void M21()
    {
        M25(0, 1, 2, 3, this);
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void M25(int r0, int r1, int r2, int r3, S0 stkArg)
    {
    }
}

public class Program
{
    public static int Main()
    {
        new S0().M21();

        return 100;
    }
}

The assert happens when generating PUTARG_STK(OBJ) in M21 to pass 6-byte struct argument stkArg on stack

Generating: N006 (  9,  6) [000005] -c-XG--------        t5 = *  OBJ       struct<S0, 6> REG NA
                                                               /--*  t5     struct
Generating: N008 (???,???) [000014] ---XG--------             *  PUTARG_STK [+0x00] void   (2 slots), (8 stackByteSize), (0 slot), (0 byteOffset) REG NA
                                                        Byref regs: 0001 {r0} => 0000 {}
IN0002:         2B      ldr     r1, [r0]
IN0003:         2B      str     r1, [sp]

Codegen tries to generate ldrh\strh instruction pair for copying the remaining 2 bytes and ended up passing EA_2BYTE as attr to emitIns_R_R_I call. However, emitter expects (even for the small integer types byte\short) attr to be EA_4BYTE for these instructions.

I wonder why we never seen a similar situation on Arm64 - I am going try to repro this before submitting a fix.

[echesakov]

Un-assigning myself
cc @BruceForstall

[jakobbotsch]

@JulieLeeMSFT can you assign someone for this?

[jakobbotsch]

Actually I can take a look.