From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7863 invoked by alias); 17 Jan 2004 03:21:57 -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 7856 invoked from network); 17 Jan 2004 03:21:57 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 17 Jan 2004 03:21:57 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA15949; Fri, 16 Jan 04 22:24:08 EST Date: Sat, 17 Jan 2004 03:21:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10401170324.AA15949@vlsi1.ultra.nyu.edu> To: s.bosscher@student.tudelft.nl Subject: Re: [RFC] Contributing tree-ssa to mainline Cc: gcc@gcc.gnu.org X-SW-Source: 2004-01/txt/msg01014.txt.bz2 Expecting tree-ssa to produce code better by a factor of two is simply unreasonable. In general, of course. But if it is really allowing new classes of optimizations to be performed (which was the argument to justify the new infrastructure), it should be possible to construct test cases that show that sort of performance improvement (factors of two or more). Remember that the last time we had the discussion of the timing of tree-ssa, people claimed it was "essential" for 3.5 since there was a tremendous improvement on some C++ cases. So let's see those cases.