Skip to content

[SILCombine] Dominance check for inject_enum_addr. #73040

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

Merged
merged 2 commits into from
Apr 16, 2024

Conversation

nate-chandler
Copy link
Contributor

If stores of empty values to the address don't dominate the inject_enum_addr, the inject_enum_addr can't be eliminated--it's the only indication of the case that's in the address.

@nate-chandler nate-chandler requested a review from meg-gupta April 15, 2024 18:57
@nate-chandler
Copy link
Contributor Author

@swift-ci please test

@@ -1219,7 +1246,7 @@ SILCombiner::visitInjectEnumAddrInst(InjectEnumAddrInst *IEAI) {
// store %1 to %nopayload_addr
//
auto *AI = dyn_cast_or_null<ApplyInst>(getSingleNonDebugUser(DataAddrInst));
if (!AI)
if (!AI || !DI->properlyDominates(AI, IEAI))
Copy link
Contributor

@meg-gupta meg-gupta Apr 15, 2024

Choose a reason for hiding this comment

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

Should the dominance check be limited to empty types ? For non empty types we do not have uninitialized paths and won't need this check? With the check we may not be optimizing the case where one path could have the initializing apply, and another uninitialized path may end in an unreachable.

Copy link
Contributor Author

@nate-chandler nate-chandler Apr 16, 2024

Choose a reason for hiding this comment

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

With the check we may not be optimizing the case where one path could have the initializing apply, and another uninitialized path may end in an unreachable.

It seems like, even if the address is uninitialized on some unreachable-terminated path, every path through IEAI would still go through AI``* (AI would dominate IEAI). But...

For non empty types we do not have uninitialized paths and won't need this check?

Great point! This check is wasteful for non-empty types. Added a check that the type is empty before checking dominance. And added some test cases with dead end blocks after the init_enum_data_addr.

* Or some other initialization in which case there's another bailout since the apply case only handles the case where the apply is the single use.

auto pair = pairs[0];
assert(pair.has_value());
if (!DI->properlyDominates(pair->second, forInst))
return std::nullopt;
Copy link
Contributor

@meg-gupta meg-gupta Apr 15, 2024

Choose a reason for hiding this comment

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

Looks like without the dominance check here, we can have bad SIL with non empty types too!?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, we can't have them here either because that would imply there was a memory location whose type is non-empty which wasn't initialized on some path, which is invalid SIL.

If stores of empty values to the address don't dominate the
inject_enum_addr, the inject_enum_addr can't be eliminated--it's the
only indication of the case that's in the address.
@nate-chandler
Copy link
Contributor Author

@swift-ci please test

Copy link
Contributor

@meg-gupta meg-gupta left a comment

Choose a reason for hiding this comment

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

LGTM. Thank you!

@nate-chandler nate-chandler merged commit 2600aa5 into swiftlang:main Apr 16, 2024
@nate-chandler nate-chandler deleted the rdar126231554 branch April 16, 2024 14:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants