Project

General

Profile

Feature #3698

use call-graph analysis to link shared resource usage to the original resource definition

Added by Greg Shah almost 6 years ago. Updated almost 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
version_reported:
version_resolved:

History

#1 Updated by Greg Shah almost 6 years ago

For each type of shared/global resource (variables, buffers, frames...) use the call-graph to link resource references to the original (NEW) resource definition.

The results of the calculation should be provided as a new call-graph report.

#2 Updated by Greg Shah almost 6 years ago

I think we should also include "indirectly shared" resources. This would be a resource passed by HANDLE as a parameter.

#3 Updated by Constantin Asofiei almost 6 years ago

Greg Shah wrote:

For each type of shared/global resource (variables, buffers, frames...) use the call-graph to link resource references to the original (NEW) resource definition.

There are a couple of issues here:
  • a new global shared will act as a shared, if on the runtime stack there is another new global shared definition for the same resource
  • NEW SHARED vars are scoped - i.e. they will hide another NEW [GLOBAL] SHARED from a previous scope, until this gets 'out of scope'.

I think this can be solved by walking the callgraph 'in reverse', starting with the var's program, via BFS: first found NEW definition will act as a barrier and stop the walk, on that path - and a link will be created to it. Thus, as a shared var can be reached by multiple paths, more than one link to a definition may be created.

The correctness of this report will depend on how detailed the callgraph was built (same as dead code and others).

I think ~5 days of work here.

I think we should also include "indirectly shared" resources. This would be a resource passed by HANDLE as a parameter.

The runtime object of the HANDLE reference can be hidden by the logic, so that a static analysis can be almost impossible to compute, without heavy hint usage; and when considering dynamic widgets, UI widget iteration, the fact that a var can be used for more than one resource type (think frame widget iteration), I'm not sure how doable this is.

#4 Updated by Greg Shah almost 6 years ago

The runtime object of the HANDLE reference can be hidden by the logic, so that a static analysis can be almost impossible to compute, without heavy hint usage; and when considering dynamic widgets, UI widget iteration, the fact that a var can be used for more than one resource type (think frame widget iteration), I'm not sure how doable this is.

Yes, handles can be re-used for multiple different resource types. However, I think most usage of handles only ever assigns a single resource type to any given handle. I would expect that we implement a handle type analysis in early annotations, then use that result in the indirect analysis.

For those which have multiple types, we can use hints.

Also available in: Atom PDF