Stop passing StandardOptimizationData.mibc to crossgen2 multiple times for SPC

[jakobbotsch]

When invoking crossgen2 we are currently passing the mibc file 4 times, once for each scenario we have PGO data for. It means that the counts the JIT sees for SPC are inflated by 4x.

Note that we are using raw counts in the JIT that might be affected by this change:

runtime/src/coreclr/jit/fgprofile.cpp

Lines 50 to 73 in 063d080

	//------------------------------------------------------------------------
	// fgHaveSufficientProfileData: check if profile data is available
	// and is sufficient enough to be trustful.
	//
	// Returns:
	// true if so
	//
	// Note:
	// See notes for fgHaveProfileData.
	//
	bool Compiler::fgHaveSufficientProfileData()
	{
	if (!fgHaveProfileData())
	{
	return false;
	}
	if ((fgFirstBB != nullptr) && (fgPgoSource == ICorJitInfo::PgoSource::Static))
	{
	const weight_t sufficientSamples = 1000;
	return fgFirstBB->bbWeight > sufficientSamples;
	}
	return true;
	}

However it is not right to multiply this value by 0.25x either as I believe for other framework DLLs we are passing StandardOptimizationData.mibc just once. So I am hoping to see if this has ill effects on SPC from the perf legs. @EgorBo's original PR #55096 already has data showing that most hot methods have more than 5000 counts, so hopefully we will not see anything too bad.

cc @dotnet/jit-contrib @davidwrighton

[ghost]

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

Issue Details

---

When invoking crossgen2 we are currently passing the mibc file 4 times, once for each scenario we have PGO data for. It means that the counts the JIT sees for SPC are inflated by 4x.

Note that we are using raw counts in the JIT that might be affected by this change:

runtime/src/coreclr/jit/fgprofile.cpp

Lines 50 to 73 in 063d080

	//------------------------------------------------------------------------
	// fgHaveSufficientProfileData: check if profile data is available
	// and is sufficient enough to be trustful.
	//
	// Returns:
	// true if so
	//
	// Note:
	// See notes for fgHaveProfileData.
	//
	bool Compiler::fgHaveSufficientProfileData()
	{
	if (!fgHaveProfileData())
	{
	return false;
	}
	if ((fgFirstBB != nullptr) && (fgPgoSource == ICorJitInfo::PgoSource::Static))
	{
	const weight_t sufficientSamples = 1000;
	return fgFirstBB->bbWeight > sufficientSamples;
	}
	return true;
	}

However it is not right to multiply this value by 0.25x either as I believe for other framework DLLs we are passing StandardOptimizationData.mibc just once. So I am hoping to see if this has ill effects on SPC from the perf legs. @EgorBo's original PR #55096 already has data showing that most hot methods have more than 5000 counts, so hopefully we will not see anything too bad.

cc @dotnet/jit-contrib @davidwrighton

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

[EgorBo]

I've checked locally this reduces R2R'd corelib size from 10.887 Mb to 10.852 Mb (-0.3%) in --Ot mode which means it inlines slightly less now but it's expected and looks fine to me

[jakobbotsch]

The build failure seems to be because the .mibc file does not exist there, and the build previously did not have any files in OptimizationMibcFiles. @davidwrighton do you know if it is expected that we are currently not passing any .mibc file when crossgenning SPC in the "Build Linux x64 release SourceBuild" pipeline? E.g. the invocation for a previous passing build of the pipeline is:

    /__w/1/s/artifacts/source-build/self/src/dotnet.sh /__w/1/s/artifacts/source-build/self/src/artifacts/bin/coreclr/Linux.x64.Release/crossgen2/crossgen2.dll -o:/__w/1/s/artifacts/source-build/self/src/artifacts/bin/coreclr/Linux.x64.Release/System.Private.CoreLib.dll -r:/__w/1/s/artifacts/source-build/self/src/artifacts/bin/coreclr/Linux.x64.Release/IL/*.dll --targetarch:x64  --embed-pgo-data -O /__w/1/s/artifacts/source-build/self/src/artifacts/bin/coreclr/Linux.x64.Release/IL/System.Private.CoreLib.dll --perfmap-format-version:1 --perfmap --perfmap-path:/__w/1/s/artifacts/source-build/self/src/artifacts/bin/coreclr/Linux.x64.Release/

[jakobbotsch]

Also cc @dotnet/source-build-contrib, is it expected that we are not passing PGO data in the SourceBuild pipeline?

[crummel]

Yes, the PGO data is considered a prebuilt binary that isn't allowed to be used in the open-source builds. We've talked about ways around this but haven't had the resources to really fix it yet.

[jakobbotsch]

Failure is #58927