Issue 43: Dead variable treatment problems
Status:  Fixed
Owner:
Closed:  Sep 2008
Project Member Reported by kevin.bi...@gmail.com, Sep 25, 2008
- Looses facts for objects which are still target of an implication

This problem means that implications of dead objects sometimes become
useless when they are removed too early.

- Needs an instruction to collect

Dead variables are collected before each instruction; this leads to missed
collection opportunities before join points and method returns.

Test cases in GCTest file.
Sep 25, 2008
Project Member #1 kevin.bi...@gmail.com
Test methods committed in r68
Sep 26, 2008
Project Member #2 kevin.bi...@gmail.com
r70 fixes these problems, although possibly with more overhead than necessary.  In
particular, need not consider variables kept alive by implications when looking for
implications to apply.
Sep 26, 2008
Project Member #3 kevin.bi...@gmail.com
Turns out it's possible that a variable is dead on one edge out of a node, but not
another, but we're currently (conservatively) not taking that into account, leading
to problems at later merge points.  This can be improved by garbage-collecting on the
incoming lattice elements during joins, or by getting edge-sensitive liveness
information.  The problem with the former is that liveness information is not
currently available during joins.  The problem with the latter is that we can only
approximate the ideal by getting labeled results, which in the case of liveness would
only include true, false, and normal labels (because we're looking at the incoming
information to nodes, and Crystal only tracks those three labels for incoming results).
Sep 29, 2008
Project Member #4 kevin.bi...@gmail.com
r83 uses branch-sensitive liveness information, which will hopefully be good enough
to address comment 3 (test case in r84).  Extended Crystal (revision 93) to provide
branch-sensitive results for TAC instructions.
Status: Fixed
Sep 29, 2008
Project Member #5 kevin.bi...@gmail.com
Noticed that DynamicStateLogic.join drops all implications if the incoming
implication lists for a location are not the same; could just drop the ones missing
in one of the incoming lists.  Also could think about trying to apply the
implications which are about to be dropped.  Will file separate issue for this.
Sep 29, 2008
Project Member #6 kevin.bi...@gmail.com
Filed issue 45 about join issues mentioned in last comment