This is an archive of the discontinued LLVM Phabricator instance.

[PH] Remove all use of AssertingVH from members of analysis results.
ClosedPublic

Authored by chandlerc on Jan 23 2017, 1:45 AM.

Details

Summary

These are fundamentally incompatible with cache-invalidation of analysis
results. The invaliadtion happens after the AssertingVH has already
fired. There are more appropriate tools to use in these scenarios if and
when someone needs them to debug things. For example, a debug-build-only
WeakVH and an explicit assert that it hasn't gone null when it is *used*
so that it can still *exist* even when the value goes away.

This patch also removes all of the (numerous) doomed attempts to work
around this fundamental incompatibility. It is a pretty significant
simplification IMO.

The most interesting change is in the Inliner where we still do some
clearing because we don't want to rely on the coarse grained
invalidation strategy of the containing pass manager. However, I prefer
the approach that contains this logic to the cleanup phase of the
Inliner, and I think we could enhance the CGSCC analysis management
layer to make this even better in the future if desired.

The rest is straight cleanup.

I've also added a test for one of the harder cases to work around: when
a *module analysis* contains many AssertingVHes pointing at functions.

Note that this remains a bit controversial. See the llvm-dev discussion here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109394.html

Diff Detail

Repository
rL LLVM

Event Timeline

chandlerc created this revision.Jan 23 2017, 1:45 AM
hfinkel added inline comments.
include/llvm/Analysis/ScalarEvolution.h
603 ↗(On Diff #85330)

This seems relatively safe. If you remove a loop's exiting block, you'll need to call SE->forgetLoop(L).

lib/Analysis/LazyValueInfo.cpp
384 ↗(On Diff #85330)

This seems less obvious; once you remove any blocks that LVI might have visited, if you add any other blocks, the analysis becomes instantly invalid in a subtle way for all other queries (i.e. subject to allocator-reuse-triggered non-determinism bugs), even for completely-unrelated parts of the function, even if you've proven the removed block dynamically unreachable, etc.

A callback handle here that removes the cached values if you remove the block would add value here in making this much less fragile. Even though flawed, I'm concerned that the asserting VH here is adding value by forcefully reminding us of this fragility. Fixing this "for real" seems straightforward (just like we do in SE in other cases).

davide edited edge metadata.Jan 23 2017, 7:13 AM

No objections to having this in in some form, but I agree with Hal about LVI.

lib/Analysis/LazyValueInfo.cpp
384 ↗(On Diff #85330)

Agree.

lib/Transforms/IPO/Inliner.cpp
941 ↗(On Diff #85330)

s/cclear/clear/

sanjoy edited edge metadata.Jan 23 2017, 10:11 AM

Hi Chandler,

I'm not sure this is a good idea.

If this is the *only* path forward then I'll be okay going ahead with
it, but I think AssertingVH (not unlike most other similar things)
is useful and provides a superset of functionality provided by
sanitizers.

For example, a debug-build-only
WeakVH and an explicit assert that it hasn't gone null when it is *used*
so that it can still *exist* even when the value goes away.

But we don't *have* such a thing today, and for that reason this
change is a strict decrease in debug-ability. If you wanted to add
something like that, and replace existing AssertingVH uses with it
then I may feel better about this; however AssertingVH is stronger
than what you suggest since AssertingVH catches cases where we've
keyed a hash table off AssertingVH s. To be on part with that
functionality, we'd also need to write data structures like DenseMap
that can be "poisoned" by a CallbackVH key.

chandlerc updated this revision to Diff 85502.Jan 23 2017, 5:32 PM

Update to use a new PoisoningVH to implement this logic.

chandlerc updated this revision to Diff 85506.Jan 23 2017, 5:46 PM

This time with code that compiles.

sanjoy accepted this revision.Jan 23 2017, 7:38 PM

lgtm!

Thanks for indulging my paranoia!

This revision is now accepted and ready to land.Jan 23 2017, 7:38 PM
This revision was automatically updated to reflect the committed changes.