From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16747 invoked by alias); 20 Jul 2010 01:19:58 -0000 Received: (qmail 16731 invoked by uid 22791); 20 Jul 2010 01:19:57 -0000 X-SWARE-Spam-Status: No, hits=3.0 required=5.0 tests=AWL,BAYES_00,BOTNET,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from vms173003pub.verizon.net (HELO vms173003pub.verizon.net) (206.46.173.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Jul 2010 01:19:52 +0000 Received: from [192.168.1.10] ([unknown] [64.234.92.14]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5U00ABP10L2GP4@vms173003.mailsrvcs.net>; Mon, 19 Jul 2010 20:19:37 -0500 (CDT) Message-id: <4C44F9A4.1080908@verizon.net> Date: Tue, 20 Jul 2010 01:19:00 -0000 From: Jerry DeLisle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-version: 1.0 To: Thomas Koenig Cc: Daniel Kraft , 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> <1279578709.9185.9.camel@linux-fd1f.site> In-reply-to: <1279578709.9185.9.camel@linux-fd1f.site> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit 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/msg01539.txt.bz2 On 07/19/2010 03:31 PM, Thomas Koenig wrote: > Hi Jerry, >> 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. > > So, how do we proceed? > > I could set up a general pass framework. This have structs of > containing pointers to functions which handle assignments, > expressions, operators and actual arglists, one for each pass, > and a routine for walking the expressions and invoking the correct > functions. > > This would mean one file passes.c (which contains the handle_code and > handle_code_node functions), a passes.h header and a single file (e.g. > pass-optimize.c) for each pass containing the individual functions. > > This sounds doable, but will take a bit of time. > > Further comments? > > Thomas > > Why not start by just changing the filename optimize.c to passes.c and go with what you have now, then this can evolve further with time. One thing I would like to suggest is can you identify a real world application that benefits from this initial optimization pass? Proof in the pudding so to speak, but not strictly necessary. I am more curious then anything. Jerry