Reject and report regions that contains loops overlapping nonaffine region.
This situation typically happens in the presence of inifinite loops.
This addresses bug PR28071.
Differential D21312
[Polly] Fix assertion due to loop overlap with nonaffine region.
huihuiz on Jun 13 2016, 3:41 PM. Authored by
Details Reject and report regions that contains loops overlapping nonaffine region. This addresses bug PR28071.
Diff Detail
Event TimelineComment Actions Thank you for submitting the patch Some remarks for submitting Polly patches:
Such non-properly nested loops and regions are strange and we maybe should those generally. This is Johannes' code and therefore I'd wait for his response.
Comment Actions
I agree with the first part but not with the second. Please feel free to decide on your own. Thanks for the patch and the review!
Comment Actions Thank you for the update. You changed the contains test to only check contained Loop. Are you sure this is sufficient? The Region might contain a single non-loop BasicBlock that is outside of the surrounding loop. Or is there a reason why this cannot happen? Comment Actions Huihui is right, just checking Entry and Exiting blocks is not enough. The loop is: The region is: [2] for.body => if.else Due to how a region is interpreted, %if.then and %while.body belong to the region, even though there is no path from the blocks to the exit node, it just loops infinitely. Loops exclude such dead-end blocks. Naively, I'd assume regions being 'single entry - single exit' parts that each of the blocks in a region has a path to the exit region. This might be due to the definition of Region::contains For this patch I'd prefer checking all BBs instead of only the loops. Not only infinite loops can be dead-ends, but also Unreachable instructions. These are currently caught by polly::isErrorBlock, but maybe isErrorBlock could/should also be extended to recognize dead-end loops. I'd prefer a single mechanism for such cases instead of multiple in different parts of the code. Huihui, can you add a descriptive comment about these findings into this patch (that is, why a region is not entirely contained in a loop)? I'd accept it even when only checking boxed loops, assuming that the UnreachableInst case will be caught by isErrorBlock().
Comment Actions Thanks for the review and comments! For cases where loop overlap with nonaffine subregion, typically happens in the presence of infinite loop. That neither the surrounding loop contains the nonaffine subregion, nor the nonaffine subregion contains the surrounding loop. That said, the surrounding loop does not entirely contain the nonaffine subregion. When presence with infinite loop, using entry and existing bb of nonaffine subregion to check if surrounding loop contains this region is not sufficient. This patch handles cases with dead-end loops, assuming cases of UnreachableInst caught by isErrorBlock(). I have updated this patch with fix for the test case, please help commit and merge this patch, thanks! |
If L and R do not overlap, there isn't even a reason to create a ReportLoopOverlapWithNonAffineRegion object, ie. are always set.
Try to give L and R independent descriptions.