From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16621 invoked by alias); 19 Jan 2004 14:17:18 -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 16614 invoked from network); 19 Jan 2004 14:17:17 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 19 Jan 2004 14:17:17 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA28304; Mon, 19 Jan 04 09:19:30 EST Date: Mon, 19 Jan 2004 14:17:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10401191419.AA28304@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/msg01284.txt.bz2 Full FE type information is available in GIMPLE. 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. VRP is one of the passes I'm planning to work on in the immediate future. The goal is to eliminate mudflap checks, though it should help Java and Ada as well. Sure it will. There will indeed be checks that can't be supressed statically that can with VRP, but the opposite is also true. If the check needs dataflow information to be eliminated, the FE had better not deal with it. I don't follow. Why "had better not"? For every check that the FE can eliminate, there's that much less work for the rest of the compiler to do. A check is merely a flag on an operation node in the Ada tree. If it can be suppressed at that level, we avoid ever generating *any* tree nodes for the check. That seems a good thing to me: why do you see it as something that "had better not" happen? Nothing in tree-ssa is language specific. I didn't say there was. What I said was that it looked like the *example* was relying on language-specific features. It turned out I misread the message, but my concern was in the example only. I have an idea. Why don't you provide test cases in the form of bugzilla reports? Because I don't exactly what the optimizations goals are, nor am I particularly concerned about the details. Even more, we could vote on a set of specific bugzilla PRs as merge or post-merge criteria. I think that would be unfair to the tree-ssa project. I don't see the merge criteria as the GCC project giving some test cases to the tree-ssa folks and saying "show me that you can improve these cases". I think that's much too hard a standard to meet. Instead, I think the tree-ssa folks should implement several new optimizers that rely on higher-level information to show the utility of the new infrastucture and should produce test cases (preferably in C) that show the success of those optimizers. I think that's both an easier and more relevant standard. What information? Type? Yes, we preserve full user-level type and variable information. Control flow? We have a flow graph. Data flow? We have an SSA web. What specific information are you concerned about? Information regarding the form of array and component accesses. In a discussion about RTL loop code, I thought I saw that the addressing computation would be done early on and the COMPONENT_REFs and ARRAY_REFs would be removed.