Add budget check to optReachable

[EgorBo]

Fixes #106675

Reduces crossgen compilation time from 60s to 6s for that test.

[dotnet-policy-service]

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

[EgorBo]

PTAL @jakobbotsch @dotnet/jit-contrib

A few diffs, only from the fast-path check (m_comp->compHasBackwardJump && - I inspected the diffs, they don't contain any loops, but something introduces an artificial backward branch, most likely it's tail-deduplication phase.

[Copilot]

Pull Request Overview

This PR addresses a performance issue in the JIT compiler's if-conversion optimization by adding budget checks to prevent excessive computation during reachability analysis. The change reduces crossgen compilation time from 60 seconds to 6 seconds for the reported test case.

Key changes:

• Added a budget parameter to optReachable to limit the number of blocks examined during reachability analysis
• Modified if-conversion logic to use the budget and skip expensive checks when appropriate
• Optimized debug checking routines to avoid expensive operations on large basic block counts

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/coreclr/jit/compiler.h	Added optional budget parameter to optReachable method signature
src/coreclr/jit/redundantbranchopts.cpp	Implemented budget checking logic in optReachable with two code paths for budgeted vs non-budgeted operation
src/coreclr/jit/ifconversion.cpp	Added reachability budget field and logic to use budgeted reachability checks only when backward jumps are present
src/coreclr/jit/fgdiagnostic.cpp	Optimized debug checks to skip expensive operations when basic block count exceeds 10,000

[risc-vv]

@dotnet/samsung Could you please take a look? These changes may be related to riscv64.

[EgorBo]

@dotnet/samsung Could you please take a look? These changes may be related to riscv64.

Presumably not related.

[kg]

Do you know whether this also reduces peak memory usage during compilation? I can't tell if the allocation of all the huge bitvecs is suppressed by the budget system or not. Improved compile time is good but my understanding is that the test failure in #106675 is caused by the oom killer, so being faster won't necessarily fix it even if it is fantastic for it to be faster.

[EgorBo]

Do you know whether this also reduces peak memory usage during compilation?

Hm.. no, that is something else (I'm seeing 2GB peak memory usage while compiling the repro), this PR only fixes the compilation duration issue, the phase that I'm touching here is not responsible for the working set size.

[EgorBo]

ping @jakobbotsch