From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-456086-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6258 invoked by alias); 16 Jun 2017 10:26:38 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 5542 invoked by uid 89); 16 Jun 2017 10:26:37 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: smtp.eu.adacore.com
Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Jun 2017 10:26:35 +0000
Received: from localhost (localhost [127.0.0.1])	by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 7F5AC81477;	Fri, 16 Jun 2017 12:26:38 +0200 (CEST)
Received: from smtp.eu.adacore.com ([127.0.0.1])	by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id 20EP8RHsXqJA; Fri, 16 Jun 2017 12:26:38 +0200 (CEST)
Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133])	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))	(No client certificate requested)	by smtp.eu.adacore.com (Postfix) with ESMTPSA id 4498081354;	Fri, 16 Jun 2017 12:26:38 +0200 (CEST)
From: Eric Botcazou <ebotcazou@adacore.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [patch] Do not directly change TARGET_MEM_REF in maybe_canonicalize_mem_ref_addr
Date: Fri, 16 Jun 2017 10:26:00 -0000
Message-ID: <1942070.BArXlNHR71@polaris>
User-Agent: KMail/4.14.10 (Linux/3.16.7-53-desktop; KDE/4.14.9; x86_64; ; )
In-Reply-To: <CAFiYyc3y-8ZEe=pQAQ5_t=4g3K6HeXmx9_cLEZnoX_CSkV8cbQ@mail.gmail.com>
References: <59903573.zuAO1vMF2R@polaris> <CAFiYyc3y-8ZEe=pQAQ5_t=4g3K6HeXmx9_cLEZnoX_CSkV8cbQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-SW-Source: 2017-06/txt/msg01181.txt.bz2

> I don't think so.  get_address_description assumes TMR_BASE is in
> canonical form,
> that is, when it is an ADDR_EXPR we have a symbol and when not we have
> a pointer.
> TMR[&p->a] violates this and the gimple-fold.c part first canonicalizes this
> to TMR[p + offsetof(a)].

get_address_description doesn't assume anything on TMR_BASE:

void
get_address_description (tree op, struct mem_address *addr)
{
  if (TREE_CODE (TMR_BASE (op)) == ADDR_EXPR)
    {
      addr->symbol = TMR_BASE (op);
      addr->base = TMR_INDEX2 (op);
    }
  else
    {
      addr->symbol = NULL_TREE;
      if (TMR_INDEX2 (op))
	{
	  gcc_assert (integer_zerop (TMR_BASE (op)));
	  addr->base = TMR_INDEX2 (op);
	}
      else
	addr->base = TMR_BASE (op);
    }
  addr->index = TMR_INDEX (op);
  addr->step = TMR_STEP (op);
  addr->offset = TMR_OFFSET (op);
}

and maybe_fold_tmr will precisely turn TMR[&p->a] into TMR[p + offsetof(a)]:

  if (addr.symbol
      && TREE_CODE (TREE_OPERAND (addr.symbol, 0)) == MEM_REF)
    {
      addr.offset = fold_binary_to_constant
			(PLUS_EXPR, TREE_TYPE (addr.offset),
			 addr.offset,
			 TREE_OPERAND (TREE_OPERAND (addr.symbol, 0), 1));
      addr.symbol = TREE_OPERAND (TREE_OPERAND (addr.symbol, 0), 0);
      changed = true;
    }
  else if (addr.symbol
	   && handled_component_p (TREE_OPERAND (addr.symbol, 0)))
    {
      HOST_WIDE_INT offset;
      addr.symbol = build_fold_addr_expr
		      (get_addr_base_and_unit_offset
		         (TREE_OPERAND (addr.symbol, 0), &offset));
      addr.offset = int_const_binop (PLUS_EXPR,
				     addr.offset, size_int (offset));
      changed = true;
    }

The transformations are exactly the same in maybe_canonicalize_mem_ref_addr.

-- 
Eric Botcazou