Page MenuHomePhabricator

Aggressively hoist guards out of loops (to provide a target for widening)

Authored by reames on Jun 4 2019, 8:45 AM.



If we have a guard w/loop invariant operands, which is reached along a side effect free path on the first iteration, we can hoist that guard outside the loop, even over control flow we can not analyse. Doing so may widen the condition - make it fail on more executions than the original program - but that's explicitly allowed by the documented semantics of guards.

At the moment, I'm mostly looking for feedback on approach. Is this the right framing and placement? As noted in the comment, I'm considering an alternate "spliting" framing, would that be cleaner?

I need to add dedicated tests and will rebase when done so, but for now, the GuardWidening/basics.ll test show the difference fairly well. (I have not included the output in the diff yet.)

Diff Detail

Event Timeline

reames created this revision.Jun 4 2019, 8:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 4 2019, 8:45 AM
reames planned changes to this revision.Jun 11 2019, 2:39 PM

Planning a change in direction after offline discussion w/Artur. Instead of framing this as hoisting/widening, I'm going to reframe as a separate loop transform which lifts a trivial guard (by splitting the condition) into the loop preheader where possible. We think this will be easier to test, and may have positive effects beyond guard widening,

reames abandoned this revision.Oct 19 2019, 2:42 PM

No longer actively working on this, we've moved to widenable conditions by default anyway.