Feature #3698
use call-graph analysis to link shared resource usage to the original resource definition
0%
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:
There are a couple of issues here:For each type of shared/global resource (variables, buffers, frames...) use the call-graph to link resource references to the original (NEW) resource definition.
- a
new global shared
will act as ashared
, if on the runtime stack there is anothernew global shared
definition for the same resource NEW SHARED
vars are scoped - i.e. they will hide anotherNEW [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.