Re: [RFC/RFT] Improving SMS by data dependence export

["Daniel Berlin" <dberlin at dberlin dot org>]

On 12/10/07, Alexander Monakov <monoid@ispras.ru> wrote:
> Hi.  Sorry for the previous empty reply.
>
> > also, i see
> > +  /* We do not use operand_equal_p for ORIG_EXPRs because we need to
> > +     distinguish memory references at different points of the loop
> > (which
> > +     would have different indices in SSA form, like a[i_1] and a[i_2],
> > but
> > +     were later rewritten to same a[i]).  */
> > +         && (p->orig_expr == q->orig_expr));
> >
> > This doesn't do enough to distinguish memory references at different
> > points of the loop, while also eliminating from consideration that
> > *are* the same.
> >
> > What if they are regular old VAR_DECL?
> > This will still return true, but they may be different accesses at
> > different points in the loop.
>
> Sorry, I don't really follow.  The comment is somewhat badly worded
> indeed.  The purpose of making handling of MEM_ORIG_EXPRs (introduced by
> this patch) different from MEM_EXPRs in ignoring operand_equal'ity of
> trees pointed to by this field is enforcing that MEMs corresponding to
> accesses to objects of the same type but with (potentially) different
> addresses will not share MEM_ATTRS structure.  So, if both are VAR_DECLs,
> returning true is OK, since different accesses still correspond to the
> same memory location.

Okay, then you should edit the comment to make this clear.  Because it
is certainly incorrect as is.

>
> The first sentence also implies that potentially different accesses could
> be merged here, but I don't see any reason for that except for NULL
> MEM_ORIG_EXPRs.  Could you please elaborate on this?

COMPONENT_REF of INDIRECT_REF ( IE a->c), for example, would be merged
here, incorrectly (since a may not be the same memory at this point in
time) but  it's not clear we ever generate them as MEM_ORIG_EXPR.

Relying on pointer equality of tree expressions to give you some
semantic value seems a very bad idea to me.

>
> > In any case, this doesn't belong in mem_attrs_htab_eq, because if they
> > are operand_equal_p, for purposes of memory attributes, they *are*
> > equal.  They may still be different accesses, which is something you
> > have to discover later on.
>
> I don't follow this either.  Since I add a new field to MEM_ATTRS struct,

I misread this portion, my apologies.
I thought you were changing the semantics of an existing field.