[LLVMdev] darwin llvm-gfortran Polyhedron 2005 results
Dale Johannesen
dalej at apple.com
Thu Apr 8 11:12:24 PDT 2010
On Apr 8, 2010, at 8:45 AMPDT, 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.
This is the first I was aware this patch broke anything; nobody cc'd me on the bugzilla, and I don't normally pay attention to Fortran mail.
We definitely don't want to revert 81455; the bug caused a crash building something that's part of MacOS, and yes, that's more important than Fortran. But it should be possible to get Fortran to build. I would think the right idea is to change the build so that either darwin-c.o gets linked in (theoretically wrong but it should work), or (better) gt_gcc–r_gt_darwin_c_h is not referenced in Fortran. It appears to be configured into gtype-fortran.h, which is generated during the build, so the thing would be to get it not to go in there....I'm not that expert with the GC mechanism, but I can play around a little....
> 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