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

["Alexander Monakov" <monoid at ispras dot ru>]

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.

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?

> 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,  
which in some cases allows better disambiguation, why should I enforce  
MEM_EXPR's rules on it?  If I, similarly to MEM_EXPRs, apply  
operand_equal_p also to MEM_ORIG_EXPRs, this will give me incorrect  
results, since different MEMs will be annotated with same MEM_ORIG_EXPR,  
which is wrong, since the latter is flow-sensitive, and operand_equal_p  
will discard that (since trees will look the same after out-of-SSA).  I do  
not see a better way to provide flow-sensitive annotations for MEMs.

> DDR will mark them as data refs

Come again? :)

Thanks.
--
Alexander Monakov