12

I would like concretely to know what does the various optimizations levels of LLVM correspond to.

That is to say, I would like to know which optimization passes are EXACTLY executed (outside the frontend) and in which order when I use the "-0x" options of llvm (or clang or opt). The "man" of the corresponding tools do not provide much information on this matter (to the oposite of gcc's one).

I am aware of this useful page: http://llvm.org/docs/Passes.html, but it does not provide any information regarding the "-Ox" options. I was looking for some debugging or verbose options (esp. using informations from "opt --help") but I couldn't find any useful option.

As a complement, I noticed by parsing the code that all various LLVM tools as well as clang use distinct drivers which parse options their own way. Are all those drivers similar with respect to the "-Ox" options ?

Edit: I found the option "-debug-pass=Arguments" for the "opt" tool, which gives the following output for option "O1":

Pass Arguments:  -targetdata -no-aa -tbaa -targetlibinfo -basicaa -simplifycfg -domtree -scalarrepl -early-cse -lower-expect
Pass Arguments:  -targetlibinfo -targetdata -no-aa -tbaa -basicaa -globalopt -ipsccp -deadargelim -instcombine -simplifycfg -basiccg -prune-eh -always-inline -functionattrs -scalarrepl-ssa -domtree -early-cse -simplify-libcalls -lazy-value-info -jump-threading -correlated-propagation -simplifycfg -instcombine -tailcallelim -simplifycfg -reassociate -domtree -loops -loop-simplify -lcssa -loop-rotate -licm -lcssa -loop-unswitch -instcombine -scalar-evolution -loop-simplify -lcssa -iv-users -indvars -loop-idiom -loop-deletion -loop-unroll -memdep -memcpyopt -sccp -instcombine -lazy-value-info -jump-threading -correlated-propagation -domtree -memdep -dse -adce -simplifycfg -instcombine -strip-dead-prototypes -preverify -domtree -verify

This is close from what I wanted but remains two questions:

  • why are there two lists ?

  • is there any similar option for other tools, especially "clang" ? (according to my tests, "-debug-pass=Arguments" does not work with clang)

Edit: the option "-debug-pass=Structure" for the tool "opt" gives even more user friendly data (from http://llvm.org/docs/WritingAnLLVMPass.html)

Antoine Trouve
  • 1,198
  • 10
  • 21

1 Answers1

12

why are there two lists?

Function and Module passes have their own pass managers and so print out separately.

is there any similar option for other tools, especially "clang"

With clang you can use -mllvm -debug-pass=Arguments.

echristo
  • 1,687
  • 10
  • 8
  • @echristo: could you elaborate more on the difference between function and module pass in LLVM? say, I am passing the whole source code file foo.c to opt with one of the standard optimization passes (O1,2,3,...). What will happen next ? – Amir Nov 13 '14 at 18:44
  • 1
    @Amir Sorry for the delay, just saw this. Anyhow, a module pass is something that generally works across all functions, etc and has global visibility. A function pass works on an individual function at a time and can't pass information back and forth as far as analysis on individual functions. In general, things like data layout, global code generation, interprocedural analysis etc are module while gvn are function passes. You can take a look at the source for each pass to find out what it is in particular. Do you have a more specific question or more information? – echristo Dec 10 '14 at 21:50
  • Tnx for the answer @echristo, I basically work on the front-end of LLVM using those flags for auto-tuning (if you take a look at my papers), I was interested to know why there are several identital compiler flags for both module and pass ? e.g. `-targetdata -no-aa -tbaa -basicaa` and so on. LLVM-opt starts from module or function ? – Amir Dec 11 '14 at 01:24
  • 1
    @Amir There shouldn't be identical compiler flags, they're basically various different sets, e.g.: -targetdata enables the analysis pass that gets target data for various other passes. -no-aa,-basicaa, -tbaa are different kinds of alias analysis for use by other optimizations in disambiguating memory references. – echristo Dec 12 '14 at 18:53