- User Since
- Feb 12 2020, 11:23 AM (32 w, 1 d)
I think I'm still missing how exactly this will fit into the pipeline. As in where is registerPassBuilderCallbacks() going to be called?
Yep I'll take a look.
Wed, Sep 23
Yeah that makes sense. Or maybe have some global counter, since this is mostly a debugging thing, although that seems fairly hacky.
LTOBackend may also need to deal with this, but I don't know if flags like opt-bisect apply there.
I suppose we can think about interactions with the legacy PM in a later patch, this on its own is an improvement.
Actually, doing verify-each in StandardInstrumentations seems much nicer. Not sure about how to do debugify-each though, filed https://bugs.llvm.org/show_bug.cgi?id=47633.
Turns out this doesn't actually work as intended...
The callbacks need to be done at the addPass() level, or else something like 'default<O3>' only runs the callbacks once, even though it adds a bunch of passes. Will probably revert once I come up with something better.
Makes sense, but do you have an example usage of this?
Tue, Sep 22
instead, just fix all 6 tests failing because of -enable-mssa-loop-dependency
ASan to the rescue:
I believe this is causing issues in Windows builds, e.g. http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/25705 and hangs in http://188.8.131.52/win/summary.html.
I'm seeing a hang locally:
$ ./build/debug/obj/llvm/unittests/Analysis/AnalysisTests.exe --gtest_filter='*IRSimilarityCandidate.IdenticalWithDebug*'
Note: Google Test filter = *IRSimilarityCandidate.IdenticalWithDebug*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from IRSimilarityCandidate
[ RUN ] IRSimilarityCandidate.IdenticalWithDebug
warning: ignoring debug info with an invalid version (0) in <string>
this causes some tests to fail, let me fix those up
small comment change
asbirlea, you mentioned offline that there were passes that replaced this in the NPM and that this shouldn't be ported, do you know what those are so I can put them in the description of another change pinning tests to the legacy PM?
Mon, Sep 21
add option to disable adding AlwaysInlinerPass
add assertion reason string
I discovered that some tests regarding optimization remarks were failing since AlwaysInlinerPass didn't emit optimization remarks, separated that out into https://reviews.llvm.org/D88067.
add NPM CHECK lines for phi-values-usage.ll
alias-analysis-uses.ll doesn't really seem to be testing anything that would make sense in the NPM
I got asan to fire on some out of bounds stuff with this change, but couldn't get ubsan to trigger on integer overflow for some reason. -fsanitize=undefined is in the ninja files, so maybe I just didn't trip it in the right way.
http://lists.llvm.org/pipermail/llvm-dev/2020-September/145187.html for more agreement of this patch.
Any suggestions on how to fix this? Add an alwaysinline phase in InlinerPass that runs before the rest of inlining?
Fri, Sep 18
One of the issues raised in http://lists.llvm.org/pipermail/llvm-dev/2018-September/126477.html was that we'd have to somehow thread the -opt-bisect-limit through two different pass managers. If you look in BackendUtil.cpp's EmitAssemblyHelper::EmitAssemblyWithNewPassManager(), there's a NPM for the optimization pipeline, then a legacy PM for the codegen pipeline. OptBisect.rst says that you can use -opt-bisect-limit through clang -mllvm -opt-bisect-limit=, and I don't think that would properly work with this implementation since the codegen pipeline would restart -opt-bisect-limit.
Add back comment