Page MenuHomePhabricator

[WIP] An alternate approach to widening exit conditions using widenable conditions
AbandonedPublic

Authored by reames on Oct 26 2019, 1:01 PM.

Details

Reviewers
None
Summary

This is an alternative approach to D69454. Despite the lack of code sharing, I like this version a lot better. The interweaving of ideas in the IndVars version is really hard to follow.

Diff Detail

Event Timeline

reames created this revision.Oct 26 2019, 1:01 PM

Recording some thoughts.

There's a potential serious problem here with both approaches. We're hoisting logic (mostly arithmetic) out of the loop and adding a new use outside the loop. As such, there's a potentially serious problem with undef and poison as the existing flags may no longer be correct for the new user.

This is exactly the same problem which unswitch has. Interestingly, this proposed transform basically implements unswitch, but without the duplication. As such, any solution (say, the proposed freeze intrinsic) which works for unswitch, should work here as well.

While waiting for freeze, some practical notes:

  • propagatesFullPoison does not include and. And unswitch appears to essentially rely on this. As such, from a poison perspective, anding in a new condition to the widenable branch is probably okay in practice. (Caveat: unless poison is exploited by some transform above the loop following use simplification? But unswitch would have this problem too.)
  • Undef is harder. I haven't found a chain of logic to convince myself it's harmless in practice just yet.
reames abandoned this revision.Nov 4 2019, 3:40 PM