From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17864 invoked by alias); 12 Apr 2011 06:35:25 -0000 Received: (qmail 17846 invoked by uid 22791); 12 Apr 2011 06:35:24 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nef2.ens.fr (HELO nef2.ens.fr) (129.199.96.40) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 06:35:19 +0000 Received: from mailhost.lps.ens.fr (tournesol.lps.ens.fr [129.199.120.1]) by nef2.ens.fr (8.13.6/1.01.28121999) with ESMTP id p3C6ZHei021547 ; Tue, 12 Apr 2011 08:35:17 +0200 (CEST) X-Envelope-To: gcc-patches@gcc.gnu.org Received: from localhost (localhost [127.0.0.1]) by mailhost.lps.ens.fr (Postfix) with ESMTP id 33A9C3BE17; Tue, 12 Apr 2011 08:35:17 +0200 (CEST) Received: from mailhost.lps.ens.fr ([127.0.0.1]) by localhost (tournesol.lps.ens.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3X--6uvV087; Tue, 12 Apr 2011 08:35:17 +0200 (CEST) Received: by mailhost.lps.ens.fr (Postfix, from userid 8513) id 2094B3BE18; Tue, 12 Apr 2011 08:35:17 +0200 (CEST) Date: Tue, 12 Apr 2011 06:35:00 -0000 To: paul.richard.thomas@gmail.com, matz@suse.de Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, dominiq@lps.ens.fr Subject: Re: Implement stack arrays even for unknown sizes References: <20110409100809.BF9CD3BE18@mailhost.lps.ens.fr> In-Reply-To: User-Agent: Heirloom mailx 12.4pre 6/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20110412063517.2094B3BE18@mailhost.lps.ens.fr> From: dominiq@lps.ens.fr (Dominique Dhumieres) 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: 2011-04/txt/msg00834.txt.bz2 > The resulting speed up for nf.f90 is rather remarkable. What specific > feature of the fortran leads to a 30=>15s ? I think it is the automatic array in the subroutine trisolve. Note that the speedup is rather 27->19s and may be darwin specific (slow malloc). Note also that -fstack-arrays prevents some optimizations on fatigue: 4.7->7s. This may be related to pr45810. Dominique