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

Kenneth Hoste kenneth.hoste at ugent.be
Fri Sep 1 07:46:03 PDT 2006


Hello,

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.

+++ 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

-- 

Statistics are like a bikini. What they reveal is suggestive, but  
what they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
kenneth.hoste at elis.ugent.be
http://www.elis.ugent.be/~kehoste






More information about the llvm-dev mailing list