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. -Matt
