Ensure one backedge per target: restore lexical loops

[tautschnig]

Figure-of-eight loop pairs may indeed have just one backedge, but still confused symex' unwinding counters. Re-create properly nested lexical loops from such loop pairs to avoid this problem.

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[codecov]

Codecov Report

Base: 78.28% // Head: 78.29% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (c127049) compared to base (d7dd40a).
Patch coverage: 89.88% of modified lines in pull request are covered.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #7321   +/-   ##
========================================
  Coverage    78.28%   78.29%           
========================================
  Files         1642     1642           
  Lines       189995   190068   +73     
========================================
+ Hits        148737   148806   +69     
- Misses       41258    41262    +4     

Impacted Files	Coverage Δ
src/solvers/flattening/boolbv_byte_extract.cpp	69.73% <ø> (ø)
src/solvers/flattening/boolbv_byte_update.cpp	100.00% <ø> (ø)
src/solvers/flattening/boolbv_equality.cpp	63.63% <ø> (ø)
src/solvers/flattening/boolbv_index.cpp	72.91% <ø> (ø)
...ncremental/smt2_incremental_decision_procedure.cpp	96.81% <ø> (ø)
src/util/byte_operators.h	92.72% <ø> (ø)
src/cprover/propagate.cpp	65.85% <16.66%> (-8.44%)	⬇️
...c/goto-programs/ensure_one_backedge_per_target.cpp	84.09% <82.97%> (-1.63%)	⬇️
src/util/lower_byte_operators.cpp	92.70% <95.50%> (ø)
src/solvers/smt2/smt2_conv.cpp	66.79% <100.00%> (+0.40%)	⬆️
... and 3 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[kroening]

Should the loop counters be fixed instead? Say by tracking pairs of locations instead of just the target?

[tautschnig]

Should the loop counters be fixed instead? Say by tracking pairs of locations instead of just the target?

Seems desirable, but would it actually work? Is it just the loop header that we want to track?

[peterschrammel]

Identifying loops by two locations has obvious advantages (less reliance on a 'normalised' GOTO program). I'm fine with either approach as long as we clearly document our assumptions. In 2LS we also normalise loops so that each loop head is a separate location.

[kroening]

Making changes to the program will, of course, break any user who expects counterexamples to follow the original program. I'd also prefer to use a pair to identify the loops instead.