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

Fix bug where a ref assignment is moved ouside a conditional #7176

Merged
merged 3 commits into from
Nov 27, 2024

Conversation

cristianoc
Copy link
Collaborator

@cristianoc cristianoc commented Nov 25, 2024

Fixes #7170

There is an optimisation of this form:

if (guard) { c; c1 } else { c; c2}

is transformed to:

c;
if (guard) { c1 } else { c2 }

The current check is that guard does not have side effects. (Also, this same optimisation does not apply to guard ? {c; c1} : {c; c2} which is what the vast majority of cases of this form are compiled to -- that's why the original issue is not so easy to repro.

However, the check for side effects is not enough. What you want to know is: executing c does not change the truth value of guard, which is a form of non-interference, much harder to establish.

Fixes #7170

Assignment of a ref, or other record with a single mutable field, is compiled to simple variable assignment.
This triggers an incorrect optimisation that moves identical assignments in the true and false branches of a conditional above if they are identical and the guard has no side effects.

Added a check that if the assigments to be moved are to variable, that variable must not occur free in the guard of the conditional.
Copy link
Member

@cknitt cknitt left a comment

Choose a reason for hiding this comment

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

Nice work! You'll probably need to rebase though as I just merged #7174, sorry!

Copy link
Collaborator

@zth zth left a comment

Choose a reason for hiding this comment

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

Nicely tracked down!

@cristianoc
Copy link
Collaborator Author

The optimisation is still incorrect. In fact it would be only sound under very unlikely circumstances.
Will update the description and kill the optimisation entirely.

if (x.TAG === "A") {
v = 1;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is the only case where the optimisation was kicking.
It's pretty unlikely to fire to begin with, and when it fires the cases where one can legitimately move the common instruction up are pretty rare.
In this case, it would be OK because assigning to v does not change the value of x.TAG, because the two values cannot be aliases.

@cristianoc
Copy link
Collaborator Author

@cknitt @zth removed the optimisation entirely, up for re-review now.

@cristianoc cristianoc merged commit f9862d1 into master Nov 27, 2024
21 checks passed
@cristianoc cristianoc deleted the fix_ref_assignment branch November 27, 2024 06:13
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.

Miscompilation of assignment
3 participants