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.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
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.
|
|
@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. |
| @@ -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.
src/coreclr/jit/loopcloning.h
Outdated
| // 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?
src/coreclr/jit/loopcloning.h
Outdated
| 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, |
|
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. |
|
SPMI legs seems to be failing to find things to download and so failing. |
|
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. |
|
No worries, just was puzzled for a bit. |
|
Going to spiff up the ASP.NET collection for the new GUID and then push some changes based on Bruce's feedback. |
|
Some perf cases that need investigation
(non-pgo result, for reference)
|
|
Improvements on x64 dotnet/perf-autofiling-issues#6065 |
Not sure if these are related, many of them have regressed back since |
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.