Large perf regressions in coreclr.dll native code

[jkotas]

Repro

• build.cmd -s clr.native -c release -rc release -a x86 at https://github.com/dotnet/runtime/tree/48dd30ed6e21699fa03422872b0539b165bd4741

Observe coreclr.dll size is 4,579,328

• build.cmd -s clr.native -c release -rc release -a x86 at https://github.com/dotnet/runtime/tree/3086d8a1c30b28290b44e73cd96b23194906c2cf (commit immediately after)

Observe coreclr.dll size is 6,098,432 (33% regression)

The x86 large size difference is just one manifestation of the regression. There are regressions on other architectures and there are regressions in throughput too. (I have run into them when trying to validate #93766 for servicing backport.)

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

Issue Details

---

Repro

• build.cmd -s clr.native -c release -rc release -a x86 at https://github.com/dotnet/runtime/tree/48dd30ed6e21699fa03422872b0539b165bd4741

Observe coreclr.dll size is 4,579,328

• build.cmd -s clr.native -c release -rc release -a x86 at https://github.com/dotnet/runtime/tree/3086d8a1c30b28290b44e73cd96b23194906c2cf

Observe coreclr.dll size is 6,098,432 (33% regression)

The x86 large size difference is just one manifestation of the regression. There are regressions on other architectures and there are regressions in throughput too. (I have run into them when trying to validate #93766 for servicing backport.)

Author:	jkotas
Assignees:	-
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-

[jkotas]

@jtschuster This was introduced by #92844.

cc @jkoritzinsky

I am considering reverting the change. The longer we run with it, the more problems it is going to cause in our performance tracking.

[jakobbotsch]

FWIW, I noticed that CET was enabled in the native EXEs before #93838 (windbg was exiting with an error when trying to record TTD trace). Maybe it could explain the regression?

[jkotas]

CET should not be a thing on 32-bit x86. I have briefly looked into it before reverting and the top contributor to the binary size regression seemed to be broken LTCG. The linker command line had number of changes that did not look intentional.