JIT: fix inliner profile consistency computation

[AndyAyersMS]

It's possible for the JIT to inline a profiled inlinee into an unprofiled context, and then have a subsequent inline fold a profiled branch. If so we may see a case where the folded edges don't have profile information.

Tolerate this.

Fixes #109657

Re-morphing of a statement during early-prop may mistakenly believe it has altered the flow graph and so invalidates DFS. Value numbering is not set up to handle this and crashes. Since this seems like a rare occurrence, have morph detect if it has really changed the flowgraph and avoid invalidating the DFS when it hasn't.

Fixes #109730

[AndyAyersMS]

cc @dotnet/jit-contrib
@amanasifkhalid PTAL

There is some other libraries jitstress issue, so it still may not run cleanly.

[AndyAyersMS]

/azp run runtime-coreclr libraries-jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[amanasifkhalid]

LGTM, thanks!

There is some other libraries jitstress issue, so it still may not run cleanly.

Do you know if there's an issue already tracking this? I'm seeing quite a few tests fail with AVs.

[AndyAyersMS]

LGTM, thanks!

There is some other libraries jitstress issue, so it still may not run cleanly.

Do you know if there's an issue already tracking this? I'm seeing quite a few tests fail with AVs.

I just opened one: #109730

[AndyAyersMS]

Not sure why build analysis is unhappy here...

[amanasifkhalid]

Not sure why build analysis is unhappy here...

I suspect it's because there aren't tracking issues for the timeouts, and opening a meta-issue to capture all timeouts isn't ideal.

Edit: Ah, Build Analysis marked the timeouts as "known" infra issues. Not sure either.

[AndyAyersMS]

I added a fix for the AVs, so let's see if libraries jit stress is now happy.

[AndyAyersMS]

/azp run runtime-coreclr libraries-jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[amanasifkhalid]

AV fix LGTM

[AndyAyersMS]

Jitutils build is failing, wonder if 6.0 packages are no longer findable? 6.0 is out of support now.

Determining projects to restore...
/__w/runtime/runtime/jitutils/src/jit-dasm/jit-dasm.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.linux-x64 with version (= 6.0.36)
/__w/runtime/runtime/jitutils/src/jit-dasm/jit-dasm.csproj : error NU1102:   - Found 1562 version(s) in dotnet7 [ Nearest version: 7.0.0-alpha.1.21[41](https://github.com/dotnet/runtime/actions/runs/11804422106/job/32884591447?pr=109714#step:5:42)7.28 ]
/__w/runtime/runtime/jitutils/src/jit-dasm/jit-dasm.csproj : error NU1102:   - Found 174 version(s) in dotnet-public [ Nearest version: 7.0.0-preview.1.22076.8 ]
/__w/runtime/runtime/jitutils/src/jit-dasm/jit-dasm.csproj : error NU1102:   - Found 0 version(s) in dotnet-libraries
/__w/runtime/runtime/jitutils/src/jit-dasm/jit-dasm.csproj : error NU1102:   - Found 0 version(s) in myget-legacy
  Failed to restore /__w/runtime/runtime/jitutils/src/jit-dasm/jit-dasm.csproj (in 1.28 sec).

[AndyAyersMS]

libraries-jitstress still not clean:

Assert failure(PID 4116 [0x00001014], Thread: 9356 [0x248c]): Assertion failed 'doesVNMatch' in 'System.Collections.Immutable.Tests.ImmutableArrayTest+<ChangeType>d__192`1[int]:MoveNext():ubyte:this' during 'Assertion prop' (IL size 362; hash 0x08aa2d36; FullOpts)

    File: D:\a\_work\1\s\src\coreclr\jit\assertionprop.cpp:1486
    Image: C:\h\w\A3450896\p\dotnet.exe

Opened #109745

[AndyAyersMS]

handful of Diffs... not sure why yet.

[AndyAyersMS]

Diffs are because fgConvertBBtoThrowBB also makes the block rare. So revising the fix a bit to preserve this behavior.