Skip to content
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 strength reduction by default #105131

Merged
merged 2 commits into from
Jul 19, 2024

Conversation

jakobbotsch
Copy link
Member

@jakobbotsch jakobbotsch commented Jul 19, 2024

Fix #100913

Strength reduction is considered profitable for all strides, even ones that can be part of addressing modes. This is motivated by results of the micro benchmark I did over in #100913 using @EgorBo's bot: arm64, x64 AMD, x64 Intel (ignore the duplicated Main/PR rows). In all cases this micro benchmark was either the same or improved by strength reduction.

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jul 19, 2024
Copy link
Contributor

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

@jakobbotsch
Copy link
Member Author

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress, runtime-coreclr gcstress0x3-gcstress0xc

Copy link

Azure Pipelines successfully started running 3 pipeline(s).

@jakobbotsch
Copy link
Member Author

There is a related problem it looks like -- crash during StaysWithinManagedObject in a test that disables assertion prop. Need to disable IV opts when assertion prop is disabled.
There is an arm64 libraries-jitstress failure as well, but I was able to repro it even without DOTNET_JitEnableStrengthReduction=1. Will open an issue.

@jakobbotsch
Copy link
Member Author

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Overall a size improvement, although the size diffs are very mixed; it is not equivocally a size improvement to do strength reduction:

  1. In cases where the bound is a constant we could fold it into the cmp in the baseline. After we make the loop downwards counted we need to materialize the bound in the preheader, which ends up with bigger code overall.
  2. For arrays, forming the "start" byref in the preheader increases the size. Sometimes we can do this with add <reg>, 0x10 while other times we need a full lea <other reg>, [<reg>+0x10] to do it. This also takes up more size in the preheader.
  3. On x64, the strided increment inside the loop is bigger than the inc we could previously use, which often means the loop body does not make up for the preheader size
  4. In some cases we actually do introduce new primary IVs, for example when the bound is a constant and we cannot fold the base byref into the primary IV. We start with two pieces of live state in the loop: 1) the primary IV i; 2) the array base. And we end up with three pieces: 1) the new strided offset primary IV; 2) the array base; 3) the downwards bound primary IV. These cases can lead to unfortunate register allocation changes. We should perhaps be smarter here and replace the test by one on the strided offset, so that we avoid another primary IV, but I think that's a separate work item.

Perfscore wise we look to be good -- this is an overall improvement in all the collections. I also think many of the regressions aren't actual regressions; we give the 1,2,3-operand addressing modes the same score, while in reality the micro benchmarks indicate that the scaled addressing modes are significantly more expensive than the others. So the perfscore doesn't always account for what strength reduction is actually trying to do.

x86 has some large size regressions, but mostly from coreclr_tests. I'd like to leave this as is and see the perf results.

I looked through a large chunk of the asp.net x64 size regressions, and they all looked fine to me. We get rid of the more expensive addressing mode in trade of some larger code in the preheader. A canonical size regressions looks like the following:

image

@jakobbotsch jakobbotsch marked this pull request as ready for review July 19, 2024 14:44
Copy link
Member

@AndyAyersMS AndyAyersMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to see this finally turned on.

@jakobbotsch jakobbotsch merged commit 39968e7 into dotnet:main Jul 19, 2024
102 of 108 checks passed
@jakobbotsch jakobbotsch deleted the enable-strength-reduction branch July 19, 2024 18:43
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JIT: Add support for strength reduction
2 participants