From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4439 invoked by alias); 13 May 2003 23:28:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4432 invoked from network); 13 May 2003 23:28:18 -0000 Received: from unknown (HELO mail.goquest.com) (12.18.108.6) by sources.redhat.com with SMTP; 13 May 2003 23:28:18 -0000 Received: (qmail 12089 invoked by uid 0); 13 May 2003 23:28:09 -0000 Received: from mszick@goquest.com by mail.goquest.com by uid 502 with qmail-scanner-1.15 (spamassassin: 2.31. Clear:. Processed in 0.87793 secs); 13 May 2003 23:28:09 -0000 Received: from unknown (HELO wolf686) (66.90.213.30) by mail.goquest.com with SMTP; 13 May 2003 23:28:08 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Michael S. Zick To: Geoff Keating , kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Subject: Re: [tree-ssa] Out of SSA status and issues Date: Tue, 13 May 2003 23:28:00 -0000 Cc: gcc@gcc.gnu.org References: <10305131528.AA14941@vlsi1.ultra.nyu.edu> In-Reply-To: MIME-Version: 1.0 Message-Id: <03051318205600.00935@wolf686> Content-Transfer-Encoding: 8bit X-SW-Source: 2003-05/txt/msg01376.txt.bz2 On Tuesday 13 May 2003 01:50 pm, Geoff Keating wrote: > kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes: > > Consider instead that '*p' is just the name given a register's > > contents. Neither 'i' nor '9' are processor internal. Both are > > external to the cpu. The memory reference for 'i' is source code > > implicit, the memory reference for '*p' is source code explicit. > > > > True, but given caching effects, it's hard to see how *p could be less > > expensive than 'i'. > > Given the code > > i = *p; > // operations that don't use 'i' or change '*p' > foo(i); > > and this is the only use of 'i', surely this is always as fast or faster > than > > foo(*p); > > due to reducing register pressure. I think this sub-thread has developed a split viewpoint. I (and I think RK) was talking about optimization at the hardware independent level. The above seems to be in the area of hardware dependent optimizations. Translation: You folks have lost me on this one, I'll go back to lurking. Mike