Skip to content

Explicit nondet initialisation #35

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

Closed

Conversation

tautschnig
Copy link
Collaborator

Instead of leaving the right-hand side empty, explicitly assign non-deterministic values when creating objects. This enables constant propagation for non-POD types.

@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from 4efea63 to 17c27c1 Compare April 3, 2016 09:46
@kroening kroening self-assigned this Apr 18, 2016
@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from 17c27c1 to 2b19b59 Compare May 18, 2016 16:58
@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from 2b19b59 to e3767ec Compare May 30, 2016 11:39
@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from e3767ec to d268552 Compare June 21, 2016 07:12
@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from d268552 to a82ffaa Compare July 20, 2016 15:21
@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from a82ffaa to c00ea94 Compare November 5, 2016 23:16
@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from c00ea94 to 440d1e4 Compare November 17, 2016 20:58
@tautschnig
Copy link
Collaborator Author

@martin-cs If you have any spare cycles to evaluate the performance impact of this pull request I'd be grateful. It should enable a lot more constant propagation for any code using structs or fixed-size arrays.

@peterschrammel
Copy link
Member

@tautschnig, needs rebasing...

@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from 440d1e4 to f86fb0b Compare January 12, 2017 10:22
@tautschnig
Copy link
Collaborator Author

@peterschrammel Rebasing done.

@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from f86fb0b to 5d208a6 Compare January 25, 2017 21:23
@forejtv forejtv assigned tautschnig and unassigned kroening Feb 21, 2017
@forejtv
Copy link
Contributor

forejtv commented Feb 21, 2017

@tautschnig can you please rebase to see if all tests pass?

@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from 5d208a6 to 3090a26 Compare February 21, 2017 19:09
@tautschnig
Copy link
Collaborator Author

Rebased, all checks passing. There is another question about performance, however.

@forejtv
Copy link
Contributor

forejtv commented Feb 22, 2017

@kroening can you let me know if this is good to go or whom I should ask to evaluate the performance?

@kroening
Copy link
Member

kroening commented Apr 3, 2017

Would the performance concern be addressed by only doing this for compound/array types?

@tautschnig
Copy link
Collaborator Author

I don't necessarily think there is a performance problem - it just needs to be evaluated to make sure there is no such problem. The lack of evaluation infrastructure for doing this evaluation is a problem...

@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch 3 times, most recently from 4242805 to 2262960 Compare April 10, 2017 10:05
@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from 80f79a4 to 2775f9e Compare May 13, 2018 10:28
@tautschnig
Copy link
Collaborator Author

CI passes here, TG bump would be appreciated. I am meanwhile working on eliminating/clarifying init_l1 and then some performance evaluation.

@smowton
Copy link
Contributor

smowton commented May 14, 2018

@tautschnig tautschnig force-pushed the explicit-nondet-initialisation branch from 2775f9e to 15c7af1 Compare May 14, 2018 11:22
@tautschnig
Copy link
Collaborator Author

I have now added two additional commits that clean up the code a fair bit, most notably is the init_l1 gone (and all the special-casing at the beginning of symex_assign_symbol). Could the TG run please be updated (if that's necessary)?

@smowton
Copy link
Contributor

smowton commented May 14, 2018

Updated.

@smowton
Copy link
Contributor

smowton commented May 14, 2018

Test-gen bump fails; it appears to break lots of tests, but they all have strings in common, so I suspect the string solver is being perturbed somehow. @romainbrenguier @allredj could either of you have a look here please?

@tautschnig
Copy link
Collaborator Author

tautschnig commented May 14, 2018

If there's any info that can be shared (such as a failing assertion) then I'm happy to take a look. It is entirely possible that there are more places in the code that handle ID_symbol but don't yet handle ID_nondet_symbol.

Edit: I am meanwhile working on the performance analysis. There are some cases that show improvement, while others have considerable higher memory consumption, which I need to investigate.

@@ -90,10 +73,16 @@ void goto_symext::symex_decl(statet &state, const symbol_exprt &expr)
state.top().hidden_function ||
state.source.pc->source_location.get_hide();

target.decl(
Copy link
Contributor

Choose a reason for hiding this comment

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

Surprised the target doesn't get told of the declaration anymore?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's a point worth considering, but really symex_targett::decl just bloats the formula. I might rather go one step further and remove it completely?!

@@ -42,6 +42,7 @@ void c_typecheck_baset::add_argc_argv(const symbolt &main_symbol)
argc_symbol.type=op0.type();
argc_symbol.is_static_lifetime=true;
argc_symbol.is_lvalue=true;
argc_symbol.value = side_effect_expr_nondett(op0.type());
Copy link
Contributor

Choose a reason for hiding this comment

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

This is surprising -- the convention elsewhere seems to be that a nil value implies nondet init (for example, Java globals)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Is that maybe only the case in Java? The one place that takes care of initialising globals is static_lifetime_init, which will zero-initialise all symbols that don't have a value (unless they are marked extern). Now of course the Java front-end had to do this in its very own way...

@@ -83,7 +83,7 @@ void goto_symex_statet::level1t::operator()(ssa_exprt &ssa_expr)
/// "constants"
bool goto_symex_statet::constant_propagation(const exprt &expr) const
{
if(expr.is_constant())
if(expr.is_constant() || expr.id() == ID_nondet_symbol)
Copy link
Contributor

Choose a reason for hiding this comment

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

This commit ( cb6f737 ) seems to be breaking our string tests...

Copy link
Contributor

Choose a reason for hiding this comment

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

We can see the difference on this example:

public class test
{
   public static int check(String s)
   {
       if(s.length()==2)
	   return 2;
       if(s.length()==4)
	   return 4;
       return s.length()+1;
   }
}

running with options: jbmc test.class --refine-strings --function test.check --trace --string-max-length 100 --cover location --trace --json-ui
current develop as some assignment in the trace of the form

{
        "assignmentType": "variable",
        "hidden": false,
        "internal": true,
        "lhs": "dynamic_object2",
        "mode": "java",
        "stepType": "assignment",
        "thread": 0,
        "value": {
          "elements": [
            {
              "index": 0,
              "value": {
                "binary": "0000000000111111",
                "data": "(char)'?'",
                "name": "integer",
                "type": "char",
                "width": 16
              }
            },
            {
              "index": 1,
              "value": {
                "binary": "0000000000111111",
                "data": "(char)'?'",
                "name": "integer",
                "type": "char",
                "width": 16
              }
            }
          ],
          "name": "array"
        }
      }

but with this commit, this is just replaced by

{
        "assignmentType": "variable",
        "hidden": false,
        "internal": true,
        "lhs": "dynamic_object2",
        "mode": "java",
        "stepType": "assignment",
        "thread": 0,
        "value": {
          "name": "unknown"
        }
      }

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thank you for bisecting! I'll take a look and will try to figure out what is going on.

@tautschnig
Copy link
Collaborator Author

Closing as field sensitivity already covers possible benefits of this change.

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.

7 participants