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

/ba-g unrelated failures

@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).

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 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).

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.