From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-289365-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9889 invoked by alias); 13 Apr 2011 09:42:40 -0000
Received: (qmail 9870 invoked by uid 22791); 13 Apr 2011 09:42:39 -0000
X-SWARE-Spam-Status: No, hits=-2.2 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-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Apr 2011 09:42:28 +0000
Received: by bwz5 with SMTP id 5so512893bwz.20        for <multiple recipients>; Wed, 13 Apr 2011 02:42:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.126.152 with SMTP id c24mr6806244bks.4.1302687746855; Wed, 13 Apr 2011 02:42:26 -0700 (PDT)
Received: by 10.204.120.201 with HTTP; Wed, 13 Apr 2011 02:42:26 -0700 (PDT)
In-Reply-To: <20110412063517.2094B3BE18@mailhost.lps.ens.fr>
References: <20110409100809.BF9CD3BE18@mailhost.lps.ens.fr>	<BANLkTikwa8es+FxG2ThwWMo4MFGWVeddvg@mail.gmail.com>	<Pine.LNX.4.64.1104111800010.1989@wotan.suse.de>	<BANLkTi=jh8pGdaKLMFhJyEEU+_bnJ1VusQ@mail.gmail.com>	<20110412063517.2094B3BE18@mailhost.lps.ens.fr>
Date: Wed, 13 Apr 2011 09:42:00 -0000
Message-ID: <BANLkTikXktcLnXGkkJwpCigL-ti0NZYEdA@mail.gmail.com>
Subject: Re: Implement stack arrays even for unknown sizes
From: Paul Richard Thomas <paul.richard.thomas@gmail.com>
To: Dominique Dhumieres <dominiq@lps.ens.fr>
Cc: matz@suse.de, gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org
Content-Type: text/plain; charset=ISO-8859-1
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-04/txt/msg00969.txt.bz2

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?  If I have understood properly, a patch has
been devised that cures the problem and does not cause slow-downs
anywhere else?

Cheers

Paul