Conversation
|
I am currently working on implementing a dominance tree data structure that closely mirrors with the one defined in LLVM: https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/GenericDomTree.h |
85e953d to
156344b
Compare
ineol
left a comment
There was a problem hiding this comment.
Thank you!
Maybe we should consider splitting the dominance tree off of the PR to keep it manageable?
I definitely will. I also intend on cleaning up all of these commits because they're a mess. I've been under the weather lately - I was planning on splitting up the PR a couple days ago. I'll get to it soon. Also, thanks for the comments. This'll help me write better Lean code :) |
I just split my work into two PRs. This one now only contains the Dominance Tree. #264 contains the Dataflow Analysis Framework now. |
|
Hi @axelcool1234, can you rebase this PR on main? We'd like to start merging it soon :) |
Ah shoot, sorry about that! I'll get on that |
| def DomTreeNodePtr.getSibling! (ptr : DomTreeNodePtr) (ctx : DomContext) : Option DomTreeNodePtr := | ||
| (ptr.get! ctx).sibling | ||
|
|
||
| def DomTreeNodePtr.getLastChildSibling! (ptr : DomTreeNodePtr) (ctx : DomContext) : Option DomTreeNodePtr := |
There was a problem hiding this comment.
I'm confused. According to the invariant it should always return none?
| finger2 := (finger2.getIDom! domCtx).get! | ||
| return (finger1.getBlock! domCtx) | ||
|
|
||
| -- Postorder traversal of blocks, insert into DomTree (which is just an array!) |
There was a problem hiding this comment.
Would it make sense to split this into a function and document what it does? this function is really large
898562b to
d9ad389
Compare
This implements CFG dominance analysis on top of the dataflow framework: #264
This is based off of the Cooper-Harvey-Kennedy algorithm.