[CI run only] Enable FEATURE_INSTANTIATINGSTUB_AS_IL on win-x86

[filipnavara]

Seems like it works and passes tests, let's verify that. Needs some benchmarking.

[filipnavara]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

[filipnavara]

@EgorBot -windows_intel -use32bit

usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;publicclassSimpleBench{[Benchmark]publicvoidInvokeGenericDelegate()=>(newAction<Object>(ActionFunction)).Invoke(1);voidActionFunction<T>(Tobj){}}

[huoyaoyuan]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

First I just viewed the generated assembly with DOTNET_Jitdisasm before doing benchmark.
For these type of feature that involves signature handling, I'd test something complex, like #104192 (comment)

[filipnavara]

Thanks, that helped. Seems like I will need to investigate if we can make the tailcalls work (ie. no FEATURE_FASTTAILCALL at the moment).

[filipnavara]

Closing this for now, there's too many paper cuts. I'll save the good bits of x86 fast tailcall in a branch for some other time. It's not too far off from working but even if it did work there are code quality issues that need to be resolved first. Analyzing the JIT output revealed three separate problems:

1. Unnecessary EBP frames - addressing that in Exclude tail call counts from check to prevent unnecessary EBP frame #116413
2. When tailcalling a method with struct on stack we copy the argument through PartialRepInstr. This copy and related register allocation happens even if the source and target location of the argument is the same. That's particularly more pronounced on x86 where Span<T> happens to fall into this case. (cc @dotnet/jit-contrib, this would be nice to fix for all platforms)
3. Even the simplest calli happens to be represented by mov eax, <address>; jmp eax. This is not necessarily the end of the world. We generate the same pattern in IL stubs on x64 now. On x86 we do generate jmp near <address> instead in the IL stubs. Seems like this micro-optimization affects the benchmarks on certain Intel processors even if I would expect the effect to be negligable.

[filipnavara]

Seems like it works and passes tests, let's verify that. Needs some benchmarking.

[filipnavara]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

[filipnavara]

@EgorBot -windows_intel -use32bit

usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;publicclassSimpleBench{[Benchmark]publicvoidInvokeGenericDelegate()=>(newAction<Object>(ActionFunction)).Invoke(1);voidActionFunction<T>(Tobj){}}

[huoyaoyuan]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

First I just viewed the generated assembly with DOTNET_Jitdisasm before doing benchmark.
For these type of feature that involves signature handling, I'd test something complex, like #104192 (comment)

[filipnavara]

Thanks, that helped. Seems like I will need to investigate if we can make the tailcalls work (ie. no FEATURE_FASTTAILCALL at the moment).

[filipnavara]

Closing this for now, there's too many paper cuts. I'll save the good bits of x86 fast tailcall in a branch for some other time. It's not too far off from working but even if it did work there are code quality issues that need to be resolved first. Analyzing the JIT output revealed three separate problems:

1. Unnecessary EBP frames - addressing that in Exclude tail call counts from check to prevent unnecessary EBP frame #116413
2. When tailcalling a method with struct on stack we copy the argument through PartialRepInstr. This copy and related register allocation happens even if the source and target location of the argument is the same. That's particularly more pronounced on x86 where Span<T> happens to fall into this case. (cc @dotnet/jit-contrib, this would be nice to fix for all platforms)
3. Even the simplest calli happens to be represented by mov eax, <address>; jmp eax. This is not necessarily the end of the world. We generate the same pattern in IL stubs on x64 now. On x86 we do generate jmp near <address> instead in the IL stubs. Seems like this micro-optimization affects the benchmarks on certain Intel processors even if I would expect the effect to be negligable.

[filipnavara]

Seems like it works and passes tests, let's verify that. Needs some benchmarking.

[filipnavara]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

[filipnavara]

@EgorBot -windows_intel -use32bit

usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;publicclassSimpleBench{[Benchmark]publicvoidInvokeGenericDelegate()=>(newAction<Object>(ActionFunction)).Invoke(1);voidActionFunction<T>(Tobj){}}

[huoyaoyuan]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

First I just viewed the generated assembly with DOTNET_Jitdisasm before doing benchmark.
For these type of feature that involves signature handling, I'd test something complex, like #104192 (comment)

[filipnavara]

Thanks, that helped. Seems like I will need to investigate if we can make the tailcalls work (ie. no FEATURE_FASTTAILCALL at the moment).

[filipnavara]

Closing this for now, there's too many paper cuts. I'll save the good bits of x86 fast tailcall in a branch for some other time. It's not too far off from working but even if it did work there are code quality issues that need to be resolved first. Analyzing the JIT output revealed three separate problems:

1. Unnecessary EBP frames - addressing that in Exclude tail call counts from check to prevent unnecessary EBP frame #116413
2. When tailcalling a method with struct on stack we copy the argument through PartialRepInstr. This copy and related register allocation happens even if the source and target location of the argument is the same. That's particularly more pronounced on x86 where Span<T> happens to fall into this case. (cc @dotnet/jit-contrib, this would be nice to fix for all platforms)
3. Even the simplest calli happens to be represented by mov eax, <address>; jmp eax. This is not necessarily the end of the world. We generate the same pattern in IL stubs on x64 now. On x86 we do generate jmp near <address> instead in the IL stubs. Seems like this micro-optimization affects the benchmarks on certain Intel processors even if I would expect the effect to be negligable.

[filipnavara]

Seems like it works and passes tests, let's verify that. Needs some benchmarking.

[filipnavara]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

[filipnavara]

@EgorBot -windows_intel -use32bit

usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;publicclassSimpleBench{[Benchmark]publicvoidInvokeGenericDelegate()=>(newAction<Object>(ActionFunction)).Invoke(1);voidActionFunction<T>(Tobj){}}

[huoyaoyuan]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

First I just viewed the generated assembly with DOTNET_Jitdisasm before doing benchmark.
For these type of feature that involves signature handling, I'd test something complex, like #104192 (comment)

[filipnavara]

Thanks, that helped. Seems like I will need to investigate if we can make the tailcalls work (ie. no FEATURE_FASTTAILCALL at the moment).

[filipnavara]

Closing this for now, there's too many paper cuts. I'll save the good bits of x86 fast tailcall in a branch for some other time. It's not too far off from working but even if it did work there are code quality issues that need to be resolved first. Analyzing the JIT output revealed three separate problems:

1. Unnecessary EBP frames - addressing that in Exclude tail call counts from check to prevent unnecessary EBP frame #116413
2. When tailcalling a method with struct on stack we copy the argument through PartialRepInstr. This copy and related register allocation happens even if the source and target location of the argument is the same. That's particularly more pronounced on x86 where Span<T> happens to fall into this case. (cc @dotnet/jit-contrib, this would be nice to fix for all platforms)
3. Even the simplest calli happens to be represented by mov eax, <address>; jmp eax. This is not necessarily the end of the world. We generate the same pattern in IL stubs on x64 now. On x86 we do generate jmp near <address> instead in the IL stubs. Seems like this micro-optimization affects the benchmarks on certain Intel processors even if I would expect the effect to be negligable.

[filipnavara]

Seems like it works and passes tests, let's verify that. Needs some benchmarking.

[filipnavara]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

[filipnavara]

@EgorBot -windows_intel -use32bit

usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;publicclassSimpleBench{[Benchmark]publicvoidInvokeGenericDelegate()=>(newAction<Object>(ActionFunction)).Invoke(1);voidActionFunction<T>(Tobj){}}

[huoyaoyuan]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

First I just viewed the generated assembly with DOTNET_Jitdisasm before doing benchmark.
For these type of feature that involves signature handling, I'd test something complex, like #104192 (comment)

[filipnavara]

Thanks, that helped. Seems like I will need to investigate if we can make the tailcalls work (ie. no FEATURE_FASTTAILCALL at the moment).

[filipnavara]

Closing this for now, there's too many paper cuts. I'll save the good bits of x86 fast tailcall in a branch for some other time. It's not too far off from working but even if it did work there are code quality issues that need to be resolved first. Analyzing the JIT output revealed three separate problems:

1. Unnecessary EBP frames - addressing that in Exclude tail call counts from check to prevent unnecessary EBP frame #116413
2. When tailcalling a method with struct on stack we copy the argument through PartialRepInstr. This copy and related register allocation happens even if the source and target location of the argument is the same. That's particularly more pronounced on x86 where Span<T> happens to fall into this case. (cc @dotnet/jit-contrib, this would be nice to fix for all platforms)
3. Even the simplest calli happens to be represented by mov eax, <address>; jmp eax. This is not necessarily the end of the world. We generate the same pattern in IL stubs on x64 now. On x86 we do generate jmp near <address> instead in the IL stubs. Seems like this micro-optimization affects the benchmarks on certain Intel processors even if I would expect the effect to be negligable.

[filipnavara]

Seems like it works and passes tests, let's verify that. Needs some benchmarking.

[filipnavara]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

[filipnavara]

@EgorBot -windows_intel -use32bit

usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;publicclassSimpleBench{[Benchmark]publicvoidInvokeGenericDelegate()=>(newAction<Object>(ActionFunction)).Invoke(1);voidActionFunction<T>(Tobj){}}

[huoyaoyuan]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

First I just viewed the generated assembly with DOTNET_Jitdisasm before doing benchmark.
For these type of feature that involves signature handling, I'd test something complex, like #104192 (comment)

[filipnavara]

Thanks, that helped. Seems like I will need to investigate if we can make the tailcalls work (ie. no FEATURE_FASTTAILCALL at the moment).

[filipnavara]

Closing this for now, there's too many paper cuts. I'll save the good bits of x86 fast tailcall in a branch for some other time. It's not too far off from working but even if it did work there are code quality issues that need to be resolved first. Analyzing the JIT output revealed three separate problems:

1. Unnecessary EBP frames - addressing that in Exclude tail call counts from check to prevent unnecessary EBP frame #116413
2. When tailcalling a method with struct on stack we copy the argument through PartialRepInstr. This copy and related register allocation happens even if the source and target location of the argument is the same. That's particularly more pronounced on x86 where Span<T> happens to fall into this case. (cc @dotnet/jit-contrib, this would be nice to fix for all platforms)
3. Even the simplest calli happens to be represented by mov eax, <address>; jmp eax. This is not necessarily the end of the world. We generate the same pattern in IL stubs on x64 now. On x86 we do generate jmp near <address> instead in the IL stubs. Seems like this micro-optimization affects the benchmarks on certain Intel processors even if I would expect the effect to be negligable.

[filipnavara]

Seems like it works and passes tests, let's verify that. Needs some benchmarking.

[filipnavara]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

[filipnavara]

@EgorBot -windows_intel -use32bit

usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;publicclassSimpleBench{[Benchmark]publicvoidInvokeGenericDelegate()=>(newAction<Object>(ActionFunction)).Invoke(1);voidActionFunction<T>(Tobj){}}

[huoyaoyuan]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

First I just viewed the generated assembly with DOTNET_Jitdisasm before doing benchmark.
For these type of feature that involves signature handling, I'd test something complex, like #104192 (comment)

[filipnavara]

Thanks, that helped. Seems like I will need to investigate if we can make the tailcalls work (ie. no FEATURE_FASTTAILCALL at the moment).

[filipnavara]

Closing this for now, there's too many paper cuts. I'll save the good bits of x86 fast tailcall in a branch for some other time. It's not too far off from working but even if it did work there are code quality issues that need to be resolved first. Analyzing the JIT output revealed three separate problems:

1. Unnecessary EBP frames - addressing that in Exclude tail call counts from check to prevent unnecessary EBP frame #116413
2. When tailcalling a method with struct on stack we copy the argument through PartialRepInstr. This copy and related register allocation happens even if the source and target location of the argument is the same. That's particularly more pronounced on x86 where Span<T> happens to fall into this case. (cc @dotnet/jit-contrib, this would be nice to fix for all platforms)
3. Even the simplest calli happens to be represented by mov eax, <address>; jmp eax. This is not necessarily the end of the world. We generate the same pattern in IL stubs on x64 now. On x86 we do generate jmp near <address> instead in the IL stubs. Seems like this micro-optimization affects the benchmarks on certain Intel processors even if I would expect the effect to be negligable.

[filipnavara]

Seems like it works and passes tests, let's verify that. Needs some benchmarking.

[filipnavara]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

[filipnavara]

@EgorBot -windows_intel -use32bit

usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;publicclassSimpleBench{[Benchmark]publicvoidInvokeGenericDelegate()=>(newAction<Object>(ActionFunction)).Invoke(1);voidActionFunction<T>(Tobj){}}

[huoyaoyuan]

@huoyaoyuan Any thoughts on how to benchmark this? Asking you since you worked on enabling the other FEATURE_*_AS_IL features earlier.

First I just viewed the generated assembly with DOTNET_Jitdisasm before doing benchmark.
For these type of feature that involves signature handling, I'd test something complex, like #104192 (comment)

[filipnavara]

Thanks, that helped. Seems like I will need to investigate if we can make the tailcalls work (ie. no FEATURE_FASTTAILCALL at the moment).

[filipnavara]

Closing this for now, there's too many paper cuts. I'll save the good bits of x86 fast tailcall in a branch for some other time. It's not too far off from working but even if it did work there are code quality issues that need to be resolved first. Analyzing the JIT output revealed three separate problems:

1. Unnecessary EBP frames - addressing that in Exclude tail call counts from check to prevent unnecessary EBP frame #116413
2. When tailcalling a method with struct on stack we copy the argument through PartialRepInstr. This copy and related register allocation happens even if the source and target location of the argument is the same. That's particularly more pronounced on x86 where Span<T> happens to fall into this case. (cc @dotnet/jit-contrib, this would be nice to fix for all platforms)
3. Even the simplest calli happens to be represented by mov eax, <address>; jmp eax. This is not necessarily the end of the world. We generate the same pattern in IL stubs on x64 now. On x86 we do generate jmp near <address> instead in the IL stubs. Seems like this micro-optimization affects the benchmarks on certain Intel processors even if I would expect the effect to be negligable.