Specific AVX2 intrinsic inlining generates faulty x64 code

[damageboy]

I have a short sequence of code that seems to generate faulty x64 code (and crashes the program).

I'm using the latest SDK bits as of this time as suggested by @tannergooding, dotnet --info says:

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview7-012287
 Commit:    f202b59402

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  19.04
 OS Platform: Linux
 RID:         ubuntu.19.04-x64
 Base Path:   /home/dmg/dotnet/sdk/3.0.100-preview7-012287/

Host (useful for support):
  Version: 3.0.0-preview7-27806-02
  Commit:  90a101062a

.NET Core SDKs installed:
  2.1.603 [/home/dmg/dotnet/sdk]
  2.1.700 [/home/dmg/dotnet/sdk]
  3.0.100-preview5-011568 [/home/dmg/dotnet/sdk]
  3.0.100-preview7-012287 [/home/dmg/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.11 [/home/dmg/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.11 [/home/dmg/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview5-19227-01 [/home/dmg/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview7.19306.7 [/home/dmg/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.10 [/home/dmg/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.11 [/home/dmg/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview5-27626-15 [/home/dmg/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview7-27806-02 [/home/dmg/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

I have a complete-repro project setup for this issue.

The faulty code (as seen from lldb disassmbly is):

    0x7f91fc3d149a: shl    esi, 0x3
    0x7f91fc3d149d: movsxd rsi, esi
    0x7f91fc3d14a0: movabs rsi, 0x7f927405ece8
->  0x7f91fc3d14aa: vpmovzxbd ymm1, qword ptr [rsi + rsi] ; ymm1 = mem[0],zero,zero,zero,mem[1],zero,zero,zero,mem[2],zero,zero,zero,mem[3],zero,zero,zero,mem[4],zero,zero,zero,mem[5],zero,zero,zero,mem[6],zero,zero,zero,mem[7],zero,zero,zero

In this fragment, esi is initially the index into the permutation table I'm trying to load/convert, and is left shifted by 3 (as each entry is 8 bytes), but is then overwritten with the base address for the permutation table.

At this stage, the vpmovzxbd [rsi + rsi] is obviously totally bonkers and thankfully generated s segfault...

I think that the bug might be related to the base-address of the permutation array being a ReadOnlySpan<byte> embedded inside the executable, thanks to C# 7.3, as it seems the JIT is trying to correctly optimize it as a constant address during the compilation, but I could also be completely wrong about that last part.

Perviously @tannergooding opened up #25008, which is somewhat related to this issue as it related to how the offset calculation is expressed in the generated code.

[mikedn]

Checked JIT asserts:

Assert failure(PID 12140 [0x00002f6c], Thread: 6644 [0x19f4]): Assertion failed '!"Expected empty defList at end of block"' in 'bugbugbug.Program:Main(ref)' (IL size 110)

    File: d:\projects\coreclr\src\jit\lsrabuild.cpp Line: 2210
    Image: D:\Projects\coreclr\bin\Product\Windows_NT.x64.Checked\CoreRun.exe

[tannergooding]

CC. @CarolEidt

[mikedn]

Same old problem - duplicate logic between lowering/LSRA/codegen. Lowering is deciding when something can be contained and then LSRA and codegen attempt to replicate its decision instead of just obeying what was already decided. And getting it wrong in the process.

In this case lowering has special logic for ConvertToVector256Int32 containment and LSRA doesn't have that and fails to call BuildAddrUses. And the codegen similarly fails to call genConsumeAddress.

I would expect that both LSRA and codegen notice that the operand is a contained address mode and do the right thing. What they instead is attempting to guess if the operand might be a contained address mode.

[AndyAyersMS]

cc @dotnet/jit-contrib. @CarolEidt is this something you plan to work on?

[mikedn]

@CarolEidt If you're busy with something else I think I can fix this later today. Let me know.

[CarolEidt]

@mikedn - thanks, but I can take a look at this (unless you're eager to do it - just let me know!)

[mikedn]

I think I'm going to take a look to see if it's possible to remove the duplicate logic between lowering/LSRA/codegen. However, I expect that to be a more intrusive fix and it's probably not the right time for that.