[arm64] JIT assertion failures for valid C# code

[adamsitnik]

In #73768 I've wrote quite complex, but valid (it defnitely works fine on x64) C# code that produces JIT assertion failures on arm64:

Sample run: https://github.com/dotnet/runtime/pull/73768/checks?check_run_id=7793120898

Sample log: https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-73768-merge-b3d703c3580445e6b2/JIT.1.Attempt.3/1/console.32c25b20.log?helixlogtype=result

    JIT\Performance\CodeQuality\BenchmarksGame\regex-redux\regex-redux-5\regex-redux-5.cmd [FAIL]
      
      Assert failure(PID 2736 [0x00000ab0], Thread: 11800 [0x2e18]): Assertion failed 'ins != INS_invalid' in 'System.SpanHelpers:LastIndexOfValueType(byref,short,int):int' during 'Generate code' (IL size 335; hash 0xbe43e860; FullOpts)
      
          File: D:\a\_work\1\s\src\coreclr\jit\hwintrinsiccodegenarm64.cpp Line: 282
          Image: D:\h\w\A7BB0946\p\corerun.exe
      
      
      Return code:      1
      Raw output file:      D:\h\w\A7BB0946\w\A93E0970\uploads\Reports\JIT.Performance\CodeQuality\BenchmarksGame\regex-redux\regex-redux-5\regex-redux-5.output.txt
      Raw output:

It would be great if someone from the @dotnet/jit-contrib Team could take a look and let me know whether I've hit a bug in JIT or my code is invalid. Thanks!

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

Issue Details

---

In #73768 I've wrote quite complex, but valid (it defnitely works fine on x64) C# code that produces JIT assertion failures on arm64:

Sample run: https://github.com/dotnet/runtime/pull/73768/checks?check_run_id=7793120898

Sample log: https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-73768-merge-b3d703c3580445e6b2/JIT.1.Attempt.3/1/console.32c25b20.log?helixlogtype=result

    JIT\Performance\CodeQuality\BenchmarksGame\regex-redux\regex-redux-5\regex-redux-5.cmd [FAIL]
      
      Assert failure(PID 2736 [0x00000ab0], Thread: 11800 [0x2e18]): Assertion failed 'ins != INS_invalid' in 'System.SpanHelpers:LastIndexOfValueType(byref,short,int):int' during 'Generate code' (IL size 335; hash 0xbe43e860; FullOpts)
      
          File: D:\a\_work\1\s\src\coreclr\jit\hwintrinsiccodegenarm64.cpp Line: 282
          Image: D:\h\w\A7BB0946\p\corerun.exe
      
      
      Return code:      1
      Raw output file:      D:\h\w\A7BB0946\w\A93E0970\uploads\Reports\JIT.Performance\CodeQuality\BenchmarksGame\regex-redux\regex-redux-5\regex-redux-5.output.txt
      Raw output:

It would be great if someone from the @dotnet/jit-contrib Team could take a look and let me know whether I've hit a bug in JIT or my code is invalid. Thanks!

Author:	adamsitnik
Assignees:	-
Labels:	arch-arm64, area-CodeGen-coreclr
Milestone:	7.0.0

[JulieLeeMSFT]

@BruceForstall, PTAL.

[BruceForstall]

You should never hit a JIT assert under any circumstance.

cc @tannergooding in case I'm wrong w.r.t. hw intrinsics

[SingleAccretion]

The issue here is that for some scalar intrinsics (here it is ArmBase_LeadinZeroCount) "the base type", which is also "the operation type" is derived from the the first operand. This operand can be small while the operation itself isn't.

Simple reproduction:

private static int Problem(short* s)
{
    return ArmBase.LeadingZeroCount(*s);
}

Edit: the presumable fix would be to use genActualType when deriving "base types" from operands.

[tannergooding]

cc @tannergooding in case I'm wrong w.r.t. hw intrinsics

This is correct, assertions shouldn't be hit ever. For recursive intrinsics we should be at worst bailing out in import and causing it to throw a PNSE instead, for regular intrinsics we should at worst be falling back to the managed implementation.

[BruceForstall]

What should be the IR behavior for short types in indirections? The incoming IL is:

ldarg.0
ldind.i2
call

So the ldind.i2 loads an int16 into int32 on the evaluation stack; an implicit cast to int.

If we don't recognize the intrinsic, we have:

  t3 =    LCL_VAR   long   V00 arg0         u:1 x0 (last use) REG x0 $80
       /--*  t3     long
  t4 = *  IND       short  REG x0 <l:$201, c:$200>
       /--*  t4     short
  t8 = *  PUTARG_REG int    REG x0
  t9 =    CNS_INT(h) long   0x7ff7fd7a7d20 ftn REG x1
       /--*  t9     long
 t10 = *  IND       long   REG x1
       /--*  t8     int    arg0 in x0
       +--*  t10    long   control expr
  t5 = *  CALL      int    System.Runtime.Intrinsics.Arm.ArmBase.LeadingZeroCount REG x0 $240

and generate a call like:

ldrsh   w0, [x0]
...
blr     x1

The PUTARG_REG is TYP_INT, but we don't have to generate any code for it.

When we recognize the intrinsic, we have:

  t3 =    LCL_VAR   long   V00 arg0         u:1 x0 (last use) REG x0 $80
       /--*  t3     long
  t4 = *  IND       short  REG x0 <l:$201, c:$200>
       /--*  t4     short
  t5 = *  HWINTRINSIC int     LeadingZeroCount REG x0 <l:$281, c:$280>

and generate the same:

ldrsh   w0, [x0]

before hitting the assert.

the presumable fix would be to use genActualType when deriving "base types" from operands.

Or do we need to insert a cast during importation?

[jakobbotsch]

What should be the IR behavior for short types in indirections?

They are zero/sign-extended to TYP_INT as part of the indirection.

Or do we need to insert a cast during importation?

That cast would just be removed by morph. Using genActualType should be the right fix (using non-actual types for a child node is almost never correct).

I've said this a few times, but I really wish GenTree::TypeGet() would always return actual types and that we would have specific type getters for the nodes that have support for small typed operations (e.g. GenTreeIndir::IndirType()). We time and time again hit these issues due to our representation.