[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver added a comment.

@nikic I added this patch to a work in progress (WIP) "stack" of patches. 
D158352  and D158353 
 show what the intended progression looks 
like for mem2reg. I will add WIP SROA changes in the next few days.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver added a comment.

@nikic Thanks for responding. I will get a "work in progress" patch up in the 
next three days.

In the API adaptation, instruction insertion is still being handled in the 
caller as some passes are only allowed removal and not insertion.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@jmciver Thanks for the context. I would recommend you to put up the patch you 
have based on top of this, because it's pretty hard to tell whether this API 
design makes sense without seeing the use. I have some doubts about that, for 
two reasons:

- If I understand correctly, for your use case getInitialValueOfAllocation() 
can't just return a constant anymore, it may have to insert an instruction. 
Additionally, there is no longer a single "initial value", but it may wary 
between different loads from the same allocation. This means that the API is 
going to change to the point that getInitialValueOfAllocation() is no longer 
recognizable (and probably no longer correctly named -- it would be more 
materializeInitialValueOfAllocation()).
- As some of the changes in this patch show, we also have to give 
lifetime.start intrinsics similar treatment to allocas, but this doesn't quite 
fit the current API.

I think supporting allocas in getInitialValueOfAllocation() is perfectly fine, 
but I'm not sure this really brings you closer to what you want to do.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver added inline comments.



Comment at: llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp:809-811
+  Updater.AddAvailableValue(
+  Alloca.getParent(),
+  getInitialValueOfAllocation(&Alloca, nullptr, VectorTy));

arsenm wrote:
> This is very specifically handling alloca, not any random allocation like 
> function
@arsenm thanks for the feedback. I added functionality to 
`getInitalValueOfAllocation` to handle `alloca` instructions specifically. This 
is being done as preliminary to some possible refactorizations allowing 
uninitialized memory to move to poison semantics. The behavior for these 
changes would be the same for `alloca` and allocation like functions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added inline comments.



Comment at: llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp:809-811
+  Updater.AddAvailableValue(
+  Alloca.getParent(),
+  getInitialValueOfAllocation(&Alloca, nullptr, VectorTy));

This is very specifically handling alloca, not any random allocation like 
function


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver updated this revision to Diff 545294.
jmciver edited the summary of this revision.
jmciver added a comment.
Herald added subscribers: foad, kerbowa, jvesely, arsenm.

Refactor AMDGPUPromoteAlloca to use getInitialValueOfAllocation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

Files:
  llvm/include/llvm/Analysis/MemoryBuiltins.h
  llvm/lib/Analysis/MemoryBuiltins.cpp
  llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp
  llvm/lib/Transforms/Scalar/GVN.cpp
  llvm/lib/Transforms/Scalar/NewGVN.cpp
  llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp

Index: llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
===
--- llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
+++ llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
@@ -24,6 +24,7 @@
 #include "llvm/Analysis/AssumptionCache.h"
 #include "llvm/Analysis/InstructionSimplify.h"
 #include "llvm/Analysis/IteratedDominanceFrontier.h"
+#include "llvm/Analysis/MemoryBuiltins.h"
 #include "llvm/Analysis/ValueTracking.h"
 #include "llvm/IR/BasicBlock.h"
 #include "llvm/IR/CFG.h"
@@ -600,7 +601,7 @@
 if (I == StoresByIndex.begin()) {
   if (StoresByIndex.empty())
 // If there are no stores, the load takes the undef value.
-ReplVal = UndefValue::get(LI->getType());
+ReplVal = getInitialValueOfAllocation(AI, nullptr, LI->getType());
   else
 // There is no store before this load, bail out (load may be affected
 // by the following stores - see main comment).
Index: llvm/lib/Transforms/Scalar/NewGVN.cpp
===
--- llvm/lib/Transforms/Scalar/NewGVN.cpp
+++ llvm/lib/Transforms/Scalar/NewGVN.cpp
@@ -1496,21 +1496,18 @@
   if (LoadPtr != lookupOperandLeader(DepInst) &&
   !AA->isMustAlias(LoadPtr, DepInst))
 return nullptr;
-  // If this load really doesn't depend on anything, then we must be loading an
-  // undef value.  This can happen when loading for a fresh allocation with no
-  // intervening stores, for example.  Note that this is only true in the case
-  // that the result of the allocation is pointer equal to the load ptr.
-  if (isa(DepInst)) {
-return createConstantExpression(UndefValue::get(LoadType));
-  }
   // If this load occurs either right after a lifetime begin,
   // then the loaded value is undefined.
-  else if (auto *II = dyn_cast(DepInst)) {
+  if (auto *II = dyn_cast(DepInst)) {
 if (II->getIntrinsicID() == Intrinsic::lifetime_start)
   return createConstantExpression(UndefValue::get(LoadType));
-  } else if (auto *InitVal =
- getInitialValueOfAllocation(DepInst, TLI, LoadType))
-  return createConstantExpression(InitVal);
+  }
+  // If this load really doesn't depend on anything, then we must be loading an
+  // undef value.  This can happen when loading for a fresh allocation with no
+  // intervening stores, for example.  Note that this is only true in the case
+  // that the result of the allocation is pointer equal to the load ptr.
+  else if (auto *InitVal = getInitialValueOfAllocation(DepInst, TLI, LoadType))
+return createConstantExpression(InitVal);
 
   return nullptr;
 }
Index: llvm/lib/Transforms/Scalar/GVN.cpp
===
--- llvm/lib/Transforms/Scalar/GVN.cpp
+++ llvm/lib/Transforms/Scalar/GVN.cpp
@@ -1239,11 +1239,12 @@
   }
   assert(DepInfo.isDef() && "follows from above");
 
-  // Loading the alloca -> undef.
   // Loading immediately after lifetime begin -> undef.
-  if (isa(DepInst) || isLifetimeStart(DepInst))
+  if (isLifetimeStart(DepInst))
 return AvailableValue::get(UndefValue::get(Load->getType()));
 
+  // In addition to allocator function calls this includes loading the alloca ->
+  // undef.
   if (Constant *InitVal =
   getInitialValueOfAllocation(DepInst, TLI, Load->getType()))
 return AvailableValue::get(InitVal);
Index: llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp
===
--- llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp
+++ llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp
@@ -32,6 +32,7 @@
 #include "llvm/Analysis/CaptureTracking.h"
 #include "llvm/Analysis/InstSimplifyFolder.h"
 #include "llvm/Analysis/InstructionSimplify.h"
+#include "llvm/Analysis/MemoryBuiltins.h"
 #include "llvm/Analysis/ValueTracking.h"
 #include "llvm/CodeGen/TargetPassConfig.h"
 #include "llvm/IR/IRBuilder.h"
@@ -805,7 +806,9 @@
   // undef.
   SSAUpdater Updater;
   Updater.Initialize(VectorTy, "promotealloca");
-  Updater.AddAvailableValue(Alloca.getParent(), UndefValue::get(VectorTy));
+  Updater.AddAvailableValue(
+  Alloca.getParent(),
+  getInitialValueOfAllocation(&Alloca, nullptr, VectorTy));
 
   // First handle the initial worklist.
   SmallVector DeferredLoads;
Inde

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver updated this revision to Diff 542618.
jmciver added a comment.

Remove reliance on TLI objects where only alloca instructions are processes


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

Files:
  llvm/include/llvm/Analysis/MemoryBuiltins.h
  llvm/lib/Analysis/MemoryBuiltins.cpp
  llvm/lib/Transforms/Scalar/GVN.cpp
  llvm/lib/Transforms/Scalar/NewGVN.cpp
  llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp

Index: llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
===
--- llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
+++ llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
@@ -24,6 +24,7 @@
 #include "llvm/Analysis/AssumptionCache.h"
 #include "llvm/Analysis/InstructionSimplify.h"
 #include "llvm/Analysis/IteratedDominanceFrontier.h"
+#include "llvm/Analysis/MemoryBuiltins.h"
 #include "llvm/Analysis/ValueTracking.h"
 #include "llvm/IR/BasicBlock.h"
 #include "llvm/IR/CFG.h"
@@ -600,7 +601,7 @@
 if (I == StoresByIndex.begin()) {
   if (StoresByIndex.empty())
 // If there are no stores, the load takes the undef value.
-ReplVal = UndefValue::get(LI->getType());
+ReplVal = getInitialValueOfAllocation(AI, nullptr, LI->getType());
   else
 // There is no store before this load, bail out (load may be affected
 // by the following stores - see main comment).
Index: llvm/lib/Transforms/Scalar/NewGVN.cpp
===
--- llvm/lib/Transforms/Scalar/NewGVN.cpp
+++ llvm/lib/Transforms/Scalar/NewGVN.cpp
@@ -1489,21 +1489,18 @@
   if (LoadPtr != lookupOperandLeader(DepInst) &&
   !AA->isMustAlias(LoadPtr, DepInst))
 return nullptr;
-  // If this load really doesn't depend on anything, then we must be loading an
-  // undef value.  This can happen when loading for a fresh allocation with no
-  // intervening stores, for example.  Note that this is only true in the case
-  // that the result of the allocation is pointer equal to the load ptr.
-  if (isa(DepInst)) {
-return createConstantExpression(UndefValue::get(LoadType));
-  }
   // If this load occurs either right after a lifetime begin,
   // then the loaded value is undefined.
-  else if (auto *II = dyn_cast(DepInst)) {
+  if (auto *II = dyn_cast(DepInst)) {
 if (II->getIntrinsicID() == Intrinsic::lifetime_start)
   return createConstantExpression(UndefValue::get(LoadType));
-  } else if (auto *InitVal =
- getInitialValueOfAllocation(DepInst, TLI, LoadType))
-  return createConstantExpression(InitVal);
+  }
+  // If this load really doesn't depend on anything, then we must be loading an
+  // undef value.  This can happen when loading for a fresh allocation with no
+  // intervening stores, for example.  Note that this is only true in the case
+  // that the result of the allocation is pointer equal to the load ptr.
+  else if (auto *InitVal = getInitialValueOfAllocation(DepInst, TLI, LoadType))
+return createConstantExpression(InitVal);
 
   return nullptr;
 }
Index: llvm/lib/Transforms/Scalar/GVN.cpp
===
--- llvm/lib/Transforms/Scalar/GVN.cpp
+++ llvm/lib/Transforms/Scalar/GVN.cpp
@@ -1240,11 +1240,12 @@
   }
   assert(DepInfo.isDef() && "follows from above");
 
-  // Loading the alloca -> undef.
   // Loading immediately after lifetime begin -> undef.
-  if (isa(DepInst) || isLifetimeStart(DepInst))
+  if (isLifetimeStart(DepInst))
 return AvailableValue::get(UndefValue::get(Load->getType()));
 
+  // In addition to allocator function calls this includes loading the alloca ->
+  // undef.
   if (Constant *InitVal =
   getInitialValueOfAllocation(DepInst, TLI, Load->getType()))
 return AvailableValue::get(InitVal);
Index: llvm/lib/Analysis/MemoryBuiltins.cpp
===
--- llvm/lib/Analysis/MemoryBuiltins.cpp
+++ llvm/lib/Analysis/MemoryBuiltins.cpp
@@ -436,6 +436,9 @@
 Constant *llvm::getInitialValueOfAllocation(const Value *V,
 const TargetLibraryInfo *TLI,
 Type *Ty) {
+  if (isa(V))
+return UndefValue::get(Ty);
+
   auto *Alloc = dyn_cast(V);
   if (!Alloc)
 return nullptr;
Index: llvm/include/llvm/Analysis/MemoryBuiltins.h
===
--- llvm/include/llvm/Analysis/MemoryBuiltins.h
+++ llvm/include/llvm/Analysis/MemoryBuiltins.h
@@ -119,8 +119,8 @@
 });
 
 /// If this is a call to an allocation function that initializes memory to a
-/// fixed value, return said value in the requested type.  Otherwise, return
-/// nullptr.
+/// fixed value, return said value in the requested type. If this is a call to
+/// alloca instruction the returned value is 

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver added a comment.

@nikic as per my GSoC project I am trying, under the guidance of @nlopes, a 
load attribute based approach to migrating uninitialized load to poison. The 
first attribute that I am working on is !freeze which effectively inserts a 
freeze poison if the load is uninitialized. Obviously this can only be done in
optimizations that allow instruction creation. In the future I am looking to 
add a load instruction parameter to getInitialValueOfAllocation to allow 
modification of the returned constant based on the allocation 
function/instruction and the presence of a load attribute.

So why pack the alloca test into getInitialValueOfAllocation? The reasoning is 
that attribute is on a per-load instruction, but allocation could be alloca or 
function. I agree if the application of the load attribute were universal 
passing in the default value to mem2reg would work, but as we are modulating 
the returned constant based on individual load instruction attributes this 
would not work. Hence the query based approach.

As for the TLI I agree that making it required is probably not ideal. @nlopes 
can vouch that I thought about this :-). Two options off the top of my head are:

1. Make the TLI parameter of getInitialValueOfAllocation a pointer with 
defaults to nullptr.

2. Add a separated query function for alloca instructions.

The advantage to option 1 is all allocation initial state queries are handled 
in one place. The detractor is we have a parameter that has a default nullptr.

The advantage to option 2 is allocation functions vs alloca instruction are 
handled by functions that have only the required parameterizations exposed. The 
detractor is there will be some combinatorial overlap between the two functions.

Thoughts?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[Nikita Popov via Phabricator via cfe-commits]

nikic requested changes to this revision.
nikic added a comment.
This revision now requires changes to proceed.

> This commit is in support of future uninitialized memory handling and adds
> alloca instruction support to getInitialValueOfAllocation. This unifies 
> initial
> memory state querying (both stack and heap) to a single utility function.

Could you explain in more detail what future work you have based on this? Is 
this about the promotion of malloc (and similar) memory?

In any case, I don't think it's acceptable to go through TLI as a required 
dependency for mem2reg. Alloca promotion doesn't need it, and that's what all 
the existing code is doing. This should at least be an optional dependency.

However, I think it would be better to directly pass the initial value to 
mem2reg instead (defaulting to UndefValue), rather than making it query it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D155773: [llvm][MemoryBuiltins] Add alloca support to getInitialValueOfAllocation

[John McIver via Phabricator via cfe-commits]

jmciver created this revision.
jmciver added reviewers: nikic, efriedma, fhahn.
Herald added subscribers: kmitropoulou, ormris, ChuanqiXu, StephenFan, wenlei, 
steven_wu, hiraditya.
Herald added a project: All.
jmciver published this revision for review.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This commit is in support of future uninitialized memory handling and adds
alloca instruction support to getInitialValueOfAllocation. This unifies initial
memory state querying (both stack and heap) to a single utility function.

Several optimizations are refactored to take advantage of alloca support in
getInitialValueOfAllocation, see below list. A majority of the optimizations are
effected by the migration of PromoteMemToReg to use getInitialValueOfAllocation,
which requires TLI for allocation function data, but is not used in support of
alloca instructions.

- PromoteMemToReg
- Mem2Reg
- IPO
- CoroSplit
- Coroutines (clang)
- GVN
- NewGVN
- Statepoint

Coroutines have a clang based optimization call to PromoteMemToReg from
FinishFunction, which requires a TLI object outside of the optimization pass
framework. Generation of the TLI is added at the module level to prevent
generation of multiple TLI objects for each coroutine function contained
within. Furthermore generation of the TLI object is lazy.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155773

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  llvm/include/llvm/Analysis/MemoryBuiltins.h
  llvm/include/llvm/Transforms/Scalar/SROA.h
  llvm/include/llvm/Transforms/Utils/PromoteMemToReg.h
  llvm/lib/Analysis/MemoryBuiltins.cpp
  llvm/lib/Transforms/Coroutines/CoroFrame.cpp
  llvm/lib/Transforms/Coroutines/CoroInternal.h
  llvm/lib/Transforms/Coroutines/CoroSplit.cpp
  llvm/lib/Transforms/IPO/ArgumentPromotion.cpp
  llvm/lib/Transforms/Scalar/GVN.cpp
  llvm/lib/Transforms/Scalar/NewGVN.cpp
  llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
  llvm/lib/Transforms/Scalar/SROA.cpp
  llvm/lib/Transforms/Utils/Mem2Reg.cpp
  llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll

Index: llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
@@ -39,8 +39,8 @@
 ; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
 ; CHECK-O-NEXT: Running pass: SROAPass
 ; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
-; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
+; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O3-NEXT: Running pass: CallSiteSplittingPass
 ; CHECK-O-NEXT: Running pass: SampleProfileLoaderPass
 ; CHECK-O-NEXT: Running analysis: ProfileSummaryAnalysis
Index: llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
@@ -40,8 +40,8 @@
 ; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
 ; CHECK-O-NEXT: Running pass: SROAPass
 ; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
-; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
+; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O3-NEXT: Running pass: CallSiteSplittingPass
 ; CHECK-O-NEXT: Running pass: OpenMPOptPass
 ; CHECK-O-NEXT: Running pass: IPSCCPPass
Index: llvm/test/Other/new-pm-thinlto-prelink-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-defaults.ll
@@ -52,8 +52,8 @@
 ; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
 ; CHECK-O-NEXT: Running pass: SROAPass
 ; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
-; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
+; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O3-NEXT: Running pass: CallSiteSplittingPass
 ; CHECK-O-NEXT: Running pass: OpenMPOptPass
 ; CHECK-O-NEXT: Running pass: IPSCCPPass
Index: llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
@@ -38,8 +38,8 @@
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: Ru