-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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: Drop redundant static initializations from (Equality)Comparer<T>.Default #50446
Conversation
src/coreclr/System.Private.CoreLib/src/System/Collections/Generic/EqualityComparer.CoreCLR.cs
Outdated
Show resolved
Hide resolved
src/coreclr/System.Private.CoreLib/src/System/Collections/Generic/EqualityComparer.CoreCLR.cs
Outdated
Show resolved
Hide resolved
Are you planning to do that in this PR? 😄 |
Yes but I want to see green CI first to make sure it doesn't crash anything 🙂 |
@dotnet/jit-contrib PTAL, failures are not related to this PR. |
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 seem to be 3 things going on here that are interesting. I would like you to think about how to handle each a bit more generally:
- Avoiding extra work when repeatedly checking for named intrinsics. Seems like here we could mark call sites with failed lookups with some new call flag, and short-circuit future lookups if that flag was set.
- Allowing some user methods to be considered "pure" or effectively pure. Instead of repeatedly analyzing for this we could also mark the call site or similar. Generalizing VN to handle arbitrary cases of pure user methods seems challenging though.
- Deciding not to inline some pure functions if we suspect their results are not going to be used and the benefit of inlining them is marginal, so it is easy later on to dead call them.
Co-authored-by: Andy Ayers <andya@microsoft.com>
That flag is unset for most intrinsics, only just a few survive after impIntrinsic (literally just 5) - still makes sense to reset the flag once we handle those 5 I agree.
I wonder if it's easier to do on the Roslyn side (however, I assume Roslyn doesn't want to do this kind of things for performance reasons - otherwise Nullability Analysis would be super powerful)
it'd be nice to have! But first we need to make sure the function we're about to inline is pure (or contains "ignorable" side-effects) so basically solve the second question first. |
@dotnet/jit-contrib PTAL |
Ping @dotnet/jit-contrib |
…comparer-live # Conflicts: # src/coreclr/jit/gentree.h
@dotnet/jit-contrib @AndyAyersMS can anybody please take a look, thanks |
@sandreenko @jakobbotsch could you please take a look? |
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.
LGTM. Can we get rid of the definition of GTF_CALL_M_HELPER_SPECIAL_DCE
now?
Also remember to remove the workarounds that are no longer necessary.
…parer<T>.Default (dotnet#50446)" This reverts commit 46e5fe1.
Implements #48358
Current codegen (tier1, bypassed tier0 due to loop):
NOTE: ^
Equals
is inlined (with help of #48279) but there is some redundant mess (static initialization + nullcheck for field).New codegen:
It looks to me it's easier to just not inline
get_Default
so we'll have a named-intrinsic always available (instead ofCOMMA(cctor, IND(FLD_ADDR))
) so we can always query its class handle viagtGetClassHandle
(see this) or drop the whole call if we see its return value is not used anywhere.It should allow us to remove workaround such as this one and a similar one in the
PriorityQueue
.jit-diff (
-f --pmi
)crossgen jit-diff: