From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23909 invoked by alias); 19 Jan 2004 12:38:41 -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 23902 invoked from network); 19 Jan 2004 12:38:40 -0000 Received: from unknown (HELO mta07-svc.ntlworld.com) (62.253.162.47) by sources.redhat.com with SMTP; 19 Jan 2004 12:38:40 -0000 Received: from cuddles.cambridge.redhat.com ([81.96.64.123]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040119123841.RSOS17928.mta07-svc.ntlworld.com@cuddles.cambridge.redhat.com> for ; Mon, 19 Jan 2004 12:38:41 +0000 Received: from redhat.com (localhost.localdomain [127.0.0.1]) by cuddles.cambridge.redhat.com (8.12.8/8.12.8) with ESMTP id i0JCcYnB024737; Mon, 19 Jan 2004 12:38:34 GMT Received: (from aph@localhost) by redhat.com (8.12.8/8.12.8/Submit) id i0JCcYJw024733; Mon, 19 Jan 2004 12:38:34 GMT From: Andrew Haley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16395.53194.540017.226340@cuddles.cambridge.redhat.com> Date: Mon, 19 Jan 2004 12:38:00 -0000 To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Cc: hubicka@ucw.cz, gcc@gcc.gnu.org Subject: Re: [RFC] Contributing tree-ssa to mainline In-Reply-To: <10401191226.AA27734@vlsi1.ultra.nyu.edu> References: <10401191226.AA27734@vlsi1.ultra.nyu.edu> X-SW-Source: 2004-01/txt/msg01269.txt.bz2 Richard Kenner writes: > > 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. I would reject this approach on the grounds of parsimony: Java needs to generate (and remove) these checks as well, and if we do optimization in the front end we'll have multiple optimizers essentially doing the same thing, probably using the same algorithms. We'll have separate implementations of the same algorithms -- with disjoint sets of errors. On the other hand, if Ada can really do the job of its check elimination so much better than a generic optimizer, fair enough. But range check elimination using VRP is a sufficiently generic problem that many languages will benefit. And of course there are other things: escape analysis, for example. Sure, I could do that in the Java front end, but I'd rather not. Andrew.