llvm-project/mlir/lib/Analysis/DataFlow/LivenessAnalysis.cpp
Srishti Srivastava de826ea35d [MLIR][ANALYSIS] Add liveness analysis utility
This commit adds a utility to implement liveness analysis using the
sparse backward data-flow analysis framework. Theoretically, liveness
analysis assigns liveness to each (value, program point) pair in the
program and it is thus a dense analysis. However, since values are
immutable in MLIR, a sparse analysis, which will assign liveness to
each value in the program, suffices here.

Liveness analysis has many applications. It can be used to avoid the
computation of extraneous operations that have no effect on the memory
or the final output of a program. It can also be used to optimize
register allocation. Both of these applications help achieve one very
important goal: reducing runtime.

A value is considered "live" iff it:
  (1) has memory effects OR
  (2) is returned by a public function OR
  (3) is used to compute a value of type (1) or (2).
It is also to be noted that a value could be of multiple types (1/2/3) at
the same time.

A value "has memory effects" iff it:
  (1.a) is an operand of an op with memory effects OR
  (1.b) is a non-forwarded branch operand and a block where its op could
  take the control has an op with memory effects.

A value `A` is said to be "used to compute" value `B` iff `B` cannot be
computed in the absence of `A`. Thus, in this implementation, we say that
value `A` is used to compute value `B` iff:
  (3.a) `B` is a result of an op with operand `A` OR
  (3.b) `A` is used to compute some value `C` and `C` is used to compute
  `B`.

---

It is important to note that there already exists an MLIR liveness
utility here: llvm-project/mlir/include/mlir/Analysis/Liveness.h. So,
what is the need for this new liveness analysis utility being added by
this commit? That need is explained as follows:-

The similarities between these two utilities is that both use the
fixpoint iteration method to converge to the final result of liveness.
And, both have the same theoretical understanding of liveness as well.

However, the main difference between (a) the existing utility and (b)
the added utility is the "scope of the analysis". (a) is restricted to
analysing each block independently while (b) analyses blocks together,
i.e., it looks at how the control flows from one block to the other,
how a caller calls a callee, etc. The restriction in the former implies
that some potentially non-live values could be marked live and thus the
full potential of liveness analysis will not be realised.

This can be understood using the example below:

```
1 func.func private @private_dead_return_value_removal_0() -> (i32, i32) {
2   %0 = arith.constant 0 : i32
3   %1 = arith.addi %0, %0 : i32
4   return %0, %1 : i32, i32
5 }
6 func.func @public_dead_return_value_removal_0() -> (i32) {
7   %0:2 = func.call @private_dead_return_value_removal_0() : () -> (i32, i32)
8   return %0#0 : i32
9 }
```

Here, if we just restrict our analysis to a per-block basis like (a), we
will say that the %1 on line 3 is live because it is computed and then
returned outside its block by the function. But, if we perform a
backward data-flow analysis like (b) does, we will say that %0#1 of line
7 is not live because it isn't returned by the public function and thus,
%1 of line 3 is also not live. So, while (a) will be unable to suggest
any IR optimizations, (b) can enable this IR to convert to:-

```
1 func.func private @private_dead_return_value_removal_0() -> i32 {
2   %0 = arith.constant 0 : i32
3   return %0 : i32
4 }
5 func.func @public_dead_return_value_removal_0() -> i32 {
6   %0 = call @private_dead_return_value_removal_0() : () -> i32
7   return %0 : i32
8 }
```

One operation was removed and one unnecessary return value of the
function was removed and the function signature was modified. This is an
optimization that (b) can enable but (a) cannot. Such optimizations can
help remove a lot of extraneous computations that are currently being
done.

Signed-off-by: Srishti Srivastava <srishtisrivastava.ai@gmail.com>

Reviewed By: matthiaskramm, jcai19

Differential Revision: https://reviews.llvm.org/D153779
2023-07-21 13:29:14 -07:00

191 lines
7.6 KiB
C++

//===- LivenessAnalysis.cpp - Liveness 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
//
//===----------------------------------------------------------------------===//
#include <mlir/Analysis/DataFlow/LivenessAnalysis.h>
#include <mlir/Analysis/DataFlow/ConstantPropagationAnalysis.h>
#include <mlir/Analysis/DataFlow/DeadCodeAnalysis.h>
#include <mlir/Analysis/DataFlow/SparseAnalysis.h>
#include <mlir/Analysis/DataFlowFramework.h>
#include <mlir/IR/Operation.h>
#include <mlir/IR/Value.h>
#include <mlir/Interfaces/SideEffectInterfaces.h>
#include <mlir/Support/LLVM.h>
using namespace mlir;
using namespace mlir::dataflow;
//===----------------------------------------------------------------------===//
// Liveness
//===----------------------------------------------------------------------===//
void Liveness::print(raw_ostream &os) const {
os << (isLive ? "live" : "not live");
}
ChangeResult Liveness::markLive() {
bool wasLive = isLive;
isLive = true;
return wasLive ? ChangeResult::NoChange : ChangeResult::Change;
}
ChangeResult Liveness::meet(const AbstractSparseLattice &other) {
const auto *otherLiveness = reinterpret_cast<const Liveness *>(&other);
return otherLiveness->isLive ? markLive() : ChangeResult::NoChange;
}
//===----------------------------------------------------------------------===//
// LivenessAnalysis
//===----------------------------------------------------------------------===//
/// For every value, liveness analysis determines whether or not it is "live".
///
/// A value is considered "live" iff it:
/// (1) has memory effects OR
/// (2) is returned by a public function OR
/// (3) is used to compute a value of type (1) or (2).
/// It is also to be noted that a value could be of multiple types (1/2/3) at
/// the same time.
///
/// A value "has memory effects" iff it:
/// (1.a) is an operand of an op with memory effects OR
/// (1.b) is a non-forwarded branch operand and a block where its op could
/// take the control has an op with memory effects.
///
/// A value `A` is said to be "used to compute" value `B` iff `B` cannot be
/// computed in the absence of `A`. Thus, in this implementation, we say that
/// value `A` is used to compute value `B` iff:
/// (3.a) `B` is a result of an op with operand `A` OR
/// (3.b) `A` is used to compute some value `C` and `C` is used to compute
/// `B`.
void LivenessAnalysis::visitOperation(Operation *op,
ArrayRef<Liveness *> operands,
ArrayRef<const Liveness *> results) {
// This marks values of type (1.a) liveness as "live".
if (!isMemoryEffectFree(op)) {
for (auto *operand : operands)
propagateIfChanged(operand, operand->markLive());
}
// This marks values of type (3) liveness as "live".
bool foundLiveResult = false;
for (const Liveness *r : results) {
if (r->isLive && !foundLiveResult) {
// It is assumed that each operand is used to compute each result of an
// op. Thus, if at least one result is live, each operand is live.
for (Liveness *operand : operands)
meet(operand, *r);
foundLiveResult = true;
}
addDependency(const_cast<Liveness *>(r), op);
}
}
void LivenessAnalysis::visitBranchOperand(OpOperand &operand) {
// We know (at the moment) and assume (for the future) that `operand` is a
// non-forwarded branch operand of an op of type `RegionBranchOpInterface`,
// `BranchOpInterface`, or `RegionBranchTerminatorOpInterface`.
Operation *op = operand.getOwner();
assert((isa<RegionBranchOpInterface>(op) || isa<BranchOpInterface>(op) ||
isa<RegionBranchTerminatorOpInterface>(op)) &&
"expected the op to be `RegionBranchOpInterface`, "
"`BranchOpInterface`, or `RegionBranchTerminatorOpInterface`");
// The lattices of the non-forwarded branch operands don't get updated like
// the forwarded branch operands or the non-branch operands. Thus they need
// to be handled separately. This is where we handle them.
// This marks values of type (1.b) liveness as "live". A non-forwarded
// branch operand will be live if a block where its op could take the control
// has an op with memory effects.
// Populating such blocks in `blocks`.
SmallVector<Block *, 4> blocks;
if (isa<RegionBranchOpInterface>(op)) {
// When the op is a `RegionBranchOpInterface`, like an `scf.for` or an
// `scf.index_switch` op, its branch operand controls the flow into this
// op's regions.
for (Region &region : op->getRegions()) {
for (Block &block : region)
blocks.push_back(&block);
}
} else if (isa<BranchOpInterface>(op)) {
// When the op is a `BranchOpInterface`, like a `cf.cond_br` or a
// `cf.switch` op, its branch operand controls the flow into this op's
// successors.
blocks = op->getSuccessors();
} else {
// When the op is a `RegionBranchTerminatorOpInterface`, like a
// `scf.condition` op, its branch operand controls the flow into this op's
// parent's (which is a `RegionBranchOpInterface`'s) regions.
for (Region &region : op->getParentOp()->getRegions()) {
for (Block &block : region)
blocks.push_back(&block);
}
}
bool foundMemoryEffectingOp = false;
for (Block *block : blocks) {
if (foundMemoryEffectingOp)
break;
for (Operation &nestedOp : *block) {
if (!isMemoryEffectFree(&nestedOp)) {
Liveness *operandLiveness = getLatticeElement(operand.get());
propagateIfChanged(operandLiveness, operandLiveness->markLive());
foundMemoryEffectingOp = true;
break;
}
}
}
// Now that we have checked for memory-effecting ops in the blocks of concern,
// we will simply visit the op with this non-forwarded operand to potentially
// mark it "live" due to type (1.a/3) liveness.
if (operand.getOperandNumber() > 0)
return;
SmallVector<Liveness *, 4> operandLiveness;
operandLiveness.push_back(getLatticeElement(operand.get()));
SmallVector<const Liveness *, 4> resultsLiveness;
for (const Value result : op->getResults())
resultsLiveness.push_back(getLatticeElement(result));
visitOperation(op, operandLiveness, resultsLiveness);
// We also visit the parent op with the parent's results and this operand if
// `op` is a `RegionBranchTerminatorOpInterface` because its non-forwarded
// operand depends on not only its memory effects/results but also on those of
// its parent's.
if (!isa<RegionBranchTerminatorOpInterface>(op))
return;
Operation *parentOp = op->getParentOp();
SmallVector<const Liveness *, 4> parentResultsLiveness;
for (const Value parentResult : parentOp->getResults())
parentResultsLiveness.push_back(getLatticeElement(parentResult));
visitOperation(parentOp, operandLiveness, parentResultsLiveness);
}
void LivenessAnalysis::setToExitState(Liveness *lattice) {
// This marks values of type (2) liveness as "live".
lattice->markLive();
}
//===----------------------------------------------------------------------===//
// RunLivenessAnalysis
//===----------------------------------------------------------------------===//
RunLivenessAnalysis::RunLivenessAnalysis(Operation *op) {
SymbolTableCollection symbolTable;
solver.load<DeadCodeAnalysis>();
solver.load<SparseConstantPropagation>();
solver.load<LivenessAnalysis>(symbolTable);
(void)solver.initializeAndRun(op);
}
const Liveness *RunLivenessAnalysis::getLiveness(Value val) {
return solver.lookupState<Liveness>(val);
}