On Thu, Aug 5, 2021 at 3:45 PM Erick Ochoa <eoc...@gcc.gnu.org> wrote: > > 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?
Parameters that are written into SSA form have their default definition represent the incoming value. Such parameter SSA names are identified by SSA_NAME_IS_DEFAULT_DEF (name) && SSA_NAME_VAR (name) && TREE_CODE (SSA_NAME_VAR (name)) == PARM_DECL and the corresponding PARM_DECL is the SSA_NAME_VAR. Parameters not written into SSA will appear as PARM_DECL in the IL. Note similar things happen to DECL_BY_REFERENCE RESULT_DECLs, the pointer will be in SSA form and the default def is the address of the return slot so you might see *result_3(D) = x; in the IL. See get_constraint_for_ssa_var for example. > > Many thanks! > -Erick
