On 03/02/2016 11:58 AM, Jeff Law wrote:
I think this doesn't quite work, to make it match the comment you'd
have to add
a SSA_NAME_VAR (dst) != NULL_TREE check as otherwise all anonymous
SSA names count as "the same value we're tracking". Shouldn't you simply
compare the SSA names themselves but for the operand corresponding to
the edge we are threading instead of the PHI result?
Without testing, yea, I think SSA_NAME_VAR != NULL_TREE ought to be
added to handle anonymous names.
So some raw data.
66% of the time both objects have an underlying SSA_NAME_VAR and we can
make an accurate guess if they're related or not by looking at the
underlying object.
17% of the time the name we're tracking has an SSA_NAME_VAR, but the
result of the PHI does not. Assuming the names are not related is
probably accurate here too.
3% of the time the name we're tracking is anonymous, but the result of
the PHI is not. Again, assuming names are not related is probably
accurate. Note the low value here is not unexpected.
Leaving the remaining 14% where both names are anonymous. Which is the
case we're getting wrong right now. I think the safe thing to do
without significant further investment is to consider the names
unrelated in this case, which I'm testing now. If we wanted to do
better here we could do things like building partitions similar to what
we do for coalescing. If the objects end up in the same partition, then
consider them related, but that seems like severe overkill here.
Jeff
