<div dir="ltr">Thanks Sanjay - your hint enabled me to get most of the way there. I found that I can reproduce the -O3 results by:<div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><br></div><div>(1) Running OPT with all the pass flags up to but not including the -simplifycfg pass with differing results. </div><div>(2) Run a second OPT on the result from (1) with -switch-to-lookup then the -simplifycfg pass with the remaining pass flags. </div></blockquote></div><div><br></div><div>Adding the -switch-to-lookup flag unfortunately impacts all -simplifycfg passes if I try to do this with one OPT run. </div><div><br></div><div>Does anyone know if there is a way to scope the -switch-to-lookup flag to a specific -simplycfg instance in a long opt command line so I can achieve this result with a single opt run?</div><div><br></div><div>Thanks for all your help!</div><div><br></div><div>-Chad</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2020 at 5:12 AM Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The pipeline built with -O3 includes non-default options for -simplifycfg when it runs late. I don't know if it is possible to replicate that behavior if you are trying to specify multiple runs of a pass via the command-line options.<br></div><div><br></div><div>  // Cleanup after loop vectorization, etc. Simplification passes like CVP and<br>  // GVN, loop transforms, and others have already run, so it's now better to<br>  // convert to more optimized IR using more aggressive simplify CFG options.<br>  // The extra sinking transform can create larger basic blocks, so do this<br>  // before SLP vectorization.<br>  // FIXME: study whether hoisting and/or sinking of common instructions should<br>  //        be delayed until after SLP vectorizer.<br>  MPM.add(createCFGSimplificationPass(SimplifyCFGOptions()<br>                                          .forwardSwitchCondToPhi(true)<br>                                          .convertSwitchToLookupTable(true)<br>                                          .needCanonicalLoops(false)<br>                                          .hoistCommonInsts(true)<br>                                          .sinkCommonInsts(true)));<br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 1:14 PM Chad Verbowski via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Update: Comparing the -print-before-all and -print-after-all for -O3 and the run with the flags, I see a difference starting with the 7th (of 8) "*** IR Dump After Simplify the CFG ***" which I assume is the -simplifycfg flag. <br></div><div dir="ltr"><div><br></div><div>Is there any known reason -simplifycfg would behave differently if the pipeline of passes up to this point  are identical (order and their input and output)?</div></div><div><br></div><div>Thanks.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 10, 2020 at 10:42 PM Chad Verbowski <<a href="mailto:chad@verbowski.com" target="_blank">chad@verbowski.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<br><div><br></div><div>I am trying to replicate the output from opt -O3 foo.bc -o foo.opt.bc by specifying the individual passes instead of the -O3 flag. </div><div><br></div><div>Looking at the passes from opt -O3 foo.bc -o foo.bc -debug-pass=Executions  it seems there are two passes being run. When I run the flags indicated for the two passes specified in the 'Pass Arguments:' as two sequential opt processes or a single opt process with the concatenated flags  I get a different binary result compared to the O3 run. (Note I had to remove the -targetpassconfig flag and add -spec-exec-only-if-divergent-target to the second pass to get my run to match O3's second pass.)</div><div><br></div><div>Comparing the -debug-pass=Executions from my runs with the O3 run, it seems the first pass in my run has additional 'TargetLibrary Information', 'Target Pass Configuration' and the 'Module Pass Manager' entries compared to O3 (copied below). My output shows the 'Pass Arguments:' line has automatically added  -targetpassconfig -verify -writebitcode, and the -targetlibinfo flag was moved to the start. </div><div><br></div><div>Is there a way I can address these differences to enable replicating the -O3 first and second passes using opt flags?</div><div><br></div><div>Thanks for considering this,</div><div><br></div><div>-Chad</div><div><br></div><div>(Opt -O3 first pass) Pass Arguments:  -tti -tbaa -scoped-noalias -assumption-cache-tracker -targetlibinfo -verify -ee-instrument -simplifycfg -domtree -sroa -early-cse -lower-expect</div>Target Transform Information<br>Type-Based Alias Analysis<br>Scoped NoAlias Alias Analysis<br>Assumption Cache Tracker<br>Target Library Information<br>  FunctionPass Manager<br>    Module Verifier<br>    Instrument function entry/exit with calls to e.g. mcount() (pre inlining)<br>    Simplify the CFG<br>    Dominator Tree Construction<br>    SROA<br>    Early CSE<br>    Lower 'expect' Intrinsics<div><br></div><div>(My Run): opt in.bc -o out.bc -debug-pass=Executions  -tti -tbaa -scoped-noalias -assumption-cache-tracker -targetlibinfo -verify -ee-instrument -simplifycfg -domtree -sroa -early-cse -lower-expect</div><div><br></div><div>Pass Arguments: <b><u> -targetlibinfo</u></b> -tti <b>-targetpassconfig</b> -tbaa -scoped-noalias -assumption-cache-tracker -verify -ee-instrument -simplifycfg -domtree -sroa -early-cse -lower-expect <b>-verify -write-bitcode</b><br><b><i>Target Library Information</i></b><br>Target Transform Information<br>Target Pass Configuration<br>Type-Based Alias Analysis<br>Scoped NoAlias Alias Analysis<br>Assumption Cache Tracker<br>  <b><i>ModulePass Manager</i></b><br>    FunctionPass Manager<br>      Module Verifier<br>      Instrument function entry/exit with calls to e.g. mcount() (pre inlining)<br>      Simplify the CFG<br>      Dominator Tree Construction<br>      SROA<br>      Early CSE<br>      Lower 'expect' Intrinsics<br></div></div>
</blockquote></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>