JIT: update jit config defaults for PGO

[AndyAyersMS]

Enable edge profiling by default, when jitting, or when prejitting for R2R.
Keep block profiling there for classic ngen (so there is an entry probe).

Enable minimal probing by default, when jitting. Keep full probing there for
prejitting so presence of counts in a method implies method was executed.

Enable class profiling by default when jitting. Still TBD if we will also
do this when prejitting.

Enable guarded devirtualization by default (will only kick in for PGO).

Adjust experimental CI legs to reflect the above.

Net effect is that when jitting, COMPlus_TieredPGO=1 turns on dynamic PGO
with the expected set of behaviors, without any other options.

We'll still need to set COMPlus_TC_QuickJitForLoops=1 to have methods with
loops pass through Tier0.

[AndyAyersMS]

cc @dotnet/jit-contrib

No diffs in Tier1 codegen for a number of tests I tried manually (versus non-minimal probing).

[jkotas]

Keep block profiling there for classic ngen

Is block profiling generally useful to keep around, or is it just a classic ngen legacy?

If it is the latter, I think it would be ok to just make it no-op for classic ngen. It is what we have been doing in other places.

[AndyAyersMS]

Is block profiling generally useful to keep around,

It is still used if OSR is enabled, since OSR methods can't consume edge profiles just yet.

[AndyAyersMS]

/azp run runtime-jit-experimental

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AndyAyersMS]

There are some expected failures in the jit-experimental runs. However there is a novel failure in bytemark, with the assert:

Assertion failed 'weight >= BB_LOOP_WEIGHT_SCALE' in 'EMFloat:DivideInternalFPF(byref,byref,byref)' 
    during 'Update flow graph opt pass' (IL size 631)
File: D:\workspace\_work\1\s\src\coreclr\jit\optimizer.cpp Line: 385

This is the code in the optimizer that scales non-pgo loop counts.

Since this failure comes from the inline-pgo leg and we're not enabling the pgo inlining policy yet, I'm going to ignore these here.

[AndyAyersMS]

@dotnet/jit-contrib anyone able to review?

[clamp03]

@AndyAyersMS
I tested PGO on crossgen2. It doesn't work. I found this patch that enables edge profiling by default. And I found edge profiler cannot allocate instrumentation data.

runtime/src/coreclr/jit/fgprofile.cpp

Lines 1632 to 1633 in 016ec29

	HRESULT res = info.compCompHnd->allocPgoInstrumentationBySchema(info.compMethodHnd, schema.data(),
	(UINT32)schema.size(), &profileMemory);

because of the below source codes.
in crossge2

runtime/src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs

Lines 2348 to 2355 in 016ec29

	// Validate that each schema item is only used for a basic block count
	for (uint iSchema = 0; iSchema < countSchemaItems; iSchema++)
	{
	if (pSchema[iSchema].InstrumentationKind != PgoInstrumentationKind.BasicBlockIntCount)
	return HRESULT.E_NOTIMPL;
	if (pSchema[iSchema].Count != 1)
	return HRESULT.E_NOTIMPL;
	}

in crossgen1 (R2R)

runtime/src/coreclr/zap/zapinfo.cpp

Lines 960 to 967 in 016ec29

	// Validate that each schema item is only used for a basic block count
	for (UINT32 iSchema = 0; iSchema < countSchemaItems; iSchema++)
	{
	if (pSchema[iSchema].InstrumentationKind != PgoInstrumentationKind::BasicBlockIntCount)
	return E_NOTIMPL;
	if (pSchema[iSchema].Count != 1)
	return E_NOTIMPL;
	}

The default profiling method is changed, but other codes only support BasicBlockIntCount.
Could you please update?

[AndyAyersMS]

@clamp03 thanks for pointing this out.

I'll change the defaults for prejitting back to block profiling.

Our plan going forward is to do instrumentation at runtime instead of when prejitting. See the dotnet-pgo spec.

[AndyAyersMS]

@davidwrighton now that I think about it, it seems like the static PGO path might want to disable the minimal probing so that static tooling can reason about what methods were executed and how often they were called.

I had though the jit/prejit distinction was the right one here, but both static and dynamic PGO leverage dynamic instrumentation, so the interesting distinction is really whether we're going to force methods to remain in Tier0, or let them get re-optimized.

I wonder if we should have a more direct signal for this instead of inferring it from say an unusually high setting for COMPLUS_TC_CallCountThreshold -- knowing what we're trying to measure might also influence the sampling scheme used for class profiling.