http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #19 from bin.cheng <amker.cheng at gmail dot com> ---
> 
> >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
>

Reply via email to