JIT: SSA does not add proper phi args for second pass EH successors

[jakobbotsch]

SSA only looks at the full set of EH successors as part of the "end-of-block" successor iteration. When it sees definitions inside the block, it only looks for enclosing handlers. For example:

private static void Foo()
{
    int x = 123;
    try
    {
        try
        {
            throw new Exception();
        }
        finally
        {
            Console.WriteLine(x);
        }
    }
    catch (Exception) when (Bar(x = 50, Throw(x), x = 123))
    {
    }
}

private static bool Bar(int x, int y, int z)
{
    return true;
}

[MethodImpl(MethodImplOptions.NoInlining)]
private static int Throw(int x)
{
    throw new Exception();
}

The x = 50 here needs to induce a phi arg in the enclosed finally handler, but it doesn't. We effectively get a PHI that indicates the only possible value for x is 123 inside the enclosed finally, but this program enters the finally block with x=50.
It does not cause silent bad codegen here because there is a cycle in the flow-graph between the enclosed finally and the filter, so VN isn't able to deduce x = 123 from the phis.

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

Issue Details

---

SSA only looks at the full set of EH successors as part of the "end-of-block" successor iteration. When it sees definitions inside the block, it only looks for enclosing handlers. For example:

private static void Foo()
{
    int x = 123;
    try
    {
        try
        {
            throw new Exception();
        }
        finally
        {
            Console.WriteLine(x);
        }
    }
    catch (Exception) when (Bar(x = 50, Throw(x), x = 123))
    {
    }
}

private static bool Bar(int x, int y, int z)
{
    return true;
}

[MethodImpl(MethodImplOptions.NoInlining)]
private static int Throw(int x)
{
    throw new Exception();
}

The x = 50 here needs to induce a phi arg in the enclosed finally handler, but it doesn't. We effectively get a PHI that indicates the only possible value for x is 123 inside the enclosed finally, but this program enters the finally block with x=50.
It does not cause silent bad codegen here because there is a cycle between the enclosed finally and the filter, so VN isn't able to deduce x = 123 from the phis.

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