From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9661 invoked by alias); 19 Jan 2004 15:05:12 -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 9644 invoked from network); 19 Jan 2004 15:05:10 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 19 Jan 2004 15:05:10 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA28782; Mon, 19 Jan 04 10:07:23 EST Date: Mon, 19 Jan 2004 15:05:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10401191507.AA28782@vlsi1.ultra.nyu.edu> To: dnovillo@redhat.com Subject: Re: [RFC] Contributing tree-ssa to mainline Cc: gcc@gcc.gnu.org X-SW-Source: 2004-01/txt/msg01290.txt.bz2 > The Ada tree has *a lot* more information than can be (or should be) > encoded into the GCC tree datastructure. Each tree node has 183 > defined flags, for example. When the time comes to generate GENERIC from Ada, then that information should be propagated down. I disagree. I see no reason to find ways of representing the sort of language-specific information that's encoded there. Sure, some of that is used for code generation information and is propagated down, but most of it is not and need not be. If you're curious about what kinds of information is in Ada tree nodes, look at ada/einfo.ads and ada/sinfo.ads. Note that the Ada tree is a parse tree augmented with semantic information, rather than a purely semantic tree like GCC. One thing that I'm vaguely concerned regarding Ada is the potential of having to create new GIMPLE trees. Having to create new GENERIC codes wouldn't be a problem, but adding GIMPLE means changing the optimizers as well. I don't know enough about GIMPLE to answer that and I think it's not practical to answer that for certain at least until "old-style" function-at-a-time is working for Ada, but as long as there's handling for the present PLACEHOLDER_EXPR and WITH_RECORD_EXPR, which seems to me to be needed at that level (though perhaps it might not be), I doubt there should be any significant issue here. I only meant checks that need dataflow information. If the elimination needs dataflow information, then the FE will be duplicating code and effort. Not necessarily. If the front end is already tracking some dataflow for its own purposes and can use that knowlege to eliminate a check, why would it be better for it *not* to do so? As I said, all over GCC we're doing "duplicate" simplifications and the fact that we do so is one of the major strengths of the compiler. There has been some discussion of perhaps lowering ARRAY_REFs. But that would be done relatively late in the tree pipeline. Good, because that's my concern: the form of the subscript information is critical to many high-level loop optimizations. If you're going to have to figure that out from an address computation, you're giving up much of the benefit of doing that optimization on trees instead of RTL>