Hi, On Wed, Dec 21, 2011 at 12:53:10PM +1100, Matt Davis wrote: > 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.
I am still not sure I understand but... if the uses of the old parameter could be quite arbitrary then you should not be inventing your own into-SSA mechanism. Just traverse all statements and replace all SSA_NAMEs of the old PARM_DECL with the new PARM_DECL (yes, with the DECL, don't bother creating any SSA_NAMES yourself). ipa_modify_formal_paramaters already calls mark_sym_for_renaming on the new parameter for you so you should be fine by just returning TODO_update_ssa from your pass. Is that not so? (Or perhaps replace only the default definition SSA_NAME, depending on what you actually want to do, but then you'd need to replace the others with a VAR_DECL, just like IPA-SRA does in replace_removed_params_ssa_names.) BTW, All this assumes that the types are register types (i.e. not aggregates like records or arrays), these never have SSA_NAMEs at all. Of course, nothing of the above dealt with that almost certainly there would be new type-casts necessary. But really you should not need to create your own SSA_NAMES for the new PARM_DECL, neither IPA-SRA nor IPA-CP/inlining do so. Martin
