This is an archive of the discontinued LLVM Phabricator instance.

[NewPM] -print-module-scope -print-after now prints module even after invalidated Loop/SCC

Authored by fedor.sergeev on Dec 4 2018, 8:46 AM.



-print-after IR printing generally can not print the IR unit (Loop or SCC) which has just been invalidated by the pass.
However, when working in -print-module-scope mode even if Loop was invalidated there is still a valid module
that we can print.

Since we can not access invalidated IR unit from AfterPassInvalidated instrumentation point we can remember
the module to be printed *before* pass. This change introduces BeforePass instrumentation that stores all the
information required for module printing into the stack and then after pass (in AfterPassInvalidated) just print
whatever has been placed on stack.

Diff Detail


Event Timeline

fedor.sergeev created this revision.Dec 4 2018, 8:46 AM
fedor.sergeev planned changes to this revision.Dec 4 2018, 9:10 AM

oops, this needs a small update

stack handling fixed (AfterPass now pops stack as well)

minor cleanup

What exactly does this change solve?

fedor.sergeev retitled this revision from [NewPM] -print-module-scope now prints module even after invalidated Loop/SCC to [NewPM] -print-module-scope -print-after now prints module even after invalidated Loop/SCC.Dec 6 2018, 12:44 PM
fedor.sergeev edited the summary of this revision. (Show Details)

What exactly does this change solve?

updated the summary.

This generally looks fine, some code comments inline.

34 ↗(On Diff #176947)

This should be an Optional.

35 ↗(On Diff #176947)

Why this intermiate? Why not just return?

169 ↗(On Diff #176947)

Avoid AAA

philip.pfaffe added inline comments.Dec 17 2018, 1:40 PM
35 ↗(On Diff #176947)


addressing comments

fedor.sergeev marked 4 inline comments as done.Dec 20 2018, 3:58 AM
philip.pfaffe added inline comments.Dec 20 2018, 4:37 AM
113 ↗(On Diff #179037)

Is this truly more readable than UnwrappedModule->first, UnwrappedModule->second?

fixing Optional use

fedor.sergeev marked 2 inline comments as done.Dec 20 2018, 5:36 AM
fedor.sergeev added inline comments.
113 ↗(On Diff #179037)

Definitely not, thanks for suggestion.

philip.pfaffe accepted this revision.Dec 20 2018, 6:18 AM

Thanks, LGTM!

This revision is now accepted and ready to land.Dec 20 2018, 6:18 AM
This revision was automatically updated to reflect the committed changes.
fedor.sergeev marked an inline comment as done.