-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[opt] Support begin/end access instructions in store/load elimination. #31078
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
Conversation
* Update the projection utility to support projecting begin_access (used by both store and load elim). * Update RedundantLoadElimination to skip begin/end access while processing instructions. It can figure out read/write info by processing the other instructions (see comment for more details). * Update DeadStoreElimination to skip begin/end access while processing instructions for the same reason as above. * Also don't process strong_release instructions.
@swift-ci please benchmark |
Turns out I can't just ignore strong_release instructions :P I've fixed the issue while (hopefully) still maintaining the performance. I've had to tweak half a dozen passes, though. I'll make sure I split those changes off into separate PRs but, as I said in the description, I want to see the combined benchmarks first. |
@swift-ci please benchmark |
1 similar comment
@swift-ci please benchmark |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -OsizePerformance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
It's strange to have any regressions here. I'll investigate. |
DSE and RLE passes used to, in most cases, bail on all tracked locations when they ran into an instruction that modified memory that they couldn't identify. In most cases this memory address can be tracked to a specific tracked location. If so, only that location has to be invalidated.
@swift-ci please benchmark |
1 similar comment
@swift-ci please benchmark |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
// If this is a reference type, then the *live* store counts as an unkown | ||
// read. | ||
if (L.getBase()->getType().isAnyClassReferenceType()) | ||
S->stopTrackingLocation(S->BBWriteSetMid, i); |
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.
This was always an issue. We just never ran into it because before this patch we struggled with reference types.
Yes! That's the kind of benchmark result I was looking for. @eeckstein thank you for the suggestion about how to solve the alloc_ref problem. This was definitely the right path. The regressions look either not-serious or easy edge cases to fix. |
Now that I've got the benchmarks I'm going to close this PR and open separate PRs for all of the changes here. |
This change has been broken into individual PRs:
I can split this into three patches if that would be easier to review (this is one patch so I can see the benchmark results of all three together):