[llvm-dev] Should analyses be able to hold AssertingVH to IR? (related to PR28400)

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 24 12:39:38 PST 2017


> On Jan 24, 2017, at 11:59 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> On Tue, Jan 24, 2017 at 8:19 AM Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> Another view of it is that there should be another handle that triggers the invalidation of the analysis when this IR is changed: i.e. keeping the analysis cached while it holds a reference to the IR can be seen as the problem.
> 
> The issue is only with Asserting VH, not with other kinds of value handles though. So with those, we would have different invalidation in NDEBUG from !NDEBUG? Or would you always do this invalidation?

Not sure why would the invalidation be different? If you have an AssertingVH in your analysis, you need a mechanism to invalidate it before the assertion fires. But that invalidation needs to happens both in NDEBUG and !NDEBUG consistently (even if there wouldn’t be an assertion in NDEBUG mode if this is violated) .

> I guess I'm not too clear what the concrete approach here would be.

I should have mentioned that I didn’t give much thought about a concrete plan, it was more an abstract view on the semantic of holding AssertingVH. 
Deciding that AssertingVH is the wrong semantic for a given analysis can be OK (I believe this is what you did right?), and there might not be any practical alternative (to provide invalidation on the fly when IR is deleted).

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170124/9be1c04a/attachment.html>


More information about the llvm-dev mailing list