This is an archive of the discontinued LLVM Phabricator instance.

Fixed LegacyPassManager inconsistency
AbandonedPublic

Authored by JesperAntonsson on Jun 17 2016, 6:18 AM.

Details

Reviewers
chandlerc
grosser
Summary

This fix locks the "last use"-point for a pass as soon as the pass is determined to be "not preserved".

This prevents "last use" and "preservation" information from becoming inconsistent, i.e. a "last use" point beyond where the pass is no longer preserved. Since "last use" information is used to remove dead passes, this will make sure passes does not stay around when they are not preserved.

The LegacyPassManager has an algorithm that transitively calculates "last use", so a pass' last use point could otherwise be dragged along beyond non-preservation points, and thus stay alive for too long. For instance, two call graphs would exist at the same time, leading to various problems, especially value handle asserts.

This solves the following four llvm bugs:
26865 - Inliner crashes in ValueHandleBase::ValueIsDeleted
27050 - ArgumentPromotion crashing with "An asserting value handle still pointed to this value!"
27112 - Inliner crashing with "An asserting value handle still pointed to this value!"
27697 - Passmanager assertion failure in PassAnalysisSupport

Diff Detail

Event Timeline

JesperAntonsson retitled this revision from to Fixed LegacyPassManager inconsistency.
JesperAntonsson updated this object.
JesperAntonsson added reviewers: chandlerc, grosser.
JesperAntonsson added a subscriber: llvm-commits.
mehdi_amini added inline comments.Jun 17 2016, 3:14 PM
include/llvm/IR/LegacyPassManagers.h
194

Could these be better documented here?

252

Why a small vector? Also the comment says it is a "Map" apparently, while it is used as a set.
We have SmallPtrSet for instance.

lib/IR/LegacyPassManager.cpp
877

Why removing the early return?

test/Feature/legacypassmanager.ll
20

Do we have a better way of testing PM?
Do we have C++ unit tests?

mehdi_amini added inline comments.Jun 17 2016, 6:34 PM
lib/IR/LegacyPassManager.cpp
877

(Sorry I meant to remove this comment before validating, you can ignore)

Thank you to Mehdi Amini for good review comments. I've updated the diff accordingly: Improved description, changed to a more appropriate container type for the book-keeping and also I added a C++ unittest.

I'll need more time to figure if it is the right fix or if it is a bandaid on top of the existing complexity.

lib/IR/LegacyPassManager.cpp
557

Merge with previous if?

Whether this is the the right fix or band-aid is a fair question. :-) The problematic operation seems to be the transitive update of LastUser, and that's what I'm restraining in a minimal way to retain consistency with preservation info. OTOH, I don't understand/like the transitive update at all, but perhaps you understand its implications and what, if anything, would need to be done if it were to be removed entirely? There are other possibilities as well but I guess those would require more fundamental redesign.

I'm going for vacation at the end of this work day. I'll be back mid August and won't do anything more until then, but if you find this patch the right way to go, please feel free to push it at any time. (I don't have commit rights yet anyway, so I need help with that.)

Thanks, and have a great summer! /Jesper

So, I'm back in business. :-) Mehdi, what say you?

Welcome back!

I won't have time to get back to this before next week, ping me on Monday!

Monday, so I'm pinging. :-)

(It is still in my list, sorry for the delay)

Good that this isn't forgotten. :-) It's Monday, so I'm sending another friendly ping.

Pinging Mehdi Amini. :-)

I don't have time to page-in the LegacyPassManager infrastructure, but I know @chandlerc has been reviewing stuff in this area recently, maybe he can have a look.

davide added a subscriber: davide.Jun 12 2017, 12:48 AM

@chandlerc is probably the right person to take a look at this.

This fix is still relevant and would be nice to land, but 3 out of 4 related TR have gone into hiding/are non-reproducible after AssertingValueHandle functionality was changed. 27697 is still reproducible.

JesperAntonsson abandoned this revision.Sep 25 2019, 1:20 AM

Seems irrelevant now e.g. due to the new pass manager.

foad added a subscriber: foad.Nov 27 2020, 8:53 AM