Provide block counts in tiered compilation from R2R images

[davidwrighton]

Tiered compilation can reduce the performance of application by replacing IBC tuned R2R code with non-tuned jitted code. See #13451 Consider enhancing the R2R format to allow method block counts to be stored in R2R images and used by the runtime. This is causing a ~20% regression in the performance of the StringBuilder.Append code

[EgorBo]

Not sure it's related but today I found this gem:
https://github.com/dotnet/coreclr/blob/8460516ceb23458f7a279bb73aa6176e17e8a90d/src/jit/emit.cpp#L4542-L4552

PS: Don't we need a kind of deoptimization in order to rely on PGO data? E.g. something in the app session changed and now blocks' weights are not relevant anymore.

[BruceForstall]

cc @briansull @AndyAyersMS

[briansull]

PS: Don't we need a kind of deoptimization in order to rely on PGO data? E.g. something in the app session changed and now blocks' weights are not relevant anymore.

Yes, That is already what we do when a method is modified and the ILsize no longer matches.

https://github.com/dotnet/coreclr/blob/2f1d783cbaa806981c6640d85a28da8f5875b735/src/jit/compiler.cpp#L3516-L3533

[davidwrighton]

I think that @EgorBo is referring to the idea that the application may have different typical pathways through code than the training data. While this is a serious concern, historically we've had this problem for the binaries we shipped to customers for many years on the desktop framework, and the performance impact was not a large problem for the scenarios where our optimizations have kicked in in unfortunate ways.

I believe (but do not have strong evidence for my belief) that this is due to the fairly limited sets of optimizations that take advantage of this profile data. I also believe this to be a higher risk if we start to take a heavier dependence on profile data for optimizations such as devirtualization. Since our training scenarios are quite limited in CoreCLR, I expect that when we implement this feature, we will have a good opportunity to observe potential positive/negative effects on our performance results and make a judgement of regressions at that time.

[sergiy-k]

/cc: @kouvel

[davidwrighton]

This work won't make .NET 5.

[davidwrighton]

EgorBo is working on this with #70941

[mangod9]

@EgorBo do we expect this to make it into 7?

[davidwrighton]

We implemented this particular feature with --embed-pgo-data which we use only for System.Private.CoreLib. @EgorBo's work provides the ability to get live runtime based pgo data, which is even better.