From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25336 invoked by alias); 19 Oct 2004 22:41:43 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 25327 invoked from network); 19 Oct 2004 22:41:42 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 19 Oct 2004 22:41:42 -0000 Received: (qmail 13547 invoked from network); 19 Oct 2004 22:41:42 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 19 Oct 2004 22:41:42 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Tue, 19 Oct 2004 15:41:41 -0700 To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Cc: gcc-patches@gcc.gnu.org Subject: Re: [patch] for PR 18040 References: <10410181423.AA03699@vlsi1.ultra.nyu.edu> From: Zack Weinberg Date: Tue, 19 Oct 2004 22:47:00 -0000 In-Reply-To: <10410181423.AA03699@vlsi1.ultra.nyu.edu> (Richard Kenner's message of "Mon, 18 Oct 04 10:23:01 EDT") Message-ID: <87acuiqqje.fsf@codesourcery.com> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-10/txt/msg01654.txt.bz2 kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes: > [First of all, let me apologize about the lack of threading. I *do* have > the sources I need to implement that, but I want to catch up on some of > the technical stuff (ACATS bugs) first.] > > Ok. Does that also address the objection you raised to the > pointer-punning operation at the outermost level? > > The *correctness* objection, yes, but not the code quality > objection. We'd have a situation where it's impossible for the tree > optimizers to improve the code because there's no way of > representing the improvement. That's bad. The tree optimizers do better on simple operations, which is why we have GIMPLE in the first place. In fact, some people have argued that we should be breaking up _all_ chains of dereference operations so that the optimizers can see better. > The goal is not to be able to represent as one statement every > operation that can be encoded in one machine instruction, and it is > certainly not to be able to represent as one statement every primitive > operation of every supported language. > > No, of course not. But I thought the idea is to encode each statement as > one *expansion* operation. I do not understand this statement. zw