This is an archive of the discontinued LLVM Phabricator instance.

[LoopPred] Implement a version of the profitability heuristic w/o BPI
AbandonedPublic

Authored by reames on Apr 16 2019, 9:52 AM.

Details

Summary

In the new pass manager, getting access to BPI reliability is a challenge. In practice, we've been running downstream with a variation of this non-BPI based heuristic.

(I also have some patches I'll post shortly to improve invalidation, but I'm not sure I can push that all the way through yet.)

Original patch by: Anna Thomas (with heavy modification by me)

Diff Detail

Event Timeline

reames created this revision.Apr 16 2019, 9:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 16 2019, 9:52 AM

In the new pass manager, getting access to BPI reliability is a challenge. In practice, we've been running downstream with a variation of this non-BPI based heuristic.

Can you please explain why? The new pass manager was supposed to make our problems getting a hold of analysis results in different places easier, not harder.

In the new pass manager, getting access to BPI reliability is a challenge. In practice, we've been running downstream with a variation of this non-BPI based heuristic.

Can you please explain why? The new pass manager was supposed to make our problems getting a hold of analysis results in different places easier, not harder.

I haven't dug through this entirely, but I'm seeing invalidation of BPI being done outside of a loop pass manager. Which is a bit of a problem if I have a loop pass manager which contains two passes, the *first* of which invalidates, and the *second* uses. We appear to be using stale info for the second pass without notice or error.

In the new pass manager, getting access to BPI reliability is a challenge. In practice, we've been running downstream with a variation of this non-BPI based heuristic.

Can you please explain why? The new pass manager was supposed to make our problems getting a hold of analysis results in different places easier, not harder.

New pass manager provides proper organization of analyses but it cant (and shouldnt!) hide innate asymmetry in relationship between Function-level analysis and Loop-level transformation.
NPM specifically prohibits reruns of outer-level analysis from within a inner-level-pass (proxy is readonly).
When working on loop-level you can only *use* function/module-level analysis, manually *preserve* it or automatically invalidate analysis results as a whole after the changes to IR.
That seems to be a proper design decision.

For BPI that means we can not rerun BPI as soon as some loop-level pass invalidates it. So the only way to get BPI reliably in all loop passes is to teach all the loop passes to preserve BPI.

In the new pass manager, getting access to BPI reliability is a challenge. In practice, we've been running downstream with a variation of this non-BPI based heuristic.

Can you please explain why? The new pass manager was supposed to make our problems getting a hold of analysis results in different places easier, not harder.

New pass manager provides proper organization of analyses but it cant (and shouldnt!) hide innate asymmetry in relationship between Function-level analysis and Loop-level transformation.
NPM specifically prohibits reruns of outer-level analysis from within a inner-level-pass (proxy is readonly).
When working on loop-level you can only *use* function/module-level analysis, manually *preserve* it or automatically invalidate analysis results as a whole after the changes to IR.
That seems to be a proper design decision.

Indeed.

For BPI that means we can not rerun BPI as soon as some loop-level pass invalidates it. So the only way to get BPI reliably in all loop passes is to teach all the loop passes to preserve BPI.

Either that, or we need some kind of LoopBPI analysis which can be re-constructed at the loop level. I'd prefer either of these to duplicating the logic elsewhere.

reames planned changes to this revision.Jun 17 2019, 2:15 PM

On hold given previous review comments.

reames requested review of this revision.Oct 19 2019, 2:42 PM

No longer actively working on this, may return to it in the future.

reames abandoned this revision.Oct 20 2019, 4:08 PM