[NewPM][GuardWidening] Fix loop guard widening tests under NPM

[ychen]

LGTM

[bjope]

llvm/test/Transforms/GuardWidening/loop-schedule.ll

7–14

Why isn't this checked for NewPM?
If this is the main point with the test, then the main point verification is missing with NewPM!?!?

Btw, shouldn't it be CHECK-NEXT if one wants to verify that there is nothing between those checked lines.

[aeubanks]

One more missed test

[asbirlea]

llvm/test/Transforms/GuardWidening/loop-schedule.ll

2

For NPM use -debug-pass-manager. The flag -debug-pass=Structure is a no-op.
Add --check-prefixes=NPM,CHECK.
Check lines with NPM prefix:

Starting Loop pass manager run.
Running pass: LICMPass on Loop at depth 1 containing: %loop<header><latch><exiting>
Running pass: GuardWideningPass on Loop at depth 1 containing: %loop<header><latch><exiting>
Running pass: LICMPass on Loop at depth 1 containing: %loop<header><latch><exiting>
Finished Loop pass manager run.

[aeubanks]

Also test under NPM

[aeubanks]

llvm/test/Transforms/GuardWidening/loop-schedule.ll

7–14

I also was wondering why it wasn't CHECK-NEXT.

Here's the relevant output:

Loop Pass Manager
  Loop Invariant Code Motion
Loop Pass Manager
  Widen guards (within a single loop, as a loop pass)
Memory SSA
Loop Pass Manager
  Loop Invariant Code Motion

The "Memory SSA" looks like what the test is hoping doesn't exist, maybe that's why it isn't CHECK-NEXT. You can try and fix this test up if you want.

The NPM version does work as intended though, added that.

[ychen]

Not sure we need to be so complete here. 9258e9d190af643ed5d770fa8a965af3b7090502 introduce this test for legacy PM only. There are separate tests for NPM.

[asbirlea]

llvm/test/Transforms/GuardWidening/loop-schedule.ll

7–14

This seems to be due to the widen guards pass not marking MemorySSA as preserved. This seems worth fixing in GuardWidening to explicitly mark it preserved for all types of passes.

llvm/test/Transforms/GuardWidening/basic-loop.ll

 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
-; RUN: opt -S -loop-guard-widening < %s        | FileCheck %s
+; RUN: opt -S -loop-guard-widening -enable-new-pm=0 < %s | FileCheck %s
 ; RUN: opt -S -passes="loop(guard-widening)" < %s | FileCheck %s
 
 declare void @llvm.experimental.guard(i1,...)
 
 @G = external global i32
 
 ; Show that we can widen into early checks within a loop, and in the process
 ; expose optimization oppurtunities.

llvm/test/Transforms/GuardWidening/loop-schedule.ll

-; RUN: opt -S -licm -loop-guard-widening -licm -debug-pass=Structure < %s 2>&1   | FileCheck %s
+; RUN: opt -S -licm -loop-guard-widening -licm -debug-pass=Structure -enable-new-pm=0 < %s 2>&1 | FileCheck %s --check-prefixes=LPM,CHECK
+; RUN: opt -S -passes='licm,guard-widening,licm' -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefixes=NPM,CHECK
 
 ; Main point of this test is to check the scheduling -- there should be
 ; no analysis passes needed between LICM and LoopGuardWidening
 
-; CHECK: Loop Pass Manager
-; CHECK:   Loop Invariant Code Motion
-; CHECK:   Widen guards (within a single loop, as a loop pass)
-; CHECK:   Loop Invariant Code Motion
+; LPM: Loop Pass Manager
+; LPM:   Loop Invariant Code Motion
+; LPM:   Widen guards (within a single loop, as a loop pass)
+; LPM:   Loop Invariant Code Motion
+
+; NPM: LICMPass
+; NPM-NEXT: GuardWideningPass
+; NPM-NEXT: LICMPass
 
 declare void @llvm.experimental.guard(i1,...)
 
 define void @iter(i32 %a, i32 %b, i1* %c_p) {
 ; CHECK-LABEL: @iter
 ; CHECK:  %cond_0 = icmp ult i32 %a, 10
 ; CHECK:  %cond_1 = icmp ult i32 %b, 10
 ; CHECK:  %wide.chk = and i1 %cond_0, %cond_1