JIT: don't report profile for methods with insufficient samples during prejitting

[EgorBo]

Profile for AOT is collected via a special build of an app (all methods stay in tier0 and are instrumented). Let's assume all methods in hot paths are executed at least 1000 times.
I use entryWeight + callSiteWeight > 1000 formula in order to handle hot loops inside cold methods.

^ Histogram for entryWeight + callSiteWeight for SPC.dll

This PR drastically reduces R2R size when --Ot is passed to crossgen2 (it means ExtendedDefaultPolicy is used).

New size: 10.06Mb

[EgorBo]

@jakobbotsch could you please take a look?

[jakobbotsch]

This seems fine for now, but using raw counts like this in the JIT makes me a bit nervous. E.g. instrumented counts are vastly inflated compared to sampled counts, so comparing them in a raw fashion is difficult.
Ideally this kind of filtering would happen in the training job when the .mibc files are created. We might want to revisit this when we begin consuming SPGO data.

[EgorBo]

This seems fine for now, but using raw counts like this in the JIT makes me a bit nervous. E.g. instrumented counts are vastly inflated compared to sampled counts, so comparing them in a raw fashion is difficult.
Ideally this kind of filtering would happen in the training job when the .mibc files are created. We might want to revisit this when we begin consuming SPGO data.

I agree, but initially I wanted to only decrease chances to inline callees in methods with small call counts. But it makes sense only in case if profile was collected by user for his/her specific workflow so the jit can more or less trust it. But it's not the case for the default profile we ship, e.g. it reports just a few calls for "IntPtr.op_Equaliyt(long, long)`. I believe mostly those come from HelloWorld.ibc - I need to check.