[LLVMdev] Stale SCEV pointer to deleted AssumptionCache (original) (raw)

Steve King steve at metrokings.com
Wed Jul 15 12:24:46 PDT 2015

The the problem is solved by ScalarEvolution specifying that required passes are transitive, i.e. have matching the lifetime. This prevents passes being prematurely deleted and thus prevents the dangling raw pointers. I submitted a patch: http://reviews.llvm.org/D11236

Using long lived raw pointers to unique_ptr data owned by another pass is very uncomfortable. We currently cannot even catch this case in an assert(). I'm always astonished at how well deleted memory works in practice, which only makes these problems tougher to debug.

Cheers, -steve

On Tue, Jul 14, 2015 at 4:19 PM, Steve King <steve at metrokings.com> wrote:

Hello LLVM, I have a small-ish custom pass that runs after LoopStrengthReduce. After a recent upstream merge, this custom pass caused an impossible assert(), the root cause of which is that the SCEV pass has a stale pointer to a deleted AssumptionCache. Specifically:

bool ScalarEvolution::runOnFunction(Function &F) { ... AC = &getAnalysis().getAssumptionCache(F); ... AC is long lived raw pointer to memory owned by a uniqueptr. Sounds bad. The sequence of events is quite hairy, but what seems to be happening is that PMDataManager::removeDeadPasses() blows away the AssumptionCache data, while the SCEV object and its dangling pointer live on. As far as I can tell, all the passes have correctly registered their dependencies. My previous upstream merge was June 29, and everything worked fine then. I'm a little stumped as to what the real problem might be. Pointers for chasing this own would be much appreciated. Thanks, -steve

More information about the llvm-dev mailing list