2012-03-16 06:51:52 +01:00
|
|
|
//===- CodeMetrics.cpp - Code cost measurements ---------------------------===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// 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
|
2012-03-16 06:51:52 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements code cost measurement utilities.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Analysis/CodeMetrics.h"
|
2020-04-13 14:09:08 +02:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2017-06-06 13:49:48 +02:00
|
|
|
#include "llvm/Analysis/AssumptionCache.h"
|
2014-09-07 15:49:57 +02:00
|
|
|
#include "llvm/Analysis/LoopInfo.h"
|
2013-01-21 14:04:33 +01:00
|
|
|
#include "llvm/Analysis/TargetTransformInfo.h"
|
2014-09-07 15:49:57 +02:00
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/Function.h"
|
2014-09-07 15:49:57 +02:00
|
|
|
#include "llvm/Support/Debug.h"
|
2021-02-11 11:25:14 +01:00
|
|
|
#include "llvm/Support/InstructionCost.h"
|
2014-09-07 15:49:57 +02:00
|
|
|
|
|
|
|
#define DEBUG_TYPE "code-metrics"
|
2012-03-16 06:51:52 +01:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2016-08-18 19:51:24 +02:00
|
|
|
static void
|
|
|
|
appendSpeculatableOperands(const Value *V,
|
|
|
|
SmallPtrSetImpl<const Value *> &Visited,
|
|
|
|
SmallVectorImpl<const Value *> &Worklist) {
|
|
|
|
const User *U = dyn_cast<User>(V);
|
|
|
|
if (!U)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (const Value *Operand : U->operands())
|
|
|
|
if (Visited.insert(Operand).second)
|
|
|
|
if (isSafeToSpeculativelyExecute(Operand))
|
|
|
|
Worklist.push_back(Operand);
|
|
|
|
}
|
2014-09-07 15:49:57 +02:00
|
|
|
|
2016-08-18 19:51:24 +02:00
|
|
|
static void completeEphemeralValues(SmallPtrSetImpl<const Value *> &Visited,
|
|
|
|
SmallVectorImpl<const Value *> &Worklist,
|
|
|
|
SmallPtrSetImpl<const Value *> &EphValues) {
|
2014-09-07 15:49:57 +02:00
|
|
|
// Note: We don't speculate PHIs here, so we'll miss instruction chains kept
|
|
|
|
// alive only by ephemeral values.
|
|
|
|
|
2016-08-18 19:51:24 +02:00
|
|
|
// Walk the worklist using an index but without caching the size so we can
|
|
|
|
// append more entries as we process the worklist. This forms a queue without
|
|
|
|
// quadratic behavior by just leaving processed nodes at the head of the
|
|
|
|
// worklist forever.
|
|
|
|
for (int i = 0; i < (int)Worklist.size(); ++i) {
|
|
|
|
const Value *V = Worklist[i];
|
Treat the WorkSet used to find ephemeral values as double-ended
We need to make sure that we visit all operands of an instruction before moving
deeper in the operand graph. We had been pushing operands onto the back of the work
set, and popping them off the back as well, meaning that we might visit an
instruction before visiting all of its uses that sit in between it and the call
to @llvm.assume.
To provide an explicit example, given the following:
%q0 = extractelement <4 x float> %rd, i32 0
%q1 = extractelement <4 x float> %rd, i32 1
%q2 = extractelement <4 x float> %rd, i32 2
%q3 = extractelement <4 x float> %rd, i32 3
%q4 = fadd float %q0, %q1
%q5 = fadd float %q2, %q3
%q6 = fadd float %q4, %q5
%qi = fcmp olt float %q6, %q5
call void @llvm.assume(i1 %qi)
%q5 is used by both %qi and %q6. When we visit %qi, it will be marked as
ephemeral, and we'll queue %q6 and %q5. %q6 will be marked as ephemeral and
we'll queue %q4 and %q5. Under the old system, we'd then visit %q4, which
would become ephemeral, %q1 and then %q0, which would become ephemeral as
well, and now we have a problem. We'd visit %rd, but it would not be marked as
ephemeral because we've not yet visited %q2 and %q3 (because we've not yet
visited %q5).
This will be covered by a test case in a follow-up commit that enables
ephemeral-value awareness in the SLP vectorizer.
llvm-svn: 219815
2014-10-15 19:34:48 +02:00
|
|
|
|
2016-08-18 19:51:24 +02:00
|
|
|
assert(Visited.count(V) &&
|
|
|
|
"Failed to add a worklist entry to our visited set!");
|
2014-09-07 15:49:57 +02:00
|
|
|
|
|
|
|
// If all uses of this value are ephemeral, then so is this value.
|
2016-08-11 23:15:00 +02:00
|
|
|
if (!all_of(V->users(), [&](const User *U) { return EphValues.count(U); }))
|
2014-09-07 15:49:57 +02:00
|
|
|
continue;
|
|
|
|
|
|
|
|
EphValues.insert(V);
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "Ephemeral Value: " << *V << "\n");
|
2014-09-07 15:49:57 +02:00
|
|
|
|
2016-08-18 19:51:24 +02:00
|
|
|
// Append any more operands to consider.
|
|
|
|
appendSpeculatableOperands(V, Visited, Worklist);
|
2014-09-07 15:49:57 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Find all ephemeral values.
|
2015-01-04 13:03:27 +01:00
|
|
|
void CodeMetrics::collectEphemeralValues(
|
2016-12-19 09:22:17 +01:00
|
|
|
const Loop *L, AssumptionCache *AC,
|
|
|
|
SmallPtrSetImpl<const Value *> &EphValues) {
|
2016-08-18 19:51:24 +02:00
|
|
|
SmallPtrSet<const Value *, 32> Visited;
|
|
|
|
SmallVector<const Value *, 16> Worklist;
|
2014-09-07 15:49:57 +02:00
|
|
|
|
2016-12-19 09:22:17 +01:00
|
|
|
for (auto &AssumeVH : AC->assumptions()) {
|
2021-02-11 19:03:20 +01:00
|
|
|
if (!AssumeVH)
|
|
|
|
continue;
|
|
|
|
Instruction *I = cast<Instruction>(AssumeVH);
|
2016-12-19 09:22:17 +01:00
|
|
|
|
|
|
|
// Filter out call sites outside of the loop so we don't do a function's
|
|
|
|
// worth of work for each of its loops (and, in the common case, ephemeral
|
|
|
|
// values in the loop are likely due to @llvm.assume calls in the loop).
|
|
|
|
if (!L->contains(I->getParent()))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (EphValues.insert(I).second)
|
|
|
|
appendSpeculatableOperands(I, Visited, Worklist);
|
|
|
|
}
|
2014-09-07 15:49:57 +02:00
|
|
|
|
2016-08-18 19:51:24 +02:00
|
|
|
completeEphemeralValues(Visited, Worklist, EphValues);
|
2014-09-07 15:49:57 +02:00
|
|
|
}
|
|
|
|
|
2015-01-04 13:03:27 +01:00
|
|
|
void CodeMetrics::collectEphemeralValues(
|
2016-12-19 09:22:17 +01:00
|
|
|
const Function *F, AssumptionCache *AC,
|
|
|
|
SmallPtrSetImpl<const Value *> &EphValues) {
|
2016-08-18 19:51:24 +02:00
|
|
|
SmallPtrSet<const Value *, 32> Visited;
|
|
|
|
SmallVector<const Value *, 16> Worklist;
|
2014-09-07 15:49:57 +02:00
|
|
|
|
2016-12-19 09:22:17 +01:00
|
|
|
for (auto &AssumeVH : AC->assumptions()) {
|
2021-02-11 19:03:20 +01:00
|
|
|
if (!AssumeVH)
|
|
|
|
continue;
|
|
|
|
Instruction *I = cast<Instruction>(AssumeVH);
|
2016-12-19 09:22:17 +01:00
|
|
|
assert(I->getParent()->getParent() == F &&
|
|
|
|
"Found assumption for the wrong function!");
|
|
|
|
|
|
|
|
if (EphValues.insert(I).second)
|
|
|
|
appendSpeculatableOperands(I, Visited, Worklist);
|
|
|
|
}
|
2014-09-07 15:49:57 +02:00
|
|
|
|
2016-08-18 19:51:24 +02:00
|
|
|
completeEphemeralValues(Visited, Worklist, EphValues);
|
2014-09-07 15:49:57 +02:00
|
|
|
}
|
|
|
|
|
2016-03-08 21:53:48 +01:00
|
|
|
/// Fill in the current structure with information gleaned from the specified
|
|
|
|
/// block.
|
[LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands.
D84108 exposed a bad interaction between inlining and loop-rotation
during regular LTO, which is causing notable regressions in at least
CINT2006/473.astar.
The problem boils down to: we now rotate a loop just before the vectorizer
which requires duplicating a function call in the preheader when compiling
the individual files ('prepare for LTO'). But this then prevents further
inlining of the function during LTO.
This patch tries to resolve this issue by making LoopRotate more
conservative with respect to rotating loops that have inline-able calls
during the 'prepare for LTO' stage.
I think this change intuitively improves the current situation in
general. Loop-rotate tries hard to avoid creating headers that are 'too
big'. At the moment, it assumes all inlining already happened and the
cost of duplicating a call is equal to just doing the call. But with LTO,
inlining also happens during full LTO and it is possible that a previously
duplicated call is actually a huge function which gets inlined
during LTO.
From the perspective of LV, not much should change overall. Most loops
calling user-provided functions won't get vectorized to start with
(unless we can infer that the function does not touch memory, has no
other side effects). If we do not inline the 'inline-able' call during
the LTO stage, we merely delayed loop-rotation & vectorization. If we
inline during LTO, chances should be very high that the inlined code is
itself vectorizable or the user call was not vectorizable to start with.
There could of course be scenarios where we inline a sufficiently large
function with code not profitable to vectorize, which would have be
vectorized earlier (by scalarzing the call). But even in that case,
there probably is no big performance impact, because it should be mostly
down to the cost-model to reject vectorization in that case. And then
the version with scalarized calls should also not be beneficial. In a way,
LV should have strictly more information after inlining and make more
accurate decisions (barring cost-model issues).
There is of course plenty of room for things to go wrong unexpectedly,
so we need to keep a close look at actual performance and address any
follow-up issues.
I took a look at the impact on statistics for
MultiSource/SPEC2000/SPEC2006. There are a few benchmarks with fewer
loops rotated, but no change to the number of loops vectorized.
Reviewed By: sanwou01
Differential Revision: https://reviews.llvm.org/D94232
2021-01-19 10:22:40 +01:00
|
|
|
void CodeMetrics::analyzeBasicBlock(
|
|
|
|
const BasicBlock *BB, const TargetTransformInfo &TTI,
|
|
|
|
const SmallPtrSetImpl<const Value *> &EphValues, bool PrepareForLTO) {
|
2012-03-16 06:51:52 +01:00
|
|
|
++NumBlocks;
|
2021-02-11 11:25:14 +01:00
|
|
|
// Use a proxy variable for NumInsts of type InstructionCost, so that it can
|
|
|
|
// use InstructionCost's arithmetic properties such as saturation when this
|
|
|
|
// feature is added to InstructionCost.
|
|
|
|
// When storing the value back to NumInsts, we can assume all costs are Valid
|
|
|
|
// because the IR should not contain any nodes that cannot be costed. If that
|
|
|
|
// happens the cost-model is broken.
|
|
|
|
InstructionCost NumInstsProxy = NumInsts;
|
|
|
|
InstructionCost NumInstsBeforeThisBB = NumInsts;
|
2016-03-08 21:53:48 +01:00
|
|
|
for (const Instruction &I : *BB) {
|
2014-09-07 15:49:57 +02:00
|
|
|
// Skip ephemeral values.
|
2016-03-08 21:53:48 +01:00
|
|
|
if (EphValues.count(&I))
|
2014-09-07 15:49:57 +02:00
|
|
|
continue;
|
|
|
|
|
2012-03-16 06:51:52 +01:00
|
|
|
// Special handling for calls.
|
2019-02-11 10:03:32 +01:00
|
|
|
if (const auto *Call = dyn_cast<CallBase>(&I)) {
|
|
|
|
if (const Function *F = Call->getCalledFunction()) {
|
2021-01-19 15:34:55 +01:00
|
|
|
bool IsLoweredToCall = TTI.isLoweredToCall(F);
|
2012-03-16 06:51:52 +01:00
|
|
|
// If a function is both internal and has a single use, then it is
|
|
|
|
// extremely likely to get inlined in the future (it was probably
|
|
|
|
// exposed by an interleaved devirtualization pass).
|
[LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands.
D84108 exposed a bad interaction between inlining and loop-rotation
during regular LTO, which is causing notable regressions in at least
CINT2006/473.astar.
The problem boils down to: we now rotate a loop just before the vectorizer
which requires duplicating a function call in the preheader when compiling
the individual files ('prepare for LTO'). But this then prevents further
inlining of the function during LTO.
This patch tries to resolve this issue by making LoopRotate more
conservative with respect to rotating loops that have inline-able calls
during the 'prepare for LTO' stage.
I think this change intuitively improves the current situation in
general. Loop-rotate tries hard to avoid creating headers that are 'too
big'. At the moment, it assumes all inlining already happened and the
cost of duplicating a call is equal to just doing the call. But with LTO,
inlining also happens during full LTO and it is possible that a previously
duplicated call is actually a huge function which gets inlined
during LTO.
From the perspective of LV, not much should change overall. Most loops
calling user-provided functions won't get vectorized to start with
(unless we can infer that the function does not touch memory, has no
other side effects). If we do not inline the 'inline-able' call during
the LTO stage, we merely delayed loop-rotation & vectorization. If we
inline during LTO, chances should be very high that the inlined code is
itself vectorizable or the user call was not vectorizable to start with.
There could of course be scenarios where we inline a sufficiently large
function with code not profitable to vectorize, which would have be
vectorized earlier (by scalarzing the call). But even in that case,
there probably is no big performance impact, because it should be mostly
down to the cost-model to reject vectorization in that case. And then
the version with scalarized calls should also not be beneficial. In a way,
LV should have strictly more information after inlining and make more
accurate decisions (barring cost-model issues).
There is of course plenty of room for things to go wrong unexpectedly,
so we need to keep a close look at actual performance and address any
follow-up issues.
I took a look at the impact on statistics for
MultiSource/SPEC2000/SPEC2006. There are a few benchmarks with fewer
loops rotated, but no change to the number of loops vectorized.
Reviewed By: sanwou01
Differential Revision: https://reviews.llvm.org/D94232
2021-01-19 10:22:40 +01:00
|
|
|
// When preparing for LTO, liberally consider calls as inline
|
|
|
|
// candidates.
|
2021-01-19 15:34:55 +01:00
|
|
|
if (!Call->isNoInline() && IsLoweredToCall &&
|
[LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands.
D84108 exposed a bad interaction between inlining and loop-rotation
during regular LTO, which is causing notable regressions in at least
CINT2006/473.astar.
The problem boils down to: we now rotate a loop just before the vectorizer
which requires duplicating a function call in the preheader when compiling
the individual files ('prepare for LTO'). But this then prevents further
inlining of the function during LTO.
This patch tries to resolve this issue by making LoopRotate more
conservative with respect to rotating loops that have inline-able calls
during the 'prepare for LTO' stage.
I think this change intuitively improves the current situation in
general. Loop-rotate tries hard to avoid creating headers that are 'too
big'. At the moment, it assumes all inlining already happened and the
cost of duplicating a call is equal to just doing the call. But with LTO,
inlining also happens during full LTO and it is possible that a previously
duplicated call is actually a huge function which gets inlined
during LTO.
From the perspective of LV, not much should change overall. Most loops
calling user-provided functions won't get vectorized to start with
(unless we can infer that the function does not touch memory, has no
other side effects). If we do not inline the 'inline-able' call during
the LTO stage, we merely delayed loop-rotation & vectorization. If we
inline during LTO, chances should be very high that the inlined code is
itself vectorizable or the user call was not vectorizable to start with.
There could of course be scenarios where we inline a sufficiently large
function with code not profitable to vectorize, which would have be
vectorized earlier (by scalarzing the call). But even in that case,
there probably is no big performance impact, because it should be mostly
down to the cost-model to reject vectorization in that case. And then
the version with scalarized calls should also not be beneficial. In a way,
LV should have strictly more information after inlining and make more
accurate decisions (barring cost-model issues).
There is of course plenty of room for things to go wrong unexpectedly,
so we need to keep a close look at actual performance and address any
follow-up issues.
I took a look at the impact on statistics for
MultiSource/SPEC2000/SPEC2006. There are a few benchmarks with fewer
loops rotated, but no change to the number of loops vectorized.
Reviewed By: sanwou01
Differential Revision: https://reviews.llvm.org/D94232
2021-01-19 10:22:40 +01:00
|
|
|
((F->hasInternalLinkage() && F->hasOneUse()) || PrepareForLTO)) {
|
2012-03-16 06:51:52 +01:00
|
|
|
++NumInlineCandidates;
|
[LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands.
D84108 exposed a bad interaction between inlining and loop-rotation
during regular LTO, which is causing notable regressions in at least
CINT2006/473.astar.
The problem boils down to: we now rotate a loop just before the vectorizer
which requires duplicating a function call in the preheader when compiling
the individual files ('prepare for LTO'). But this then prevents further
inlining of the function during LTO.
This patch tries to resolve this issue by making LoopRotate more
conservative with respect to rotating loops that have inline-able calls
during the 'prepare for LTO' stage.
I think this change intuitively improves the current situation in
general. Loop-rotate tries hard to avoid creating headers that are 'too
big'. At the moment, it assumes all inlining already happened and the
cost of duplicating a call is equal to just doing the call. But with LTO,
inlining also happens during full LTO and it is possible that a previously
duplicated call is actually a huge function which gets inlined
during LTO.
From the perspective of LV, not much should change overall. Most loops
calling user-provided functions won't get vectorized to start with
(unless we can infer that the function does not touch memory, has no
other side effects). If we do not inline the 'inline-able' call during
the LTO stage, we merely delayed loop-rotation & vectorization. If we
inline during LTO, chances should be very high that the inlined code is
itself vectorizable or the user call was not vectorizable to start with.
There could of course be scenarios where we inline a sufficiently large
function with code not profitable to vectorize, which would have be
vectorized earlier (by scalarzing the call). But even in that case,
there probably is no big performance impact, because it should be mostly
down to the cost-model to reject vectorization in that case. And then
the version with scalarized calls should also not be beneficial. In a way,
LV should have strictly more information after inlining and make more
accurate decisions (barring cost-model issues).
There is of course plenty of room for things to go wrong unexpectedly,
so we need to keep a close look at actual performance and address any
follow-up issues.
I took a look at the impact on statistics for
MultiSource/SPEC2000/SPEC2006. There are a few benchmarks with fewer
loops rotated, but no change to the number of loops vectorized.
Reviewed By: sanwou01
Differential Revision: https://reviews.llvm.org/D94232
2021-01-19 10:22:40 +01:00
|
|
|
}
|
2012-03-16 06:51:52 +01:00
|
|
|
|
|
|
|
// If this call is to function itself, then the function is recursive.
|
|
|
|
// Inlining it into other functions is a bad idea, because this is
|
|
|
|
// basically just a form of loop peeling, and our metrics aren't useful
|
|
|
|
// for that case.
|
|
|
|
if (F == BB->getParent())
|
|
|
|
isRecursive = true;
|
|
|
|
|
2021-01-19 15:34:55 +01:00
|
|
|
if (IsLoweredToCall)
|
2013-01-22 12:26:02 +01:00
|
|
|
++NumCalls;
|
|
|
|
} else {
|
2012-03-16 06:51:52 +01:00
|
|
|
// We don't want inline asm to count as a call - that would prevent loop
|
|
|
|
// unrolling. The argument setup cost is still real, though.
|
2019-02-11 10:03:32 +01:00
|
|
|
if (!Call->isInlineAsm())
|
2012-03-16 06:51:52 +01:00
|
|
|
++NumCalls;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-08 21:53:48 +01:00
|
|
|
if (const AllocaInst *AI = dyn_cast<AllocaInst>(&I)) {
|
2012-03-16 06:51:52 +01:00
|
|
|
if (!AI->isStaticAlloca())
|
|
|
|
this->usesDynamicAlloca = true;
|
|
|
|
}
|
|
|
|
|
2016-03-08 21:53:48 +01:00
|
|
|
if (isa<ExtractElementInst>(I) || I.getType()->isVectorTy())
|
2012-03-16 06:51:52 +01:00
|
|
|
++NumVectorInsts;
|
|
|
|
|
2016-03-08 21:53:48 +01:00
|
|
|
if (I.getType()->isTokenTy() && I.isUsedOutsideOfBlock(BB))
|
2015-08-14 07:09:07 +02:00
|
|
|
notDuplicatable = true;
|
|
|
|
|
2016-03-08 21:53:48 +01:00
|
|
|
if (const CallInst *CI = dyn_cast<CallInst>(&I)) {
|
2014-03-17 17:19:07 +01:00
|
|
|
if (CI->cannotDuplicate())
|
2012-12-20 17:04:27 +01:00
|
|
|
notDuplicatable = true;
|
2016-02-12 22:01:31 +01:00
|
|
|
if (CI->isConvergent())
|
|
|
|
convergent = true;
|
|
|
|
}
|
2012-12-20 17:04:27 +01:00
|
|
|
|
2016-03-08 21:53:48 +01:00
|
|
|
if (const InvokeInst *InvI = dyn_cast<InvokeInst>(&I))
|
2014-03-17 17:19:07 +01:00
|
|
|
if (InvI->cannotDuplicate())
|
2012-12-20 17:04:27 +01:00
|
|
|
notDuplicatable = true;
|
|
|
|
|
2021-02-11 11:25:14 +01:00
|
|
|
NumInstsProxy += TTI.getUserCost(&I, TargetTransformInfo::TCK_CodeSize);
|
|
|
|
NumInsts = *NumInstsProxy.getValue();
|
2012-03-16 06:51:52 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (isa<ReturnInst>(BB->getTerminator()))
|
|
|
|
++NumRets;
|
|
|
|
|
|
|
|
// We never want to inline functions that contain an indirectbr. This is
|
|
|
|
// incorrect because all the blockaddress's (in static global initializers
|
|
|
|
// for example) would be referring to the original function, and this indirect
|
|
|
|
// jump would jump from the inlined copy of the function into the original
|
|
|
|
// function which is extremely undefined behavior.
|
|
|
|
// FIXME: This logic isn't really right; we can safely inline functions
|
|
|
|
// with indirectbr's as long as no other function or global references the
|
|
|
|
// blockaddress of a block within the current function. And as a QOI issue,
|
|
|
|
// if someone is using a blockaddress without an indirectbr, and that
|
|
|
|
// reference somehow ends up in another function or global, we probably
|
|
|
|
// don't want to inline this function.
|
2012-12-20 17:04:27 +01:00
|
|
|
notDuplicatable |= isa<IndirectBrInst>(BB->getTerminator());
|
2012-03-16 06:51:52 +01:00
|
|
|
|
|
|
|
// Remember NumInsts for this BB.
|
2021-02-11 11:25:14 +01:00
|
|
|
InstructionCost NumInstsThisBB = NumInstsProxy - NumInstsBeforeThisBB;
|
|
|
|
NumBBInsts[BB] = *NumInstsThisBB.getValue();
|
2012-03-16 06:51:52 +01:00
|
|
|
}
|