On 12/10/07, Alexander Monakov <[EMAIL PROTECTED]> 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.
