-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unclear logic in Compiler::impDevirtualizeCall #43607
Comments
As far as I understand it - it's something a PGO could help with, see #43371 (namely https://github.com/dotnet/runtime/blob/9fb832835ae76aaea574ab88b23da86933b1aa15/docs/design/features/DynamicPgo.md#guarded-devirtualization) I had a quick prototype to implement [__UniqueImplementation("System.Lion, Animals")] // emitted by ILLink substep
public interface IAnimal
{
int GetLegsCount();
}
`` |
You're right that we never create guarded devirtualization candidates for interface calls -- it is not obvious to the jit what class it should guess, and so the jit has to rely on the runtime, and the runtime part is missing. There was some experimental runtime support for [edit: added "never" to the above] For virtual calls the jit can guess a plausible type and drive guarded devirtualization, and we enable that in some of our weekend testing, so the guarded devirt code still works. Feel free to check out the changes in my experimental branch where Tier0 will profile types at virtual and interface call sites and then Tier1 enables guarded devirtualization based on those profiles. I am actively working on this as we speak. If you want experiment with the changes in my branch, you need
and you may also want
In that branch, If you also write out the PGO data
I have a tool that can analyze the data file and produce reports like the following. Happy to share this out if you find it interesting.
|
@AndyAyersMS amazing! can't wait to see a PR with it 🙂 A small question, if I want to collect a profile (and save it to a file) - I should disable tier1 promotion? because I don't want to bake profile data too soon. |
FWIW here's a bit of the output from the jit, when running the CSCBench
|
@EgorBo if you want to collect a full profile for an entire process lifetime for as many methods as possible, then you want something like:
The data is written during normal runtime shutdown so the process has to exit normally. For class profiles you will see things like:
So at this virtual site the Note class profiles are ignored when reading profile data files as my simple profile system doesn't have a robust way of identifying classes. So the write-out support for class profiles is just there for the analysis tool. |
FYI: I broke something in a recent edit so |
Fixed... |
Glad it's working. Have been looking about for realistic benchmarks to try this on. |
Since the original question appears to be answered, I'm closing this. |
I'm learning the code behind devirtualization and stumbled upon this one:
https://github.com/dotnet/runtime/blob/master/src/coreclr/src/jit/importer.cpp#L20539-L20547
For some reason this doesn't embeds, so here are lines under question:
This was introduced in dotnet/coreclr#21270 and never changed afterwards
What my guesses are:
There is no implementation (yet) for getUniqueImplementingClass, so commented out
getUniqueImplementingClass(objClass);
makes sense. And I guess this stub meant to produce value foruniqueImplementingClass
.What surprised me is the following logic ending with the call to
addGuardedDevirtualizationCandidate
which will never be reached due toif (uniqueImplementingClass == NO_CLASS_HANDLE)
.I found no mention of this in dotnet/coreclr#21270
Github search for
getUniqueImplementingClass
gives me nothing as well.The text was updated successfully, but these errors were encountered: