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.