[PATCH] D88307: [DON'T MERGE] Jump-threading for finite state automata

[Ehsan Amiri via Phabricator via llvm-commits]

amehsan added a comment.

This is the remaining of the algorithm that I mentioned above.  (Step (3) of the algorithm). Please see the previous comment first. There should be enough details here to make the algorithm clear. Let me know if something is missing. Our work on revising the code has been suspended for a while. Will try to resume that soon. We are currently running some experiments to find similar code patterns so we can check generalizability of the algorithm beyond  coremark.

(3-1) Enumerate all paths in the loop. Each path will be a sequence of basic blocks.
(3-2) For each path indicate the point in which a new value for the variable is defined. This is either a phi node or a select statement. But we can unfold select statements to make things easier.  This statements should have been identified in the step (2) of the algorithm in the previous comment.
(3-3) The crucial point here (that needs to be checked) is that there is only  a single point in each path where a new value is assigned to “the variable”. We partition the set of blocks in each path to two sets: “AFTER SET” The blocks that contain the phi node of (3-2), and the blocks after that. Every other block goes to “BEFORE SET”.

The required check for this step should be fairly straightforward by following the use-def chains. Note that once we focus on a path in the loop, there is a fixed constant value for “the variable” when we are in a block in the “BEFORE SET”. There is also a fixed constant value for “the variable” in the “AFTER SET”.

(3-4) With the information available at this point, it should be possible to decide which basic blocks needs to be replicated.  Consider a BB that appears in the “BEFORE SET” of some paths. Let’s X denote the number of distinct values that “the variable” takes in the “BEFORE SET” of all these paths. We will need X copies of this BB, one for each of the distinct values. Similar property holds for basic blocks that appear in the “AFTER SET”. Note that one property that we rely on is the following: No BB appears in  “BEFORE SET” of one path and “AFTER SET” of another path. Edges between new BBs should be fairly straightforward.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88307/new/

https://reviews.llvm.org/D88307