-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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: defer creating throw helper blocks until simple lower #93371
JIT: defer creating throw helper blocks until simple lower #93371
Conversation
Don't create any throw helper blocks until simple lowering. This removes some of the flow graph updates from morph, with the am of making it easier to show that an RPO traversal in morph is safe. Unfortunately it's hard to get these blocks in the exact same places they were before, so there are some diffs.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsDon't create any throw helper blocks until simple lowering. This removes some of the flow graph updates from morph, with the aim of making it easier to show that an RPO traversal in morph is safe. Unfortunately it's hard to get these blocks in the exact same places they were before, so there are some diffs.
|
cc @dotnet/jit-contrib Code size improvements here are somewhat surprising.... highlighting the need for a global layout algorithm, as there are multiple considerations to determine optimal placements of blocks. |
SPMI replay errors look like #93527 |
Nice wins! I presume it should fix various cases where we have unreachable throw helper blocks, e,g. I've just came up with: void Test(bool cond)
{
int b = 10;
if (cond)
{
_ = checked((byte)b);
}
} Emits: G_M12030_IG01: ;; offset=0x0000
sub rsp, 40
;; size=4 bbWeight=1 PerfScore 0.25
G_M12030_IG02: ;; offset=0x0004
add rsp, 40
ret
;; size=5 bbWeight=1 PerfScore 1.25
G_M12030_IG03: ;; offset=0x0009
call CORINFO_HELP_OVERFLOW
int3
;; size=6 bbWeight=0 PerfScore 0.00
; Total bytes of code 15 |
Actually, no... let me look into this as a follow-up. |
Unfortunately, this seems tricky. We don't know if we really need a throw helper until after codegen, and by then it's not so easy to get rid of things. I suppose I can at least see how often a helper ends up being unused, if it turns out this is a common thing, we can find a way to fix it. |
It looks like this PR had a ton of misses, so the diffs may be even greater (depending on the reason for the misses I suppose). |
It could be a bad sign, like the JIT is asking for throw helpers now that it didn't ask for before. Maybe once we have new collections we can do a trial revert and see how that looks. |
`compUsesThrowHelper` indicates codegen will likely need to create a call to a helper, whether or not such calls are shared. In dotnet#93371 I didn't appreciate this, and so the JIT was failing to set `compUsesThrowHelper` in cases where a throw helper was going to be needed but throw helper calls were not going to be shared. Fixes dotnet#93710.
`compUsesThrowHelper` indicates codegen will likely need to create a call to a helper, whether or not such calls are shared. In #93371 I didn't appreciate this, and so the JIT was failing to set `compUsesThrowHelper` in cases where a throw helper was going to be needed but throw helper calls were not going to be shared. Fixes #93710.
…93897) `compUsesThrowHelper` indicates codegen will likely need to create a call to a helper, whether or not such calls are shared. In dotnet#93371 I didn't appreciate this, and so the JIT was failing to set `compUsesThrowHelper` in cases where a throw helper was going to be needed but throw helper calls were not going to be shared. Fixes dotnet#93710.
Defer creating throw helper blocks until just before the late flow graph optimizations. This removes some of the flow graph updates from morph, with the aim of making it easier to show that an RPO traversal in morph is safe.
Unfortunately, it's hard to get these blocks in the exact same places they were before, so there are quite a few diffs. They are generally improvements. I also saw some cases where the early creation of throw helpers in try regions inhibited loop recognition; this no longer happens, and may enable loop cloning (and hence size increses).
Diffs
This also lays the groundwork for removing simple lowering.