From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26065 invoked by alias); 20 Apr 2011 11:22:33 -0000 Received: (qmail 26054 invoked by uid 22791); 20 Apr 2011 11:22:32 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Apr 2011 11:22:19 +0000 From: "jb at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/48636] Enable more inlining with -O2 and higher X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jb at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 20 Apr 2011 11:22:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg02135.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 Janne Blomqvist changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jb at gcc dot gnu.org --- Comment #6 from Janne Blomqvist 2011-04-20 11:21:15 UTC --- Note that some of these issues might change with the new array descriptor that we must introduce at some point (the hope is that it'll get in for 4.7, but it remains to be seen if there is enough time). See http://gcc.gnu.org/wiki/ArrayDescriptorUpdate For instance (comments inline): (In reply to comment #4) > (In reply to comment #3) > > > The second item is interesting - it would be cool if backend was able to work > > out that the code is supposed to simplify after inlining. Either by itself or > > by frontend hint. > > Can you provide me very simple testcase for that I can look into how it looks > > like in backend? Perhaps some kind of frontend hinting would work well here. > > Here is some sample code (extreme, I admit) which profits a lot from > inlining: > > - Strides are known to be one when inlining (a common case, but you can > never be sure if the user doesn't call a(1:5:2)) Not strictly related to inlining, but in the new descriptor we'll have a field specifying whether the array is simply contiguous, so it might make sense to generate two loops for each loop over the array in the source, one for the contiguous case where it can be vectorized etc. and another loop for the general case. This might reduce the profitability of inlining. > - Expensive setting up of, and reading from the array descriptor As we're planning to use the TR 29113 descriptor as the native one, this has some implications for the procedure call interface as well. See http://gcc.gnu.org/ml/fortran/2011-03/msg00215.html This will reduce the procedure call overhead substantially, at the cost of some extra work in the caller in the case of non-default lower bounds.