[Simh] XCode and LTO

Wed Apr 18 12:36:05 EDT 2012

On Tuesday, April 17, 2012, at 8:53 PM, Craig A. Berry wrote:
> On Apr 17, 2012, at 9:22 PM, Mark Pizzolato - Info Comm wrote:
> 
> > Hi Craig,
> >
> > On Tuesday, April 17, 2012, at 5:25 PM, Craig A. Berry wrote:
> >> On Apr 17, 2012, at 11:06 AM, Mark Pizzolato - Info Comm wrote:
> >>> My OSX test environment is using the XCode which came with Snow
> >> Leopard (or was available when Snow Leopard released).  I don't
> >> recall the version and I'm not sure how to determine this detail.
> >>
> >> If you open XCode and look in the about box, that will tell you.  It
> >> should also be in a version.plist file somewhere.
> >
> > I am NOT a MAC user, so what I get to work I manage by stumbling around
> until my head bangs into something.  My OSX test environment is running in
> a VirtualBox VM on my windows desktop.
> 
> The following commands may be useful.  There is probably some better way
> but this is what I found quickly:
> 
> % defaults read /Applications/Xcode.app/Contents/version
> CFBundleShortVersionString
> 4.3.2
> 
> or with older versions of XCode, prepend /Developer :
> 
> % defaults read /Developer/Applications/Xcode.app/Contents/version
> CFBundleShortVersionString
> 3.1.4
> 
> 
> > My llvm-gcc -v returns:
> 
> > gcc version 4.2.1 (Based on Apple Inc. build 5658)  (LLVM build
> > 2335.6)
> 
> Very similar to mine:
> 
> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)

Well thanks for how to determine what I've got.  It is 3.2.6.  Looking on the Apple Developer site, it seems to be there as Xcode 3.2.6 and IOS SDK 4.3 for Snow Leopard (Apr 21, 2011).

> >>> The attached makefile has been adjusted so that for OSX
> >> LTO_EXCLUDE_VERSIONS contains the current GCC_VERSION if gcc -v
> >> doesn't contain "--enable-lto" as you suggested.  I believe that
> >> setting this will do the right thing on my XCode environment and your
> >> XCode and native gcc environments AND the native gcc built without
> >> --enable-lto.  Can you test and confirm this?
> >>
> >> I'm going to do that.
> 
> The new makefile works, thanks.  With GCC=llvm-gcc in the environment, it
> successfully builds a working vax executable, though without optimizations.
> Without GCC in the environment, it successfully picks up the LTO-capable,
> true blue, built from source with ./configure --enable-lto GCC and builds with
> the intended optimizations.

Hopefully it doesn't exclude ALL optimizations, it just is missing the potential lto benefits.  On my environment it still does some other stuff: -O2 -finline-functions -fgcse-after-reload -fnounsafe-loop-optimizations -fno-strict-overflow

The Primary goal is to produce a simulator which works.  The Secondary goal is to produce a simulator which works faster than before.  The Tertiary goal is to produce a simulator which works as fast as possible.

I believe we've cleanly achieved 1 and 2 for standard compile environments (using vanilla Xcode compiler), and allowed for goal 3 if you build the best gcc available.

> >>   I have gotten a successful compile by doing:
> >>
> >> % make NO_LTO=1 CFLAGS_O=-O4 vax
> >
> 
> Unfortunately this produced a binary 25% larger and 17% slower than
> without the -O4:
> 
> 
> VUPS	SIMH version, Compiler
> _____	___________________________
> 14.0	v3.8-1, gcc (4.0?)
> 18.5	v3.8-2-rc2-190, llvm-gcc 4.2.1, NO_LTO=1
> 22.5	v3.8-2-rc2-190, gcc v4.7.0
> 15.4	v3.8-2-rc2-190, llvm-gcc 4.2.1, NO_LTO=1 CFLAGS_O=-O4

Building with the current (attached) makefile using the XCode compiler should be equivalent to NO_LTO=1 which produces the same (working) results with both older XCode and newer Xcode compilers.

> > How it runs will be interesting.
> >
> > -O4 compiles for me as well, but I'm not sure what it really did.
> >
> > Since I'm running my tests inside a VM on relatively slow hardware,
> performance testing isn't very useful, but the simple DCL loop might illustrate
> something when comparing compile options...
> >
> > I'll test the speed tomorrow.

Actually, I'll trust your efforts and results.

> If this llvm thing can be made to do beneficial optimizations, I haven't seen it
> yet.  There may be linker invocations involved, or maybe one has to use clang
> rather than the gcc-compatible front end.
> 
> Hmm.  Putting GCC=clang in the environment gets a successful compile,
> though with lots of warnings.  However, starting the simulator hangs after
> "Eth: opened OS device en0" which it didn't do with other compilers, so there
> would be more work to support that compiler or it may not like something
> about the libpcap library.

The current makefile (or at least it's attempts at optimizing) presumes strongly that gcc is the compiler engine (as it expects that make will be gnu-make).  Please let me know if you come up with any way which will provide better results using the most common compilers which an OSX environment might have.  

Thanks for your input.

- Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile
Type: application/octet-stream
Size: 28941 bytes
Desc: makefile
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120418/0d8e772d/attachment-0002.obj>