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