Testing LLVM 3.1 on Ubuntu 11.10/12.04 ARM

Few weeks ago LLVM project released LLVM 3.1 release and I decided to give it a try on my ARM boards. I’ve tested on Ubuntu 11.10 on Freescale donated i.MX53 Quick Start Board and on Ubuntu 12.04 on Pandaboard. The results are pretty interesting as is shown in the table below. The table lists number of unexpected failures of basic LLVM testsuite when LLVM is compiled with specific optimization option and with specific GNU C compiler (on appropriate Ubuntu). Please note that Ubuntu 11.10 is last soft-float ABI Ubuntu and it provides GNU C 4.6.1:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 

On the other hand, Ubuntu 12.04 is the first which provides hard-float ABI and it comes with GNU C 4.6.3:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

And now, finally those interesting results. The numbers are clickable and link to the testsuite log file which you can see for your reference.

	-O0	-O1	-O2	default
GCC 4.6.1 (Ubuntu 11.10)	6	6	54	54
GCC 4.6.3 (Ubuntu 12.04)	6	6	6	6

So it looks like GCC 4.6.3 did a very nice job here. Honestly speaking I’m not sure if this is GCC or ABI switch from soft-float to hard-float and I’m not able to verify it since Ubuntu 12.04 is only hard-float ABI but my bet is on GCC here.

Testing LLVM 3.0 on Ubuntu 11.10 ARM

LLVM 3.0 was released some time ago and I’ve thought it’ll be good to give it a try on stock Ubuntu 11.10 ARM. That means I’ve tested LLVM 3.0 with Ubuntu provided GNU C++ 4.6.1 and Clang 2.9. GNU C++ configuration looks:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 

I’ve compiled LLVM 3.0 by those two compilers with default configuration and then with optimization flags set to -O0, -O1, -O2 and -O3. The table below lists sum of unexpected failures and unexpected passes with appropriate links to the tests output files. What’s surprising to me is that Clang on ARM even in version 2.9 performs so well. I know, Clang depends on LLVM and LLVM by default checks for Clang as a preferred compiler and both projects are mainly developed by Apple’s engineers, but still this is on native ARM/Linux system, so nothing like cross-compilation from MacOSX/x64 to iOS/ARM!

	-O0	-O1	-O2	-O3	default
GCC 4.6.1	6	6	51	51	51
Clang 2.9	1147	8	12	12	12

So as you can see GCC still wins on the lowest number of failures while using -O0/-O1, but Clang performs very well on -O2/-O3/default optimization levels. Please note that the excess number of failures on -O0 with Clang is probably caused by the fact that LLVM code requires some optimization to be performed on it to behaves correctly and it looks like Clang does not perform such optimization while GCC does when compiling with -O0.
Also what’s kind of surprise to me is to see Clang compilation performance. I’ve not marked hard numbers since this was not the task for this testing, but I’ve been surprised to see what GCC took around 700 minutes, Clang did in about 400 minutes. I’m talking about default compilation on i.MX53 Quick Start Board here.

Now the questions are: how Clang compiled LLVM affects GHC tests and GHC compilation speed? (i.e. I may use -O3 compiled LLVM for this). Also how would the numbers look like while testing latest greatest Linaro GCC and Clang 3.0? Perhaps material for another post or two…