From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6840 invoked by alias); 18 Jul 2010 10:18:27 -0000 Received: (qmail 6826 invoked by uid 22791); 18 Jul 2010 10:18:26 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp6.netcologne.de (HELO smtp6.netcologne.de) (194.8.194.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 18 Jul 2010 10:17:52 +0000 Received: from [192.168.0.197] (xdsl-213-168-110-187.netcologne.de [213.168.110.187]) by smtp6.netcologne.de (Postfix) with ESMTP id 997DC2A05AB; Sun, 18 Jul 2010 12:17:49 +0200 (CEST) Subject: Re: [patch, fortran] PR 40628, front-end optimization pass From: Thomas Koenig To: Daniel Kraft Cc: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org In-Reply-To: <4C42BF4D.20400@domob.eu> References: <1279391905.4628.7.camel@linux-fd1f.site> <4C42BF4D.20400@domob.eu> Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 18 Jul 2010 10:18:00 -0000 Message-ID: <1279448269.5509.22.camel@linux-fd1f.site> Mime-Version: 1.0 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/msg01429.txt.bz2 Hi Daniel. > 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. > > thinking about this, I'm not really convinced that we want "front-end > optimization passes". At least for heavier optimization, at least > conceptually the middle-end should be responsible. There are things which are hard for the middle-end to do, especially character and array expressions. See, for example, PR 22572 (double occurrence of matmul not optimized). > And for smaller ones > that are Fortran-specific, we already have the "simplify" code-path. Simplify is very much geared toward constant simplification. I made some attempt at optimization, only to find I would have to modify large chunks, leading to unnecessary and error-prone changes. Also, in simplify.c, removing whole statements, adding new variables etc. is not forseen, also leading to large changes. Adding a new pass seamed cleaner. I also wanted the possibility of making the front-end optimizations > So > what do you think are appropriate use-cases for your new optimization pass? Things like PR 22572, optimizing expressions like f(x) + f(x) (and warning about cases where f(x) is non-PURE), optimizing string assignments, PR 30609, ... A lot of cases where a programmer might be tempted to write "lazy" code that is currently sub-optimally translated. > On the other hand, I like the idea of a general high-level > pass-framework. I think that this could help in implementing F2003 > features (and co), because I'm not sure the current handling during > resolution is the best and cleanest (at least not for all constructs). > I would have liked to add some construct lowering as seperate passes in > the past, so that it does not interfere with real resolution. That also makes sense. > What do you (and others) think about introducing your patch as a general > pass-framework (and probably not calling it "optimization"), which could > then both handle construct implementations as well as certain > optimization passes (if it seems reasonable to implement them that way)? We can use my pass as a starting point, certainly. Currently, my patch is run after resolution, but we could certainly set up a general pass management system. Thomas