We tend to assume that the AA pipeline is by default the default AA
pipeline and it's confusing when it's empty instead.
PR48779
Paths
| Differential D95117
[NewPM][opt] Run the "default" AA pipeline by default ClosedPublic Authored by aeubanks on Jan 20 2021, 11:52 PM.
Details Summary We tend to assume that the AA pipeline is by default the default AA PR48779
Diff Detail
Event TimelineHerald added subscribers: wenlei, lxfind, asbirlea and 5 others. · View Herald TranscriptJan 20 2021, 11:52 PM Comment Actions Could we have at least one test showing how to pass an empty pipeline, solely for testing purposes? This revision is now accepted and ready to land.Jan 21 2021, 1:08 PM This revision was landed with ongoing or failed builds.Jan 21 2021, 7:47 PM Closed by commit rGbe611431cd1f: [NewPM][opt] Run the "default" AA pipeline by default (authored by aeubanks). · Explain Why This revision was automatically updated to reflect the committed changes. aeubanks added a reverting change: rGba9b4ea4eeae: Revert "[NewPM][opt] Run the "default" AA pipeline by default".Jan 21 2021, 8:17 PM markus added inline comments.
lxfind added a child revision: D95247: [Coroutine] Improve coro-elide-musttail.ll test.Jan 22 2021, 10:14 AM bjope added inline comments.
Revision Contents
Diff 318405 llvm/test/Analysis/MemorySSA/pr43569.ll
llvm/test/CodeGen/Hexagon/loop-idiom/pmpy-mod.ll
llvm/test/Other/loop-pm-invalidation.ll
llvm/test/Other/new-pass-manager.ll
llvm/test/Other/new-pm-defaults.ll
llvm/test/Other/new-pm-lto-defaults.ll
llvm/test/Other/new-pm-pr42726-cgscc.ll
llvm/test/Other/new-pm-thinlto-defaults.ll
llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
llvm/test/Other/pass-pipeline-parsing.ll
llvm/test/Transforms/Coroutines/coro-elide-musttail.ll
llvm/test/Transforms/Coroutines/coro-retcon.ll
llvm/test/Transforms/Inline/cgscc-incremental-invalidate.ll
llvm/test/Transforms/LoopRotate/pr35210.ll
llvm/test/Transforms/LoopVectorize/PowerPC/optimal-epilog-vectorization.ll
llvm/test/Transforms/LoopVectorize/optimal-epilog-vectorization.ll
llvm/test/Transforms/LoopVersioningLICM/loopversioningLICM1.ll
llvm/test/Transforms/LoopVersioningLICM/loopversioningLICM2.ll
llvm/test/Transforms/OpenMP/parallel_region_merging.ll
llvm/test/Transforms/PhaseOrdering/ARM/arm_fill_q7.ll
llvm/test/Transforms/PhaseOrdering/X86/SROA-after-loop-unrolling.ll
llvm/test/Transforms/PhaseOrdering/X86/addsub-inseltpoison.ll
llvm/test/Transforms/PhaseOrdering/X86/addsub.ll
llvm/test/Transforms/PhaseOrdering/X86/loop-idiom-vs-indvars.ll
llvm/test/Transforms/PhaseOrdering/X86/masked-memory-ops.ll
llvm/test/Transforms/PhaseOrdering/X86/vdiv.ll
llvm/test/Transforms/PhaseOrdering/globalaa-retained.ll
llvm/test/Transforms/PhaseOrdering/instcombine-sroa-inttoptr.ll
llvm/test/Transforms/PhaseOrdering/pr39282.ll
llvm/test/Transforms/SimplifyCFG/X86/invalidate-dom.ll
llvm/test/Transforms/ThinLTOBitcodeWriter/pr33536.ll
llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc.ll
llvm/tools/opt/NewPMDriver.cpp
|
Realizing I am a bit late to the party but this change here confuses me.
Previously in https://reviews.llvm.org/D82488?id=273164#inline-758886 it was requested that "Could you assert AAPipeline and AA passes inside Passes don't co-exist?" but the assert added at that point was actually stronger making sure that Passes contains no passes at all.
While I guess this code is equivalent to its predecessor in that sense I don't quite understand why this limitation is needed. Especially as it gets in the way for our use case.
E.g. if I run
I do not get any "default" AA at all.
Could of course be our use case is unintended and dumb but still … :)