JIT produces different asm from IL emit than from source

[timcassell]

While refactoring BenchmarkDotNet to call benchmark methods directly instead of through a delegate (dotnet/BenchmarkDotNet#2334), I ran into an issue where the InProcessEmitToolchain is producing different results than the default toolchain. I disassembled it to try to figure out why it was different, and found the only difference is the call instruction.

Default toolchain

call      qword ptr [BenchmarkDotNet.Autogenerated.Runnable_0.__Overhead()]

InProcessEmit

call      BenchmarkDotNet.Autogenerated.Runnable_0.__Overhead()

It wouldn't really be an issue if the workload call also used the same call instruction, but it doesn't, so the overhead measurement is off.

call      qword ptr [ActualWork.IncrementField()]

Is there any way I can make the asm match so we can get correct measurements?

call-direct-default-asm.md
call-direct-inprocess-asm.md

[ghost]

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

Issue Details

---

While refactoring BenchmarkDotNet to call benchmark methods directly instead of through a delegate (dotnet/BenchmarkDotNet#2334), I ran into an issue where the InProcessEmitToolchain is producing different results than the default toolchain. I disassembled it to try to figure out why it was different, and found the only difference is the call instruction.

Default toolchain

call      qword ptr [BenchmarkDotNet.Autogenerated.Runnable_0.__Overhead()]

InProcessEmit

call      BenchmarkDotNet.Autogenerated.Runnable_0.__Overhead()

It wouldn't really be an issue if the workload call also used the same call instruction, but it doesn't, so the overhead measurement is off.

call      qword ptr [ActualWork.IncrementField()]

Is there any way I can make the asm match so we can get correct measurements?

call-direct-default-asm.md
call-direct-inprocess-asm.md

Author:	timcassell
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

Managed calls are always expected to be indirect (square brackets) so it's not clear to me what produced the direct calls, perhaps, those are direct calls to jump-stubs?

[MichalPetryka]

Managed calls are always expected to be indirect (square brackets) so it's not clear to me what produced the direct calls, perhaps, those are direct calls to jump-stubs?

Maybe it's related to the fact that ILEmit is not tiered?

[timcassell]

Maybe it's related to the fact that ILEmit is not tiered?

Would that matter here, though? The OverheadActionUnroll etc methods are annotated with AggressiveOptimization, and the __OverheadWrapper and __WorkloadWrapper methods are annotated with NoOptimization, so there should be no tiering involved.

[EgorBo]

Managed calls are always expected to be indirect (square brackets) so it's not clear to me what produced the direct calls, perhaps, those are direct calls to jump-stubs?

Maybe it's related to the fact that ILEmit is not tiered?

They're indirect not because of tiereing, but because of stubs and potential rejit profiler sessions

[timcassell]

I tried making the wrapper method static and passing in the instance for a virtual call.
I tried making a separate class between the benchmark class and generated class in the hierarchy.
I tried making them completely separate classes (no hierarchical relationship).

No matter what I tried, I could not get the overhead and workload calls to have the same assembly call.

This is only an issue in net7.0+, net6.0 has matching assembly for both methods (it uses the direct calls without qword ptr).

[timcassell]

@EgorBo This issue impacts #89940 (it's part of the fix in my PR).

[EgorBo]

I tried making the wrapper method static and passing in the instance for a virtual call. I tried making a separate class between the benchmark class and generated class in the hierarchy. I tried making them completely separate classes (no hierarchical relationship).

No matter what I tried, I could not get the overhead and workload calls to have the same assembly call.

This is only an issue in net7.0+, net6.0 has matching assembly for both methods (it uses the direct calls without qword ptr).

Are there any steps on how to reproduce this locally?

[timcassell]

Are there any steps on how to reproduce this locally?

Are you able to pull my fork/branch and check it? If not, I can try to create a simple repro.

[EgorBo]

Are there any steps on how to reproduce this locally?

Are you able to pull my fork/branch and check it? If not, I can try to create a simple repro.

I can clone it but it'd be nice to have exact steps on how to build it and reproduce 🙂

[timcassell]

exact steps on how to build it and reproduce

In the BenchmarkDotNet.IntegrationTests.ManualRunning there is a test NonEmptyBenchmarksReportsNonZeroTimeAndZeroAllocated_InProcess. Remove the Skip reason and run it in net7.0 with typeof(ActualWork).