-
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: Enable CSE for CLS/STR const handles #70580
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsMotivated by #59704 Example: public static void Test(object left, object right)
{
if (left.GetType() == typeof(string) ||
right.GetType() == typeof(string))
{
Console.WriteLine();
}
} codegen diff: https://www.diffchecker.com/tI9sCqxx
|
This is more impactful on arm64 because of 4 instructions we have to produce the constant. |
On arm64 it works as is - CSE for constants is enabled, cost is adjusted (e.g. [4, 12] as far as I remember) |
|
Ah, so the real benefit is on x64? |
yep, I expect zero diffs on arms |
@dotnet/jit-contrib PTAL, diffs
on arm32
for There are size/PerfScore regressions but it's impossible to tune CSE and not getting them, regressions are mainly due to register pressure - more spills/restores, etc. No diffs on arm64 as expected |
// Unconditionally allow these constant handles to be CSE'd | ||
!tree->IsIconHandle(GTF_ICON_STATIC_HDL) && !tree->IsIconHandle(GTF_ICON_CLASS_HDL) && | ||
!tree->IsIconHandle(GTF_ICON_STR_HDL)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why only these types of handles?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why only these types of handles?
when I enable all of them I see a lot of size/perfscore regression. I was only interested in GTF_ICON_CLASS_HDL (for PGO), String literals and statics were added because they produced good diffs as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I think you should run stress jobs.
if (tree->IsIntegralConst()) | ||
{ | ||
if (!enableConstCSE) | ||
if (!enableConstCSE && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is unsatisfying that we will now CSE things even when explicitly asked not to (CONST_CSE_DISABLE_ALL
).
Perhaps the easiest solution would be to delete CONST_CSE_DISABLE_ALL
. Or check it separately (if (forceDisableConstCSE) continue;
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I'll delete CONST_CSE_DISABLE_ALL in a follow up PR, thanks
oops didn't notice your suggestion, I assume it just partially enables what was already fully enabled for arm. I'll check if I can enable CSE for even more things under JitStress mode |
Improvements on x64: dotnet/perf-autofiling-issues#6127, dotnet/perf-autofiling-issues#6139 |
@EgorBo This PR enabled shared constant CSE for ARM (confusingly, the comments around But it didn't enable CSE of constants (non-shared) for ARM. Does that make sense? (It makes the runtime/src/coreclr/jit/optcse.cpp Line 1778 in 06062e7
|
I don't remember the details, ARM32 wasn't initialy the goal of this PR, it was just enabled along the road (produced huge diffs), if nonshared CSE is not enabled - it should propably be enabled too I presume? |
Motivated by #59704
Example:
codegen diff: https://www.diffchecker.com/tI9sCqxx
Quite impactful Diffs (up to
-881922
on x64 and-2283090
on arm32)