[Simh] XCode and LTO

[Craig A. Berry]

I've been running the vax simulator from 3.8-1 off and on for a couple of years and thought I would take a current snapshot for a spin to see if the performance differs, so I grabbed a GitHub snapshot with the precise but unpronounceable name "markpizz-simh-v3.8-2-rc2-190-geb60957.zip".  Building it on Mac OS X Lion proved to be more fun than I intended to have.

I have the latest version of XCode (4.3.2) on my Macbook Pro, so that includes GCC, right?  Wrong.  Not anymore.  What it includes is a gcc-alike front end to llvm, which identifies itself as:

% llvm-gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)

Problem is, llvm-gcc, while claiming to be gcc, does not support the options -flto -fwhole-program.  It accepts (actually ignores) those options on the command line but then you get dozens of undefined symbols at link time.

The makefile script currently in SIMH assumes all compilers identifying themselves as gcc support the LTO options unless they are in the version list explicitly excluded with LTO_EXCLUDE_VERSIONS.  I tried adding LLVM to that list, but the makefile code stops listening after it gets to the numeric part of the version string and doesn't see the "LLVM" in the last line of the compiler output above.  

So at the very least, the ability to hard-code a list of compilers that don't support the LTO options needs a bit of work.  But I'm not sure that's the whole story, because true blue GCC doesn't necessarily support that option either.  How do I know?

A reasonable person would have simply hacked the makefile script to hard-wire NO_LTO to 1, and that's what I did eventually.  That works, for some definition of works, but there are performance implications that I'll get to shortly.  Not being entirely reasonable, I decided that if it wanted gcc, I'd give it gcc.  So I downloaded the massive GCC 4.7.0 source distribution and built it from source with default options.  The llvm-gcc did just fine bootstrapping a build of the GCC package, and a few hours later I had a working gcc.

So then I had another whack at compiling SIMH, and it told me that the -flto option was not supported.  Ouch.  The one option I was in need of was not a default option.  So desperation led me (at long last) to read a few passages from the family-friendly manual, whereupon I discovered that configuring with "./configure --enable-lto" and rebuilding GCC got me (after another hour or three of compiling) a compiler that reports itself as:

% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.3.0
Configured with: ./configure --enable-lto
Thread model: posix
gcc version 4.7.0 (GCC)

This turned out to be what SIMH was expecting and it built without a hitch.  But it occurred to me that what SIMH was expecting was not what I was expecting, was not what a default build of GCC from the authoritative sources provides, and was not what the Apple gizmo provided as part of XCode that impersonates gcc provides.  So perhaps a better method of detecting LTO capability is needed, perhaps scanning the version output above for "--enable-lto".

But to sprinkle some good news over my complaint, I was finally able to fire up my image of OpenVMS VAX v7.3 and compare performance between 3.8-1 (built with a real gcc from a previous version of XCode, probably gcc 4.0), llvm-gcc 4.2.1, and actual gcc from GCC 4.7.0.  I used a DCL procedure I found on the interwebs ages ago called CALCULATE_VUPS.COM.  Before the benchmark police show up, I should say it was just for fun, it was a Sunday afternoon, and no actual benchmarks were harmed by doing a bit of casual looping in DCL.  Here's what I got, averaging five runs:

VUPS	SIMH version, Compiler
_____	___________________________
14.0	v3.8-1, gcc (4.0?)
18.5	v3.8-2-rc2-190, llvm-gcc 4.2.1
22.5	v3.8-2-rc2-190, gcc v4.7.0

So v3.8.2 is shaping up to be 61% faster than v3.8.1 at hopping around in DCL.  Perhaps more surprising is that SIMH built with gcc v4.7.0 is 22% faster than the exact same SIMH built with llvm-gcc v4.2.1.  Someone is doing something right and in this case it doesn't appear to be Apple or llvm.

Cheers,
________________________________________
Craig A. Berry
mailto:craigberry at mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser