This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Sun, 12 Oct 2014 19:44:45 +0200
- Subject: Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4ZJwrxFjcHBDgg=zzztQXxSmA3_OjjmkGhYKfEppZ2cxQ at mail dot gmail dot com> <54381DCA dot 10805 at redhat dot com> <CAFULd4aUpzoakgaRkGP24Yy5KV2Le9iQgDM_7bWoX79yfMOTdg at mail dot gmail dot com> <543822E3 dot 60801 at redhat dot com> <CAFULd4YzSnXMENw_Ycb-5QnKd8rRxLXVDwcG4RrhL-uFJEQv=w at mail dot gmail dot com>
On Fri, Oct 10, 2014 at 8:37 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> Right. And my question is what happens if we aren't as aggressive here.
>> What happens if before this check we return nonzero if X or Y is a VALUE?
>> Do we then get into memrefs_conflict_p and does it do the right thing?
>
> Following patch just after AND detection in base_alias_check fixes the
> testcase from PR:
>
> --cut here--
> Index: alias.c
> ===================================================================
> --- alias.c (revision 216100)
> +++ alias.c (working copy)
> @@ -1842,6 +1842,8 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
> || (int) GET_MODE_UNIT_SIZE (x_mode) < -INTVAL (XEXP (y, 1))))
> return 1;
>
> + return 1;
> +
> /* Differing symbols not accessed via AND never alias. */
> if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS)
> return 0;
> --cut here--
>
> I have started a bootstrap on alpha native with this patch (it will
> take a day or so) and will report back findings
Yes, this "patch" solves the original gfortran problem.
It looks to me that the code that handles AND addresses in
base_alias_check is not prepared to handle VALUES correctly.
Uros.