From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1893 invoked by alias); 19 Jan 2004 12:00:23 -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 1870 invoked from network); 19 Jan 2004 12:00:15 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 19 Jan 2004 12:00:15 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 44F784C0149; Mon, 19 Jan 2004 13:00:15 +0100 (CET) Date: Mon, 19 Jan 2004 12:00:00 -0000 From: Jan Hubicka To: Richard Kenner Cc: rth@redhat.com, gcc@gcc.gnu.org Subject: Re: [RFC] Contributing tree-ssa to mainline Message-ID: <20040119120015.GG31365@atrey.karlin.mff.cuni.cz> References: <10401191147.AA27388@vlsi1.ultra.nyu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10401191147.AA27388@vlsi1.ultra.nyu.edu> User-Agent: Mutt/1.5.4i X-SW-Source: 2004-01/txt/msg01258.txt.bz2 > So we've missed the required factor of 2 on this test case by 0.8%. > Since that seems likely to be in the relm of measurement error, I > think that should qualify. > > I agree. > > With a bit more work unwravelling C++ front-end obfuscation, I would > expect the 10-20% to be visible on just about any object abstraction > test case. Particularly for any object that has more than one field, > and thus can't benefit from rtl addressof. That seems like it should > be a large enough class to qualify. > > Likewise. > > However, it would be good to see cases of both of the above for C as well as > C++: if the gain is just C++, one could argue that the most appropriate place > for such code is in the C++ front end. (There are Ada-specific optimizations > in the Ada front end, for example.) While it is possible to find/construct C testcases with large abstraction penalties, this is not as common as for C++ or other more modern languages. 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. I don't think re-doing optimizations in each frontend is good design decision. 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. The optimizations tree-SSA implement right now are just essentials to get more work in this area done. Honza > > The tree-ssa infrastructure is supposed to benefit *all* languages. If > benefits can be shown in C, they will clearly apply to all languages. But > that's not true for C++.