public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Julian Brown <julian@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Jakub Jelinek <jakub@redhat.com>,
	 Tobias Burnus <tobias@codesourcery.com>,
	Chung-Lin Tang <cltang@codesourcery.com>,
	 "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	Thomas Schwinge <thomas@codesourcery.com>
Subject: Re: [PATCH 2/4] [og11] Unify ARRAY_REF/INDIRECT_REF stripping code in extract_base_bit_offset
Date: Wed, 2 Jun 2021 13:59:05 +0200	[thread overview]
Message-ID: <CAFiYyc270xcMkngL0=0s-r5vqanAWkGrbhvPxNiZ9EOspUetWw@mail.gmail.com> (raw)
In-Reply-To: <309548a704fdfbf6b2786d0eac659d4a493af65f.1622630252.git.julian@codesourcery.com>

On Wed, Jun 2, 2021 at 12:47 PM Julian Brown <julian@codesourcery.com> wrote:
>
> For historical reasons, it seems that extract_base_bit_offset
> unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
> nodes from component accesses. I verified that the two ways of performing
> the operation gave the same results across the whole testsuite (and
> several additional benchmarks).

But the two code paths clearly do sth different.  The base_ref case
allows (*p)[i] while the !base_ref does not because TREE_CODE (base)
!= COMPONENT_REF.
And the !base_ref case for INDIRECT_REF is quite odd, only allowing
*(x.p) where x.p is of REFERENCE_TYPE.

Whatever this code is supposed to do ... maybe the "prologue" should be inlined
at the two callers instead.

Richard.

> The code was like this since an earlier "mechanical" refactoring by me,
> first posted here:
>
>   https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html
>
> It was never clear to me if there was an important semantic
> difference between the two ways of stripping the base before calling
> get_inner_reference, but it appears that there is not, so one can go away.
>
> 2021-06-02  Julian Brown  <julian@codesourcery.com>
>
> gcc/
>         * gimplify.c (extract_base_bit_offset): Unify ARRAY_REF/INDIRECT_REF
>         stripping code in first call/subsequent call cases.
> ---
>  gcc/gimplify.c | 32 +++++++++++---------------------
>  1 file changed, 11 insertions(+), 21 deletions(-)
>
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index a38cd502aa5..255a2a648c1 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -8527,31 +8527,21 @@ extract_base_bit_offset (tree base, tree *base_ref, poly_int64 *bitposp,
>    poly_offset_int poffset;
>
>    if (base_ref)
> -    {
> -      *base_ref = NULL_TREE;
> -
> -      while (TREE_CODE (base) == ARRAY_REF)
> -       base = TREE_OPERAND (base, 0);
> +    *base_ref = NULL_TREE;
>
> -      if (TREE_CODE (base) == INDIRECT_REF)
> -       base = TREE_OPERAND (base, 0);
> -    }
> -  else
> +  if (TREE_CODE (base) == ARRAY_REF)
>      {
> -      if (TREE_CODE (base) == ARRAY_REF)
> -       {
> -         while (TREE_CODE (base) == ARRAY_REF)
> -           base = TREE_OPERAND (base, 0);
> -         if (TREE_CODE (base) != COMPONENT_REF
> -             || TREE_CODE (TREE_TYPE (base)) != ARRAY_TYPE)
> -           return NULL_TREE;
> -       }
> -      else if (TREE_CODE (base) == INDIRECT_REF
> -              && TREE_CODE (TREE_OPERAND (base, 0)) == COMPONENT_REF
> -              && (TREE_CODE (TREE_TYPE (TREE_OPERAND (base, 0)))
> -                  == REFERENCE_TYPE))
> +      while (TREE_CODE (base) == ARRAY_REF)
>         base = TREE_OPERAND (base, 0);
> +      if (TREE_CODE (base) != COMPONENT_REF
> +         || TREE_CODE (TREE_TYPE (base)) != ARRAY_TYPE)
> +       return NULL_TREE;
>      }
> +  else if (TREE_CODE (base) == INDIRECT_REF
> +          && TREE_CODE (TREE_OPERAND (base, 0)) == COMPONENT_REF
> +          && (TREE_CODE (TREE_TYPE (TREE_OPERAND (base, 0)))
> +              == REFERENCE_TYPE))
> +    base = TREE_OPERAND (base, 0);
>
>    base = get_inner_reference (base, &bitsize, &bitpos, &offset, &mode,
>                               &unsignedp, &reversep, &volatilep);
> --
> 2.29.2
>

  reply	other threads:[~2021-06-02 11:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 10:45 [PATCH 0/4] [og11] OpenACC: Rework struct component handling Julian Brown
2021-06-02 10:45 ` [PATCH 1/4] [og11] Rewrite GOMP_MAP_ATTACH_DETACH mappings unconditionally Julian Brown
2021-06-02 10:45 ` [PATCH 2/4] [og11] Unify ARRAY_REF/INDIRECT_REF stripping code in extract_base_bit_offset Julian Brown
2021-06-02 11:59   ` Richard Biener [this message]
2021-06-02 13:36     ` Julian Brown
2021-06-02 10:45 ` [PATCH 3/4] [og11] Refactor struct lowering for OpenACC/OpenMP in gimplify.c Julian Brown
2021-06-02 10:45 ` [PATCH 4/4] [og11] Rework indirect struct handling for OpenACC " Julian Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFiYyc270xcMkngL0=0s-r5vqanAWkGrbhvPxNiZ9EOspUetWw@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=cltang@codesourcery.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=julian@codesourcery.com \
    --cc=thomas@codesourcery.com \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).