In D144226#4301073, @congzhe wrote:

In addition to Michael's comment, I'd like to suggest several comments:

1. This patch "undo" LICM within loop interchange in order to form a tightly nest loopnest. This sounds like a phase ordering problem, i.e., you could just place loop interchange before LICM and then you'll be able to interchange the loopnest. If it is a phase ordering problem then I'm not sure if it makes perfect sense to undo pass A within pass B, because things could quickly get messy if we choose to develop in this way.

2. Also, have you considered the "loopnest" version of loop passes? For example if you use the loopnest invariant code motion (LNICM) pass instead of LICM pass in the pipeline, you'll not hoist z[j] into int tmp = z[j] (in the example from your summary), because LNICM will only do hoisting if a variable is invariant across the entire loopnest.

3. In D53027, support for inner-only reductions is removed because of miscompilation of certain cases, as well as profitability concerns since interchange would move loads and stores from the outer loop into the inner loop. Have you thought about addressing these problems?

One possible miscompilation, as mentioned in https://reviews.llvm.org/D53027#1272786, is that it would miscompile if we interchange the following code, given that y is a global variable.

for (unsigned i = 0; i < N; i++) {
  y = 0;
  for (unsigned j = 0; j < N; j++) {
    A[i][j] += 1;
    y += A[i][j];
  }
}

In D144226#4299835, @Meinersbur wrote:

Summarize the algorithm in the description, in particular what a "removablePHIs" is and what distinguishes a inner-only reduction from an inner reduction?

@fhahn @efriedma @Meinersbur @congzhe @bmahjour @kparzysz Can you please help review this patch?

Ping!

Ping! Thank you @efriedma for adding more reviewers

@fhahn @eli.friedman Can you please review this patch?

@fhahn Ping!

Ping

@fhahn I used the lit-test from your patch from here: https://reviews.llvm.org/D53027?vs=on&id=168822#toc

In D93929#2485807, @aeubanks wrote:

In D93929#2485715, @quic_aankit wrote:

@asbirlea I remember that HexagonVLCR pass has a dependency on LCSSA and LoopSimplifyPass. Is there any way we can run these passes too at LoopOptimizerEndEP? If not maybe use another EP for legacy PM? I'm not sure if the below code would run these passes in the correct order as well

PB.registerOptimizerLastEPCallback(
    [=](ModulePassManager &MPM, PassBuilder::OptimizationLevel Level) {
      LoopPassManager LPM(DebugPassManager);
      FunctionPassManager FPM(DebugPassManager);
      LPM.addPass(HexagonVectorLoopCarriedReusePass());
      FPM.addPass(LoopSimplifyPass());
      FPM.addPass(LCSSAPass());
      FPM.addPass(createFunctionToLoopPassAdaptor(std::move(LPM)));
      MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM)));
    });

@pranavb Can you comment more on this?

LCSSA should be preserved by all loop passes under the new PM. LCSSA and LoopSimplify are run before any loop pass: https://github.com/llvm/llvm-project/blob/8dddcc762dd98d53b9406b36e92f62502834187c/llvm/include/llvm/Transforms/Scalar/LoopPassManager.h#L406. Although I don't think passes are required preserve loop simplify form.

@asbirlea I remember that HexagonVLCR pass has a dependency on LCSSA and LoopSimplifyPass. Is there any way we can run these passes too at LoopOptimizerEndEP? If not maybe use another EP for legacy PM? I'm not sure if the below code would run these passes in the correct order as well

In D88138#2397785, @vtjnash wrote:

I think this, and similar recent commits, are causing the shared library builds to fail some tests if this code gets linked into libLLVM.so: https://bugs.llvm.org/show_bug.cgi?id=48181. I assume it might actually a bug in ld (GNU Binutils for Ubuntu 2.34), as I don't understand the linker behavior there?

Makes sense. Removed the default value

@aeubanks Thanks for the review. Can you also commit the patch on my behalf?

@aeubanks PTAL

In D88138#2295699, @aeubanks wrote:

In D88138#2295673, @kparzysz wrote:

In D88138#2294257, @aeubanks wrote:

I think I'm still missing how exactly this will fit into the pipeline. As in where is registerPassBuilderCallbacks() going to be called?

Perhaps EmitAssemblyHelper::EmitAssemblyWithNewPassManager in BackendUtil.cpp. PassBuilder actually has TM as a member, so maybe from somewhere inside of PassBuilder itself, but I'm not sure whether that's the right thing to do.

Anywhere adjustPassManager() is called should have a corresponding call to registerPassBuilderCallbacks() in the NPM path. So yes EmitAssemblyHelper::EmitAssemblyWithNewPassManager() in BackendUtil.cpp, but also since opt.cpp calls adjustPassManager(), the corresponding NPM path in NewPMDriver.cpp should also call registerPassBuilderCallbacks(). Both places have access to a TM.

This should be done either before or in this patch, or else we can't test it and make sure it works.

In D88138#2294257, @aeubanks wrote:

I think I'm still missing how exactly this will fit into the pipeline. As in where is registerPassBuilderCallbacks() going to be called?

And a test like llvm/test/CodeGen/AMDGPU/opt-pipeline.ll for the new pass manager route would be nice to make sure this actually works.
something like RUN: opt -passes='default<O0>' -mtriple=... -disable-output -disable-verify -debug-pass-manager. Maybe checking all the normal passes isn't necessary like in the existing opt-pipeline.ll isn't necessary, just need to check that the custom passes (e.g. HexagonVectorLoopCarriedReusePass) are actually added.

Added HexagonVectorLoopCarriedReusePass to registerPassBuilderCallbacks

In D88138#2291222, @aeubanks wrote:

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

In D86955#2283186, @pzheng wrote:

In D86955#2280318, @quic_aankit wrote:

In D86955#2274924, @pzheng wrote:

In D86955#2271328, @quic_aankit wrote:

In D86955#2261551, @pzheng wrote:

In D86955#2261510, @quic_aankit wrote:

In D86955#2261498, @pzheng wrote:

Is there any existing test case for this pass with the legacy pass manager? If so, you might want to add one with the new pass manager too.

All the existing testcases use opt to run the pass. The pass is not run integrated in the main list of passes for any -Ox level.

That's what I meant. For each legacy pass manager test "RUN: opt -hexagon-vlcr ...", you can add a corresponding new pass manager test "RUN: opt -passes=hexagon-vlcr". This way, we will have the same test coverage with both the legacy and new pass managers.

Hi pzheng, I could not figure out a way to register a target specific pass in opt? I can see that llvm/lib/Passes/PassRegistry.def is the registry for target independent passes. Can you point me to an example/API which can help me in registering this pass so that I can use it -passes option in opt?

I am not sure if there is a better place to register the pass other than PassRegistry.def. Maybe someone who knows can comment on this.

Hi pzheng, testing target specific passes using opt+NPM is not currently supported and the work is still work-in-progress. Can we land this without modifying the testcases for now?

Hi @quic_aankit, just to be clear, you tried registering the pass in PassRegistry.def, but still couldn't get "opt -passes=hexagon-vlcr" to work, right? If so, I am fine with leaving out the tests for now, but we should probably mention in the commit message that tests are still to be ported.

In D86955#2274924, @pzheng wrote:

In D86955#2271328, @quic_aankit wrote:

In D86955#2261551, @pzheng wrote:

In D86955#2261510, @quic_aankit wrote:

In D86955#2261498, @pzheng wrote:

Is there any existing test case for this pass with the legacy pass manager? If so, you might want to add one with the new pass manager too.

All the existing testcases use opt to run the pass. The pass is not run integrated in the main list of passes for any -Ox level.

That's what I meant. For each legacy pass manager test "RUN: opt -hexagon-vlcr ...", you can add a corresponding new pass manager test "RUN: opt -passes=hexagon-vlcr". This way, we will have the same test coverage with both the legacy and new pass managers.

Hi pzheng, I could not figure out a way to register a target specific pass in opt? I can see that llvm/lib/Passes/PassRegistry.def is the registry for target independent passes. Can you point me to an example/API which can help me in registering this pass so that I can use it -passes option in opt?

I am not sure if there is a better place to register the pass other than PassRegistry.def. Maybe someone who knows can comment on this.

In D86955#2261551, @pzheng wrote:

In D86955#2261510, @quic_aankit wrote:

In D86955#2261498, @pzheng wrote:

Is there any existing test case for this pass with the legacy pass manager? If so, you might want to add one with the new pass manager too.

All the existing testcases use opt to run the pass. The pass is not run integrated in the main list of passes for any -Ox level.

That's what I meant. For each legacy pass manager test "RUN: opt -hexagon-vlcr ...", you can add a corresponding new pass manager test "RUN: opt -passes=hexagon-vlcr". This way, we will have the same test coverage with both the legacy and new pass managers.

In D86955#2261498, @pzheng wrote:

Is there any existing test case for this pass with the legacy pass manager? If so, you might want to add one with the new pass manager too.

Ran clang-format on the patch

Hi @fhahn, I've updated the patch to handle the failure with MSVC. Using iterator with pop_back was causing problems on windows.

Hi @fhahn , the commit caused a buildbot failure.
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/20911
Can you please revert the patch for now while I investigate the issue?

I'm trying to get access to commit the patch, but it would be great if you can get someone to commit it.

Hi @fhahn , I've updated the patch to address your comments

In D65326#1763222, @fhahn wrote:

Reverse ping.

Are you still looking to submit this patch? If so, it would be great to not wait too long with responding, otherwise the reviewers will have to re-familiarize themselves with the patch and the comment history.

@fhahn Gentle reminder

@fhahn Ping

@fhahn Gentle reminder

Hi fhahn, sorry for the delay. I've addressed your comments. However, I was unable to add a test where multiple entries are removed from the mapping in a single deleteDeadInstructions call. The method you suggested does not work because deleting a function that may throw is not a legal operation. In the testcase that I have since it is a new function call "_Znwj", we are able to remove the call.

@fhahn @efriedma @bcahoon Please review

In D65326#1603693, @fhahn wrote:

I think SetVector would be more suitable and lead to slightly simpler code (http://llvm.org/doxygen/classllvm_1_1SetVector.html)

Also, could you upload the patch with more context? (git show HEAD -U999999)

Uploading patch with more context