This is an archive of the discontinued LLVM Phabricator instance.

[SCEV][NFC] Assert that we do not expand something unsafe
AbandonedPublic

Authored by mkazantsev on Oct 24 2017, 4:53 AM.

Details

Summary

When using SCEVExpander, we rely on passes to check that what they do is OK from
the point of the expander. Effectively, if they fail to do so, it is never checked.

This patch adds assert on the fact that if we need to create any instructions in SCEV
expander, it is safe to create them. Failure of this assert should be interpreted as a bug
in the pass where it happened.

The examples of passes (and fixes to them) that failed to ensure that what they do is safe are:
https://reviews.llvm.org/D39229
https://reviews.llvm.org/D39230
https://reviews.llvm.org/D39234

Diff Detail

Event Timeline

mkazantsev created this revision.Oct 24 2017, 4:53 AM
mkazantsev edited the summary of this revision. (Show Details)Oct 24 2017, 4:56 AM
mkazantsev added reviewers: sanjoy, anna, apilipenko, reames.
mkazantsev edited subscribers, added: llvm-commits; removed: sanjoy.
mkazantsev edited the summary of this revision. (Show Details)Oct 24 2017, 5:21 AM
sanjoy requested changes to this revision.Oct 24 2017, 9:44 AM
sanjoy added inline comments.
lib/Analysis/ScalarEvolutionExpander.cpp
1749

I think this is overtly conservative. Expanding something unsafe is a problem only if "unsafety" (in practice, today this is just division by zero) was not present in the IR before. For instance if we have %v = udiv i32 %x, %y in the IR then it is perfectly fine to getSCEV on %v and then re-expand it before or after %v since if %y was 0 then the program is undefined.

This revision now requires changes to proceed.Oct 24 2017, 9:44 AM
mkazantsev abandoned this revision.Oct 26 2017, 1:30 AM