From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14798 invoked by alias); 19 Jan 2004 12:24:03 -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 14746 invoked from network); 19 Jan 2004 12:24:01 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 19 Jan 2004 12:24:01 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA27734; Mon, 19 Jan 04 07:26:14 EST Date: Mon, 19 Jan 2004 12:24:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10401191226.AA27734@vlsi1.ultra.nyu.edu> To: hubicka@ucw.cz Subject: Re: [RFC] Contributing tree-ssa to mainline Cc: gcc@gcc.gnu.org X-SW-Source: 2004-01/txt/msg01265.txt.bz2 Even if tree-SSA didn't made important speedups for common C programs I think this is not problem as long as it is not making C worse and do make C++ and Java better. Can similar cases as those shown for C++ be constructed and measured for Java? I don't think re-doing optimizations in each frontend is good design decision. I agree that *re-doing* is not a good design decision, but it's quite often the case that *doing* optimizations in a front-end is the appropriate design decision. 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. 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. 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. In longer run, with the new loop optimizer or profile driven inlining, we will see considerable benefits for C programs too, but I would prefer this to not be blocker for tree-SSA acceptance. I would. The optimizations tree-SSA implement right now are just essentials to get more work in this area done. I'm not suggesting not getting any work done: there's active development work being on it now and I'm all in favor of it being continued. 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'd like to see examples of some of these optimizations that provide "significant" (leaving that undefined for the moment) benefits for all languages before accepting that the tree-ssa structure is as beneficial as its proponents argue. 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? 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.