From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31801 invoked by alias); 10 Dec 2007 17:31:10 -0000 Received: (qmail 31790 invoked by uid 22791); 10 Dec 2007 17:31:10 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0506.google.com (HELO nz-out-0506.google.com) (64.233.162.234) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Dec 2007 17:31:02 +0000 Received: by nz-out-0506.google.com with SMTP id i11so707827nzh for ; Mon, 10 Dec 2007 09:30:57 -0800 (PST) Received: by 10.142.252.11 with SMTP id z11mr3129670wfh.1197307856665; Mon, 10 Dec 2007 09:30:56 -0800 (PST) Received: by 10.142.217.1 with HTTP; Mon, 10 Dec 2007 09:30:56 -0800 (PST) Message-ID: <4aca3dc20712100930m144f2e45o7f8af0d21b1bbc05@mail.gmail.com> Date: Mon, 10 Dec 2007 18:32:00 -0000 From: "Daniel Berlin" To: "Alexander Monakov" Subject: Re: [RFC/RFT] Improving SMS by data dependence export Cc: gcc.gcc.gnu.org , "Revital1 Eres" , "Andrey Belevantsev" , "Ayal Zaks" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4aca3dc20712071249u2cc5242age0fc1a3b62d6c00@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00321.txt.bz2 On 12/10/07, Alexander Monakov wrote: > Hi. Sorry for the previous empty reply. > > > also, i see > > + /* We do not use operand_equal_p for ORIG_EXPRs because we need to > > + distinguish memory references at different points of the loop > > (which > > + would have different indices in SSA form, like a[i_1] and a[i_2], > > but > > + were later rewritten to same a[i]). */ > > + && (p->orig_expr == q->orig_expr)); > > > > This doesn't do enough to distinguish memory references at different > > points of the loop, while also eliminating from consideration that > > *are* the same. > > > > What if they are regular old VAR_DECL? > > This will still return true, but they may be different accesses at > > different points in the loop. > > Sorry, I don't really follow. The comment is somewhat badly worded > indeed. The purpose of making handling of MEM_ORIG_EXPRs (introduced by > this patch) different from MEM_EXPRs in ignoring operand_equal'ity of > trees pointed to by this field is enforcing that MEMs corresponding to > accesses to objects of the same type but with (potentially) different > addresses will not share MEM_ATTRS structure. So, if both are VAR_DECLs, > returning true is OK, since different accesses still correspond to the > same memory location. Okay, then you should edit the comment to make this clear. Because it is certainly incorrect as is. > > The first sentence also implies that potentially different accesses could > be merged here, but I don't see any reason for that except for NULL > MEM_ORIG_EXPRs. Could you please elaborate on this? COMPONENT_REF of INDIRECT_REF ( IE a->c), for example, would be merged here, incorrectly (since a may not be the same memory at this point in time) but it's not clear we ever generate them as MEM_ORIG_EXPR. Relying on pointer equality of tree expressions to give you some semantic value seems a very bad idea to me. > > > In any case, this doesn't belong in mem_attrs_htab_eq, because if they > > are operand_equal_p, for purposes of memory attributes, they *are* > > equal. They may still be different accesses, which is something you > > have to discover later on. > > I don't follow this either. Since I add a new field to MEM_ATTRS struct, I misread this portion, my apologies. I thought you were changing the semantics of an existing field.