This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SSA_NAMES: should there be an unused, un-free limbo?
On 12/21/06, Robert Kennedy <jimbob@google.com> wrote:
> Robert, can you attach the testcase you've been working with?
One testcase is libstdc++-v3/libsupc++/vec.cc from mainline.
But it compiles without trouble unless you add verification or a walk
over the SSA_NAMEs at the right time.
> 1. We replace all uses of a phi node with something else
> 2. We then call remove_phi_node with false as the last parameter (only
> 3 places in the compiler), which ends up destroying the phi node but
> not releasing the LHS name (since this is what the last parameter says
> whether to do).
That's right. Zdenek recommended that I change one of those places
(the one in tree_merge_blocks that you quoted) to "true", but doing
that causes some other code of his to break. I haven't analyzed why he
needs those things to stay around, but I suspect it's because -- for a
while, anyway -- he needs the DEF_STMT for something that's been
removed.
You can't change the last parameter to true in the if's true branch,
but you can in the else branch.
He's reusing the phi result's ssa_name on the true branch for a
statement copy, which will set the def_stmt to something valid.
I.E. this should work:
if (!may_replace_uses)
{
gcc_assert (is_gimple_reg (def));
/* Note that just emitting the copies is fine -- there is no problem
with ordering of phi nodes. This is because A is the single
predecessor of B, therefore results of the phi nodes cannot
appear as arguments of the phi nodes. */
copy = build2_gimple (GIMPLE_MODIFY_STMT, def, use);
bsi_insert_after (&bsi, copy, BSI_NEW_STMT);
SSA_NAME_DEF_STMT (def) = copy;
remove_phi_node (phi, NULL, false);
}
else
{
replace_uses_by (def, use);
remove_phi_node (phi, NULL, true);
}
<remove the call that was always occurring that went here>
-- Robert