From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4681 invoked by alias); 22 Jun 2004 20:27:27 -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 4671 invoked from network); 22 Jun 2004 20:27:26 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 22 Jun 2004 20:27:26 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA10260; Tue, 22 Jun 04 16:28:58 EDT Date: Tue, 22 Jun 2004 21:10:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10406222028.AA10260@vlsi1.ultra.nyu.edu> To: mark@codesourcery.com Subject: Re: Patch to allow Ada to work with tree-ssa Cc: gcc-patches@gcc.gnu.org X-SW-Source: 2004-06/txt/msg01794.txt.bz2 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. Also, I'm told that over on IRC, the Fortran folks have ideas about what to do with some of the new fields. I think the memory cost argument in GIMPLE is very weak: only a very tiny fraction of GIMPLE nodes are ARRAY_REF and COMPONENT_REF. Your arguments about trees that are permanently kept around at the GENERIC level seems a far stronger argument and that's why I was thinking about having a different node for front-end use that corresponds to the shorter form.