[LLVMdev] darwin llvm-gfortran Polyhedron 2005 results
Jack Howarth
howarth at bromo.med.uc.edu
Thu Apr 8 10:18:59 PDT 2010
On Thu, Apr 08, 2010 at 08:45:48AM -0700, Bob Wilson wrote:
> [CCing Dale since this was his change, not mine]
>
> The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets confused somehow.
Bob,
Duncan suggested moving va_opt into darwin.o and changing the declaration from static to
extern in darwin-c.o. I have tried that here...
http://llvm.org/bugs/attachment.cgi?id=4652
in various forms. While the change seems to work for
a simple make, it breaks parallel builds...
http://llvm.org/bugs/show_bug.cgi?id=6778#c17
Do you have any suggestions for a change to the fortran build
to solve this? We can't link in darwin-c.o of course, but would
it make sense to have fortran declare it's own static copy of
va_opt somewhere?
Jack
>
> On Apr 8, 2010, at 6:25 AM, Jack Howarth wrote:
>
> > On Wed, Apr 07, 2010 at 09:54:36PM -0700, Chris Lattner wrote:
> >>
> >> On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote:
> >>
> >>> Building the current release 2.7 branch on x86_64-apple-darwin10
> >>> with r81455 reverted, I get the following Polyhedron 2005 benchmark
> >>> results (with no test failures)...
> >>
> >> Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested in analyzing the performance. I don't think that anyone has done *any* llvm-gfortran perf work.
> >>
> >> -Chris
> >
> > Chris,
> > How essential is r81455 to the llvm-gcc4.2-2.7 release? Can we regress it
> > out for 2.7? I've tried all of the suggestions in...
> >
> > http://llvm.org/bugs/show_bug.cgi?id=6778
> >
> > from Duncan for moving va_opt into darwin.c as an extern. While this
> > works at first glance, it destablizes the parallel make. Regressing r81455
> > doesn't appear to cause any problems.
> > Jack
> >
> >>
> >>>
> >>> ================================================================================
> >>> Date & Time : 7 Apr 2010 22:24:16
> >>> Test Name : llvm_gfortran_lin_p4
> >>> Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n
> >>> Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft
> >>> Maximum Times : 2000.0
> >>> Target Error % : 0.100
> >>> Minimum Repeats : 10
> >>> Maximum Repeats : 100
> >>>
> >>> Benchmark Compile Executable Ave Run Number Estim
> >>> Name (secs) (bytes) (secs) Repeats Err %
> >>> --------- ------- ---------- ------- ------- ------
> >>> ac 0.34 10000 12.85 10 0.0067
> >>> aermod 20.01 10000 15.42 10 0.0076
> >>> air 1.52 10000 7.50 12 0.0934
> >>> capacita 0.58 10000 45.67 10 0.0152
> >>> channel 0.41 10000 2.19 10 0.0365
> >>> doduc 2.29 10000 29.08 10 0.0140
> >>> fatigue 1.02 10000 8.83 10 0.0582
> >>> gas_dyn 0.77 10000 13.12 21 0.0909
> >>> induct 2.54 10000 24.22 10 0.0096
> >>> linpk 0.28 10000 15.67 10 0.0343
> >>> mdbx 0.79 10000 12.09 10 0.0070
> >>> nf 0.33 10000 30.10 12 0.0751
> >>> protein 1.10 10000 42.02 10 0.0100
> >>> rnflow 1.53 10000 32.00 10 0.0214
> >>> test_fpu 1.28 10000 11.73 10 0.0446
> >>> tfft 0.24 10000 2.16 13 0.0988
> >>>
> >>> Geometric Mean Execution Time = 14.07 seconds
> >>>
> >>> ================================================================================
> >>>
> >>> This compares to the last time I ran these for the release 2.5 branch...
> >>>
> >>> ================================================================================
> >>> Date & Time : 2 Feb 2009 23:57:03
> >>> Test Name : llvm_gfortran_lin_p4
> >>> Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n
> >>> Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft
> >>> Maximum Times : 2000.0
> >>> Target Error % : 0.100
> >>> Minimum Repeats : 10
> >>> Maximum Repeats : 100
> >>>
> >>> Benchmark Compile Executable Ave Run Number Estim
> >>> Name (secs) (bytes) (secs) Repeats Err %
> >>> --------- ------- ---------- ------- ------- ------
> >>> ac 0.28 10000 15.01 10 0.0805
> >>> aermod 16.03 10000 15.83 10 0.0772
> >>> air 1.62 10000 8.21 10 0.0472
> >>> capacita 0.47 10000 51.23 10 0.0261
> >>> channel 0.23 10000 3.32 10 0.0106
> >>> doduc 1.64 10000 34.17 10 0.0060
> >>> fatigue 0.70 10000 12.74 10 0.0572
> >>> gas_dyn 0.55 10000 16.07 10 0.0771
> >>> induct 1.75 10000 26.54 10 0.0017
> >>> linpk 0.22 10000 15.42 10 0.0205
> >>> mdbx 0.63 10000 14.13 12 0.0162
> >>> nf 0.26 10000 29.01 10 0.0909
> >>> protein 0.70 10000 44.89 10 0.0133
> >>> rnflow 1.09 10000 39.58 10 0.0212
> >>> test_fpu 0.89 10000 14.02 10 0.0132
> >>> tfft 0.17 10000 2.20 12 0.0149
> >>>
> >>> Geometric Mean Execution Time = 16.15 seconds
> >>>
> >>> ================================================================================
> >>>
> >>> In general, since the 2.5 release, the code performance is better
> >>> but the compile time is somewhat regressed.
> >>> Jack
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev
mailing list