You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
go/pointer is designed around the idea of queries. Before running the actual analysis, one adds objects of interest, for which one can then obtain the points-to sets. go/pointer even has special optimizations to only track information required to satisfy these queries. All in all, go/pointer is designed around one-off queries in support of editor tools (most prominently, guru).
This API doesn't scale well for our needs. For errcheck, we'll want points-to sets for a very large number of objects. And ideally, we won't have to walk the program code twice (once for adding the queries, once for consuming them).
The obvious change to the API is to track all objects, regardless of queries having been made. This prevents us from doing destructuring queries, but this can be worked around in two ways:
some destructuring queries can be answered simply by looking at different objects
we can apply destructuring for all objects during analysis. For example, for a function call, we can automatically track all returned values, even if no ssa.Extract instructions are present.
Another change would be to store points-to information directly in SSA values. This would avoid the use of huge maps (for reasons similar to #340). It would also let us build a points-to graph, with both forward and backward edges (may point to/may be pointed to by).
Unlike #340, this change may actually degrade performance. We may end up "querying" a lot more objects than is necessary. Especially dereferencing queries are very costly.
The text was updated successfully, but these errors were encountered:
go/pointer is designed for whole-program analysis, something we no longer generally do, with the exception of unused. If/when we're going to work on PTA again, we'll have to design something based on function summaries, or strictly restricted to intra-procedural analysis.
go/pointer is designed around the idea of queries. Before running the actual analysis, one adds objects of interest, for which one can then obtain the points-to sets. go/pointer even has special optimizations to only track information required to satisfy these queries. All in all, go/pointer is designed around one-off queries in support of editor tools (most prominently, guru).
This API doesn't scale well for our needs. For errcheck, we'll want points-to sets for a very large number of objects. And ideally, we won't have to walk the program code twice (once for adding the queries, once for consuming them).
The obvious change to the API is to track all objects, regardless of queries having been made. This prevents us from doing destructuring queries, but this can be worked around in two ways:
Another change would be to store points-to information directly in SSA values. This would avoid the use of huge maps (for reasons similar to #340). It would also let us build a points-to graph, with both forward and backward edges (may point to/may be pointed to by).
Unlike #340, this change may actually degrade performance. We may end up "querying" a lot more objects than is necessary. Especially dereferencing queries are very costly.
The text was updated successfully, but these errors were encountered: