[DTU] Refine the interface and logic of applyUpdates

Authored by NutshellySima on Feb 22 2019, 5:48 AM.


[DTU] Refine the interface and logic of applyUpdates

This patch separates two semantics of applyUpdates:

  1. User provides an accurate CFG diff and the dominator tree is updated according to the difference of the number of edge insertions and the number of edge deletions to infer the status of an edge before and after the update.
  2. User provides a sequence of hints. Updates mentioned in this sequence might never happened and even duplicated.

Logic changes:

Previously, removing invalid updates is considered a side-effect of deduplication and is not guaranteed to be reliable. To handle the second semantic, applyUpdates does validity checking before deduplication, which can cause updates that have already been applied to be submitted again. Then, different calls to applyUpdates might cause unintended consequences, for example,

DTU(Lazy) and Edge A->B exists.
1. DTU.applyUpdates({{Delete, A, B}, {Insert, A, B}}) // User expects these 2 updates result in a no-op, but {Insert, A, B} is queued
2. Remove A->B
3. DTU.applyUpdates({{Delete, A, B}}) // DTU cancels this update with {Insert, A, B} mentioned above together (Unintended)

But by restricting the precondition that updates of an edge need to be strictly ordered as how CFG changes were made, we can infer the initial status of this edge to resolve this issue.

Interface changes:
The second semantic of applyUpdates is separated to applyUpdatesPermissive.
These changes enable DTU(Lazy) to use the first semantic if needed, which is quite useful in transforms/utils.

Reviewers: kuhar, brzycki, dmgreen, grosser

Reviewed By: brzycki

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58170

llvm-svn: 354669


NutshellySimaFeb 22 2019, 5:48 AM
Differential Revision
D58170: [DTU] Refine the interface and logic of applyUpdates
rGab86d3da7ac4: Avoid two-stage initialization of MinidumpParser