On Sun, 15 Jan 2006, Tobias Schlüter wrote:
> Richard Guenther wrote:
> > I guess the fix for PR tree-optimization/22555 could make some difference
> > if fortran uses a lot of structures with embedded arrays. Basically this
> > enables decomposing these structures for aliasing purposes and shoul
> > ac5.8s 6.0s 24.7s 23.0s+ 37.9s
>
> Hm, so that regresses even more. Weird. I'd like to have it to
> investigate.
Sorry this was a typo, the first two lines should be:
ac5.8s 6.0s 24.7s 23.0s+4.0s
aermod 223.9s227.3s
On Mon, 16 Jan 2006, Dominique Dhumieres wrote:
> > with the patch applied it improves a little bit ;)
>
> I get for the list I have sent:
>
> snapshot 12/24 12/31 01/07 01/14 +patch
>
> ac5.8s 6.0s 24.7s 23.0s+ 37.9s
Hm, so that
> with the patch applied it improves a little bit ;)
I get for the list I have sent:
snapshot 12/24 12/31 01/07 01/14 +patch
ac5.8s 6.0s 24.7s 23.0s+ 37.9s
aermod 223.9s227.3s485.8s467.6s+ 229.6s
air
> I see that. I'm testing the following fix to address the fortran
> regressions. The observation is that the fortran FE uses structures
> to pass (lots of) arguments to I/O functions, and uses array descriptors
> for passing arrays, which are handled similarly. Now those structures
> are only _
On Mon, 16 Jan 2006, Dominique Dhumieres wrote:
> > Can you send me this file (and all the files it requires)?
>
> You can find it on:
>
> http://www.lps.ens.fr/~dominiq/polyhedron/channel.f90
Ok, without the patch, compile-time is (f951 compiled with checking
enabled and -g):
[EMAIL PROTECTE
On Sun, 15 Jan 2006, Daniel Berlin wrote:
> On Sun, 2006-01-15 at 18:35 -0500, Daniel Berlin wrote:
> > On Mon, 2006-01-16 at 00:24 +0100, Richard Guenther wrote:
> > > On Sun, 15 Jan 2006, Daniel Berlin wrote:
> > > >
> > > > Again, this is why i was not convinced that array aliasing by
> > > >
On Sun, 2006-01-15 at 18:35 -0500, Daniel Berlin wrote:
> On Mon, 2006-01-16 at 00:24 +0100, Richard Guenther wrote:
> > On Sun, 15 Jan 2006, Daniel Berlin wrote:
> >
> > > On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> > > > Richard Guenther wrote:
> > > > > I guess the fix for PR tr
On Mon, 2006-01-16 at 00:24 +0100, Richard Guenther wrote:
> On Sun, 15 Jan 2006, Daniel Berlin wrote:
>
> > On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> > > Richard Guenther wrote:
> > > > I guess the fix for PR tree-optimization/22555 could make some
> > > > difference
> > > > if
On Sun, 15 Jan 2006, Daniel Berlin wrote:
> On Sun, 2006-01-15 at 21:49 +0100, Richard Guenther wrote:
> >
> > I guess the fix for PR tree-optimization/22555 could make some difference
> > if fortran uses a lot of structures with embedded arrays. Basically this
> > enables decomposing these stru
On Sun, 15 Jan 2006, Daniel Berlin wrote:
> On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> > Richard Guenther wrote:
> > > I guess the fix for PR tree-optimization/22555 could make some difference
> > > if fortran uses a lot of structures with embedded arrays. Basically this
> > > en
On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> Richard Guenther wrote:
> > I guess the fix for PR tree-optimization/22555 could make some difference
> > if fortran uses a lot of structures with embedded arrays. Basically this
> > enables decomposing these structures for aliasing purpo
On Sun, 2006-01-15 at 21:49 +0100, Richard Guenther wrote:
> On 1/15/06, Tobias Schlüter <[EMAIL PROTECTED]> wrote:
> >
> > In looking at compiles times, I missed looking at memory usage:
> >
> > Dominique Dhumieres wrote:
> > > On an AMD, the 20060105 build gives
> > >
> > > tree SSA rewrite
Richard Guenther wrote:
> I guess the fix for PR tree-optimization/22555 could make some difference
> if fortran uses a lot of structures with embedded arrays. Basically this
> enables decomposing these structures for aliasing purposes and should
> generate better code.
It is perhaps noteworthy t
> You can also try -fno-tree-salias and see if this helps compile time.
On my G5 I get:
[karma] lin/source% time gfortran -ftime-report -fno-tree-salias -O3
-ffast-math -funroll-loops induct.f90
Execution times (seconds)
garbage collection: 0.51 ( 2%) usr 0.05 ( 2%) sys 0.56 ( 2%) wa
On 1/15/06, Tobias Schlüter <[EMAIL PROTECTED]> wrote:
>
> In looking at compiles times, I missed looking at memory usage:
>
> Dominique Dhumieres wrote:
> > On an AMD, the 20060105 build gives
> >
> > tree SSA rewrite : 0.45 ( 2%) usr 0.02 ( 5%) sys 0.36 ( 2%)
> > wall 35265 kB (27%
In looking at compiles times, I missed looking at memory usage:
Dominique Dhumieres wrote:
> On an AMD, the 20060105 build gives
>
> tree SSA rewrite : 0.45 ( 2%) usr 0.02 ( 5%) sys 0.36 ( 2%) wall
> 35265 kB (27%) ggc
> tree SSA incremental : 0.71 ( 4%) usr 0.02 ( 5%) sys
Dominique Dhumieres wrote:
> On an AMD, the 20060105 build gives
> tree SSA verifier : 9.55 (50%) usr 0.09 (23%) sys 9.62 (48%) wall
> 19 kB ( 0%) ggc
> tree STMT verifier: 1.56 ( 8%) usr 0.00 ( 0%) sys 1.61 ( 8%) wall
> 0 kB ( 0%) ggc
> TOTAL : 1
On an AMD, the 20060105 build gives
[scala] gfortran/2006> time irun/bin/gfortran -ftime-report -O3 -ffast-math
-funroll-loops induct.f90
Execution times (seconds)
garbage collection: 0.39 ( 2%) usr 0.01 ( 2%) sys 0.40 ( 2%) wall
0 kB ( 0%) ggc
callgraph construction: 0.09 (
> Are you building with --enable-checking (the default)?
On AMD I am using the François-Xavier's builds. On my G5 I use a patched
version of the Fink's info file, the answer is probably in
ConfigureParams: --prefix=%p/lib/gcc4
--enable-languages=c,c++,fortran,objc,java --infodir='${prefix}/share
[ Added gcc@gcc.gnu.org to the CC list and included Dominique's mail in full, as
the problem might well be in the common code. ]
Quoting Dominique Dhumieres <[EMAIL PROTECTED]>:
> I have the following timing for the compilation of the polyhedron tests
> on a 1.8Ghz G5 with:
>
> gfortran -w -O3
21 matches
Mail list logo
