Skip to content

Move symex state levels to a new file #3434

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

romainbrenguier
Copy link
Contributor

@romainbrenguier romainbrenguier commented Nov 16, 2018

No functional change.
The goal is to reduce the complexity of goto_symex_state by extracting a module which takes care of the renaming levels.

  • 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.
  • [na] The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • [na] 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).
  • [na] My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • [na] White-space or formatting changes outside the feature-related changed lines are in commits of their own.

Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

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

✔️
Passed Diffblue compatibility checks (cbmc commit: f08782b).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/91673552

#include <util/irep.h>
#include <util/ssa_expr.h>

struct renaming_levelt
Copy link
Member

Choose a reason for hiding this comment

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

Would be good to add also some documentation at this occasion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added some documentation now.

@romainbrenguier romainbrenguier force-pushed the refactor/symex-state-levels branch from f0a40b4 to be65d15 Compare November 19, 2018 09:38
Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

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

✔️
Passed Diffblue compatibility checks (cbmc commit: be65d15).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/91841291

Copy link
Contributor

@antlechner antlechner left a comment

Choose a reason for hiding this comment

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

I'm not familiar with this part of the code but it's all refactoring and the changes look good to me! Just a few comments and questions before I can approve.


struct renaming_levelt
{
virtual ~renaming_levelt() = default;
Copy link
Contributor

Choose a reason for hiding this comment

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

⛏️ It would have been helpful to have the moving part and making changes in separate commits.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes sorry about that I think I had a commit before the moving that I removed by mistake before rebasing


void get_variables(std::unordered_set<ssa_exprt, irep_hash> &vars) const
{
for(const auto &pair : current_names)
Copy link
Contributor

Choose a reason for hiding this comment

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

⛏️ Can you think of a more meaningful name than pair?

operator()(ssa_exprt &ssa_expr, const namespacet &ns, unsigned thread_nr);

symex_level0t() = default;
~symex_level0t() override = default;
Copy link
Contributor

Choose a reason for hiding this comment

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

❓ Why is this line needed? 🐴

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There may subtleties I don't fully understand there, as to why there are needed. The constructor and destructor were defined before so I left the declaration, but then clion recommends to use = default instead of {} because it is more explicit (for the compiler in particular). Tagging @LAJW in case he can bring more insight here.

Copy link
Contributor

Choose a reason for hiding this comment

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

It just looks a bit strange that we're overriding a method to do exactly what its parent method does, but if it was the same before then any decision to change it can be made in a future PR.

}

symex_level1t() = default;
~symex_level1t() override = default;
Copy link
Contributor

Choose a reason for hiding this comment

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

🐴

struct symex_level2t : public renaming_levelt
{
symex_level2t() = default;
~symex_level2t() override = default;
Copy link
Contributor

Choose a reason for hiding this comment

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

🐴

@@ -35,7 +35,7 @@ bool scratch_programt::check_sat(bool do_slice)
output(ns, "scratch", std::cout);
#endif

goto_symex_statet::propagationt::valuest constants;
Copy link
Contributor

Choose a reason for hiding this comment

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

❓ This doesn't actually seem to be used anywhere, can it be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍 good catch

rename(expr.type(), ssa.get_identifier(), ns, level);
ssa.update_type();
}
else if(level==L2)
{
set_ssa_indices(ssa, ns, L1);
set_l1_indices(ssa, ns);
Copy link
Contributor

Choose a reason for hiding this comment

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

💡 "If L2 then use the L1 version" is quite confusing. I see that it was the same before your changes, but if you know the reason, could you explain it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree it's a bit confusing and I don't know exactly how it works, but I think the idea is that doing the renaming for one level you should also take care of the lower levels (for level1 we also do level0 and for level2 we do level0 and level1)

Copy link
Collaborator

Choose a reason for hiding this comment

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

We do the L2 renaming below, but first need to make sure the expression has all L1 levels set correctly, in particular in the type.

@@ -48,7 +48,7 @@ void symex_level1t::operator()(ssa_exprt &ssa_expr)

const irep_idt l0_name = ssa_expr.get_l1_object_identifier();

current_namest::const_iterator it = current_names.find(l0_name);
auto it = current_names.find(l0_name);
Copy link
Contributor

Choose a reason for hiding this comment

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

❓ Shouldn't these be const?

// level 0 -- threads!
// renaming built for one particular interleaving
/// Functor to set the level 0 renaming of SSA expressions.
/// Level 0 corresponds to threads.
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@@ -18,34 +18,41 @@ Author: Romain Brenguier, [email protected]
#include <util/irep.h>
#include <util/ssa_expr.h>

/// Wrapper for a \c current_names map, which maps each identifier to an SSA
Copy link
Contributor

Choose a reason for hiding this comment

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

❓ What do we use this map for? Could you explain a bit more about the context of this?

@romainbrenguier romainbrenguier force-pushed the refactor/symex-state-levels branch 2 times, most recently from 0d6e750 to d679724 Compare November 20, 2018 07:57
@romainbrenguier
Copy link
Contributor Author

@antlechner ready for rereview

Copy link
Contributor

@antlechner antlechner left a comment

Choose a reason for hiding this comment

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

LGTM

@romainbrenguier romainbrenguier force-pushed the refactor/symex-state-levels branch from d679724 to b265f7f Compare November 22, 2018 06:37
Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

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

✔️
Passed Diffblue compatibility checks (cbmc commit: b265f7f).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/92252168

Copy link
Collaborator

@tautschnig tautschnig left a comment

Choose a reason for hiding this comment

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

I think this is good, and probably doesn't affect performance. Given SV-COMP deadlines, right now is either the perfect time to merge this or a very bad time.

@tautschnig tautschnig merged commit d7c7434 into diffblue:develop Nov 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants