public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Bin Cheng <Bin.Cheng@arm.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: nd <nd@arm.com>
Subject: Re: [PATCH GCC][04/06]Add copying interface for dependence_info
Date: Fri, 25 Aug 2017 04:25:00 -0000	[thread overview]
Message-ID: <90e112ed-3f2a-c8dc-cff7-ae8103c0db86@redhat.com> (raw)
In-Reply-To: <DB5PR0801MB274208DAE629CBB361C7A591E78C0@DB5PR0801MB2742.eurprd08.prod.outlook.com>

On 08/14/2017 03:19 AM, Bin Cheng wrote:
> HI,
> This patch adds copying interface for dependence_info.  The methodology
> is we don't copy such information by default, and this interface should
> be called explicitly when it is safe and necessary to do so.  Just like
> this patch uses the interface in ivopts.
> Bootstrap and test in series.  Is it OK?
> 
> Thanks,
> bin
> 2017-08-10  Bin Cheng  <bin.cheng@arm.com>
> 
> 	* tree-ssa-address.c (copy_dependence_info): New function.
> 	* tree-ssa-address.h (copy_dependence_info): New declaration.
> 	* tree-ssa-loop-ivopts.c (rewrite_use_address): Call above func.
So do we have any structure sharing assumptions on the alias structures?
 ie, are we setting up the possibility that these objects will be shared
and that someone will modify them in a way that works in one context,
but not another?

If they're readonly after creation, then obviously this isn't a concern.

I wouldn't consider this an object or an ACK for the patch at this
point. More a design question we need to answer.

Jeff

  reply	other threads:[~2017-08-24 22:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-14  9:32 Bin Cheng
2017-08-25  4:25 ` Jeff Law [this message]
2017-08-25 11:14   ` Richard Biener

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=90e112ed-3f2a-c8dc-cff7-ae8103c0db86@redhat.com \
    --to=law@redhat.com \
    --cc=Bin.Cheng@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nd@arm.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).