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.
> I may be missing something, but I don't think that is the interesting > issue here. I think we would both agree that the underlying issue is our inability to efficiently determine if a given SSA_NAME: a. Appears in the IL b. Is in the free list c. Is an orphan The overloading of TREE_CHAIN/SSA_NAME_DEF_STMT inside the recycling code makes this problem somewhat uglier. If we didn't have that sharing (either because we took the hit of another field or we didn't have a recycler), then the act of releasing an SSA_NAME would probably look like: TREE_CHAIN (node) = NULL; Checking for an SSA_NAME being in-use would be TREE_CHAIN (node) != NULL And TREE_CHAIN (node) would *always* point to a statement in the IL rather than sometimes pointing to a statement (which may or may not be in the IL) and sometimes pointing to another SSA_NAME or NULL (as is the case currently for SSA_NAMEs in the free list). 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 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. Note that with clearly defined rules you can still do node recycling. But the implementation would be simpler. Jeff
