If SplitBlockPredecessors was used on a function entry block,
it wouldn't update the dominator tree.
Details
Diff Detail
Event Timeline
lib/Transforms/Utils/BasicBlockUtils.cpp | ||
---|---|---|
513 | Shouldn't this be handled in UpdateAnalysisInformation? |
We should also try to get this fix into 6.0, the surrounding lines are not new. In fact, they were last modified 9-10 years ago. I wonder why it stayed unnoticed for so long.
lib/Transforms/Utils/BasicBlockUtils.cpp | ||
---|---|---|
513 | agree with Kuba |
I too am curious how this managed to not be found for several years. @arsenm how did you discover this?
I'm working on a replacement for StructurizeCFG which needs to insert a block before certain blocks. Sometimes that ends up picking the entry block
Thanks @arsenm for the explanation. I was curious to know if you found this with a specific .c/.cpp file or if it was from changing the middle-end. The latter makes a lot more sense to discover a latent bug like this.
LGTM.
lib/Transforms/Utils/BasicBlockUtils.cpp | ||
---|---|---|
324 | Can you also add a comment explaining why we need this special case here? I think the reason is that DT.splitBlock expects NewBB to have a non-empty set of predecessors. | |
327 | Without the patch, was the crash happening inside Split in GenericDomTree.h? If it doesn't support it, maybe it would make sense to assert in DT->split that NewBB != getRootNode() for (forward) dominators? |
I'm working on a replacement for StructurizeCFG which needs to insert a block before certain blocks. Sometimes that ends up picking the entry block
lib/Transforms/Utils/BasicBlockUtils.cpp | ||
---|---|---|
327 | It was hitting |
Can you also add a comment explaining why we need this special case here? I think the reason is that DT.splitBlock expects NewBB to have a non-empty set of predecessors.