Add logic for selecting the right version of pgort140 #71968
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThis fixes an issue where the Arm64 PGO instrumented SDK had the x64 version of pgort140.dll
|
|
/azp run "CoreCLR Product Build windows arm64 release PGO" |
|
No pipelines are associated with this pull request. |
|
I have already tested this on the PGO builds locally, so if all the other checks pass I would like to merge this ASAP. @agocke @dotnet/runtime-infrastructure |
| if(CLR_CMAKE_TARGET_ARCH_ARM64) | ||
| cmake_path(SET PGORT_DIR "$ENV{VCToolsInstallDir}bin/arm64") | ||
| elseif(CLR_CMAKE_TARGET_ARCH_I386) | ||
| cmake_path(SET PGORT_DIR "$ENV{VCToolsInstallDir}bin/Hostx86/x86") |
There was a problem hiding this comment.
This should probably work, but I think we only support building on x64, so technically this should be Hostx64/x86
There was a problem hiding this comment.
I will fix it up. Want to do it right :)
There was a problem hiding this comment.
Actually, Hostx64/x86 does not contain pgort140.dll. So I am going to stick with what I have.
|
We detected that might be caused by this PR via the August Perf Report and looks like it was reported in a few places but hasn't been triaged yet:
Here are the details from the perf report: System.Numerics.Tests.Perf_BigInteger.Parse(numberString: 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890)
|
|
I doubt that this change could have caused this regression. It does not change anything about the shipping product, it just changes one of the binaries that gets bin-placed for the instrumented SDK. |
ghost
locked as resolved and limited conversation to collaborators
This fixes an issue where the Arm64 PGO instrumented SDK had the x64 version of pgort140.dll