JIT: Bad codegen on win-x86

[jakobbotsch]

// Generated by Fuzzlyn v1.5 on 2022-09-04 15:54:25
// Run on X86 Windows
// Seed: 14105179845188319926
// Reduced from 33.3 KiB to 0.8 KiB in 00:01:22
// Debug: Outputs 0
// Release: Outputs 1
public struct S1
{
 public uint F0;
 public S2 M18(ref int arg0, ulong arg1)
 {
 S1 var6;
 try
 {
 }
 finally
 {
 var6.F0 = Program.s_13;
 this = var6;
 }

 return new S2(0);
 }
}

public struct S2
{
 public S1 F0;
 public short F1;
 public S2(short f1): this()
 {
 F1 = f1;
 }
}

public class Program
{
 public static byte s_4;
 public static int s_10;
 public static uint s_13 = 1;
 public static int s_19;
 public static void Main()
 {
 S2 vr1 = new S2(-1);
 M17(vr1, M17(vr1.F0.M18(ref s_19, 0), s_4));
 }

 public static byte M17(S2 arg0, int arg4)
 {
 System.Console.WriteLine(arg0.F0.F0);
 return (byte)s_10;
 }
}

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

Issue Details

---

// Generated by Fuzzlyn v1.5 on 2022-09-04 15:54:25
// Run on X86 Windows
// Seed: 14105179845188319926
// Reduced from 33.3 KiB to 0.8 KiB in 00:01:22
// Debug: Outputs 0
// Release: Outputs 1
public struct S1
{
 public uint F0;
 public S2 M18(ref int arg0, ulong arg1)
 {
 S1 var6;
 try
 {
 }
 finally
 {
 var6.F0 = Program.s_13;
 this = var6;
 }

 return new S2(0);
 }
}

public struct S2
{
 public S1 F0;
 public short F1;
 public S2(short f1): this()
 {
 F1 = f1;
 }
}

public class Program
{
 public static byte s_4;
 public static int s_10;
 public static uint s_13 = 1;
 public static int s_19;
 public static void Main()
 {
 S2 vr1 = new S2(-1);
 M17(vr1, M17(vr1.F0.M18(ref s_19, 0), s_4));
 }

 public static byte M17(S2 arg0, int arg4)
 {
 System.Console.WriteLine(arg0.F0.F0);
 return (byte)s_10;
 }
}

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

[JulieLeeMSFT]

@jakobbotsch PTAL. cc @dotnet/jit-contrib.

[jakobbotsch]

This looks like fallout from #74384. From a cursory glance we do an illegal copy propagation: vr1 in the example is promoted, the local created for vr.F0 is address exposed, yet we remove the copy of vr1 to a temp. (We do not address expose the parent struct in this case).

Presumably the fix is simple and is to make copy propagation illegal if any field is address exposed.

I won't have time to look into a fix until next week, but this is not a 7.0 issue anyway. @AndyAyersMS feel free to pick it up if you want, otherwise I'll submit a fix next week.

[AndyAyersMS]

Seems like we ought to block this at assertion gen, not assertion prop? We won't reason about struct kills properly if any part of a struct is exposed.

We already check for exposure during assertion gen, but we don't check for dependent field exposure.