Here is a follow up. I am closer to what I need, but not quite there yet. Basically I just want to switch the type of one formal parameter to a different type.
On Mon, Dec 19, 2011 at 11:05 PM, Matt Davis <mattdav...@gmail.com> wrote: > Hi Martin and thank you very much for your reply. I do have some more > resolution to my issue. > > On Mon, Dec 19, 2011 at 8:42 PM, Martin Jambor <mjam...@suse.cz> wrote: >> Hi, >> >> On Sun, Dec 18, 2011 at 01:57:17PM +1100, Matt Davis wrote: >>> I am using 'ipa_modify_formal_parameters()' to change the type of a >>> function's >>> formal parameter. After my pass completes, I get a 'gimple_expand_cfg()' >>> error. I must be missing some key piece here, as the failure points to a >>> NULL >>> "SA.partition_to_pseudo" value. I also set_default_ssa_name() on the >>> returned >>> value from ipa_modify_formal_parameter (the adjustment's 'reduction' >>> field). Do >>> I need to re-gimplify the function or run some kind of 'cleanup' or 'update' >>> once I modify this formal parameter? >> >> It's difficult to say without knowing what and at what stage of the >> compilation you are doing. > > My pass is getting called as the last IPA pass > (PLUGIN_ALL_IPA_PASSES_END). I do use the same function > "ipa_modify_formal_parameters()" to add additional parameters to > certain functions. And it works well. > >> The sad truth is that >> ipa_modify_formal_parameters is very much crafted for its sole user >> which is IPA-SRA and is probably quite less general than what the >> original intention was. Any pass using the function then must modify >> the body itself to reflect the changes, just like IPA-SRA does. >> >> SRA does not re-gimplify the modify functions, it just returns >> TODO_update_ssa or (TODO_update_ssa | TODO_cleanup_cfg) if any EH >> cleanup changed the CFG. > > Yep, and I do call update_ssa and cleanup_tree_cfg() after my pass. > >> So I would suggest to have a look at IPA-SRA (grep for the only call >> to ipa_modify_formal_parameters in tree-sra.c), especially at what you >> do differently. If you then have any further questions, feel free to >> ask. > > Yeah, that was one of the first things I did. Now, as mentioned, I > do have some more clarity on my issue. Basically, I am just changing > the type of an existing formal parameter. When I look at > "gimple_expand_cfg()" which is called later, I notice that the > "SA.partition_to_pseudo" for that parameter is NULL, to which > "gimple_expand_cfg()" aborts() on. Now, that value is NULL, because > in "gimple_expand_cfg()" the function "expand_used_vars()" is called. > I need "expand_one_var()" called since that should fix-up the RTX > assigned to the parameter I am modifying. Unfortunately, the bitmap, > "SA.partition_has_default_def" is true for the parameter, even if I do > not set it explicitly. And since it is always set, the > "expand_one_var()" routine is never called. I need to unset the > default def associated to the param to force "expand_one_var()" to > execute. So, for the ssa name assigned to the parameter I am > modifying, I use SSA_NAME_IS_DEFAULT_DEF to set the flag to 'false' > This sounds like a really gross hack. If I do this, I will need to > set a new ssa definition for the modified parameter. I use ipa_modify_formal_paramaters() and swap the type of the param with that of my desired type. The resulting PARM_DECL that the latter function gives me has no default definition. So, I use make_ssa_name() and set the return of that to the default definition for the PARM_DECL. That works fine, however I need to somehow rebuild the SSANAMES for the function. So, the new name I have for the modified PARAM_DECL is out of order and gimple_expand_cfg() fails, because the new definition of the PARM_DECL is now of order for SA,partition_to_pseudo, when gimple_expand_cfg() is called. Since the partition-to-pseudo stuff works based on the index of where the SSA_NAME is in the functions list of SSANAMES. gimple_expand_cfg() works by iterating across all SSANAMEs including the one I no longer need. What I need to do is replace the old SSA_NAME with the newer SSA_NAME I get back from make_ssa_name(). I could do this directly, but I have yet to find an appropriate routine in tree-flow.h and tree-flow-inline.h -Matt
