DFCC instrumentation: skip unused functions

[tautschnig]

Do not attempt to instrument functions that will never be used anyway. As we eventually use remove_unused_functions there is no point in trying to instrument them, and there is a scenario where the function may not have been compiled (see included test).

• Each commit message has a non-empty body, explaining why the change was made.
• n/a 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

Attention: Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 80.37%. Comparing base (5dc709d) to head (fa4a51c).

Files with missing lines	Patch %	Lines
.../goto-instrument/contracts/dynamic-frames/dfcc.cpp	80.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #8628   +/-   ##
========================================
  Coverage    80.37%   80.37%           
========================================
  Files         1686     1686           
  Lines       206872   206877    +5     
  Branches        73       73           
========================================
+ Hits        166265   166271    +6     
+ Misses       40607    40606    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[remi-delmas-3000]

When the program uses function pointers find_used_functions is not guaranteed to discover all reachable functions. Moreover users can expand function pointer calls after contract instrumentation, so we should at least inject assert(false);assume(false) sentinel instructions in the functions we skip.

[tautschnig]

But then we use use remove_unused_functions afterwards, which itself uses find_used_functions to determine which functions to remove, so I wouldn't know how users would do something after contract instrumentation?

[remi-delmas-3000]

Still not convinced we are totally sound. CBMC removes function pointers very late, right before the analysis, so if we remove functions that we think are unused, but could have been used as a target due to their signature, wouldn't we create a change in semantics for function pointers between contracts and basic symex ?

What about a case like this one ? Would intfun_contract still be considered used ?
Does find_used_functions consider a function used if its address is taken and assigned to a function pointer variable (e.g. intfun bar = baz;)?

typedef int (*intfun)(int);

intfun __VERIFIER_nondet_intfun();

int intfun_contract(int x)
__CPROVER_requires(-12 <= x && x <= 12)
__CPROVER_ensures(__CPROVER_return_value == 2*x)
;

int foo(intfun bar)
__CPROVER_requires(__CPROVER_obeys_contract(bar, intfun_contract))
__CPROVER_ensures(__CPROVER_return_value == 24)
{
  return bar(12);
}

[tautschnig]

Neither find_used_functions nor remove_unused_functions will take function pointers into account. Yet goto-instrument will always do function pointer removal before invoking the DFCC code. And dfcct::transform_goto_model does (removed logging and a bunch of comments for compactness):

[...]
  instrument_other_functions(); // the new use of find_used_functions happens in this method
  auto assigns_clause_size = instrument.get_max_assigns_clause_size();
  if(assigns_clause_size > max_assigns_clause_size)
    max_assigns_clause_size = assigns_clause_size;
  library.specialize(max_assigns_clause_size);
  library.inhibit_front_end_builtins();
  goto_model.goto_functions.update();
  remove_skip(goto_model);
  goto_model.goto_functions.update();
  // This can prune too many functions if function pointers have not been
  // yet been removed or if the entry point is not defined.
  // Another solution would be to rewrite the bodies of functions that seem to
  // be unreachable into assert(false);assume(false)
  remove_unused_functions(goto_model, message_handler);

So, really, not a lot is happening before eventually calling remove_unused_functions (of which I don't actually know why we are calling it in this code in the first place).

[remi-delmas-3000]

The presence of the TODO in the code show that we've run into this problem before. I'll just instrument unreachable functions with assert(false).assume(false)