Page MenuHomePhabricator

[WIP!][DomTreeUpdater/Auto[3]] A new Auto UpdateStrategy candidate

Authored by NutshellySima on Aug 5 2018, 8:16 AM.



This patch is a work-in-process and I don't intend to commit it. If you are automatically subscribed to this patch, please ignore it.

This patch is the most promising one of the Auto UpdateStrategy implementations.

This patch is an approach to solve the problems in the current DomTreeUpdater and JumpThreading pass. (We need to figure out the previous state of the CFG when we call applyUpdates()/insertEdge()/deleteEdge() or we need to concern about the internal state of the DomTreeUpdater). It shows a similar performance on bitcode files with the current DomTreeUpdater working under Lazy UpdateStrategy after converting CorrelatedValuePropagation/RewriteStatepointsForGC/JumpThreading and testing under the -O3 pipeline.
This patch implements the Auto UpdateStrategy by getting a snapshot of the single from point if it didn't get one when user calls DTU.isAboutToChange(). Then use the information submitted by users (especially the From points) to narrow down the changes needs to be applied. When a flush() happens, it diffs the narrowed down range of points, thus it shows a rather good performance in line with the current one.

Diff Detail

Event Timeline

NutshellySima created this revision.Aug 5 2018, 8:16 AM

Benchmark results on Auto UpdateStrategy 3:

NutshellySima abandoned this revision.Feb 22 2019, 11:00 AM

Close this revision because D58170 is landed.
D58170 provides a cleaner interface than the Auto[3] strategy here as it does not require users to add extra functions calls before CFG changes. Moreover, it doesn't suffer from potential performance issues presented in Auto* implementations.

Herald added a project: Restricted Project. · View Herald TranscriptFeb 22 2019, 11:00 AM
Herald added a subscriber: jfb. · View Herald Transcript