From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28780 invoked by alias); 19 Jan 2004 12:49:58 -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 28712 invoked from network); 19 Jan 2004 12:49:57 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 19 Jan 2004 12:49:57 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0JCmsl18439; Mon, 19 Jan 2004 07:48:54 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0JCmra25728; Mon, 19 Jan 2004 07:48:54 -0500 Received: from dnovillo.cipe.redhat.com (dnovillo.cipe.redhat.com [10.0.0.106]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i0JCmqXd020104; Mon, 19 Jan 2004 07:48:52 -0500 Subject: Re: [RFC] Contributing tree-ssa to mainline From: Diego Novillo To: Richard Kenner Cc: Jan Hubicka , "gcc@gcc.gnu.org" In-Reply-To: <10401191226.AA27734@vlsi1.ultra.nyu.edu> References: <10401191226.AA27734@vlsi1.ultra.nyu.edu> Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1074516514.5368.191.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 Date: Mon, 19 Jan 2004 12:49:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg01271.txt.bz2 On Mon, 2004-01-19 at 07:26, Richard Kenner wrote: > A case I know about in Ada is check elimination. Because the default for Ada > is enabling checking, it's quite important to eliminate checks that can be > proven not to fail. Theoretically, a lot this could be language-independent > optimizers by value range propagation and related optimizations. But the > front-end can do a much better job because it has information only it knows. > Such as? Full FE type information is available in GIMPLE. 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. > Moreover, by suppressing the check before generating any code for it, > compilation time is reduced. I think this is clearly the proper place for > that optimization. > If the check needs dataflow information to be eliminated, the FE had better not deal with it. > That's why I asked about this, if it's truly C++-specific: wouldn't it be > better in the C++ front end? That's why it's important to understand how > language-independent it is. > Nothing in tree-ssa is language specific. There's quite a bit of design documentation available in the project's page. The presentations last year at GCC Summit should be useful. And you can always check the branch out and check for yourself. > However, I'm not as willing as some people to simply accept the argument that > this will lead to "considerable benefits" due to what are essentially > theoretical arguments. I'm a pragmatist: I'd like to *see* those benefits. > I have an idea. Why don't you provide test cases in the form of bugzilla reports? We have some reports that point out specific performance problems that we have been addressing all along. Merge or no merge, those test cases will help fix the more noticeable problems. Particularly if they are representative samples of popular constructs. Even more, we could vote on a set of specific bugzilla PRs as merge or post-merge criteria. I am going to be creating some PRs for the specific issues that were raised in the thread regarding documentation, for instance. > One specific concern I have is the issue of when to lower. I admit I haven't > been following the project closely, so please feel free to correct me if I'm > wrong, but my sense is that lowering of the level of the tree is now being > done very *early*. That seems to me to be potentially incompatible with the > argument that doing such things as loop optimization at the tree level can > use higher-level information: are we preserving such information? > 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? > As I said, perhaps I misunderstand what's going on, but if I don't, I think > the above is the critical issue and the design space of when to lower needs > to be resolved by actually demonstrating some of the hoped-for high-level > optimizations. I would not be comfortable merging tree-ssa until that level > of design issues have been settled. > I really think you ought to take a look at the branch before we can address your concerns. You are being woefully vague. Diego.