[LLVMdev] compiling the full SPEC CPU2000 suite to LLVM bytecode

[Chris Lattner]

On Fri, 1 Sep 2006, Kenneth Hoste wrote:
> Some problems were solved, new ones arised... Getting closer though...
> The fixes for the previous problems are at the bottom of this email,
> bug reports will be submitted when all problems are solved.

Kenneth,

In general, I am more than happy to help people on this list.  It is good 
for the community and I enjoy helping people be successful at what they 
do.  However, my time is finely divided by many different things I'm 
juggling on an on-going basis: it's not "my job" to monitor this list and 
respond to your emails.  As such, I would appreciate it if you 
investigated the problems and tried to find solutions on your own for some 
of these issues: I feel like you aren't doing "your share" of the 
investigation work, you are just complaining about stuff that doesn't 
work.

I'm sorry that things are not working for you "out of the box".  The one 
useful thing I can contribute w.r.t. this email is that the *warnings* 
about crtend can be simply ignored.  If you update to llvm cvs, they will 
be gone, but they don't hurt anything with LLVM 1.8.

I hope that you do figure out what has changed between NAG 5.0 and 5.1, 
because I *do* want you to be successful.  If NAG doesn't work, perhaps 
you could contribute to getting gfortran up and running.

-Chris

> +++ New/remaining problems +++
>
> Currently, 9/26 benchmarks compile and run succesfully. One (fma3d)
> still has a f95 related problem (see below).
> The other 16 are divided into two groups:
>
> *** 1) *** bytecode builds ok, but exection fails
>
> For 10 benchmarks the execution fails as follows:
>
> JIT problems:
> <start>
> Running: /home/kehoste/work/LLVM/1.8/llvm/projects/llvm-test/
> RunSafely.sh 500 galgel.in galgel.out /home/kehoste/work/LLVM/1.8/
> llvm/Release/bin/lli -force-interpreter=false ../178.galgel.llvm.bc
> (no debugging symbols found)
> Using host libthread_db library "/lib/libthread_db.so.1".
> (no debugging symbols found)
> Core was generated by `/home/kehoste/work/LLVM/1.8/llvm/Release/bin/
> lli-force-interpreter=false ../17'.
> Program terminated with signal 6, Aborted.
>
> warning: svr4_current_sos: Can't read pathname for load map: Input/
> outpu        t error
> </end>
>
> Other tests:
> <start>
>  /home/kehoste/work/LLVM/1.8/llvm/Release/bin/fpcmp: Comparison
> failed, not a numeric difference.
> ******************** TEST (llc) '178.galgel' FAILED!
> ********************
> Execution Context Diff:
> </end>
> Strangely enough, no additional output (error or warnings) is
> generated. Also, the execution diff seems to be empty.
> Additionally, I don't think the programs get executed at all, because
> make runs too fast.
>
> For gap/gcc, only the cbe test fails, the other (including JIT) are ok.
>
> Affected benchmarks: galgel, equake, lucas, gcc, gap, facerec,
> sixtrack, wupwise, mgrid, applu, apsi
>
> Since these include both SPECfp and SPECint benchmarks, this has
> nothing todo with f95.
>
> *** 2) *** Undefined references
>
> With 3 benchmarks (vpr, crafty and eon), I'm getting similar
> undefined references:
>
> /tmp/ccGCQxYs.o(.text+0x76b2): In function `init_chan':
> 175.vpr.cbe.c: undefined reference to `ltmp_6791_156'
> /tmp/ccGCQxYs.o(.text+0x76cb):175.vpr.cbe.c: undefined reference to
> `ltmp_6792_156'
> /tmp/ccGCQxYs.o(.text+0x76f1):175.vpr.cbe.c: undefined reference to
> `ltmp_6793_157'
> /tmp/ccGCQxYs.o(.text+0x76fb):175.vpr.cbe.c: undefined reference to
> `ltmp_6794_156'
>
> These also include SPECint benchmarks, so again, this has nothing
> todo with f95.
>
>> *** perlbmk syntax error
>>
>> Compiling the perlbmk benchmark produces a syntax error. This may be
>> a GCC4 problem.
>>
>> <path>/SPEC_CPU2000_1.3_src/benchspec/CINT2000/253.perlbmk/src/
>> nt_perlmain.c:80: error: syntax error before ‘int’
>>
>> (among others)
>>
>> This specific line of code is:
>>
>> DllExport int RunPerl(int argc, char **argv, char **env, void *ios);
>>
>> which does seem very strange syntax to me...
>>
>> Affected benchmarks: perlbmk.
>>
>> This one remains. Solutions/ideas are very welcome.
>
> This one remains. Solutions/ideas are very welcome.
>
>
> +++ Problems solved +++
>
>> *** cannot find library crtend
>>
>
> This is a know problem. Fix is shown at http://lists.cs.uiuc.edu/
> pipermail/llvm-commits/Week-of-Mon-20060828/037184.html
> Thanks to Reid for mentioning this (on IRC).
>
> Reason: crtend is a library used in the old frontend, and the
> Makefile weren't aware of this.
>
>>
>> +++ following errors seem to be NAG-specific +++
>>
>
> The NAG support was really friendly, here's how the NAG problems got
> fixed.
>
>> *** BEAM (fma3d)
>>
>> There seem to be some issues with the fma3d benchmark, when
>> translating from Fortran to C:
>>
>> f95 -w -S -O2 <path>/SPEC_CPU2000_1.3_src/benchspec/CFP2000/191.fma3d/
>> src/beam.f90 -o beam.c -dusty -maxcontin=69
>> Error: <path>/SPEC_CPU2000_1.3_src/benchspec/CFP2000/191.fma3d/src/
>> beam.f
>> 90: Binding label 'beam_' of COMMON/BEAM/ matches module BEAM_
>> [f95 error termination]
>>
>> Also a f95-related issue I'd guess.
>>
>> Affected benchmarks: fma3d.
>
> This is yet to be solved.
>
>> *** problems with f95.h
>
> Adding -DINT64='long long' to the CPPFLAGS solved this. I will submit
> a bug report for this some time soon.
>
>>
>> *** f95 PANIC
>
> This was a known problem, which is fixed in the latest edit
> (available at ftp://ftp.nag.co.uk/pub/nagware_support/
> nplux51na_rh90_282.tgz).
>>
>> *** libf97.dylib not found
>>
>
> It appears the *.dylib files are Mac specific. Apparently the usage
> of f95 was only tested on Mac (I think Chris did this?).
>
> Solution (for Linux/x86):
>
> modify Makefile.nagfortran:
>
> CPPFLAGS += -I$(F95_DIR)/lib
> LDFLAGS += $(F95_DIR)/lib/quickfit.o $(F95_DIR)/lib/libf98.so $
> (F95_DIR)        /lib/libf98.a
>
> I'll also submit a bug report for this one.
>
> greetings,
>
> Kenneth
>
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/