This is an archive of the discontinued LLVM Phabricator instance.

[PGO] handle infinite loop properly in pgo instrumention
ClosedPublic

Authored by davidxl on Dec 5 2017, 4:34 PM.

Details

Summary

The original fix id D40702 introduces a memory leak -- a surprising side effect of calling 'getAnalysis<>' method. Calling this has the effect of releasing the memory of current BFI and BPI.

The right way is to get the cached BPI and LI from the current BFI.

Diff Detail

Repository
rL LLVM

Event Timeline

davidxl created this revision.Dec 5 2017, 4:34 PM
vsk edited edge metadata.Dec 6 2017, 11:19 AM

I don't have my head wrapped around the cause of the leak yet. Was the issue that getAnalysis<LoopInfo...>() recomputed BFI, thereby leaking the existing analysis? If so, would it be sensible for the pass manager to provide a cached BFI instead of allowing the leak? (I'm not suggesting changing the PM, just curious about how these things fit together.)

At a more basic level: Say CFGMST depends on BFI, which in turn depends on {BPI, LI}. Is it possible for CFGMST to be scheduled after a competing pass "DestroysBPI", which preserves BFI but invalidates BPI? If so, how do we avoid that?

What happens is that the call of getAnalysis<LoopInfoWrapperPass>() is invoked after getAnalysis<BlockFrequencyInfoWrapperPass>(). The legacy pass manager in this case will do the analysis run to compute LoopInfo on the fly. Before running the analysis, it will also invoke the 'release' memory method of the analysis passes contained in, in this case is BPI and BFI. After that we basically have use-after free problem. The leaking is probably just a side effect.

The fix simply fetches the cached LI and BPI from BFI. This is a common pattern used (for getting BPI from BFI). This is only an issue with the old PM -- as it will go away soon, we don't need to worry about fixing that.

vsk accepted this revision.Dec 6 2017, 11:32 AM

What happens is that the call of getAnalysis<LoopInfoWrapperPass>() is invoked after getAnalysis<BlockFrequencyInfoWrapperPass>(). The legacy pass manager in this case will do the analysis run to compute LoopInfo on the fly. Before running the analysis, it will also invoke the 'release' memory method of the analysis passes contained in, in this case is BPI and BFI. After that we basically have use-after free problem. The leaking is probably just a side effect.

Ah ok, this makes a lot more sense to me as a use-after-free. Thanks, lgtm.

This revision is now accepted and ready to land.Dec 6 2017, 11:32 AM
This revision was automatically updated to reflect the committed changes.