[LLVMdev] LLVM 3.4 performance regressed?

[Jens Tröger]

Thanks Jonas,

I wasn't aware of the gold linker plugin.  Here's what I do, in my
current workflow.  First, I use clang to compile each .c file (e.g. for
the bzip2 benchmark, or any other) into a .bc file:

  specmake clean 2> make.clean.err | tee make.clean.out
  rm -rf bzip2 bzip2.exe *.o  *.fppized.f*
  find . \( -name \*.o -o -name '*.fppized.f*' \) -print | xargs rm -rf
  rm -rf core 
  specmake build 2> make.err | tee make.out
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o spec.o -DSPEC_CPU -DNDEBUG                    spec.c
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o blocksort.o -DSPEC_CPU -DNDEBUG                    blocksort.c
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o bzip2.o -DSPEC_CPU -DNDEBUG                    bzip2.c
  bzip2.c:487:27: warning: incompatible pointer to integer conversion
  assigning to 'int' from 'void *' [-Wint-conversion]
     outputHandleJustInCase = NULL;
                          ^ ~~~~
  bzip2.c:614:27: warning: incompatible pointer to integer conversion
  assigning to 'int' from 'void *' [-Wint-conversion]
     outputHandleJustInCase = NULL;
                          ^ ~~~~
  2 warnings generated.
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o bzlib.o -DSPEC_CPU -DNDEBUG                    bzlib.c
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o compress.o -DSPEC_CPU -DNDEBUG                    compress.c
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o crctable.o -DSPEC_CPU -DNDEBUG                    crctable.c
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o decompress.o -DSPEC_CPU -DNDEBUG                    decompress.c
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o huffman.o -DSPEC_CPU -DNDEBUG                    huffman.c
  clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm  -c -o randtable.o -DSPEC_CPU -DNDEBUG                    randtable.c

Once that's done, the Spec "linker" actually calls to a script of mine
which uses llvm-link to merge all bitcode files into one, and then calls
opt.

Ordinarily this opt call would use

  -simplifycfg -mem2reg <my-passes>

At that point I played around with various optimization switches to find
out how I can get my performance back to that of LLVM 3.1 compiled code.
Using just plain -std-compile-opts to replace my command line didn't
work.

Once opt has produced an optimized bitcode file, I call llc to lower it.

Cheers,
Jens



On Tue, Apr 08, 2014 at 10:05:03AM +0200, Jonas Wagner wrote:
>    Hi,
>    (adding llvm-dev again)
> 
>      I did enable optimization, but that didn't have an effect on the
>      runtime
>      performance numbers.
> 
>    Can you elaborate? For a program such as bzip2, I'd expect the program
>    to be at least twice as fast with -O3 than with -O0.
>    I also noticed that you use LLC in the final step. An alternative that
>    works well for me is to use the [1]gold linker plugin. This way, you
>    can link bitcode files directly into the program by using
>        clang -flto $(LDFLAGS) <bitcode files> -o <output file> $(LDLIBS)
>    If your bitcode files have the extension .o, clang will only run LTO
>    optimizations, code generation, and linking. If they have the extension
>    .bc, it will run a full set of compilation passes (in which case you
>    might want to add $(CFLAGS) to the command line).
>    Hope this helps,
>    Jonas
> 
> References
> 
>    1. http://llvm.org/docs/GoldPlugin.html

-- 
Jens Tröger
http://savage.light-speed.de/