This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Revamp fortran array types
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: Michael Matz <matz at suse dot de>, gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, Dominique Dhumieres <dominiq at lps dot ens dot fr>
- Date: Tue, 18 Aug 2009 11:07:30 +0200
- Subject: Re: RFA: Revamp fortran array types
- References: <20090817125436.D85C93BE85@mailhost.lps.ens.fr> <Pine.LNX.4.64.0908171537380.29566@wotan.suse.de> <Pine.LNX.4.64.0908171814190.29566@wotan.suse.de> <4A89CCB8.1030807@net-b.de>
On Mon, Aug 17, 2009 at 11:33 PM, Tobias Burnus<burnus@net-b.de> wrote:
> Michael,
>
> Michael Matz wrote:
>> Like so. The main difference to the last patch is that we also have to
>> make pointer (and proc_pointer) attributed things not using restrict
>> qualified pointer/references/types. ?The rest is fixing fallout of these
>> changes plus fixing the above mentioned errors.
>>
>> This patch gives clean fortran test results on x86_64-linux, full regstrap
>> currently running.
>> So, this time it is a request for approval under the assumption that
>> regstrapping works.
>>
>
> The Fortran part of the patch is OK - for tree-ssa-structalias.c you
> need to find someone else.
The middle-end changes are ok.
> (Regardings "nontarget": To make Toon happy, one could consider to
> rename it to, e.g., "restricted".)
>
> I have run the Polyhedron test suite with promising results: I see
> almost 3% speedup - and not all of it can be noise.
>
> Largest progress was seen for "induct" where the run time decreased from
> 37.19s to 28.39s (24% faster) which not only beats the Intel, Sun,
> Open64 and NAG compiler (which were already 4% to 18% slower than the
> unpatched gfortran), but also the results of an old Pathscale 3beta
> which needed 30.16s.
>
> Unfortunately, two tests took longer: "capacita" increased from 83.02 to
> 87.13 (5% slower) and protein (63.91 -> 65.21) is 2% slower.
This might be due to the middle-end bugfix (you can try just applying
that piece and see if that reproduces the slowdown). What is missing
is middle-end support for unknown shaped array arguments
(see http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01533.html,
maybe that patch fixes the regression - though it likely doesn't apply
ontop of michas patch).
Richard.
> Tobias
>