Skip to content

Conversation

@tautschnig
Copy link
Collaborator

Constant propagation and simplification may determine that a loop cannot be
unrolled further. This is determined at the loop head, which is a forward goto
in case of for or while (but not do-while) loops. Before this patch, forward
gotos would never cause loop counters to be reset. In nested loops, the inner
loop(s) would thus have their unwinding counts added to previous (complete) loop
executions.

Copy link
Member

@peterschrammel peterschrammel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, that's a major fix.

@tautschnig
Copy link
Collaborator Author

Wow, that's a major fix.

I am yet to (re-)run SV-COMP experiments; I'd guess there could be some nested loops, which previously we have necessarily aborted way too early.

Constant propagation and simplification may determine that a loop cannot be
unrolled further. This is determined at the loop head, which is a forward goto
in case of for or while (but not do-while) loops. Before this patch, forward
gotos would never cause loop counters to be reset. In nested loops, the inner
loop(s) would thus have their unwinding counts added to previous (complete) loop
executions.
The previous approach would reset loop counters when reaching an unwinding
bound, which was broken as shown by newly added regression tests.
@tautschnig
Copy link
Collaborator Author

@kroening Please review whether this approach is as discussed and reasonable. I'll then clean up the commits and will remove the do-not-merge label.

@kroening kroening merged commit 32b68ce into diffblue:master Jul 4, 2017
@tautschnig tautschnig deleted the fix-unwind-count branch July 4, 2017 17:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants