I've had better luck compiling all of pymol 1.1r2 with -O4 on darwin9. Everythink links and there appears to be no regressions in the resulting code. I take it that LTO in llvm 2.5 is still limited to dead code elimination, correct? Will LTO ever be extended to inlining across files as well as constant-folding and global data allocation optimizations? Or does the reliance on gcc-4.2 as the front end prevent those sort of things from being implemented outside of clang? Jack ps Hopefully Snow Leopard will end up with llvm 2.5 for its llvm-gcc.
Jack Howarth wrote:> I've had better luck compiling all of pymol 1.1r2 with > -O4 on darwin9. Everythink links and there appears to be > no regressions in the resulting code. I take it that LTO > in llvm 2.5 is still limited to dead code elimination, > correct?No. libLTO does the equivalent to opt -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine -inline -prune-eh -globaldce -argpromotion -instcombine -jump-threading -scalarrepl -globalsmodref-aa -licm -gvn -memcpyopt -dse -instcombine -jump-threading -mem2reg -simplifycfg -globaldce Will LTO ever be extended to inlining across> files as well as constant-folding and global data > allocation optimizations?Our optimization passes know nothing of file boundaries. That includes the inliner, which blissfully inlines across file boundaries. You can read a description of these passes in our documentation at http://llvm.org/docs/Passes.html . Ones that make particular use of whole program information include ipsccp, globalopt, deadargelim, inline, prune-eh, argpromotion and globaldce. Nick Or does the reliance on gcc-4.2> as the front end prevent those sort of things from being > implemented outside of clang? > Jack > ps Hopefully Snow Leopard will end up with llvm 2.5 > for its llvm-gcc. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Jan 24, 2009, at 5:43 PM, Nick Lewycky wrote:> Jack Howarth wrote: >> I've had better luck compiling all of pymol 1.1r2 with >> -O4 on darwin9. Everythink links and there appears to be >> no regressions in the resulting code. I take it that LTO >> in llvm 2.5 is still limited to dead code elimination, >> correct? > > No. > > libLTO does the equivalent to opt -internalize -ipsccp -globalopt > -constmerge -deadargelim -instcombine -inline -prune-eh -globaldce > -argpromotion -instcombine -jump-threading -scalarrepl - > globalsmodref-aa > -licm -gvn -memcpyopt -dse -instcombine -jump-threading -mem2reg > -simplifycfg -globaldceRight. Note however that LTO is significantly crippled if you don't use export controls. I'd strongly recommend building the code with - fvisibility-hidden or using an export map at the final link stage to avoid exporting all symbols. If the optimizer knows a symbol is private to the linked image, it can be significantly more aggressive with it. -Chris