Uh oh!
There was an error while loading. Please reload this page.
JIT: enable cloning based on loop invariant type tests - #70377
Conversation
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.
ghost
commented
Jun 7, 2022
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsSuch as those added by GDV. The JIT will now clone just for type tests, or just for array bounds, or for Unlike array bounds checks, type test failures are not intrinsically rare, This is work towards resolving #65206.
|
AndyAyersMS
commented
Jun 7, 2022
@BruceForstall PTAL 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. |
BruceForstall
left a comment
There was a problem hiding this comment.
Looks really good. A few minor comments.
| @@ -0,0 +1,48 @@ | |||
| // Licensed to the .NET Foundation under one or more agreements. | |||
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
Why is a handle ssize_t type instead of a handle type?
| 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" |
There was a problem hiding this comment.
Maybe this should be a union? Seems like that would eliminate a lot of casts (and make this struct smaller).
There was a problem hiding this comment.
Yeah, I thought about doing that... makes sense.
| ClassHandle, | ||
| Indir, |
There was a problem hiding this comment.
Update preceding comment?
AndyAyersMS
commented
Jun 7, 2022
Some data (now a bit stale) about the opportunities in ASP.NET SPMI
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
commented
Jun 7, 2022
SPMI legs seems to be failing to find things to download and so failing. |
jakobbotsch
commented
Jun 7, 2022
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
commented
Jun 7, 2022
No worries, just was puzzled for a bit. |
AndyAyersMS
commented
Jun 7, 2022
Going to spiff up the ASP.NET collection for the new GUID and then push some changes based on Bruce's feedback. |
AndyAyersMS
commented
Jun 18, 2022
Some perf cases that need investigation
(non-pgo result, for reference)
|
EgorBo
commented
Jun 28, 2022
Improvements on x64 dotnet/perf-autofiling-issues#6065 |
AndyAyersMS
commented
Jun 29, 2022
Not sure if these are related, many of them have regressed back since |
EgorBo
commented
Jun 29, 2022
I assume the regression is PGO update |
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.