Jeffrey Law <[EMAIL PROTECTED]> writes: > On Thu, 2006-12-21 at 10:08 -0800, Ian Lance Taylor wrote: > > First, let's go ahead and define an orphan. An orphan is an SSA_NAME > which has SSA_NAME_DEF_STMT pointing to a statement which does not > appear in the IL.
That's fine, that simply changes to the question to how you can tell, given an SSA_NAME, whether it is an orphan or not. > Note we'd still have the problem of orphans for which I see only two > solutions. > > First, we bite the bullet and find every point where we're not releasing > orphan and we make failure to release a dead SSA_NAME an error (which we > can check during the IL scan as part of verify_ssa). The advantage is > we know at any point the set SSA_NAMEs which appear in the IL and we > have very clearly defined rules for dealing with SSA_NAMEs. They are > either free or they appear in the IL -- no orphans. > > The alternative is to mark/sweep them between passes. The obvious > downside is that within a pass we can get orphans, which I think > is insufficient for the current needs. I can't see any reason that we would not want to adopt your first solution. > > I think the issue is whether we want to have a way to see all > > currently valid SSA_NAMEs. Right now we can have SSA_NAMEs in the > > list which are no longer used, and we have no way to tell whether they > > are used or not. Thus the only way to see all valid SSA_NAMEs is to > > walk the code. > Depends on your definition of valid :-) Until now we've allowed > valid to include orphan SSA_NAMEs. That's far from ideal. But > it's worked marginally until now. > > Note that an orphan SSA_NAME should still have a TREE_CHAIN which > points to a "valid" statement node. God help you if you try to > interpret anything inside that statement node though. Right, and since you currently can't tell whether an SSA_NAME is an orphan or not, that makes the distinction currently useless. Ian
