From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9162 invoked by alias); 13 Apr 2011 11:13:32 -0000 Received: (qmail 9144 invoked by uid 22791); 13 Apr 2011 11:13:31 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Apr 2011 11:13:23 +0000 Received: by wye20 with SMTP id 20so460688wye.20 for ; Wed, 13 Apr 2011 04:13:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.37.197 with SMTP id y5mr7826929wbd.4.1302693201689; Wed, 13 Apr 2011 04:13:21 -0700 (PDT) Received: by 10.227.0.140 with HTTP; Wed, 13 Apr 2011 04:13:21 -0700 (PDT) In-Reply-To: References: <20110409100809.BF9CD3BE18@mailhost.lps.ens.fr> <20110412063517.2094B3BE18@mailhost.lps.ens.fr> Date: Wed, 13 Apr 2011 11:13:00 -0000 Message-ID: Subject: Re: Implement stack arrays even for unknown sizes From: Richard Guenther To: Paul Richard Thomas Cc: Dominique Dhumieres , matz@suse.de, gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2011-04/txt/msg00975.txt.bz2 On Wed, Apr 13, 2011 at 12:38 PM, Richard Guenther wrote: > On Wed, Apr 13, 2011 at 11:42 AM, Paul Richard Thomas > wrote: >> Dear Dominique, >> >>> 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). >> >> I saw a speed-up of similar order on FC9/x86_64. >> >> I strongly doubt that it is anything to do with the automatic array - >> if it is there is an error somewhere, since none of the references to >> trisolve need copy-in/copy-out. >> >>> >>> Note also that -fstack-arrays prevents some optimizations on >>> fatigue: 4.7->7s. This may be related to pr45810. >> >> Has PR45810 converged now? =A0If I have understood properly, a patch has >> been devised that cures the problem and does not cause slow-downs >> anywhere else? > > VLAs and malloc based arrays may behave differently with respect to alias > analysis (I'd have to look at some examples). =A0All effects other than m= alloc > overhead I would attribute to that. =A0That said, the general idea of the= patch > is sound and I see nothing wrong with it. =A0Both performance improvements > and regressions are worth looking at - they hint at possible improvements > in the middle-end parts of the compiler. I have opened PR48590 for at least one issue that I see. It has a very simple patch which you might want to try ... Richard.