[PATCH] Simplify n-ary adds by reassociation

Andrew Trick atrick at apple.com
Mon Apr 13 23:56:47 PDT 2015


> On Apr 13, 2015, at 9:49 PM, Jingyue Wu <jingyue at google.com> wrote:
> 
> sanjoy wrote:
>> Is it possible to switch to a traversal and expression gathering scheme that will always visit defs before uses?  Reverse post-order maybe?  I think that way we can avoid the `dominates` query (which can be expensive) and just turn it into an `assert`; and just use the earliest (latest?) element in `LHSCandidates`.
> We traversed the instructions in the pre-order of the dominator tree, so defs are already always visited before uses. However, this doesn't avoid checking `dominates(*LHS, I)` because `*LHS` being visited before `I` does not mean `*LHS` dominating `I`. 
> 
> Anyhow, I think there is a way of avoiding the dominance check, and I'm happy to put it in the next patch. Whenever we backtrack from a basic block during DFS'ing the dominator tree, we remove all SCEVs defined in this basic block from `SeenExprs`. This can ensure that, at any time, all the instructions in `SeenExprs` dominate the basic block we are exploring. 
> 
> For example, suppose the dominator tree of this function looks like:
> ```
> B1 -> B2
> |
> V
> B3 -> B4
> |
> V
> B5
> ```
> Then, we traverse the tree in this order: +B1 +B2 -B2 +B3 +B4 -B4 +B5 -B5 -B3 -B1. + means entering a node, and - means exiting a node. 
> 
> Let's pick a random basic block say B4. Before entering B4, we added B1, B2, and B3 to `SeenExprs` and removed B2 from it, so `SeenExprs` contains instructions in B1 and B3 which must dominate B4.

That’s what ScopedHashTable is for. It’s not necessarily a good idea to use though. If you have a lot of hash entries, removing them is expensive. A dominance check should be constant time comparison of DFS numbers. So if you map a lot of expressions and rarely get a match, your current implementation may be much better. Feel free to experiment with it.

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150413/ebcd2626/attachment.html>


More information about the llvm-commits mailing list