http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to bin.cheng from comment #19)
> >
> > >not about an iv use appearing in memory reference while not marked as
> > >address_p, and can be fixed by revise the existing check condition, is
> > >it true?
> >
> > No, even expressing an address this way is broken as for example dependence
> > analysis via scev can get confused about the actual base object.
> Agree, only I think it's not scev's responsibility since scev only cares
> base value initialized for the analyzing loop, rather than the BASE object.
>
> >
> > IIRC previously we already avoided the mem-use case and I had to generalize
> > it
> > to also avoid addresses.
> Not all.
> For the reported case, use and cand like:
> use 3
> generic
> in statement vect_p.70_247 = PHI <vect_p.70_248(17), vect_p.73_246(6)>
>
> at position
> type vector(8) unsigned char *
> base batmp.71_245 + 1
> step 8
> base object (void *) batmp.71_245
> is a biv
> related candidates
>
> candidate 15
> depends on 3
> var_before ivtmp.154
> var_after ivtmp.154
> incremented before exit test
> type unsigned int
> base (unsigned int) pDst_39(D) - (unsigned int) &p1
> step (unsigned int) (pretmp.21_118 + 1)
>
> The check:
>
> if (address_p
> || (use->iv->base_object
> && cand->iv->base_object
> && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object))
> && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object))))
> {
> /* Do not try to express address of an object with computation based
> on address of a different object. This may cause problems in rtl
> level alias analysis (that does not expect this to be happening,
> as this is illegal in C), and would be unlikely to be useful
> anyway. */
> if (use->iv->base_object
> && cand->iv->base_object
> && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
> return infinite_cost;
> }
>
> still evaluates to false because:
> use->iv->base_object != NULL && cand->iv->base_object == NULL
> >
As I said in the PR that was last fixed with change of this code it is a
quick & dirty fix (because we were in stage3 again).
A better fix would be to detect reliably whether we are expressing an IV
with base A using an IV with base B != A (reliably == conservatively
correct) and then use whatever means (read: eventually to be invented)
to avoid the alias code from deriving bogus assumptions. One "mean" is
to use a non-pointer IV, but that only works for non-mem uses (a TMR
with a NULL TMR_BASE is not valid).
