From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24277 invoked by alias); 17 Jan 2004 02:28:26 -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 24270 invoked from network); 17 Jan 2004 02:28:25 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 17 Jan 2004 02:28:25 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA15232; Fri, 16 Jan 04 21:30:35 EST Date: Sat, 17 Jan 2004 02:28:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10401170230.AA15232@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/msg00998.txt.bz2 First and foremost is the obvious question of whether people think that the whole infrastructure is worth adding to GCC at all. From what we've discussed in the past few months, the consensus seems to be that it is. But I think it's important to find out if folks think otherwise. If we decide to add SSA for 3.5, then we need to determine exactly how we are going to go about it. My view is that I don't see this as something we can schedule (or even decide) in advance. As I said, I see the nature of the tree-ssa project as research rather than development. Nobody seemed to understand what I meant before, so let me clarify because it's part of my answer to how I view the above issues. In conventional software development (say for a game, avionics, or a linker), you have a specification and well-defined process for taking that specification and turning it into code. You have a quite good idea when you start how things are going to go and there are simple metrics for seeing how far you are in the process. In contrast, in a research project, what you start with is more a goal than a specification. You usually have an idea of how you're going about achieving that goal, but the bulk of the project is in fleshing out the details of how to achieve the goal rather than a straightforward programming project. When you start the project, you don't know in advance how things will go in detail or even if you'll be able to achieve the goal. There's usually no simple way of seeing how far you've gotten in the project because of the lack of a good metric: a long time may go by with no progress towards that goal or there might be a "eureka moment" when great progress is made suddenly. So I don't think we can or should ever answer in advance the question of when (or even if) the tree-ssa branch will be ready, but instead work on defining what criteria we'll use for making that determination. In my mind, part of that criteria would be the transition of the work from research to more conventional development, which means that it has passed the experimental stages where people are seeing what does and doesn't work and what works best. But most important in my mind is having the work meet it's goal. So the question then becomes what *is* that goal. Obviously, it's up to the people working on the project to clearly state what they see as the goal and perhaps provide metrics to see if it's being met, but roughly speaking I see the goal as making major improvements in optimization by setting up an infrastructure for doing optimizations at a high level. I do *not* see the setting up of that infrastructure as itself a useful benchmark: it needs to be shown that it actually *helps*. The issue of whether or not the RTL optimizers can be eliminated or simplified has been discussed a lot. One argument would be that we should be able to answer those questions before considering tree-ssa to be "operational", but I'm not sure how strong an argument that is. >From a performance point of view, if all we do is *add* more optimizers rather than replace some, the burden on those optimizers is higher since they will increase compilation time. On the other hand, doing more optimization earlier will speed up the RTL optimizers by giving them less to work with, so the strength of that concern is yet to be demonstrated. My feeling is that "success" would be in showing at least one class of code where we see very significantly better code (at least a factor of two) and we see significant (around 10-20%) performance improvement in a larger class of test cases. If we leave the RTL optimizers in place, then we should *always* be producing better code than without tree-ssa: any situation where we don't strikes me as demonstrating something fundamental that needs more work; if we replace some RTL optimizers, then I can see relaxing this standard if we see our way to fixing those performance regressions without major redesign. I don't see compilation performace as being a major driver here unless it's a major degradation. I understand that the longer we keep the separate branch the more maintenance cost we have, but the opposite error would be far worse: if it turns out that the tree-ssa approach is not achieving its goal and we decide to significantly postpone it (or even that it's not viable), backing it out in the presence of lots of other unrelated work being put into the tree is a *very* difficult prospect. So I'd argue for a very conservative criteria for merging it into the mainline.