From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9313 invoked by alias); 10 Dec 2007 17:02:11 -0000 Received: (qmail 9278 invoked by uid 22791); 10 Dec 2007 17:02:05 -0000 X-Spam-Check-By: sourceware.org Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.198.201) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Dec 2007 17:01:57 +0000 Received: from ispserv.ispras.ru (ispserv.ispras.ru [83.149.198.72]) by smtp.ispras.ru (Postfix) with ESMTP id DD2485D4143; Mon, 10 Dec 2007 20:12:21 +0300 (MSK) Received: from endeed2.ispras.ru (endeed2.ispras.ru [83.149.198.245]) by ispserv.ispras.ru (8.12.8/8.12.8) with ESMTP id lBAH1oTx008041; Mon, 10 Dec 2007 20:01:51 +0300 Date: Mon, 10 Dec 2007 17:16:00 -0000 To: "Daniel Berlin" Subject: Re: [RFC/RFT] Improving SMS by data dependence export From: "Alexander Monakov" Cc: "gcc.gcc.gnu.org" , "Revital1 Eres" , "Andrey Belevantsev" , "Ayal Zaks" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <4aca3dc20712071249u2cc5242age0fc1a3b62d6c00@mail.gmail.com> Content-Transfer-Encoding: Quoted-Printable Message-ID: In-Reply-To: <4aca3dc20712071249u2cc5242age0fc1a3b62d6c00@mail.gmail.com> User-Agent: Opera Mail/9.24 (Linux) 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/msg00319.txt.bz2 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=20=20 > (which > + would have different indices in SSA form, like a[i_1] and a[i_2],= =20=20 > but > + were later rewritten to same a[i]). */ > + && (p->orig_expr =3D=3D 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=20=20 indeed. The purpose of making handling of MEM_ORIG_EXPRs (introduced by=20= =20 this patch) different from MEM_EXPRs in ignoring operand_equal'ity of=20=20 trees pointed to by this field is enforcing that MEMs corresponding to=20=20 accesses to objects of the same type but with (potentially) different=20=20 addresses will not share MEM_ATTRS structure. So, if both are VAR_DECLs,= =20=20 returning true is OK, since different accesses still correspond to the=20=20 same memory location. The first sentence also implies that potentially different accesses could= =20=20 be merged here, but I don't see any reason for that except for NULL=20=20 MEM_ORIG_EXPRs. Could you please elaborate on this? > 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,= =20=20 which in some cases allows better disambiguation, why should I enforce=20=20 MEM_EXPR's rules on it? If I, similarly to MEM_EXPRs, apply=20=20 operand_equal_p also to MEM_ORIG_EXPRs, this will give me incorrect=20=20 results, since different MEMs will be annotated with same MEM_ORIG_EXPR,=20= =20 which is wrong, since the latter is flow-sensitive, and operand_equal_p=20= =20 will discard that (since trees will look the same after out-of-SSA). I do= =20=20 not see a better way to provide flow-sensitive annotations for MEMs. > DDR will mark them as data refs Come again? :) Thanks. -- Alexander Monakov