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.

In D88138#2291795, @quic_aankit wrote:

In D88138#2291222, @aeubanks wrote:

Makes sense, but do you have an example usage of this?

I wanted to add the equivalent of adjustPassManager for Hexagon. Should I make that change in this same patch itself?

In D87951#2290564, @cuviper wrote:

Hmm, thanks for those pointers. To combine opt-bisect from the two pass managers, maybe there can be an explicit call to copy stateful instrumentation? I think it helps that they are not interleaved, so we could do MPM.run(), then somehow SI.copy_to(CodeGenPasses), then CodeGenPasses.run(). I still need to read that thread too...

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.

Not sure...
I suppose we can think about interactions with the legacy PM in a later patch, this on its own is an improvement.

In D88107#2291548, @ychen wrote:

In D88107#2291529, @aeubanks wrote:

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.

If debugify-each has or could be made to have a standalone function interface, could it use StandardInstrumentations?

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?

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://45.33.8.238/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

add comment

rename

small comment change

update comment
rename

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?

add option to disable adding AlwaysInlinerPass

add assertion reason string

Thanks!
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.

rename

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

In D87734#2286252, @asbirlea wrote:

I don't think this should be ported to the NPM.

In D88056#2286494, @vitalybuka wrote:

In D88056#2286473, @vitalybuka wrote:

In D88056#2286450, @aeubanks wrote:

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.

I assume you are asking about the same code which triggers asan and you expect some ubsan report there.
Never mind if the question was about -fsanitize=signed-integer-overflow

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.

format

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?

rebase
remove braces

lgtm

In D87806#2284654, @ahatanak wrote:

Patch looks good to me, but do you have to change anything to fix the pre-merge check test failure?

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