Make IL Scanner report both variants

[eduardo-vp]

IL Scanner currently reports only the async variant inside a runtime async method. While the JIT initially chooses this variant too, it can switch to the task returning variant if the async variant is a thunk. Make IL Scanner report both variants such that the JIT can choose either one.

Fixes #127179.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Updates the NativeAOT IL scanner’s call dependency tracking for runtime-async “task await” patterns so it no longer reports only the async-variant method, but instead reports both the original method and its async variant, allowing the JIT to select either implementation during compilation.

Changes:

• Stop rewriting the scanned call target to the async variant; instead, keep the original call target and track the async variant in parallel.
• Add dependency reporting for the async variant alongside the original call target, including generic-lookup-related nodes where applicable.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[MichalStrehovsky]

We should also re-enable the disabled test to validate this indeed fixes the problem.

@jakobbotsch are you okay with us still hardcoding certain things, like the await pattern match? I assume that one is not RyuJIT implementation detail, that one is more of an IL contract.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[eduardo-vp]

/ba-g unrelated failures

[jakobbotsch]

@jakobbotsch are you okay with us still hardcoding certain things, like the await pattern match? I assume that one is not RyuJIT implementation detail, that one is more of an IL contract.

Sorry, I was OOF yesterday (public holiday here).

@EgorBo is currently working on an optimization that will see us switching to more async variants when possible. So NativeAOT should not assume that the only time we use async variants is based on the IL pattern.

For example, after inlining we really want the following to not use the task-returning thunk for C and refer directly to C:

async Task A()
{
  await B();
}

Task<int> B()
{
  return C();
}

[MethodImpl(MethodImplOptions.NoInlining)]
async Task<int> C()
{
  return 42;
}

I assume the only way to make that happen is that the ILScanner reports that the async variant of C is used when it sees it in B (for this issue my understanding is that C would need to be generic to see problems).

[MichalStrehovsky]

I guess once that gets into way, we can relax more as needed. These issues will disappear if we ever get RyuJIT-as-a-scanner.

[jakobbotsch]

I guess once that gets into way, we can relax more as needed. These issues will disappear if we ever get RyuJIT-as-a-scanner.

I imagine this would just be moving the conservativity into the JIT, right? It doesn't seem like there would be away to consistently predict during the scanning phase what happens in cases like the above, since we can later use facts obtained during scanning (like devirtualization that may result in new inlines).

[MichalStrehovsky]

I think RyuJIT-as-a-scanner could in theory already assume some optimizations during scanning phase. But yes, I don't expect it to predict everything, especially not parts that can only be optimized once we have whole program view, so this will still have to be conservative, but maybe less so.