llvm dev - May 2016 - Some questions about phase ordering in OPT and LLC

On Mon, May 09, 2016 at 01:07:07PM -0700, Mehdi Amini via llvm-dev
wrote:
> 
> > On May 9, 2016, at 10:43 AM, Ricardo Nobre via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> > 
> > Hi,
> > 
> > I'm a PhD student doing phase ordering as part of my PhD topic and
I would like to ask some questions about LLVM.
> > 
> > Executing the following command to see what passes does OPT execute
when targeting a SPARC V8 processor:
> > 
> > /opt/clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-15.10/bin/llvm-as <
/dev/null | /opt/clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-15.10/bin/opt -O3
-march=sparc -mcpu=v8 -disable-output -debug-pass=Arguments
> > 
> > I get the following output:
> > Pass Arguments:  -tti -no-aa -tbaa -scoped-noalias
-assumption-cache-tracker -targetlibinfo -basicaa -verify -simplifycfg -domtree
-sroa -early-cse -lower-expect
> > Pass Arguments:  -targetlibinfo -tti -no-aa -tbaa -scoped-noalias
-assumption-cache-tracker -basicaa -ipsccp -globalopt -deadargelim -domtree
-instcombine -simplifycfg -basiccg -prune-eh -inline-cost -inline -functionattrs
-argpromotion -domtree -sroa -early-cse -lazy-value-info -jump-threading
-correlated-propagation -simplifycfg -domtree -instcombine -tailcallelim
-simplifycfg -reassociate -domtree -loops -loop-simplify -lcssa -loop-rotate
-licm -loop-unswitch -instcombine -scalar-evolution -loop-simplify -lcssa
-indvars -loop-idiom -loop-deletion -loop-unroll -mldst-motion -domtree -memdep
-gvn -memdep -memcpyopt -sccp -domtree -bdce -instcombine -lazy-value-info
-jump-threading -correlated-propagation -domtree -memdep -dse -loops
-loop-simplify -lcssa -licm -adce -simplifycfg -domtree -instcombine -barrier
-float2int -domtree -loops -loop-simplify -lcssa -loop-rotate -branch-prob
-block-freq -scalar-evolution -loop-accesses -loop-vectorize -instcombine
-scalar-evolution -slp-vectorizer -simplifycfg -domtree -instcombine -loops
-loop-simplify -lcssa -scalar-evolution -loop-unroll -instcombine -loop-simplify
-lcssa -licm -scalar-evolution -alignment-from-assumptions
-strip-dead-prototypes -elim-avail-extern -globaldce -constmerge -verify
> > 
> > Why are there two "Pass Arguments"?
> > What does it mean?
> 
> 
> There are two PassManager instantiated and ran on the IR. I am not aware of
a good reason for that (the first one is created with
PassManagerBuilder::populateFunctionPassManager() and the second one with
PassManagerBuilder::populateModulePassManager()).
> 
> You can look at AddOptimizationPasses() in opt.cpp.
As far as I understand, the two passmanager do not interleave their
passes. It first runs all the function passes and below. Then all the
module passes. So if you specify:

    opt -mymodulepass0 -myfunctionpass -mymodulepass1

What you actually get is:

1. myfunctionpass on each function
2. mymodulepass0 
3. mymodulepass0

> On May 9, 2016, at 2:31 PM, serge guelton via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Mon, May 09, 2016 at 01:07:07PM -0700, Mehdi Amini via llvm-dev wrote:
>> 
>>> On May 9, 2016, at 10:43 AM, Ricardo Nobre via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm a PhD student doing phase ordering as part of my PhD topic
and I would like to ask some questions about LLVM.
>>> 
>>> Executing the following command to see what passes does OPT execute
when targeting a SPARC V8 processor:
>>> 
>>> /opt/clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-15.10/bin/llvm-as
< /dev/null | /opt/clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-15.10/bin/opt -O3
-march=sparc -mcpu=v8 -disable-output -debug-pass=Arguments
>>> 
>>> I get the following output:
>>> Pass Arguments:  -tti -no-aa -tbaa -scoped-noalias
-assumption-cache-tracker -targetlibinfo -basicaa -verify -simplifycfg -domtree
-sroa -early-cse -lower-expect
>>> Pass Arguments:  -targetlibinfo -tti -no-aa -tbaa -scoped-noalias
-assumption-cache-tracker -basicaa -ipsccp -globalopt -deadargelim -domtree
-instcombine -simplifycfg -basiccg -prune-eh -inline-cost -inline -functionattrs
-argpromotion -domtree -sroa -early-cse -lazy-value-info -jump-threading
-correlated-propagation -simplifycfg -domtree -instcombine -tailcallelim
-simplifycfg -reassociate -domtree -loops -loop-simplify -lcssa -loop-rotate
-licm -loop-unswitch -instcombine -scalar-evolution -loop-simplify -lcssa
-indvars -loop-idiom -loop-deletion -loop-unroll -mldst-motion -domtree -memdep
-gvn -memdep -memcpyopt -sccp -domtree -bdce -instcombine -lazy-value-info
-jump-threading -correlated-propagation -domtree -memdep -dse -loops
-loop-simplify -lcssa -licm -adce -simplifycfg -domtree -instcombine -barrier
-float2int -domtree -loops -loop-simplify -lcssa -loop-rotate -branch-prob
-block-freq -scalar-evolution -loop-accesses -loop-vectorize -instcombine
-scalar-evolution -slp-vectorizer -simplifycfg -domtree -instcombine -loops
-loop-simplify -lcssa -scalar-evolution -loop-unroll -instcombine -loop-simplify
-lcssa -licm -scalar-evolution -alignment-from-assumptions
-strip-dead-prototypes -elim-avail-extern -globaldce -constmerge -verify
>>> 
>>> Why are there two "Pass Arguments"?
>>> What does it mean?
>> 
>> 
>> There are two PassManager instantiated and ran on the IR. I am not
aware of a good reason for that (the first one is created with
PassManagerBuilder::populateFunctionPassManager() and the second one with
PassManagerBuilder::populateModulePassManager()).
>> 
>> You can look at AddOptimizationPasses() in opt.cpp.
> 
> As far as I understand, the two passmanager do not interleave their
> passes. It first runs all the function passes and below. Then all the
> module passes. So if you specify:
> 
>    opt -mymodulepass0 -myfunctionpass -mymodulepass1
> 
> What you actually get is:
> 
> 1. myfunctionpass on each function
> 2. mymodulepass0 
> 3. mymodulepass0 
(I assume your 3 was intended to be mymodulepass1 right?)

So AFAIK no, you should get the order you specified on the command line, i.e. 

1. mymodulepass0 
2. myfunctionpass on each function
3. mymodulepass1

-- 
Mehdi

> >> You can look at AddOptimizationPasses() in opt.cpp.
> > 
> > As far as I understand, the two passmanager do not interleave their
> > passes. It first runs all the function passes and below. Then all the
> > module passes. So if you specify:
> > 
> >    opt -mymodulepass0 -myfunctionpass -mymodulepass1
> > 
> > What you actually get is:
> > 
> > 1. myfunctionpass on each function
> > 2. mymodulepass0 
> > 3. mymodulepass0 
> 
> (I assume your 3 was intended to be mymodulepass1 right?)
(yes)
> So AFAIK no, you should get the order you specified on the command line,
i.e.
> 
> 1. mymodulepass0 
> 2. myfunctionpass on each function
> 3. mymodulepass1
MMMh, from opt.cpp, there's a first call to:

  if (OptLevelO1 || OptLevelO2 || OptLevelOs || OptLevelOz || OptLevelO3) {
    FPasses->doInitialization();
    for (Function &F : *M)
      FPasses->run(F);
    FPasses->doFinalization();
  }

then a few lines later, a call to:

    Passes.run(*M);

where Passes is the Module pass Manager and FPasses is the Function Pass
Manager. Each is filled in AddOptimizationPasses with different passes.
I don't see the point where the two manage interleave their passes.