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<AssumptionCacheTracker>().getAssumptionCache(F);
> ...
>
> AC is long lived raw pointer to memory owned by a unique_ptr. 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