Added a Printer to the FunctionPropertiesAnalysis [Obsolete]

[tarinduj]

Summary

A PrinterPass and a lit test case was added.

[mtrofin]

What's the value of having the result type have the analyze method? Is there a scenario where we want to get the result and then re-analyze it?

[jdoerfert]

In D82270#2106860, @mtrofin wrote:

What's the value of having the result type have the analyze method? Is there a scenario where we want to get the result and then re-analyze it?

In the new-PM if you preserve the analysis it doesn't need to be recomputed, I thought. Or maybe I misunderstand your question. Could you elaborate?

[EDIT: Do you mean the ...Info struct? It is used by two passes, right?]

[mtrofin]

In D82270#2109923, @jdoerfert wrote:

In D82270#2106860, @mtrofin wrote:

What's the value of having the result type have the analyze method? Is there a scenario where we want to get the result and then re-analyze it?

In the new-PM if you preserve the analysis it doesn't need to be recomputed, I thought. Or maybe I misunderstand your question. Could you elaborate?

[EDIT: Do you mean the ...Info struct? It is used by two passes, right?]

What I mean was, why not let the computation happen in the Analysis::run, and the Info is basically an object not meant to be mutated. This is because the PM will call ::run to recompute, and we don't really have (or want to have) a scenario where we want someone to call Info::analyze() (unless I'm missing something)

[jdoerfert]

In D82270#2110007, @mtrofin wrote:

In D82270#2109923, @jdoerfert wrote:

In D82270#2106860, @mtrofin wrote:

What's the value of having the result type have the analyze method? Is there a scenario where we want to get the result and then re-analyze it?

In the new-PM if you preserve the analysis it doesn't need to be recomputed, I thought. Or maybe I misunderstand your question. Could you elaborate?

[EDIT: Do you mean the ...Info struct? It is used by two passes, right?]

What I mean was, why not let the computation happen in the Analysis::run, and the Info is basically an object not meant to be mutated. This is because the PM will call ::run to recompute, and we don't really have (or want to have) a scenario where we want someone to call Info::analyze() (unless I'm missing something)

Oh, I see. This is a common pattern, I think. Mostly because it allows the passes to be minimal wrappers. This is good as we might want to have an old-PM pass as well. Then you want the analyze in the info "for sure". Even without an old-PM pass, this way allows old-PM cgscc passes to create the info object and populate it, something that doesn't work in the old-PM through the pass mechanism.

Is there a strong reason or is it more a design preference?

[mtrofin]

In D82270#2111746, @jdoerfert wrote:

In D82270#2110007, @mtrofin wrote:

In D82270#2109923, @jdoerfert wrote:

In D82270#2106860, @mtrofin wrote:

What's the value of having the result type have the analyze method? Is there a scenario where we want to get the result and then re-analyze it?

In the new-PM if you preserve the analysis it doesn't need to be recomputed, I thought. Or maybe I misunderstand your question. Could you elaborate?

[EDIT: Do you mean the ...Info struct? It is used by two passes, right?]

What I mean was, why not let the computation happen in the Analysis::run, and the Info is basically an object not meant to be mutated. This is because the PM will call ::run to recompute, and we don't really have (or want to have) a scenario where we want someone to call Info::analyze() (unless I'm missing something)

Oh, I see. This is a common pattern, I think. Mostly because it allows the passes to be minimal wrappers. This is good as we might want to have an old-PM pass as well. Then you want the analyze in the info "for sure". Even without an old-PM pass, this way allows old-PM cgscc passes to create the info object and populate it, something that doesn't work in the old-PM through the pass mechanism.

Is there a strong reason or is it more a design preference?

It's a design preference, under the belief that clarity in design helps readability and maintainability.

To unblock this patch, perhaps we could separate that refactoring from the printer part of the patch?

Sounds like we need the Info's self-refreshing ability to support old-PM scenarios, correct? If I understand it correctly, there, the Info object could be retrieved from the analysis (this'd be an old-PM analysis, to be added), and then the client could refresh it without the involvement of the analysis or analysis manager, but updating the state the Analysis manager. Is that even desirable?

[jdoerfert]

In D82270#2111884, @mtrofin wrote:

Sounds like we need the Info's self-refreshing ability to support old-PM scenarios, correct? If I understand it correctly, there, the Info object could be retrieved from the analysis (this'd be an old-PM analysis, to be added), and then the client could refresh it without the involvement of the analysis or analysis manager, but updating the state the Analysis manager. Is that even desirable?

Its for the old-PM scenario but there is no need for the result to be self-refreshing. The key point is that the analyze method is shared, thus not part of the new-PM pass. If we want a immutable result we can again create a Result class in the FunctionPropertiesInfo. I don't mind that either way as long as analyze (and print) logic is outside of FunctionPropertiesAnalysis I'm happy. Does that make sense?

[mtrofin]

In D82270#2112379, @jdoerfert wrote:

In D82270#2111884, @mtrofin wrote:

Sounds like we need the Info's self-refreshing ability to support old-PM scenarios, correct? If I understand it correctly, there, the Info object could be retrieved from the analysis (this'd be an old-PM analysis, to be added), and then the client could refresh it without the involvement of the analysis or analysis manager, but updating the state the Analysis manager. Is that even desirable?

Its for the old-PM scenario but there is no need for the result to be self-refreshing. The key point is that the analyze method is shared, thus not part of the new-PM pass. If we want a immutable result we can again create a Result class in the FunctionPropertiesInfo. I don't mind that either way as long as analyze (and print) logic is outside of FunctionPropertiesAnalysis I'm happy. Does that make sense?

could it be shared by having it as a static (basically, factory method) on FunctionPropertiesInfo?

[jdoerfert]

In D82270#2110007, @mtrofin wrote:

In D82270#2109923, @jdoerfert wrote:

In D82270#2106860, @mtrofin wrote:

What's the value of having the result type have the analyze method? Is there a scenario where we want to get the result and then re-analyze it?

In the new-PM if you preserve the analysis it doesn't need to be recomputed, I thought. Or maybe I misunderstand your question. Could you elaborate?

[EDIT: Do you mean the ...Info struct? It is used by two passes, right?]

What I mean was, why not let the computation happen in the Analysis::run, and the Info is basically an object not meant to be mutated. This is because the PM will call ::run to recompute, and we don't really have (or want to have) a scenario where we want someone to call Info::analyze() (unless I'm missing something)

Oh, I see. This is a common pattern, I think. Mostly because it allows the passes to be minimal wrappers. This is good as we might want to have an old-PM pass as well. Then you want the analyze in the info "for sure". Even without an old-PM pass, this way allows old-PM cgscc passes to create the info object and populate it, something that doesn't work in the old-PM through the pass mechanism.

Is there a strong reason or is it more a design preference?

In D82270#2112462, @mtrofin wrote:

In D82270#2112379, @jdoerfert wrote:

In D82270#2111884, @mtrofin wrote:

Sounds like we need the Info's self-refreshing ability to support old-PM scenarios, correct? If I understand it correctly, there, the Info object could be retrieved from the analysis (this'd be an old-PM analysis, to be added), and then the client could refresh it without the involvement of the analysis or analysis manager, but updating the state the Analysis manager. Is that even desirable?

Its for the old-PM scenario but there is no need for the result to be self-refreshing. The key point is that the analyze method is shared, thus not part of the new-PM pass. If we want a immutable result we can again create a Result class in the FunctionPropertiesInfo. I don't mind that either way as long as analyze (and print) logic is outside of FunctionPropertiesAnalysis I'm happy. Does that make sense?

could it be shared by having it as a static (basically, factory method) on FunctionPropertiesInfo?

sure.

[mtrofin]

In D82270#2112560, @jdoerfert wrote:

In D82270#2110007, @mtrofin wrote:

In D82270#2109923, @jdoerfert wrote:

In D82270#2106860, @mtrofin wrote:

What's the value of having the result type have the analyze method? Is there a scenario where we want to get the result and then re-analyze it?

In the new-PM if you preserve the analysis it doesn't need to be recomputed, I thought. Or maybe I misunderstand your question. Could you elaborate?

[EDIT: Do you mean the ...Info struct? It is used by two passes, right?]

What I mean was, why not let the computation happen in the Analysis::run, and the Info is basically an object not meant to be mutated. This is because the PM will call ::run to recompute, and we don't really have (or want to have) a scenario where we want someone to call Info::analyze() (unless I'm missing something)

Oh, I see. This is a common pattern, I think. Mostly because it allows the passes to be minimal wrappers. This is good as we might want to have an old-PM pass as well. Then you want the analyze in the info "for sure". Even without an old-PM pass, this way allows old-PM cgscc passes to create the info object and populate it, something that doesn't work in the old-PM through the pass mechanism.

Is there a strong reason or is it more a design preference?

In D82270#2112462, @mtrofin wrote:

In D82270#2112379, @jdoerfert wrote:

In D82270#2111884, @mtrofin wrote:

Sounds like we need the Info's self-refreshing ability to support old-PM scenarios, correct? If I understand it correctly, there, the Info object could be retrieved from the analysis (this'd be an old-PM analysis, to be added), and then the client could refresh it without the involvement of the analysis or analysis manager, but updating the state the Analysis manager. Is that even desirable?

Its for the old-PM scenario but there is no need for the result to be self-refreshing. The key point is that the analyze method is shared, thus not part of the new-PM pass. If we want a immutable result we can again create a Result class in the FunctionPropertiesInfo. I don't mind that either way as long as analyze (and print) logic is outside of FunctionPropertiesAnalysis I'm happy. Does that make sense?

could it be shared by having it as a static (basically, factory method) on FunctionPropertiesInfo?

sure.

deal :)

I think it'd still make sense to split the patch one chunk to refactor (NFC), one to add the printer with test and all that - wdyt?

[tarinduj]

In D82270#2112641, @mtrofin wrote:

I think it'd still make sense to split the patch one chunk to refactor (NFC), one to add the printer with test and all that - wdyt?

Yeah, it makes sense. I'll split it and add two patches.

llvm/include/llvm/Analysis/ML/FunctionPropertiesAnalysis.h

+//===- FunctionPropertiesAnalysis.h - Function Properties Analysis ----------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file defines the FunctionPropertiesInfo and FunctionPropertiesAnalysis 
+// classes used to extract function properties. 
+//
+//===----------------------------------------------------------------------===//
+
 #ifndef LLVM_FUNCTIONPROPERTIESANALYSIS_H_
 #define LLVM_FUNCTIONPROPERTIESANALYSIS_H_
 

 namespace llvm {
 class Function;
 
-class FunctionPropertiesAnalysis
-    : public AnalysisInfoMixin<FunctionPropertiesAnalysis> {
-public:
-  static AnalysisKey Key;
-  struct Result {
+class FunctionPropertiesInfo{
+  public:
     /// Number of basic blocks
     int64_t BasicBlockCount = 0;
 

     /// Number of direct calls made from this function to other functions
     /// defined in this module.
     int64_t DirectCallsToDefinedFunctions = 0;
-  };
-  Result run(const Function &F, FunctionAnalysisManager &FAM);
+
+    void analyze(const Function &F);
+
+    void print(raw_ostream &OS) const;
+};
+
+//Analysis pass
+class FunctionPropertiesAnalysis 
+    : public AnalysisInfoMixin<FunctionPropertiesAnalysis> {
+
+  public:
+    static AnalysisKey Key;
+
+    using Result = FunctionPropertiesInfo;
+    
+    Result run(Function &F, FunctionAnalysisManager &FAM);
+};
+
+/// Printer pass for the FunctionPropertiesAnalysis results.
+class FunctionPropertiesPrinterPass
+    : public PassInfoMixin<FunctionPropertiesPrinterPass> {
+  raw_ostream &OS;
+
+public:
+  explicit FunctionPropertiesPrinterPass(raw_ostream &OS) : OS(OS) {}
+
+  PreservedAnalyses run(Function &F, FunctionAnalysisManager &AM);
 };
 
 } // namespace llvm

llvm/lib/Analysis/ML/FunctionPropertiesAnalysis.cpp

+//===- FunctionPropertiesAnalysis.cpp - Function Properties Analysis ------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file defines the FunctionPropertiesInfo and FunctionPropertiesAnalysis 
+// classes used to extract function properties. 
+//
+//===----------------------------------------------------------------------===//
+
 #include "llvm/Analysis/ML/FunctionPropertiesAnalysis.h"
 #include "llvm/IR/Instructions.h"
+#include "llvm/Passes/PassBuilder.h"
+#include "llvm/Passes/PassPlugin.h"
+#include "llvm/Support/raw_ostream.h"
 
 using namespace llvm;
 
-AnalysisKey FunctionPropertiesAnalysis::Key;
+void FunctionPropertiesInfo::analyze(const Function &F) {
+  
+  Uses = ((!F.hasLocalLinkage()) ? 1 : 0) + F.getNumUses();
 
-FunctionPropertiesAnalysis::Result
-FunctionPropertiesAnalysis::run(const Function &F, FunctionAnalysisManager &FAM) {
-  Result Ret;
-  Ret.Uses = ((!F.hasLocalLinkage()) ? 1 : 0) + F.getNumUses();
   for (const auto &BB : F) {
-    ++Ret.BasicBlockCount;
+    ++BasicBlockCount;
+    
     if (const auto *BI = dyn_cast<BranchInst>(BB.getTerminator())) {
       if (BI->isConditional())
-        Ret.BlocksReachedFromConditionalInstruction += BI->getNumSuccessors();
-    } else if (const auto *SI = dyn_cast<SwitchInst>(BB.getTerminator()))
-      Ret.BlocksReachedFromConditionalInstruction +=
+        BlocksReachedFromConditionalInstruction += BI->getNumSuccessors();
+    } else if (const auto *SI = dyn_cast<SwitchInst>(BB.getTerminator())) {
+      BlocksReachedFromConditionalInstruction +=
           (SI->getNumCases() + (nullptr != SI->getDefaultDest()));
-    for (const auto &I : BB)
+    }
+
+    for (const auto &I : BB) {
       if (auto *CS = dyn_cast<CallBase>(&I)) {
         const auto *Callee = CS->getCalledFunction();
         if (Callee && !Callee->isIntrinsic() && !Callee->isDeclaration())
-          ++Ret.DirectCallsToDefinedFunctions;
-      }
-  }
-  return Ret;
-}
+          ++DirectCallsToDefinedFunctions;
+      }
+    }
+  }
+
+void FunctionPropertiesInfo::print(raw_ostream &OS) const {
+  OS << "BasicBlockCount: " << BasicBlockCount << "\n"
+     << "BlocksReachedFromConditionalInstruction: " << BlocksReachedFromConditionalInstruction << "\n"
+     << "Uses: " << Uses << "\n"
+     << "DirectCallsToDefinedFunctions: " << DirectCallsToDefinedFunctions << "\n\n";
+}
+
+AnalysisKey FunctionPropertiesAnalysis::Key;
+
+FunctionPropertiesInfo FunctionPropertiesAnalysis::run(Function &F, FunctionAnalysisManager &FAM) {
+  FunctionPropertiesInfo FPI;
+  FPI.analyze(F);
+  return FPI;
+}
+
+
+PreservedAnalyses FunctionPropertiesPrinterPass::run(Function &F, FunctionAnalysisManager &AM) {
+  OS << "Printing analysis results of CFA for function "
+     << "'" << F.getName() << "':"
+     << "\n";
+  AM.getResult<FunctionPropertiesAnalysis>(F).print(OS);
+  return PreservedAnalyses::all();
 

llvm/lib/Passes/PassRegistry.def

 FUNCTION_ANALYSIS("postdomtree", PostDominatorTreeAnalysis())
 FUNCTION_ANALYSIS("demanded-bits", DemandedBitsAnalysis())
 FUNCTION_ANALYSIS("domfrontier", DominanceFrontierAnalysis())
+FUNCTION_ANALYSIS("func-properties", FunctionPropertiesAnalysis())
 FUNCTION_ANALYSIS("loops", LoopAnalysis())
 FUNCTION_ANALYSIS("lazy-value-info", LazyValueAnalysis())
 FUNCTION_ANALYSIS("da", DependenceAnalysis())
-FUNCTION_ANALYSIS("func-properties", FunctionPropertiesAnalysis())
 FUNCTION_ANALYSIS("memdep", MemoryDependenceAnalysis())
 FUNCTION_ANALYSIS("memoryssa", MemorySSAAnalysis())
 FUNCTION_ANALYSIS("phi-values", PhiValuesAnalysis())

 FUNCTION_PASS("print<postdomtree>", PostDominatorTreePrinterPass(dbgs()))
 FUNCTION_PASS("print<demanded-bits>", DemandedBitsPrinterPass(dbgs()))
 FUNCTION_PASS("print<domfrontier>", DominanceFrontierPrinterPass(dbgs()))
+FUNCTION_PASS("print<func-properties>", FunctionPropertiesPrinterPass(dbgs()))
 FUNCTION_PASS("print<loops>", LoopPrinterPass(dbgs()))
 FUNCTION_PASS("print<memoryssa>", MemorySSAPrinterPass(dbgs()))
 FUNCTION_PASS("print<phi-values>", PhiValuesPrinterPass(dbgs()))

llvm/test/Analysis/ML/FunctionPropertiesAnalysis/matmul.ll

+; RUN: opt < %s -passes='print<func-properties>' -disable-output 2>&1 | FileCheck %s
+
+define i32 @main() {
+; CHECK-DAG: Printing analysis results of CFA for function 'main':
+
+entry:
+  %retval = alloca i32, align 4
+  %mat1 = alloca [2 x [2 x i32]], align 16
+  %mat2 = alloca [2 x [2 x i32]], align 16
+  %res = alloca [2 x [2 x i32]], align 16
+  %i = alloca i32, align 4
+  %j = alloca i32, align 4
+  store i32 0, i32* %retval, align 4
+  %arraydecay = getelementptr inbounds [2 x [2 x i32]], [2 x [2 x i32]]* %mat1, i64 0, i64 0
+  %arraydecay1 = getelementptr inbounds [2 x [2 x i32]], [2 x [2 x i32]]* %mat2, i64 0, i64 0
+  %arraydecay2 = getelementptr inbounds [2 x [2 x i32]], [2 x [2 x i32]]* %res, i64 0, i64 0
+  call void @multiply([2 x i32]* %arraydecay, [2 x i32]* %arraydecay1, [2 x i32]* %arraydecay2)
+  ret i32 0
+}
+; CHECK-DAG: BasicBlockCount: 1
+; CHECK-DAG: BlocksReachedFromConditionalInstruction: 0
+; CHECK-DAG: Uses: 1
+; CHECK-DAG: DirectCallsToDefinedFunctions: 1
+
+define void @multiply([2 x i32]* %mat1, [2 x i32]* %mat2, [2 x i32]* %res) {
+; CHECK-DAG: Printing analysis results of CFA for function 'multiply':
+entry:
+  %mat1.addr = alloca [2 x i32]*, align 8
+  %mat2.addr = alloca [2 x i32]*, align 8
+  %res.addr = alloca [2 x i32]*, align 8
+  %i = alloca i32, align 4
+  %j = alloca i32, align 4
+  %k = alloca i32, align 4
+  store [2 x i32]* %mat1, [2 x i32]** %mat1.addr, align 8
+  store [2 x i32]* %mat2, [2 x i32]** %mat2.addr, align 8
+  store [2 x i32]* %res, [2 x i32]** %res.addr, align 8
+  store i32 0, i32* %i, align 4
+  br label %for.cond
+
+for.cond:                                         ; preds = %for.inc24, %entry
+  %0 = load i32, i32* %i, align 4
+  %cmp = icmp slt i32 %0, 2
+  br i1 %cmp, label %for.body, label %for.end26
+
+for.body:                                         ; preds = %for.cond
+  store i32 0, i32* %j, align 4
+  br label %for.cond1
+
+for.cond1:                                        ; preds = %for.inc21, %for.body
+  %1 = load i32, i32* %j, align 4
+  %cmp2 = icmp slt i32 %1, 2
+  br i1 %cmp2, label %for.body3, label %for.end23
+
+for.body3:                                        ; preds = %for.cond1
+  %2 = load [2 x i32]*, [2 x i32]** %res.addr, align 8
+  %3 = load i32, i32* %i, align 4
+  %idxprom = sext i32 %3 to i64
+  %arrayidx = getelementptr inbounds [2 x i32], [2 x i32]* %2, i64 %idxprom
+  %4 = load i32, i32* %j, align 4
+  %idxprom4 = sext i32 %4 to i64
+  %arrayidx5 = getelementptr inbounds [2 x i32], [2 x i32]* %arrayidx, i64 0, i64 %idxprom4
+  store i32 0, i32* %arrayidx5, align 4
+  store i32 0, i32* %k, align 4
+  br label %for.cond6
+
+for.cond6:                                        ; preds = %for.inc, %for.body3
+  %5 = load i32, i32* %k, align 4
+  %cmp7 = icmp slt i32 %5, 2
+  br i1 %cmp7, label %for.body8, label %for.end
+
+for.body8:                                        ; preds = %for.cond6
+  %6 = load [2 x i32]*, [2 x i32]** %mat1.addr, align 8
+  %7 = load i32, i32* %i, align 4
+  %idxprom9 = sext i32 %7 to i64
+  %arrayidx10 = getelementptr inbounds [2 x i32], [2 x i32]* %6, i64 %idxprom9
+  %8 = load i32, i32* %k, align 4
+  %idxprom11 = sext i32 %8 to i64
+  %arrayidx12 = getelementptr inbounds [2 x i32], [2 x i32]* %arrayidx10, i64 0, i64 %idxprom11
+  %9 = load i32, i32* %arrayidx12, align 4
+  %10 = load [2 x i32]*, [2 x i32]** %mat2.addr, align 8
+  %11 = load i32, i32* %k, align 4
+  %idxprom13 = sext i32 %11 to i64
+  %arrayidx14 = getelementptr inbounds [2 x i32], [2 x i32]* %10, i64 %idxprom13
+  %12 = load i32, i32* %j, align 4
+  %idxprom15 = sext i32 %12 to i64
+  %arrayidx16 = getelementptr inbounds [2 x i32], [2 x i32]* %arrayidx14, i64 0, i64 %idxprom15
+  %13 = load i32, i32* %arrayidx16, align 4
+  %mul = mul nsw i32 %9, %13
+  %14 = load [2 x i32]*, [2 x i32]** %res.addr, align 8
+  %15 = load i32, i32* %i, align 4
+  %idxprom17 = sext i32 %15 to i64
+  %arrayidx18 = getelementptr inbounds [2 x i32], [2 x i32]* %14, i64 %idxprom17
+  %16 = load i32, i32* %j, align 4
+  %idxprom19 = sext i32 %16 to i64
+  %arrayidx20 = getelementptr inbounds [2 x i32], [2 x i32]* %arrayidx18, i64 0, i64 %idxprom19
+  %17 = load i32, i32* %arrayidx20, align 4
+  %add = add nsw i32 %17, %mul
+  store i32 %add, i32* %arrayidx20, align 4
+  br label %for.inc
+
+for.inc:                                          ; preds = %for.body8
+  %18 = load i32, i32* %k, align 4
+  %inc = add nsw i32 %18, 1
+  store i32 %inc, i32* %k, align 4
+  br label %for.cond6
+
+for.end:                                          ; preds = %for.cond6
+  br label %for.inc21
+
+for.inc21:                                        ; preds = %for.end
+  %19 = load i32, i32* %j, align 4
+  %inc22 = add nsw i32 %19, 1
+  store i32 %inc22, i32* %j, align 4
+  br label %for.cond1
+
+for.end23:                                        ; preds = %for.cond1
+  br label %for.inc24
+
+for.inc24:                                        ; preds = %for.end23
+  %20 = load i32, i32* %i, align 4
+  %inc25 = add nsw i32 %20, 1
+  store i32 %inc25, i32* %i, align 4
+  br label %for.cond
+
+for.end26:                                        ; preds = %for.cond
+  ret void
+}
+
+; CHECK-DAG: BasicBlockCount: 13
+; CHECK-DAG: BlocksReachedFromConditionalInstruction: 6
+; CHECK-DAG: Uses: 2
+; CHECK-DAG: DirectCallsToDefinedFunctions: 0
 No newline at end of file

llvm/unittests/Analysis/ML/FunctionPropertiesAnalysisTest.cpp

-//===- FunctionPropertiesAnalysisTest.cpp - function properties unit tests --------===//
+//===- FunctionPropertiesAnalysisTest.cpp - Function Properties Unit Tests -===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.