Fix release build infinite loop

[BruceForstall]

The problem manifested as an infinite loop during the StackLevelSetter phase
in the release build SuperPMI replay of the tests, but also occurs as a
normal release build test run of the varargsupport.il test.

The issue is we had corrupt LIR gtPrev links, with a cycle. The problem had
nothing to do with StackLevelSetter -- it just happened to be the first phase
that iterated in reverse over the gtPrev links.

The corruption was introduced in the importer, in
verConvertBBToThrowVerificationException. It required a verification failure
in a filter (possibly also catch) clause where the JIT would throw away the
currently imported code and convert the block to a call to the verification
failure helper.

This was a classic case of important, functional code being under #ifdef DEBUG
that is needed in non-DEBUG as well.

The result was we would end up adding an ASG(LCL_VAR, CATCH_ARG) to the statement
list twice, with the same CATCH_ARG node.

Fixes #45580

[BruceForstall]

This argument no longer exists

[BruceForstall]

@dotnet/jit-contrib PTAL

[BruceForstall]

/azp run runtime-coreclr outerloop

[BruceForstall]

/azp run runtime-coreclr jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AndyAyersMS]

I thought all this was now dead code. How is this getting called?

[BruceForstall]

There is this:

    // Set to TRUE if verification cannot be skipped for this method
    // CoreCLR does not ever run IL verification. Compile out the verifier from the JIT by making this a constant.
    // TODO: Delete the verifier from the JIT? (https://github.com/dotnet/runtime/issues/32648)
    // BOOL tiVerificationNeeded;
    static const BOOL tiVerificationNeeded = FALSE;

The caller is

runtime/src/coreclr/jit/importer.cpp

Line 12117 in d64c11e

verRaiseVerifyException(INDEBUG("stack must be 1 on end of filter") DEBUGARG(__FILE__)

[BruceForstall]

jitstress failure is #49954

[AndyAyersMS]

I'm still confused as to how verConvertBBToThrowVerificationException gets called.

What I'm wondering is whether we should BADCODE at the point we decide calling the above makes sense, instead of trying to defer things to runtime.

[BruceForstall]

When verRaiseVerifyException on the bad IL (a filter expression that leaves the IL stack with 2 slots when reaching an endfilter), it raises an exception via RaiseException. It's caught here:

runtime/src/coreclr/jit/importer.cpp

Line 17785 in 389674d

verHandleVerificationFailure(block DEBUGARG(false));

which calls verHandleVerificationFailure which calls verConvertBBToThrowVerificationException.

You're right that perhaps BADCODE is the right behavior; I don't understand why it was originally a verification error and deferred to runtime. I guess we allowed unverifiable code to run and only lazily fail?

[AndyAyersMS]

LGTM.

We can sort out the rest when we delete all the verifier support.