Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
JIT: Fold typeof(T).TypeHandle.Value #85804
JIT: Fold typeof(T).TypeHandle.Value #85804
Changes from 13 commits
52065e1
04210ec
3c81b79
e4d391b
375df02
9cd3880
7716934
726a42f
5b313af
5bdfc2c
7821c85
7ab11e5
ec522f2
83a6fae
473a361
eaeaef5
0442988
0e4b625
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to create this as
CORINFO_HELP_TYPEHANDLE_TO_RUNTIMETYPEHANDLE
helper call that takes the first arg ofop1
as an input?We have other places in the JIT that look for
CORINFO_HELP_TYPEHANDLE_TO_RUNTIMETYPEHANDLE
. I do not think they will be able to recognize this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It probably makes sense but we'll need to fold it back to a constant somewhere later, I tried to do this and hit no diffs (I'm running ILC for a complex app) so maybe we better teach jit to recognize raw handles if we ever find a use case?
Presumably, there is nothing JIT can do additionally for
typeof(T).TypeHandle.Value;
if it's compared against a different type handle - it will be folded (if possible) anywayThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The canonical shape for creating RuntimeTypeHandle from raw handle used in other places is
CORINFO_HELP_TYPEHANDLE_TO_RUNTIMETYPEHANDLE
helper. I think we should stick to canonical shapes where possible, to allow pattern matching optimizations to compose.Cleaning up
CORINFO_HELP_TYPEHANDLE_TO_RUNTIMETYPEHANDLE
in later stages applies to all places that use canonical shape for creating RuntimeTypeHandle from raw handle.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the change you wanted to see EgorBo@55279bc
It seems to be not needed for CoreCLR since we have to wrap RuntimeType object and I've ran SPMI searching for
CORINFO_HELP_TYPEHANDLE_TO_RUNTIMETYPEHANDLE(class handle)
and found 0 cases.I spent some time trying to find a case where this helps and wasn't able to do so, I only see a worse codegen (a stack spill I can't explain) - my understanding that we promote structs right after importer so it's better to expand them there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that the right way to do this optimization is without any AOT special-casing and without
RuntimeType
special-casing ingetObjectContent
. I think you are saying that it is complicated and not worth it, and that you would prefer to either do nothing or do some of the special casing.@dotnet/jit-contrib Any opinions about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I just feel that the energy is better to spent elsewhere since:
GC.CoreCLR.cs
in our repo + a few hits in OSS judging by grep.appSo we only miss the shared generic case on CoreCLR and unloadable ALC (on CoreCLR). To support both of them we need to mark two methods with [Intrinsic] (
Type.get_TypeHandle
andRuntimeTypeHandle.get_Value
(before it is inlined) - in this case we also will need some hacky way to work with a spilled structRuntimeTypeHandle
before we can detect the shape from two intrinsics.(as a proof that it is not trivial to do anything with this in importer - we need:
this sort of things we avoid doing in importer
We can sort of do this after importer and ForwardSub but we'll need to disable inlining for them which is not great either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it helps, I would be ok with ignoring
RuntimeTypeHandle.get_Value
and tell people to useRuntimeTypeHandle.ToIntPtr
for best results. We have addedRuntimeTypeHandle.ToIntPtr/FromIntPtr
family of APIs recently, as a managed equivalent of some Mono embedding APIs.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that one is at least do-able in importer, I've just added it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is some special spill avoidance in the importer to make recognizing these kinds of multi-call patterns easier; you could extend this if needed.
runtime/src/coreclr/jit/importercalls.cpp
Lines 1414 to 1442 in 7d54c05