Skip to content
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: enable cloning based on loop invariant type tests #70377

Merged
merged 2 commits into from
Jun 8, 2022

Conversation

AndyAyersMS
Copy link
Member

Such as those added by GDV.

The JIT will now clone just for type tests, or just for array bounds, or for
a mixture of the two. The JIT will still produce just one fast and one slow loop.
If there are a mixture of array bounds and type test conditions, all conditions
must pass for control to reach the fast loop.

Unlike array bounds checks, type test failures are not intrinsically rare,
so there is some profitability screening to ensure that a failed type test does
not force execution to run the slow version "too often". The type test must
execute frequently within the loop, and be heavily biased towards success.

This is work towards resolving #65206.

Such as those added by GDV.

The JIT will now clone just for type tests, or just for array bounds, or for
a mixture of the two. The JIT will still produce just one fast and one slow loop.
If there are a mixture of array bounds and type test conditions, all conditions
must pass for control to reach the fast loop.

Unlike array bounds checks, type test failures are not intrinsically rare,
so there is some profitability screening to ensure that a failed type test does
not force execution to run the slow version "too often". The type test must
execute frequently within the loop, and be heavily biased towards success.

This is work towards resolving dotnet#65206.
@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 7, 2022
@ghost ghost assigned AndyAyersMS Jun 7, 2022
@ghost
Copy link

ghost commented Jun 7, 2022

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

Such as those added by GDV.

The JIT will now clone just for type tests, or just for array bounds, or for
a mixture of the two. The JIT will still produce just one fast and one slow loop.
If there are a mixture of array bounds and type test conditions, all conditions
must pass for control to reach the fast loop.

Unlike array bounds checks, type test failures are not intrinsically rare,
so there is some profitability screening to ensure that a failed type test does
not force execution to run the slow version "too often". The type test must
execute frequently within the loop, and be heavily biased towards success.

This is work towards resolving #65206.

Author: AndyAyersMS
Assignees: -
Labels:

area-CodeGen-coreclr

Milestone: -

@AndyAyersMS
Copy link
Member Author

@BruceForstall PTAL
cc @dotnet/jit-contrib

This doesn't kick in as often as I would have expected, but the mechanical parts are there. I need to do more analysis to decide if the limitations are in loop recognition, invariant analysis, profitability, or something else.

Copy link
Member

@BruceForstall BruceForstall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really good. A few minor comments.

@@ -0,0 +1,48 @@
// Licensed to the .NET Foundation under one or more agreements.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is one of those tests where I wish we had the ability to verify that a particular optimization kicked in.

// local whose method table is tested
unsigned lclNum;
// handle being tested for
ssize_t clsHnd;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is a handle ssize_t type instead of a handle type?

Comment on lines 442 to 443
LC_Array arrLen; // The LC_Array if the type is "ArrLen"
unsigned constant; // The constant value if this node is of type "Const", or the lcl num if "Var"
ssize_t constant; // The constant value if this node is of type "Const", or the lcl num if "Var"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be a union? Seems like that would eliminate a lot of casts (and make this struct smaller).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I thought about doing that... makes sense.

Comment on lines +438 to +439
ClassHandle,
Indir,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update preceding comment?

@AndyAyersMS
Copy link
Member Author

Some data (now a bit stale) about the opportunities in ASP.NET SPMI

  • 323 type tests in loops
  • 78 loop invariant type tests in loops
  • 14 profitable loop invariant type tests in loops

All of these seem low, so I think we're losing opportunities at each stage. Invariant analysis was recently improved so I need to regather this data.

@AndyAyersMS
Copy link
Member Author

SPMI legs seems to be failing to find things to download and so failing.

No Azure Storage MCH files to download from 5868685e-b877-4ef5-83f0-73d601e50013/windows/arm64/

@jakobbotsch
Copy link
Member

That's because #70180 changed JIT-EE GUID so we need a new collection, which is running right now. Sorry about that, I'll keep in mind to merge JIT-EE GUID changes at end-of-day in the future.

@AndyAyersMS
Copy link
Member Author

No worries, just was puzzled for a bit.

@AndyAyersMS
Copy link
Member Author

Going to spiff up the ASP.NET collection for the new GUID and then push some changes based on Bruce's feedback.

Copy link
Member

@BruceForstall BruceForstall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@AndyAyersMS
Copy link
Member Author

Some perf cases that need investigation

IEnumerable

newplot - 2022-06-18T090143 026

(non-pgo result, for reference)

newplot - 2022-06-18T090608 558

@EgorBo
Copy link
Member

EgorBo commented Jun 28, 2022

Improvements on x64 dotnet/perf-autofiling-issues#6065

@AndyAyersMS
Copy link
Member Author

Improvements on x64 dotnet/perf-autofiling-issues#6065

Not sure if these are related, many of them have regressed back since
newplot - 2022-06-29T133623 838
.

@EgorBo
Copy link
Member

EgorBo commented Jun 29, 2022

Improvements on x64 dotnet/perf-autofiling-issues#6065

Not sure if these are related, many of them have regressed back since newplot - 2022-06-29T133623 838 .

I assume the regression is PGO update

@ghost ghost locked as resolved and limited conversation to collaborators Jul 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants