From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3903 invoked by alias); 17 Jan 2004 13:20:19 -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 3895 invoked from network); 17 Jan 2004 13:20:19 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 17 Jan 2004 13:20:19 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA17110; Sat, 17 Jan 04 08:22:30 EST Date: Sat, 17 Jan 2004 13:20:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10401171322.AA17110@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/msg01043.txt.bz2 Tree SSA has always been very conventional. If I had wanted to do research, I would have started with my Concurrent SSA work. What I meant is that there were significant details, such as the ordering of lowering and optimizations (which optimizations should be done at which level) and issues such as the replacability of the RTL optimizers, that could not be known at the start of the project and that a large part of the project is not implementing such decisions but figuring out what they should be using an experimental approach. Also, there is usually significant difference between textbooks and real life so that trying to implement algorithms from a text into a real compiler can itself be more in the research than straightforward development arena.