Page MenuHomePhabricator

[WC] Fix a subtle bug in our definition of widenable branch
ClosedPublic

Authored by reames on Nov 6 2019, 12:14 PM.

Details

Summary

We had a subtle, but nasty bug in our definition of a widenable branch, and thus in the transforms which used that utility. Specifically, we returned true for any branch which included a widenable condition within it's condition, regardless of whether that widenable condition also had other uses.

The problem is that the result of the WC() call is defined to be one particular value. As such, all users must agree as to what that value is. If we widen a branch without also updating *all other users* of the WC in the same way, we have broken the required semantics.

Most of the textual diff is updating existing transforms not to leave dead uses hanging around. They're largely NFC as the dead instructions would be immediately deleted by other passes. The reason to make these changes is so that the transforms preserve the widenable branch form.

In practice, we don't get bitten by this only because it isn't profitable to CSE WC() calls and the lowering pass from guards uses distinct WC calls per branch.

Diff Detail

Event Timeline

reames created this revision.Nov 6 2019, 12:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 6 2019, 12:14 PM
apilipenko accepted this revision.Nov 6 2019, 1:26 PM

LGTM. Maybe add a test when the WC has one use but the branch condition is used in multiple branches.

This revision is now accepted and ready to land.Nov 6 2019, 1:26 PM
reames added a comment.Nov 6 2019, 1:27 PM

LGTM. Maybe add a test when the WC has one use but the branch condition is used in multiple branches.

Er, beyond the wc-widen-block example?

This revision was automatically updated to reflect the committed changes.