This patch improves verification by making verifyReachablility look for CFG not found in the DomTree.
It also makes the verification work with postdominators by handling virtual root.
Details
Diff Detail
Event Timeline
include/llvm/Support/GenericDomTreeConstruction.h | ||
---|---|---|
302 | It's more accurate to state that the virtual root *is* a cfg node. Or at least it was. The virtual dom tree root was then the dom tree node that got built for the virtual cfg root. I don't know if this is still the case. | |
305 | When is it possible to have !BB but it's not a virtual root? |
include/llvm/Support/GenericDomTreeConstruction.h | ||
---|---|---|
302 | I mean, if you ask a virtual root for its (CFG) block, it returns a nullptr. Do you consider this nullptr block a virtual CFG exit node? | |
302 | (Or in the future, a virtual entry block for dominators?) | |
305 | It's just an oversight when cherry-picking changes :) |
include/llvm/Support/GenericDomTreeConstruction.h | ||
---|---|---|
302 | The fact that we don't hand the virtual CFG block to people is fine (but possibly annoying): Remember the dominator tree does not have predecessor edges, etc. So either you are hard coding the logic for it being a CFG block, or it's really got a virtual CFG block :P Right now I believe it's the case we hard-code the logic during post-dom construction. |
include/llvm/Support/GenericDomTreeConstruction.h | ||
---|---|---|
302 | Is it better now? |
It's more accurate to state that the virtual root *is* a cfg node. Or at least it was.
At least as used previously, the virtual root was not really a dom tree root, it was really the thing that contained the edges to the blocks.
The virtual dom tree root was then the dom tree node that got built for the virtual cfg root.
I don't know if this is still the case.