LTO v. opt

David_Callahan1 · January 3, 2015, 4:32am

Hi,

I am new to the LLVM dev community so forgive a perhaps obvious question. I am looking at bug 17623 which is an LTO/optimizer interaction bug. I am working on a Mac with Xcode installed but have also built the 3.6 LLVM binaries (from a few month old local branch).

The default version of “ld” from Apple supports an option “-save-temps” which I believe saves bitcode both before and after the optimizer (and the bug is visible as a difference between these two)

~/llvm-install/bin/clang -flto -O2 -c -o bug17623.o bug17623.c

“/usr/bin/ld” -demangle -dynamic -arch x86_64 -macosx_version_min 10.10.0 -lSystem /Users/dcallahan/llvm-install/bin/…\

/lib/clang/3.6.0/lib/darwin/libclang_rt.osx.a -save-temps -o bug36 bug17623.o

(this produces bug36.lto.bc and bug36.lto.opt.bc)

However, if I use “opt” to try and duplicate the actions run by “ld”, as in:

~/llvm-install/bin/opt -O2 -o bug36.opt.bc bug36.lto.bc

This generates a different (much cleaner and correct!) output.

So my questions are:

Is it feasible to get “opt” to reproduce the behavior of “ld”?
Assuming I am just missing some parameters to “opt”, how do I determine what they should be?

Thanks

David

void · January 4, 2015, 7:52am

Hi,

I am new to the LLVM dev community so forgive a perhaps obvious question. I am looking at bug 17623 which is an LTO/optimizer interaction bug. I am working on a Mac with Xcode installed but have also built the 3.6 LLVM binaries (from a few month old local branch).

The default version of “ld” from Apple supports an option “-save-temps” which I believe saves bitcode both before and after the optimizer (and the bug is visible as a difference between these two)

~/llvm-install/bin/clang -flto -O2 -c -o bug17623.o bug17623.c
“/usr/bin/ld” -demangle -dynamic -arch x86_64 -macosx_version_min 10.10.0 -lSystem /Users/dcallahan/llvm-install/bin/…
/lib/clang/3.6.0/lib/darwin/libclang_rt.osx.a -save-temps -o bug36 bug17623.o

(this produces bug36.lto.bc and bug36.lto.opt.bc)

However, if I use “opt” to try and duplicate the actions run by “ld”, as in:

~/llvm-install/bin/opt -O2 -o bug36.opt.bc bug36.lto.bc

This generates a different (much cleaner and correct!) output.

So my questions are:

Is it feasible to get “opt” to reproduce the behavior of “ld”?

The optimizations that occur during LTO (the ‘ld’ command) are different from the “normal” optimizations that opt runs. For one, LLVM has a view of the whole program, not just one compilation unit at a time. If you want to look at some of the optimizations that it performs, you can use the “opt -std-link-opts” command.

Assuming I am just missing some parameters to “opt”, how do I determine what they should be?

The link time optimizations are enabled via the "-std-link-opts” option.

-bw

void · January 5, 2015, 9:14am

I forgot to mention that you will need to link all of the .bc files together using 'llvm-link’ before you run ‘opt -std-link-opts’ on it.

-bw

_sean_silva · January 5, 2015, 8:59pm

tools/llvm-lto should get you pretty close.

dexonsmith · January 5, 2015, 9:14pm

tools/llvm-lto should get you pretty close.

Be aware that unless you tell `llvm-lto` to hang on to specific
symbols, LTO can dead-strip them after -internalize.

Try adding -exported-symbol=_main if you're hitting this.

dexonsmith · January 5, 2015, 9:16pm

Hi,

I am new to the LLVM dev community so forgive a perhaps obvious question. I am looking at bug 17623 which is an LTO/optimizer interaction bug. I am working on a Mac with Xcode installed but have also built the 3.6 LLVM binaries (from a few month old local branch).

The default version of “ld” from Apple supports an option “-save-temps” which I believe saves bitcode both before and after the optimizer (and the bug is visible as a difference between these two)

~/llvm-install/bin/clang -flto -O2 -c -o bug17623.o bug17623.c
"/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.10.0 -lSystem /Users/dcallahan/llvm-install/bin/..\
/lib/clang/3.6.0/lib/darwin/libclang_rt.osx.a -save-temps -o bug36 bug17623.o

(this produces bug36.lto.bc and bug36.lto.opt.bc)

However, if I use “opt” to try and duplicate the actions run by “ld”, as in:

~/llvm-install/bin/opt -O2 -o bug36.opt.bc bug36.lto.bc

This generates a different (much cleaner and correct!) output.

So my questions are:
1. Is it feasible to get “opt” to reproduce the behavior of “ld”?

The optimizations that occur during LTO (the ‘ld’ command) are different from the “normal” optimizations that opt runs. For one, LLVM has a view of the whole program, not just one compilation unit at a time. If you want to look at some of the optimizations that it performs, you can use the “opt -std-link-opts” command.

2. Assuming I am just missing some parameters to “opt”, how do I determine what they should be?

The link time optimizations are enabled via the "-std-link-opts” option.

You might also need to add `-internalize-public-api-list` to prevent
functions like `main()` from getting internalized (and dead-stripped).

I forgot to mention that you will need to link all of the .bc files together using 'llvm-link’ before you run ‘opt -std-link-opts’ on it.

(If you're starting from bug36.lto.bc then they've already been linked.)

David_Callahan1 · January 5, 2015, 9:29pm

Thanks to you both.

On my Linux (centos6) system, I have reproduce a variant of the bug and learned about
-plugin-opt=-debug-pass=Arguments
which I infer from comments is intended to built arguments to “opt” however I found that some of the arguments don’t seem to be quite correct. I assume this just minor bit rot.

bin/opt -o pass1.bc -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias -assumption-tracker -basicaa -verify -verify-di -ipsccp -globalopt -c
onstmerge -deadargelim -instcombine -basiccg -inline-cost -inline -prune-eh -globalopt -globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading -domt
ree -sroa -basiccg -functionattrs -globalsmodref-aa -domtree -loops -loop-simplify -lcssa -licm -memdep -mldst-motion -domtree -memdep -gvn -memdep -memcpyopt -dse -loops -
scalar-evolution -loop-simplify -lcssa -indvars -loop-deletion -branch-prob -block-freq -loop-vectorize -scalar-evolution -alignment-from-assumptions -instcombine -lazy-val
ue-info -jump-threading -simplifycfg -globaldce -verify -verify-di bug17623a.o
opt: Unknown command line argument ‘-basictti’. Try: ‘bin/opt -help’
opt: Did you mean ‘-basiccg’?
opt: Unknown command line argument ‘-x86tti’. Try: ‘bin/opt -help’
opt: Did you mean ‘-notti’?
opt: Unknown command line argument ‘-verify-di’. Try: ‘bin/opt -help’
opt: Did you mean ‘-verify’?
opt: Unknown command line argument ‘-verify-di’. Try: ‘bin/opt -help’
opt: Did you mean ‘-verify’?

dexonsmith · January 5, 2015, 9:33pm

Some of those passes can't be specified on the command-line; they're
implicitly added by other passes.

I usually remove the passes that `opt` complains about and things
still reproduce.

_sean_silva · January 7, 2015, 8:39pm

Yeah, it’s a pretty sad state of affairs. Hopefully the new pass manager will help in this regard (or at least bring the extent of yaks into the light).