Hello Richard, I'm still working on the points-to analysis and I am happy to say that after reviewing the ipa-cp code I was able to generate summaries for local variables, ssa variables, heap variables, global variables and functions. I am also using the callback hooks to find out if cgraph_nodes and varpool_nodes are added or deleted between read_summaries and execute. Even though I don't update the solutions between execute and function_transform yet, I am reading the points-to pairs and remapping the constraint variables back to trees during function_transform and printing the name of pointer-pointee pairs.
This is still very much a work in progress and a very weak points-to analysis. I have almost finished my Andersen's / field insensitive / context insensitive / flow-insensitive / intraprocedural analysis with the LTO framework (without interacting with other transformations yet). The only thing that I am missing is assigning parameters to be pointing to NONLOCAL memory upon entry to the function and perhaps some corner cases where gimple is not exactly how I expect it to be. I am wondering, none of the variables in function->gimple_df->ssa_names and function->local_decls are PARM_DECL. I'm also not entirely sure if I should be looking for PARM_DECLs since looking at function bodies' gimple representation I don't see the formal parameters being used inside the function. Instead, it appears that some SSA variables are automatically initialized with the parameter value. Is this the case? For example, for a function: foo (struct a* $NAME) The variable $NAME is nowhere used inside the function. I also found that there is an ssa variable in location X ( in function->gimple_df->ssa_names[X]) named with a variation like $NAME_$X(D) and this seems to correspond to the parameter $NAME. How can one (preferably looking only at function->gimple_df->ssa_names[$X]) find out that this tree corresponds to a parameter? Many thanks! -Erick
