[JitStressWithRandomNumbers] inliningVars.cmd fails

[sandreenko]

Example:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-57900-merge-139159ef372d48dba3/JIT/1/console.27a10f26.log?sv=2019-07-07&se=2021-09-12T00%3A04%3A54Z&sr=c&sp=rl&sig=LVwZuDyZuoFiIx5A5sBz65LlH%2FmTz5q9NpOiuvvQaEU%3D

Repro steps (x86 windows):

set COMPlus_TieredCompilation=0
set COMPlus_JitStress=100
JIT\opt\Inline\regression\bug584219\inliningVars\inliningVars.cmd

Failure log:

   3412
      78563412
      0
      1
      Expected: 100
      Actual: 101

the issue from a quality week JitStress experiment.

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

Issue Details

---

Example:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-57900-merge-139159ef372d48dba3/JIT/1/console.27a10f26.log?sv=2019-07-07&se=2021-09-12T00%3A04%3A54Z&sr=c&sp=rl&sig=LVwZuDyZuoFiIx5A5sBz65LlH%2FmTz5q9NpOiuvvQaEU%3D

Repro steps (x86 windows):

set COMPlus_TieredCompilation=0
set COMPlus_JitStress=100
JIT\opt\Inline\regression\bug584219\inliningVars\inliningVars.cmd

Failure log:

   3412
      78563412
      0
      1
      Expected: 100
      Actual: 101

the issue from a quality week JitStress experiment.

Author:	sandreenko
Assignees:	-
Labels:	JitStress, area-CodeGen-coreclr
Milestone:	6.0.0

[EgorBo]

Dominator BB02 of BB03 has relop with same liberal VN:
N005 (  5,  5) [000078] J------N----              *  LT        int    $40
N003 (  3,  3) [000077] ------------              +--*  ADD       int    $4b
N001 (  1,  1) [000076] ------------              |  +--*  CNS_INT   int    -2 $50
N002 (  1,  1) [000165] ------------              |  \--*  CNS_INT   int    4 $43
N004 (  1,  1) [000073] ------------              \--*  CNS_INT   int    0 $40
 Redundant compare; current relop:
N003 (  3,  6) [000036] J------N----              *  EQ        int    <l:$40, c:$4c3>
N001 (  1,  1) [000034] ------------              +--*  LCL_VAR   int    V04 tmp2         u:2 (last use) <l:$45, c:$4c1>
N002 (  1,  4) [000035] ------------              \--*  CNS_INT   int    0x3412 $54

🤔

[EgorBo]

So it's not x86 specific. The issue can be explained via the following snippet:

private static void Main()
{
    byte[] buffer = new byte[4];
    buffer[0] = 0x11;
    buffer[1] = 0x2;
    buffer[2] = 0x3;
    buffer[3] = 0x4;

    Console.WriteLine(Unsafe.ReadUnaligned<int>(ref buffer[0]) == 0x4030211);
    Console.ReadKey();
}

here is VN for that == 0x4030211 operation:

For some reason IND node has $401 VN (liberal) that is basically stands for 0x11 (17) constant (first element of buffer) - but that IND has TYP_INT => it reads 4 bytes at once, not just the first one.

in a more complicated scenario it leads to an unexpected optimization that used that liberal VN and folded that == to false.

[EgorBo]

Minimal repro:

// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.

using System;
using System.Runtime.CompilerServices;

namespace ConsoleApplication1
{
    internal class Program
    {
        private static int Main()
        {
            int result = 100;
            byte[] buffer = new byte[4];
            buffer[0] = 0x11;
            buffer[1] = 0x2;
            buffer[2] = 0x3;
            buffer[3] = 0x4;

            if (buffer.Length > 0)
            {
                int shrt = Unsafe.ReadUnaligned<int>(ref buffer[0]);
                if (shrt != 0x4030211)
                    result = 101;

                Console.WriteLine(shrt);
                Console.WriteLine(result);
                Console.ReadKey();
            }
            return result;
        }
    }
}

@AndyAyersMS is the problem here that IND node has invalid liberal VN or that optRedundantBranch used liberal VN instead of conservative?

[AndyAyersMS]

Seems like we lose sight of the fact that the IND is doing a wider read. In your jit dump snippet we see VNForMapSelect(..):byte.

Suspect the issue lies in fgValueNumberArrIndexVal or thereabouts.

[EgorBo]

Seems like we lose sight of the fact that the IND is doing a wider read. In your jit dump snippet we see VNForMapSelect(..):byte.

Suspect the issue lies in fgValueNumberArrIndexVal or thereabouts.

yes, already debugging it now 🙂