-
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: Remove GT_NULLCHECK #71707
JIT: Remove GT_NULLCHECK #71707
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsPreviously the JIT had two ways of representing null checks, either To alleviate the problem remove GT_NULLCHECK entirely and switch to I am also removing the checks for the
|
e48e629
to
f105e2a
Compare
consider doing the same for BBF_HAS_IDX_LEN - it also caused pain few times already |
Previously the JIT had two ways of representing null checks, either through GT_NULLCHECK or through any indirection node with an unused value. This is somewhat problematic since early prop supports only the former while CSE supports only the latter, so converting between them always results in improvements and regressions. To alleviate the problem remove GT_NULLCHECK entirely and switch to unused indirections to represent null checks. Add the necessary support for efficient codegen for these to the backend, and add support for early prop to recognize and fold these away.
Always use EAX as the non-memory operand to the comparison. EAX is always addressable as al, ax and eax which is not true for all registers on x86.
6ece67f
to
f4bc641
Compare
/azp run runtime-coreclr superpmi-diffs |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress |
Azure Pipelines successfully started running 2 pipeline(s). |
I've verified that the improvements seen in #68588 do not regress from this. @kunalspathak, did you have a simple example you were using there that I can double check the exact codegen for to make even more sure that it is not badly impacted by this change? |
ping @kunalspathak, do you remember what case you were using to evaluate #68588? As a general note I will keep PR as a draft until we snap for rc1. |
Sorry, I missed this. I do not recall the exact example and this came to my notice while working on hoisting expressions out of multi-nested loop. But looking at the improvements (e.g. dotnet/perf-autofiling-issues#5096), you can try one of that example to see. |
Yeah, I verified that these benchmarks do not regress with the change, but I wasn't totally sure where the logic was kicking in for them. I guess I can go investigate in further detail. |
Couple of things I need to check/address:
|
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
Previously the JIT had two ways of representing null checks, either
through GT_NULLCHECK or through any indirection node with an unused
value. This is somewhat problematic since early prop supports only the
former while CSE supports only the latter, so converting between them
always results in improvements and regressions.
To alleviate the problem remove GT_NULLCHECK entirely and switch to
unused indirections to represent null checks. Add the necessary support
for efficient codegen for these to the backend, and add support for
early prop to recognize and fold these away.
I am also removing the checks for the
BBF_HAS_NULLCHECK
flags here. It comes with some TP cost, but not too much,and I did some TP work in #71767 and #73919 that more than pays for this. We've seen frequent issues with keeping these flags up to date so I think it is worth it for the small cost in TP. I will remove these flags completely in a follow-up.