From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3238 invoked by alias); 22 Jun 2004 21:05:33 -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 3231 invoked from network); 22 Jun 2004 21:05:32 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sourceware.org with SMTP; 22 Jun 2004 21:05:32 -0000 Received: from [192.168.1.7] (account dberlin HELO [192.168.1.7]) by dberlin.org (CommuniGate Pro SMTP 4.2b6) with ESMTP-TLS id 6851257; Tue, 22 Jun 2004 17:05:31 -0400 In-Reply-To: <10406222028.AA10260@vlsi1.ultra.nyu.edu> References: <10406222028.AA10260@vlsi1.ultra.nyu.edu> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: gcc-patches@gcc.gnu.org, mark@codesourcery.com From: Daniel Berlin Subject: Re: Patch to allow Ada to work with tree-ssa Date: Tue, 22 Jun 2004 22:16:00 -0000 To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) X-SW-Source: 2004-06/txt/msg01804.txt.bz2 On Jun 22, 2004, at 4:28 PM, Richard Kenner wrote: > Since Richard Henderson and Zack seem to think it's best, why > don't you > just create new tree nodes for these variable-length cases? That > seems > to be the consensus point of view on how to solve the problem. > > Except that the authors of the optimizers haven't weighed in here yet > and they were very much against adding new nodes to GIMPLE, which is > what this would be doing. Having played with some of that code, I can > tell you that it won't be pleasant to add all the extra cases to > deal with the additional nodes. As a part who writes optimizers, as a general principle, i'm very against adding nodes to GIMPLE. However, if it's a node that is just a variable sized analogue of a node that already exists in the grammar, and retains the same basic grammar as the old node, it's not that a big a deal. IE if you allow VARIABLE_ARRAY_REF (or whatever) *only* where you currently allow array_ref, it's not that big a deal from an optimizer perspective. It's when you start making significant actual grammar changes that make GIMPLE much more complex, that the optimizers run into problems. The most painful changes in the optimizers and other walkers i've had to deal with were when we started allowing things like ADDR_EXPR's in call arguments (at one point that wasn't allowed), when we started allowing INDIRECT_REFS on both sides of the same expression (at one point that wasn't allowed), etc. In other words, things that significantly modified the shape of expressions you would see. Having a VARIABLE_ARRAY_REF (or whatever it was, i keep forgetting) exactly where you allow array_ref, doesn't change the shape of expressions you see much, if at all. --Dan