[llvm-dev] opt - replicating multiple passes from -O3 -debug-pass=Executions
Chad Verbowski via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 12 14:02:04 PDT 2020
Thanks Sanjay - your hint enabled me to get most of the way there. I found
that I can reproduce the -O3 results by:
(1) Running OPT with all the pass flags up to but not including the
-simplifycfg pass with differing results.
(2) Run a second OPT on the result from (1) with -switch-to-lookup then the
-simplifycfg pass with the remaining pass flags.
Adding the -switch-to-lookup flag unfortunately impacts all -simplifycfg
passes if I try to do this with one OPT run.
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?
Thanks for all your help!
-Chad
On Wed, Aug 12, 2020 at 5:12 AM Sanjay Patel <spatel at rotateright.com> wrote:
> 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.
>
> // Cleanup after loop vectorization, etc. Simplification passes like CVP
> and
> // GVN, loop transforms, and others have already run, so it's now better
> to
> // convert to more optimized IR using more aggressive simplify CFG
> options.
> // The extra sinking transform can create larger basic blocks, so do this
> // before SLP vectorization.
> // FIXME: study whether hoisting and/or sinking of common instructions
> should
> // be delayed until after SLP vectorizer.
> MPM.add(createCFGSimplificationPass(SimplifyCFGOptions()
> .forwardSwitchCondToPhi(true)
> .convertSwitchToLookupTable(true)
> .needCanonicalLoops(false)
> .hoistCommonInsts(true)
> .sinkCommonInsts(true)));
>
>
>
> On Tue, Aug 11, 2020 at 1:14 PM Chad Verbowski via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>> 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)?
>>
>> Thanks.
>>
>>
>> On Mon, Aug 10, 2020 at 10:42 PM Chad Verbowski <chad at verbowski.com>
>> wrote:
>>
>>> Hello,
>>>
>>> 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.
>>>
>>> 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.)
>>>
>>> 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.
>>>
>>> Is there a way I can address these differences to enable replicating the
>>> -O3 first and second passes using opt flags?
>>>
>>> Thanks for considering this,
>>>
>>> -Chad
>>>
>>> (Opt -O3 first pass) Pass Arguments: -tti -tbaa -scoped-noalias
>>> -assumption-cache-tracker -targetlibinfo -verify -ee-instrument
>>> -simplifycfg -domtree -sroa -early-cse -lower-expect
>>> Target Transform Information
>>> Type-Based Alias Analysis
>>> Scoped NoAlias Alias Analysis
>>> Assumption Cache Tracker
>>> Target Library Information
>>> FunctionPass Manager
>>> Module Verifier
>>> Instrument function entry/exit with calls to e.g. mcount() (pre
>>> inlining)
>>> Simplify the CFG
>>> Dominator Tree Construction
>>> SROA
>>> Early CSE
>>> Lower 'expect' Intrinsics
>>>
>>> (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
>>>
>>> Pass Arguments: * -targetlibinfo* -tti *-targetpassconfig* -tbaa
>>> -scoped-noalias -assumption-cache-tracker -verify -ee-instrument
>>> -simplifycfg -domtree -sroa -early-cse -lower-expect *-verify
>>> -write-bitcode*
>>> *Target Library Information*
>>> Target Transform Information
>>> Target Pass Configuration
>>> Type-Based Alias Analysis
>>> Scoped NoAlias Alias Analysis
>>> Assumption Cache Tracker
>>> *ModulePass Manager*
>>> FunctionPass Manager
>>> Module Verifier
>>> Instrument function entry/exit with calls to e.g. mcount() (pre
>>> inlining)
>>> Simplify the CFG
>>> Dominator Tree Construction
>>> SROA
>>> Early CSE
>>> Lower 'expect' Intrinsics
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200812/a5d35291/attachment.html>
More information about the llvm-dev
mailing list