From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31409 invoked by alias); 19 Jul 2010 18:21:25 -0000 Received: (qmail 31395 invoked by uid 22791); 19 Jul 2010 18:21:24 -0000 X-SWARE-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Jul 2010 18:21:19 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6JILDp9012185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Jul 2010 14:21:13 -0400 Received: from anchor.twiddle.home ([10.3.113.74]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6JILBSj020272; Mon, 19 Jul 2010 14:21:11 -0400 Message-ID: <4C449796.5000802@redhat.com> Date: Mon, 19 Jul 2010 18:21:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jerry DeLisle CC: Daniel Kraft , Thomas Koenig , fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [patch, fortran] PR 40628, front-end optimization pass References: <1279391905.4628.7.camel@linux-fd1f.site> <4C42BF4D.20400@domob.eu> <4C43D07A.9050500@verizon.net> In-Reply-To: <4C43D07A.9050500@verizon.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg01521.txt.bz2 On 07/18/2010 09:11 PM, Jerry DeLisle wrote: > On 07/18/2010 01:46 AM, Daniel Kraft wrote: >> Hi Thomas, >> >> Thomas Koenig wrote: >>> finally, here's the first attempt at a front-end optimization pass. >>> Right now, it fixes PR 40626 and optimizes comparisons between variables >>> (which only really is relevant for character comparisons). Many more >>> things could (and should) be added over time. >> > > I like the idea as long as we do not duplicate middle-end work. If we > can improve performance without sacrificing maintainability and > correctness, I am all for it. The idea of general passes is good. > Rather than optimize.c maybe call it early_pass.c or whatever. > > Do any middle-end maintainers have an opinion on adding this optimization? As long as the optimizations here are fortran-specific (e.g. high-level matrix, string, or loop pre-expansion optimizations), I don't mind. r~