Ricardo Nobre via llvm-dev
2016-May-09 17:43 UTC
[llvm-dev] Some questions about phase ordering in OPT and LLC
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? What passes should I pass the 'opt' tool (the LLVM Optimizer) so that it is equivalent to the use of -O3 with 'opt'? The ones of the first "Pass Arguments", or the second? I'm testing different phase orders, and one of the exploration schemes I want to try is to start with the equivalent of -O3 and iteratively apply small changes (e.g. swap passes in the compiler pass sequence equivalent to -O3), and compile and test with those different sequences. Additionally, I'm a bit confused about what passes does 'llc' (the LLVM static compiler) apply by default, when passing to it a LLVM IR previously optimized using the 'opt' tool. 'llc --help' says that the default is -O2: "Optimization level. [-O0, -O1, -O2, or -O3] (default = '-O2')" But is this -O2 the same as the -O2 from the 'opt' tool? Does it mean that if I generate an optimized LLVM IR with 'opt' (with -O2) and pass it to 'llc', it will by default apply all passes in -O2 a second time? Or do 'opt -O2' and 'llc -O2' represent different passes? Thanks in advance, Ricardo
Mehdi Amini via llvm-dev
2016-May-09 20:07 UTC
[llvm-dev] Some questions about phase ordering in OPT and LLC
> 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.> > What passes should I pass the 'opt' tool (the LLVM Optimizer) so that it is equivalent to the use of -O3 with 'opt'? > The ones of the first "Pass Arguments", or the second?Both, with two separate opt invocation...> > I'm testing different phase orders, and one of the exploration schemes I want to try is to start with the equivalent of -O3 and iteratively apply small changes (e.g. swap passes in the compiler pass sequence equivalent to -O3), and compile and test with those different sequences. > > Additionally, I'm a bit confused about what passes does 'llc' (the LLVM static compiler) apply by default, when passing to it a LLVM IR previously optimized using the 'opt' tool. > > 'llc --help' says that the default is -O2: > "Optimization level. [-O0, -O1, -O2, or -O3] (default = '-O2')" > > But is this -O2 the same as the -O2 from the 'opt' tool? > > Does it mean that if I generate an optimized LLVM IR with 'opt' (with -O2) and pass it to 'llc', it will by default apply all passes in -O2 a second time? > Or do 'opt -O2' and 'llc -O2' represent different passes?The optimization level for llc has nothing to do with opt, it controls only the codegen (target specific). In any case, llc won't re-run the optimizer pipeline. See llc.cpp, the logic is easy to follow. CodeGenOpt::Level OLvl = CodeGenOpt::Default; switch (OptLevel) { default: errs() << argv[0] << ": invalid optimization level.\n"; return 1; case ' ': break; case '0': OLvl = CodeGenOpt::None; break; case '1': OLvl = CodeGenOpt::Less; break; case '2': OLvl = CodeGenOpt::Default; break; case '3': OLvl = CodeGenOpt::Aggressive; break; } -- Mehdi
serge guelton via llvm-dev
2016-May-09 21:31 UTC
[llvm-dev] 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
Joseph via llvm-dev
2020-Apr-06 15:52 UTC
[llvm-dev] Placing an existing function's arguments in a call to another function in an LLVM Function Pass
Hey,
I'm writing an LLVM function pass. So far, the "Programmer's
Manual" was
a tremendous help.
I have a function `foo(int a, int b)`, where in some instances, I'll
need to replace it's call with `bar(int a, int b)`.
The way I wanted to do it is to basically:
* Locate the `foo()` I need to replace
* Make a `CallInst` to `bar()`
* Populate `CallInst::Create` with the arguments of `foo()`
* Make a call to `ReplaceInstWithInst()` to have it work
Everything is working just fine, but the arguments of `foo()` are not
getting copied to `bar()`. When the replacement call is executed, the
arguments of `bar()` are just null.
Here's the relevant code:
```c
bool runOnFunction(Function& F) override
{
CallInst* call_to_foo = 0;
Function* foo_func = 0;
/*
Loop over all calls in the function and populate foo_func when you
find it.
If we reached below, that means the current function we're in has a
call to
foo() (inside call_to_foo) that we need to replace with bar().
Also, foo_func
is pointing to a foo Function
*/
Function* bar_func = get_bar_func();
// Collect foo args
// I believe here is the issue: the arguments are not copied
// properly or there must be a deep-copy of sorts for it to work
std::vector<Value*> bar_func_args;
for (size_t i = 0; i < foo_func->arg_size(); i++) {
Argument* arg = foo_func->arg_begin() + i;
bar_func_args.push_back(arg);
}
auto* inst_to_replace = CallInst::Create(
bar_func, ArrayRef<Value*>(bar_func_args),
"bar_func");
ReplaceInstWithInst(
call_inst->getParent()->getInstList(),
BBI, inst_to_replace);
return true;
}
```
Any help would be tremendously appreciated.
--
Joseph
Craig Topper via llvm-dev
2020-Apr-09 02:19 UTC
[llvm-dev] Placing an existing function's arguments in a call to another function in an LLVM Function Pass
Is foo_func a Function*? If so that’s just the function declaration. You need to copy the arguments from the CallInst that calls foo. On Wed, Apr 8, 2020 at 6:21 PM Joseph via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hey, > > I'm writing an LLVM function pass. So far, the "Programmer's Manual" was > a tremendous help. > > I have a function `foo(int a, int b)`, where in some instances, I'll > need to replace it's call with `bar(int a, int b)`. > > The way I wanted to do it is to basically: > * Locate the `foo()` I need to replace > * Make a `CallInst` to `bar()` > * Populate `CallInst::Create` with the arguments of `foo()` > * Make a call to `ReplaceInstWithInst()` to have it work > > Everything is working just fine, but the arguments of `foo()` are not > getting copied to `bar()`. When the replacement call is executed, the > arguments of `bar()` are just null. > > Here's the relevant code: > > ```c > bool runOnFunction(Function& F) override > { > CallInst* call_to_foo = 0; > Function* foo_func = 0; > > /* > Loop over all calls in the function and populate foo_func when you > find it. > > If we reached below, that means the current function we're in has a > call to > foo() (inside call_to_foo) that we need to replace with bar(). > Also, foo_func > is pointing to a foo Function > */ > > Function* bar_func = get_bar_func(); > > // Collect foo args > // I believe here is the issue: the arguments are not copied > // properly or there must be a deep-copy of sorts for it to work > std::vector<Value*> bar_func_args; > for (size_t i = 0; i < foo_func->arg_size(); i++) { > Argument* arg = foo_func->arg_begin() + i; > bar_func_args.push_back(arg); > } > > auto* inst_to_replace = CallInst::Create( > bar_func, ArrayRef<Value*>(bar_func_args), > "bar_func"); > > ReplaceInstWithInst( > call_inst->getParent()->getInstList(), > BBI, inst_to_replace); > > return true; > } > ``` > > Any help would be tremendously appreciated. > > -- > Joseph > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/2922d4d8/attachment.html>