[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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).