Remove AggressiveOpt from CastHelpers.LdelemaRef/StelemRef

[EgorBo]

These two methods show up even for an empty app in JitDisasmSummary. The idea that we can treat them as normal managed methods and convert to direct calls once they reach Tier1 naturally (or FullOpts with TC=0).

Almost the final step (except the ETW stuff) to make empty apps jitting-free 🙂 (well, except the Main)

[stephentoub]

And #90416 clears up the ETW stuff, if it's a valid fix (but it seems too easy 😄 ... we'll see what CI and others have to say)

[EgorBo]

This seems to improve benchmarks, e.g.:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){// stelem.ref_array[1]=_obj;_array[2]=_obj;}[Benchmark]publicboolTest2(){// CastHelpers.IsInstanceOf*return_objisIDisposable
or ICloneable
or Program;}

Method	Job	Toolchain	Mean
Test1	Job-PCYDPA	\runtime-main\corerun.exe	3.531 ns
Test1	Job-ZCRCGK	\runtime\corerun.exe	2.815 ns
Test2	Job-PCYDPA	\runtime-main\corerun.exe	3.744 ns
Test2	Job-ZCRCGK	\runtime\corerun.exe	3.525 ns

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same: https://www.diffchecker.com/RT66eY3O/ (stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Test2 is slightly faster because we now optimize indirect calls to direct ones: https://www.diffchecker.com/g5yrentL/ (the last call wasn't optimized to a direct one because it never reached the tier1 in this benchmark - it was never taken).

Hopefully, the difference is even better on arm64 (don't have any device around currently to test)

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@kouvel this is ready for the 2nd round 🙂 all PGO pipelines (with TC=1) look green. Benchmarks: #90412 (comment)

[kouvel]

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same

Possibly because AggressiveOptimization was removed and now it's using tier 1 code. There are code gen differences before and after this change in the helper method.

(stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

[kouvel]

Just a comment/thought, LGTM though, thanks!

[EgorBo]

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine? Going to merge this one into 9.0 now, will see soon perf impact on microbenchmarks (my local runs show improvemnets)

The outerloop failure is #90593

[EgorBo]

With this change, empty console app (without PublishReadyToRun) on Linux jits just one method now! Main itself:

(this PR removed these two cast helpers from this list + several PRs recently got rid of Vector<> paths in some BCL functions and made them prejittable + this is Linux where ETW doesn't trigger 🙂)

[kouvel]

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine?

Yea I meant after this change, there would be R2R'ed code after the first call (AggressiveOptimization prevents R2R code to be generated), an intermediate code version with profiling instrumentation with TieredPGO, and finally the tier 1 code. The precode target I imagine would point to those things along the way and returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases. It is probably very rare though. Solving it would probably require taking the lock every time to check the tier.

Also similarly for the other cast helpers that don't have AggressiveOptimization.

[kouvel]

Solving it would probably require taking the lock every time to check the tier.

Although there may be a shortcut to avoid the lock in startup cases where the helper method hasn't yet been called (maybe the precode target is not set to a native entry point).

[jkotas]

returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

[kouvel]

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

Ah ok, I misread the code, the fallback path would always be an indirect call and that would be fine. Thanks!

[EgorBo]

Arm64 codegen diff:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){_array[1]=_obj;}[Benchmark]publicboolTest2(){return_objisIDisposable;}

https://www.diffchecker.com/WhfRiUit/

[EgorBo]

Improvements:

• [Perf] Windows/arm64: 8 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20785
• [Perf] Linux/arm64: 6 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20799
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Windows/x64: 17 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20774
• [Perf] Windows/x64: 6 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20775
• [Perf] Linux/x64: 3 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20686

Regressions:

• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20791
• [Perf] Linux/arm64: 7 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20794
• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20784
• [Perf] Linux/x64: 7 Regressions on 8/15/2023 7:48:35 PM perf-autofiling-issues#20678
• Regressions from "Remove AO from CastHelpers.LdelemaRef/StelemRef" #90931

[EgorBo]

These two methods show up even for an empty app in JitDisasmSummary. The idea that we can treat them as normal managed methods and convert to direct calls once they reach Tier1 naturally (or FullOpts with TC=0).

Almost the final step (except the ETW stuff) to make empty apps jitting-free 🙂 (well, except the Main)

[stephentoub]

And #90416 clears up the ETW stuff, if it's a valid fix (but it seems too easy 😄 ... we'll see what CI and others have to say)

[EgorBo]

This seems to improve benchmarks, e.g.:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){// stelem.ref_array[1]=_obj;_array[2]=_obj;}[Benchmark]publicboolTest2(){// CastHelpers.IsInstanceOf*return_objisIDisposable
or ICloneable
or Program;}

Method	Job	Toolchain	Mean
Test1	Job-PCYDPA	\runtime-main\corerun.exe	3.531 ns
Test1	Job-ZCRCGK	\runtime\corerun.exe	2.815 ns
Test2	Job-PCYDPA	\runtime-main\corerun.exe	3.744 ns
Test2	Job-ZCRCGK	\runtime\corerun.exe	3.525 ns

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same: https://www.diffchecker.com/RT66eY3O/ (stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Test2 is slightly faster because we now optimize indirect calls to direct ones: https://www.diffchecker.com/g5yrentL/ (the last call wasn't optimized to a direct one because it never reached the tier1 in this benchmark - it was never taken).

Hopefully, the difference is even better on arm64 (don't have any device around currently to test)

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@kouvel this is ready for the 2nd round 🙂 all PGO pipelines (with TC=1) look green. Benchmarks: #90412 (comment)

[kouvel]

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same

Possibly because AggressiveOptimization was removed and now it's using tier 1 code. There are code gen differences before and after this change in the helper method.

(stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

[kouvel]

Just a comment/thought, LGTM though, thanks!

[EgorBo]

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine? Going to merge this one into 9.0 now, will see soon perf impact on microbenchmarks (my local runs show improvemnets)

The outerloop failure is #90593

[EgorBo]

With this change, empty console app (without PublishReadyToRun) on Linux jits just one method now! Main itself:

(this PR removed these two cast helpers from this list + several PRs recently got rid of Vector<> paths in some BCL functions and made them prejittable + this is Linux where ETW doesn't trigger 🙂)

[kouvel]

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine?

Yea I meant after this change, there would be R2R'ed code after the first call (AggressiveOptimization prevents R2R code to be generated), an intermediate code version with profiling instrumentation with TieredPGO, and finally the tier 1 code. The precode target I imagine would point to those things along the way and returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases. It is probably very rare though. Solving it would probably require taking the lock every time to check the tier.

Also similarly for the other cast helpers that don't have AggressiveOptimization.

[kouvel]

Solving it would probably require taking the lock every time to check the tier.

Although there may be a shortcut to avoid the lock in startup cases where the helper method hasn't yet been called (maybe the precode target is not set to a native entry point).

[jkotas]

returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

[kouvel]

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

Ah ok, I misread the code, the fallback path would always be an indirect call and that would be fine. Thanks!

[EgorBo]

Arm64 codegen diff:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){_array[1]=_obj;}[Benchmark]publicboolTest2(){return_objisIDisposable;}

https://www.diffchecker.com/WhfRiUit/

[EgorBo]

Improvements:

• [Perf] Windows/arm64: 8 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20785
• [Perf] Linux/arm64: 6 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20799
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Windows/x64: 17 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20774
• [Perf] Windows/x64: 6 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20775
• [Perf] Linux/x64: 3 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20686

Regressions:

• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20791
• [Perf] Linux/arm64: 7 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20794
• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20784
• [Perf] Linux/x64: 7 Regressions on 8/15/2023 7:48:35 PM perf-autofiling-issues#20678
• Regressions from "Remove AO from CastHelpers.LdelemaRef/StelemRef" #90931

[EgorBo]

These two methods show up even for an empty app in JitDisasmSummary. The idea that we can treat them as normal managed methods and convert to direct calls once they reach Tier1 naturally (or FullOpts with TC=0).

Almost the final step (except the ETW stuff) to make empty apps jitting-free 🙂 (well, except the Main)

[stephentoub]

And #90416 clears up the ETW stuff, if it's a valid fix (but it seems too easy 😄 ... we'll see what CI and others have to say)

[EgorBo]

This seems to improve benchmarks, e.g.:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){// stelem.ref_array[1]=_obj;_array[2]=_obj;}[Benchmark]publicboolTest2(){// CastHelpers.IsInstanceOf*return_objisIDisposable
or ICloneable
or Program;}

Method	Job	Toolchain	Mean
Test1	Job-PCYDPA	\runtime-main\corerun.exe	3.531 ns
Test1	Job-ZCRCGK	\runtime\corerun.exe	2.815 ns
Test2	Job-PCYDPA	\runtime-main\corerun.exe	3.744 ns
Test2	Job-ZCRCGK	\runtime\corerun.exe	3.525 ns

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same: https://www.diffchecker.com/RT66eY3O/ (stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Test2 is slightly faster because we now optimize indirect calls to direct ones: https://www.diffchecker.com/g5yrentL/ (the last call wasn't optimized to a direct one because it never reached the tier1 in this benchmark - it was never taken).

Hopefully, the difference is even better on arm64 (don't have any device around currently to test)

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@kouvel this is ready for the 2nd round 🙂 all PGO pipelines (with TC=1) look green. Benchmarks: #90412 (comment)

[kouvel]

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same

Possibly because AggressiveOptimization was removed and now it's using tier 1 code. There are code gen differences before and after this change in the helper method.

(stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

[kouvel]

Just a comment/thought, LGTM though, thanks!

[EgorBo]

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine? Going to merge this one into 9.0 now, will see soon perf impact on microbenchmarks (my local runs show improvemnets)

The outerloop failure is #90593

[EgorBo]

With this change, empty console app (without PublishReadyToRun) on Linux jits just one method now! Main itself:

(this PR removed these two cast helpers from this list + several PRs recently got rid of Vector<> paths in some BCL functions and made them prejittable + this is Linux where ETW doesn't trigger 🙂)

[kouvel]

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine?

Yea I meant after this change, there would be R2R'ed code after the first call (AggressiveOptimization prevents R2R code to be generated), an intermediate code version with profiling instrumentation with TieredPGO, and finally the tier 1 code. The precode target I imagine would point to those things along the way and returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases. It is probably very rare though. Solving it would probably require taking the lock every time to check the tier.

Also similarly for the other cast helpers that don't have AggressiveOptimization.

[kouvel]

Solving it would probably require taking the lock every time to check the tier.

Although there may be a shortcut to avoid the lock in startup cases where the helper method hasn't yet been called (maybe the precode target is not set to a native entry point).

[jkotas]

returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

[kouvel]

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

Ah ok, I misread the code, the fallback path would always be an indirect call and that would be fine. Thanks!

[EgorBo]

Arm64 codegen diff:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){_array[1]=_obj;}[Benchmark]publicboolTest2(){return_objisIDisposable;}

https://www.diffchecker.com/WhfRiUit/

[EgorBo]

Improvements:

• [Perf] Windows/arm64: 8 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20785
• [Perf] Linux/arm64: 6 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20799
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Windows/x64: 17 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20774
• [Perf] Windows/x64: 6 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20775
• [Perf] Linux/x64: 3 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20686

Regressions:

• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20791
• [Perf] Linux/arm64: 7 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20794
• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20784
• [Perf] Linux/x64: 7 Regressions on 8/15/2023 7:48:35 PM perf-autofiling-issues#20678
• Regressions from "Remove AO from CastHelpers.LdelemaRef/StelemRef" #90931

[EgorBo]

These two methods show up even for an empty app in JitDisasmSummary. The idea that we can treat them as normal managed methods and convert to direct calls once they reach Tier1 naturally (or FullOpts with TC=0).

Almost the final step (except the ETW stuff) to make empty apps jitting-free 🙂 (well, except the Main)

[stephentoub]

And #90416 clears up the ETW stuff, if it's a valid fix (but it seems too easy 😄 ... we'll see what CI and others have to say)

[EgorBo]

This seems to improve benchmarks, e.g.:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){// stelem.ref_array[1]=_obj;_array[2]=_obj;}[Benchmark]publicboolTest2(){// CastHelpers.IsInstanceOf*return_objisIDisposable
or ICloneable
or Program;}

Method	Job	Toolchain	Mean
Test1	Job-PCYDPA	\runtime-main\corerun.exe	3.531 ns
Test1	Job-ZCRCGK	\runtime\corerun.exe	2.815 ns
Test2	Job-PCYDPA	\runtime-main\corerun.exe	3.744 ns
Test2	Job-ZCRCGK	\runtime\corerun.exe	3.525 ns

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same: https://www.diffchecker.com/RT66eY3O/ (stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Test2 is slightly faster because we now optimize indirect calls to direct ones: https://www.diffchecker.com/g5yrentL/ (the last call wasn't optimized to a direct one because it never reached the tier1 in this benchmark - it was never taken).

Hopefully, the difference is even better on arm64 (don't have any device around currently to test)

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@kouvel this is ready for the 2nd round 🙂 all PGO pipelines (with TC=1) look green. Benchmarks: #90412 (comment)

[kouvel]

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same

Possibly because AggressiveOptimization was removed and now it's using tier 1 code. There are code gen differences before and after this change in the helper method.

(stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

[kouvel]

Just a comment/thought, LGTM though, thanks!

[EgorBo]

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine? Going to merge this one into 9.0 now, will see soon perf impact on microbenchmarks (my local runs show improvemnets)

The outerloop failure is #90593

[EgorBo]

With this change, empty console app (without PublishReadyToRun) on Linux jits just one method now! Main itself:

(this PR removed these two cast helpers from this list + several PRs recently got rid of Vector<> paths in some BCL functions and made them prejittable + this is Linux where ETW doesn't trigger 🙂)

[kouvel]

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine?

Yea I meant after this change, there would be R2R'ed code after the first call (AggressiveOptimization prevents R2R code to be generated), an intermediate code version with profiling instrumentation with TieredPGO, and finally the tier 1 code. The precode target I imagine would point to those things along the way and returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases. It is probably very rare though. Solving it would probably require taking the lock every time to check the tier.

Also similarly for the other cast helpers that don't have AggressiveOptimization.

[kouvel]

Solving it would probably require taking the lock every time to check the tier.

Although there may be a shortcut to avoid the lock in startup cases where the helper method hasn't yet been called (maybe the precode target is not set to a native entry point).

[jkotas]

returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

[kouvel]

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

Ah ok, I misread the code, the fallback path would always be an indirect call and that would be fine. Thanks!

[EgorBo]

Arm64 codegen diff:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){_array[1]=_obj;}[Benchmark]publicboolTest2(){return_objisIDisposable;}

https://www.diffchecker.com/WhfRiUit/

[EgorBo]

Improvements:

• [Perf] Windows/arm64: 8 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20785
• [Perf] Linux/arm64: 6 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20799
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Windows/x64: 17 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20774
• [Perf] Windows/x64: 6 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20775
• [Perf] Linux/x64: 3 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20686

Regressions:

• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20791
• [Perf] Linux/arm64: 7 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20794
• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20784
• [Perf] Linux/x64: 7 Regressions on 8/15/2023 7:48:35 PM perf-autofiling-issues#20678
• Regressions from "Remove AO from CastHelpers.LdelemaRef/StelemRef" #90931

[EgorBo]

These two methods show up even for an empty app in JitDisasmSummary. The idea that we can treat them as normal managed methods and convert to direct calls once they reach Tier1 naturally (or FullOpts with TC=0).

Almost the final step (except the ETW stuff) to make empty apps jitting-free 🙂 (well, except the Main)

[stephentoub]

And #90416 clears up the ETW stuff, if it's a valid fix (but it seems too easy 😄 ... we'll see what CI and others have to say)

[EgorBo]

This seems to improve benchmarks, e.g.:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){// stelem.ref_array[1]=_obj;_array[2]=_obj;}[Benchmark]publicboolTest2(){// CastHelpers.IsInstanceOf*return_objisIDisposable
or ICloneable
or Program;}

Method	Job	Toolchain	Mean
Test1	Job-PCYDPA	\runtime-main\corerun.exe	3.531 ns
Test1	Job-ZCRCGK	\runtime\corerun.exe	2.815 ns
Test2	Job-PCYDPA	\runtime-main\corerun.exe	3.744 ns
Test2	Job-ZCRCGK	\runtime\corerun.exe	3.525 ns

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same: https://www.diffchecker.com/RT66eY3O/ (stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Test2 is slightly faster because we now optimize indirect calls to direct ones: https://www.diffchecker.com/g5yrentL/ (the last call wasn't optimized to a direct one because it never reached the tier1 in this benchmark - it was never taken).

Hopefully, the difference is even better on arm64 (don't have any device around currently to test)

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@kouvel this is ready for the 2nd round 🙂 all PGO pipelines (with TC=1) look green. Benchmarks: #90412 (comment)

[kouvel]

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same

Possibly because AggressiveOptimization was removed and now it's using tier 1 code. There are code gen differences before and after this change in the helper method.

(stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

[kouvel]

Just a comment/thought, LGTM though, thanks!

[EgorBo]

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine? Going to merge this one into 9.0 now, will see soon perf impact on microbenchmarks (my local runs show improvemnets)

The outerloop failure is #90593

[EgorBo]

With this change, empty console app (without PublishReadyToRun) on Linux jits just one method now! Main itself:

(this PR removed these two cast helpers from this list + several PRs recently got rid of Vector<> paths in some BCL functions and made them prejittable + this is Linux where ETW doesn't trigger 🙂)

[kouvel]

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine?

Yea I meant after this change, there would be R2R'ed code after the first call (AggressiveOptimization prevents R2R code to be generated), an intermediate code version with profiling instrumentation with TieredPGO, and finally the tier 1 code. The precode target I imagine would point to those things along the way and returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases. It is probably very rare though. Solving it would probably require taking the lock every time to check the tier.

Also similarly for the other cast helpers that don't have AggressiveOptimization.

[kouvel]

Solving it would probably require taking the lock every time to check the tier.

Although there may be a shortcut to avoid the lock in startup cases where the helper method hasn't yet been called (maybe the precode target is not set to a native entry point).

[jkotas]

returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

[kouvel]

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

Ah ok, I misread the code, the fallback path would always be an indirect call and that would be fine. Thanks!

[EgorBo]

Arm64 codegen diff:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){_array[1]=_obj;}[Benchmark]publicboolTest2(){return_objisIDisposable;}

https://www.diffchecker.com/WhfRiUit/

[EgorBo]

Improvements:

• [Perf] Windows/arm64: 8 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20785
• [Perf] Linux/arm64: 6 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20799
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Windows/x64: 17 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20774
• [Perf] Windows/x64: 6 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20775
• [Perf] Linux/x64: 3 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20686

Regressions:

• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20791
• [Perf] Linux/arm64: 7 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20794
• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20784
• [Perf] Linux/x64: 7 Regressions on 8/15/2023 7:48:35 PM perf-autofiling-issues#20678
• Regressions from "Remove AO from CastHelpers.LdelemaRef/StelemRef" #90931

[EgorBo]

These two methods show up even for an empty app in JitDisasmSummary. The idea that we can treat them as normal managed methods and convert to direct calls once they reach Tier1 naturally (or FullOpts with TC=0).

Almost the final step (except the ETW stuff) to make empty apps jitting-free 🙂 (well, except the Main)

[stephentoub]

And #90416 clears up the ETW stuff, if it's a valid fix (but it seems too easy 😄 ... we'll see what CI and others have to say)

[EgorBo]

This seems to improve benchmarks, e.g.:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){// stelem.ref_array[1]=_obj;_array[2]=_obj;}[Benchmark]publicboolTest2(){// CastHelpers.IsInstanceOf*return_objisIDisposable
or ICloneable
or Program;}

Method	Job	Toolchain	Mean
Test1	Job-PCYDPA	\runtime-main\corerun.exe	3.531 ns
Test1	Job-ZCRCGK	\runtime\corerun.exe	2.815 ns
Test2	Job-PCYDPA	\runtime-main\corerun.exe	3.744 ns
Test2	Job-ZCRCGK	\runtime\corerun.exe	3.525 ns

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same: https://www.diffchecker.com/RT66eY3O/ (stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Test2 is slightly faster because we now optimize indirect calls to direct ones: https://www.diffchecker.com/g5yrentL/ (the last call wasn't optimized to a direct one because it never reached the tier1 in this benchmark - it was never taken).

Hopefully, the difference is even better on arm64 (don't have any device around currently to test)

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@kouvel this is ready for the 2nd round 🙂 all PGO pipelines (with TC=1) look green. Benchmarks: #90412 (comment)

[kouvel]

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same

Possibly because AggressiveOptimization was removed and now it's using tier 1 code. There are code gen differences before and after this change in the helper method.

(stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

[kouvel]

Just a comment/thought, LGTM though, thanks!

[EgorBo]

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine? Going to merge this one into 9.0 now, will see soon perf impact on microbenchmarks (my local runs show improvemnets)

The outerloop failure is #90593

[EgorBo]

With this change, empty console app (without PublishReadyToRun) on Linux jits just one method now! Main itself:

(this PR removed these two cast helpers from this list + several PRs recently got rid of Vector<> paths in some BCL functions and made them prejittable + this is Linux where ETW doesn't trigger 🙂)

[kouvel]

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine?

Yea I meant after this change, there would be R2R'ed code after the first call (AggressiveOptimization prevents R2R code to be generated), an intermediate code version with profiling instrumentation with TieredPGO, and finally the tier 1 code. The precode target I imagine would point to those things along the way and returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases. It is probably very rare though. Solving it would probably require taking the lock every time to check the tier.

Also similarly for the other cast helpers that don't have AggressiveOptimization.

[kouvel]

Solving it would probably require taking the lock every time to check the tier.

Although there may be a shortcut to avoid the lock in startup cases where the helper method hasn't yet been called (maybe the precode target is not set to a native entry point).

[jkotas]

returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

[kouvel]

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

Ah ok, I misread the code, the fallback path would always be an indirect call and that would be fine. Thanks!

[EgorBo]

Arm64 codegen diff:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){_array[1]=_obj;}[Benchmark]publicboolTest2(){return_objisIDisposable;}

https://www.diffchecker.com/WhfRiUit/

[EgorBo]

Improvements:

• [Perf] Windows/arm64: 8 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20785
• [Perf] Linux/arm64: 6 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20799
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Windows/x64: 17 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20774
• [Perf] Windows/x64: 6 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20775
• [Perf] Linux/x64: 3 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20686

Regressions:

• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20791
• [Perf] Linux/arm64: 7 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20794
• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20784
• [Perf] Linux/x64: 7 Regressions on 8/15/2023 7:48:35 PM perf-autofiling-issues#20678
• Regressions from "Remove AO from CastHelpers.LdelemaRef/StelemRef" #90931

[EgorBo]

These two methods show up even for an empty app in JitDisasmSummary. The idea that we can treat them as normal managed methods and convert to direct calls once they reach Tier1 naturally (or FullOpts with TC=0).

Almost the final step (except the ETW stuff) to make empty apps jitting-free 🙂 (well, except the Main)

[stephentoub]

And #90416 clears up the ETW stuff, if it's a valid fix (but it seems too easy 😄 ... we'll see what CI and others have to say)

[EgorBo]

This seems to improve benchmarks, e.g.:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){// stelem.ref_array[1]=_obj;_array[2]=_obj;}[Benchmark]publicboolTest2(){// CastHelpers.IsInstanceOf*return_objisIDisposable
or ICloneable
or Program;}

Method	Job	Toolchain	Mean
Test1	Job-PCYDPA	\runtime-main\corerun.exe	3.531 ns
Test1	Job-ZCRCGK	\runtime\corerun.exe	2.815 ns
Test2	Job-PCYDPA	\runtime-main\corerun.exe	3.744 ns
Test2	Job-ZCRCGK	\runtime\corerun.exe	3.525 ns

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same: https://www.diffchecker.com/RT66eY3O/ (stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Test2 is slightly faster because we now optimize indirect calls to direct ones: https://www.diffchecker.com/g5yrentL/ (the last call wasn't optimized to a direct one because it never reached the tier1 in this benchmark - it was never taken).

Hopefully, the difference is even better on arm64 (don't have any device around currently to test)

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@kouvel this is ready for the 2nd round 🙂 all PGO pipelines (with TC=1) look green. Benchmarks: #90412 (comment)

[kouvel]

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same

Possibly because AggressiveOptimization was removed and now it's using tier 1 code. There are code gen differences before and after this change in the helper method.

(stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

[kouvel]

Just a comment/thought, LGTM though, thanks!

[EgorBo]

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine? Going to merge this one into 9.0 now, will see soon perf impact on microbenchmarks (my local runs show improvemnets)

The outerloop failure is #90593

[EgorBo]

With this change, empty console app (without PublishReadyToRun) on Linux jits just one method now! Main itself:

(this PR removed these two cast helpers from this list + several PRs recently got rid of Vector<> paths in some BCL functions and made them prejittable + this is Linux where ETW doesn't trigger 🙂)

[kouvel]

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine?

Yea I meant after this change, there would be R2R'ed code after the first call (AggressiveOptimization prevents R2R code to be generated), an intermediate code version with profiling instrumentation with TieredPGO, and finally the tier 1 code. The precode target I imagine would point to those things along the way and returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases. It is probably very rare though. Solving it would probably require taking the lock every time to check the tier.

Also similarly for the other cast helpers that don't have AggressiveOptimization.

[kouvel]

Solving it would probably require taking the lock every time to check the tier.

Although there may be a shortcut to avoid the lock in startup cases where the helper method hasn't yet been called (maybe the precode target is not set to a native entry point).

[jkotas]

returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

[kouvel]

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

Ah ok, I misread the code, the fallback path would always be an indirect call and that would be fine. Thanks!

[EgorBo]

Arm64 codegen diff:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){_array[1]=_obj;}[Benchmark]publicboolTest2(){return_objisIDisposable;}

https://www.diffchecker.com/WhfRiUit/

[EgorBo]

Improvements:

• [Perf] Windows/arm64: 8 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20785
• [Perf] Linux/arm64: 6 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20799
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Windows/x64: 17 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20774
• [Perf] Windows/x64: 6 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20775
• [Perf] Linux/x64: 3 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20686

Regressions:

• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20791
• [Perf] Linux/arm64: 7 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20794
• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20784
• [Perf] Linux/x64: 7 Regressions on 8/15/2023 7:48:35 PM perf-autofiling-issues#20678
• Regressions from "Remove AO from CastHelpers.LdelemaRef/StelemRef" #90931

[EgorBo]

These two methods show up even for an empty app in JitDisasmSummary. The idea that we can treat them as normal managed methods and convert to direct calls once they reach Tier1 naturally (or FullOpts with TC=0).

Almost the final step (except the ETW stuff) to make empty apps jitting-free 🙂 (well, except the Main)

[stephentoub]

And #90416 clears up the ETW stuff, if it's a valid fix (but it seems too easy 😄 ... we'll see what CI and others have to say)

[EgorBo]

This seems to improve benchmarks, e.g.:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){// stelem.ref_array[1]=_obj;_array[2]=_obj;}[Benchmark]publicboolTest2(){// CastHelpers.IsInstanceOf*return_objisIDisposable
or ICloneable
or Program;}

Method	Job	Toolchain	Mean
Test1	Job-PCYDPA	\runtime-main\corerun.exe	3.531 ns
Test1	Job-ZCRCGK	\runtime\corerun.exe	2.815 ns
Test2	Job-PCYDPA	\runtime-main\corerun.exe	3.744 ns
Test2	Job-ZCRCGK	\runtime\corerun.exe	3.525 ns

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same: https://www.diffchecker.com/RT66eY3O/ (stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Test2 is slightly faster because we now optimize indirect calls to direct ones: https://www.diffchecker.com/g5yrentL/ (the last call wasn't optimized to a direct one because it never reached the tier1 in this benchmark - it was never taken).

Hopefully, the difference is even better on arm64 (don't have any device around currently to test)

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@kouvel this is ready for the 2nd round 🙂 all PGO pipelines (with TC=1) look green. Benchmarks: #90412 (comment)

[kouvel]

I don't know why Test1 is faster but it seems like a stable improvement between runs, the codegen is the same

Possibly because AggressiveOptimization was removed and now it's using tier 1 code. There are code gen differences before and after this change in the helper method.

(stlem is a direct call as expected) - perhaps the method itself got allocated in a different part of the execution heap since it's no longer Aggressive opt? Or maybe the previous direct target wasn't entirely correct and pointed to a stub directly?

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

[kouvel]

Just a comment/thought, LGTM though, thanks!

[EgorBo]

Given that it was doing a direct call previously also, I wonder if there's a possibility that it could do a direct call to any tier including tier 0 (which would probably be r2r'd code, which may be ok perhaps) or an instrumented tier. Wonder if this should also be specialized for the other tiers to have it do an indirect call instead.

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine? Going to merge this one into 9.0 now, will see soon perf impact on microbenchmarks (my local runs show improvemnets)

The outerloop failure is #90593

[EgorBo]

With this change, empty console app (without PublishReadyToRun) on Linux jits just one method now! Main itself:

(this PR removed these two cast helpers from this list + several PRs recently got rid of Vector<> paths in some BCL functions and made them prejittable + this is Linux where ETW doesn't trigger 🙂)

[kouvel]

Like you mentioned, it had AggressiveOptimization attribute on it so presumably it was fine?

Yea I meant after this change, there would be R2R'ed code after the first call (AggressiveOptimization prevents R2R code to be generated), an intermediate code version with profiling instrumentation with TieredPGO, and finally the tier 1 code. The precode target I imagine would point to those things along the way and returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases. It is probably very rare though. Solving it would probably require taking the lock every time to check the tier.

Also similarly for the other cast helpers that don't have AggressiveOptimization.

[kouvel]

Solving it would probably require taking the lock every time to check the tier.

Although there may be a shortcut to avoid the lock in startup cases where the helper method hasn't yet been called (maybe the precode target is not set to a native entry point).

[jkotas]

returning the precode's target in the fallback path may mean that there is a possibility for there to be direct calls to non-final tiers in some cases

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

[kouvel]

I do not think there is any code that would short-circuit the precode. If the JIT gets a pointer to precode, it is going to call it.

Ah ok, I misread the code, the fallback path would always be an indirect call and that would be fine. Thanks!

[EgorBo]

Arm64 codegen diff:

object[]_array=newobject[1000];object_obj="test";[Benchmark]publicvoidTest1(){_array[1]=_obj;}[Benchmark]publicboolTest2(){return_objisIDisposable;}

https://www.diffchecker.com/WhfRiUit/

[EgorBo]

Improvements:

• [Perf] Windows/arm64: 8 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20785
• [Perf] Linux/arm64: 6 Improvements on 8/16/2023 6:13:11 AM perf-autofiling-issues#20799
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Linux/x64: 14 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20687
• [Perf] Windows/x64: 17 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20774
• [Perf] Windows/x64: 6 Improvements on 8/16/2023 3:30:19 PM perf-autofiling-issues#20775
• [Perf] Linux/x64: 3 Improvements on 8/15/2023 7:48:35 PM perf-autofiling-issues#20686

Regressions:

• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20791
• [Perf] Linux/arm64: 7 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20794
• [Perf] Windows/arm64: 6 Regressions on 8/16/2023 6:13:11 AM perf-autofiling-issues#20784
• [Perf] Linux/x64: 7 Regressions on 8/15/2023 7:48:35 PM perf-autofiling-issues#20678
• Regressions from "Remove AO from CastHelpers.LdelemaRef/StelemRef" #90931