This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha


On Thu, Dec 24, 2015 at 12:57 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On December 24, 2015 11:15:52 AM GMT+01:00, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak
>><ubizjak@gmail.com> wrote:
>>> >On Wed, Dec 23, 2015 at 2:39 PM, Richard Biener
>>> ><richard.guenther@gmail.com> wrote:
>>> >> On December 23, 2015 10:39:17 AM GMT+01:00, Uros Bizjak
>>> ><ubizjak@gmail.com> wrote:
>>> >>>Hello!
>>> >>>
>>> >>>There is a logic error in Honza's patch "Transparent alias suport
>>> >part
>>> >>>10" [1]. The part in memrefs_conflict_p should be changed to:
>>> >>>
>>> >>>-      /* If decls are different or we know by offsets that there
>>is
>>> >no
>>> >>>overlap,
>>> >>>- we win.  */
>>> >>>-      if (!cmp || !offset_overlap_p (c, xsize, ysize))
>>> >>>+      /* If decls are different and we know by offsets that
>>> >>>+ there is no overlap, we win.  */
>>> >>>+      if (!cmp && !offset_overlap_p (c, xsize, ysize))
>>> >>>  return 0;
>>> >>>-      /* Decls may or may not be different and offsets
>>overlap....*/
>>> >>>+      /* Decls are different and offsets overlap....*/
>>> >>>
>>> >>>Even if decls are different, their offsets shouldn't overlap!
>>> >>
>>> >> Comparing offsets of different decls does not make sense.
>>> >
>>> >Uh, yes, some more eyeballing was needed, but you are right.
>>> >
>>> >Is there a way to detect aliasing in case AND addresses are
>>involved?
>>> >
>>> >Probably we need something like in base_alias_check, where:
>>>
>>> Yeah, and in that case just give up.
>>
>>Yep, I will look into it ASAP.
>>comparing offsets of different decls is intended tohandle the case
>>where one decl is foo and other bar.
>
> ... And they resolve to the same address.
>
> For alpha we want to handle the case where an address based on decl A aliases decl B which do not resolve to the same address.  That's quite different and is generally _not_ allowed in the middle-end (apart from that pesky and-addresses).

Please note that rs6000 also needs AND-addresses, at least following
can be found in rs6000.c:

  /* Reload an offset address wrapped by an AND that represents the
     masking of the lower bits.  Strip the outer AND and let reload
     convert the offset address into an indirect address.  For VSX,
     force reload to create the address with an AND in a separate
     register, because we can't guarantee an altivec register will
     be used.  */
  if (VECTOR_MEM_ALTIVEC_P (mode)
      && GET_CODE (x) == AND
      && GET_CODE (XEXP (x, 0)) == PLUS
      && GET_CODE (XEXP (XEXP (x, 0), 0)) == REG
      && GET_CODE (XEXP (XEXP (x, 0), 1)) == CONST_INT
      && GET_CODE (XEXP (x, 1)) == CONST_INT
      && INTVAL (XEXP (x, 1)) == -16)

and

  /* If this is an unaligned stvx/ldvx type address, discard the outer AND.  */
  if (VECTOR_MEM_ALTIVEC_P (mode)
      && GET_CODE (x) == AND
      && GET_CODE (XEXP (x, 1)) == CONST_INT
      && INTVAL (XEXP (x, 1)) == -16)

so, I'm afraid that these annoyances will need to be handled until the
end of time ... alpha just uses AND-addresses a lot. The code I have
quoted a few messages ago is needed to say that aliasing can't be
determined, and this is all we need for a reliable scheduling.

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]