On Sun, 2005-03-27 at 20:08 -0500, Kazu Hirata wrote:
> Hi Diego,
>
> > By merging, do you mean *replacing* CCP with VRP? Yes, it's
> > doable. No, it's not a good idea.
>
> Understood.
>
> Also, if we are inserting ASSERT_EXPRs, it seems to be a good idea to
> run copy-prop before VRP. Otherwise, we would end up with lots of
>
> D.18001_101 = D.18001_198;
> D.18011_102 = D.18001_101->head_;
> D.18001_12 = ASSERT_EXPR <D.18001_101, D.18001_101 != 0B>;
>
> Note that ASSERT_EXPR is on D.18001_101, not on D.18001_198, which is
> older. As a result, VRP does not notice that D.18001_198 != 0B.
> Currently, we still have these even after copy prop because we don't
> allow copy propagation between const and non-const pointers, which I
> think is a bit too restrictive.
Before we go a lot further with this, I'd like to make sure we're first
all on the same page regarding the semantics of ASSERT_EXPR and whether
or not ASSERT_EXPRs appear on the RHS of MODIFY_EXPRs.
When I looked at using a similar mechanism to store context sensitive
equivalences it became very clear that context sensitive equivalences
must not be recorded with a new assignment.
ie, if we have
if (a_1 == 0)
{
}
We do not want to turn that into
if (a_1 == 0)
{
a_2 = 0;
}
OR
if (a_1 == 0)
{
a_2 = ASSERT_EXPR ...
}
Whatever scheme we use to explicitly expose context sensitive
equivalences in the IL needs to be a pure expression.
This is documented in one of the many compile-time performance PRs
from 2004.
And, yes, it is imperative that we const/copy propagate into
ASSERT_EXPRs to the fullest extent possible. Otherwise we lose a lot
of threading opportunities.
Jeff
