[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
//===---- BDCE.cpp - Bit-tracking dead code elimination -------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the Bit-Tracking Dead Code Elimination pass. Some
|
|
|
|
// instructions (shifts, some ands, ors, etc.) kill some of their input bits.
|
|
|
|
// We track these dead bits and remove instructions that compute only these
|
|
|
|
// dead bits.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-05-25 09:57:04 +08:00
|
|
|
#include "llvm/Transforms/Scalar/BDCE.h"
|
2017-08-13 00:41:08 +08:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
#include "llvm/ADT/Statistic.h"
|
2015-08-14 19:09:09 +08:00
|
|
|
#include "llvm/Analysis/DemandedBits.h"
|
2016-05-25 09:57:04 +08:00
|
|
|
#include "llvm/Analysis/GlobalsModRef.h"
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
#include "llvm/IR/CFG.h"
|
|
|
|
#include "llvm/IR/InstIterator.h"
|
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/Operator.h"
|
|
|
|
#include "llvm/Pass.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2016-05-25 09:57:04 +08:00
|
|
|
#include "llvm/Transforms/Scalar.h"
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "bdce"
|
|
|
|
|
|
|
|
STATISTIC(NumRemoved, "Number of instructions removed (unused)");
|
|
|
|
STATISTIC(NumSimplified, "Number of instructions trivialized (dead bits)");
|
|
|
|
|
2017-08-13 00:41:08 +08:00
|
|
|
/// If an instruction is trivialized (dead), then the chain of users of that
|
|
|
|
/// instruction may need to be cleared of assumptions that can no longer be
|
|
|
|
/// guaranteed correct.
|
|
|
|
static void clearAssumptionsOfUsers(Instruction *I, DemandedBits &DB) {
|
2017-08-14 23:13:46 +08:00
|
|
|
assert(I->getType()->isIntegerTy() && "Trivializing a non-integer value?");
|
2017-08-13 00:41:08 +08:00
|
|
|
|
|
|
|
// Initialize the worklist with eligible direct users.
|
|
|
|
SmallVector<Instruction *, 16> WorkList;
|
|
|
|
for (User *JU : I->users()) {
|
2017-08-14 23:13:46 +08:00
|
|
|
// If all bits of a user are demanded, then we know that nothing below that
|
|
|
|
// in the def-use chain needs to be changed.
|
2017-08-13 00:41:08 +08:00
|
|
|
auto *J = dyn_cast<Instruction>(JU);
|
2017-08-17 00:09:22 +08:00
|
|
|
if (J && J->getType()->isSized() &&
|
|
|
|
!DB.getDemandedBits(J).isAllOnesValue())
|
2017-08-13 00:41:08 +08:00
|
|
|
WorkList.push_back(J);
|
2017-08-17 00:09:22 +08:00
|
|
|
|
|
|
|
// Note that we need to check for unsized types above before asking for
|
|
|
|
// demanded bits. Normally, the only way to reach an instruction with an
|
|
|
|
// unsized type is via an instruction that has side effects (or otherwise
|
|
|
|
// will demand its input bits). However, if we have a readnone function
|
|
|
|
// that returns an unsized type (e.g., void), we must avoid asking for the
|
|
|
|
// demanded bits of the function call's return value. A void-returning
|
|
|
|
// readnone function is always dead (and so we can stop walking the use/def
|
|
|
|
// chain here), but the check is necessary to avoid asserting.
|
2017-08-13 00:41:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// DFS through subsequent users while tracking visits to avoid cycles.
|
|
|
|
SmallPtrSet<Instruction *, 16> Visited;
|
|
|
|
while (!WorkList.empty()) {
|
|
|
|
Instruction *J = WorkList.pop_back_val();
|
|
|
|
|
|
|
|
// NSW, NUW, and exact are based on operands that might have changed.
|
|
|
|
J->dropPoisonGeneratingFlags();
|
|
|
|
|
|
|
|
// We do not have to worry about llvm.assume or range metadata:
|
|
|
|
// 1. llvm.assume demands its operand, so trivializing can't change it.
|
|
|
|
// 2. range metadata only applies to memory accesses which demand all bits.
|
|
|
|
|
|
|
|
Visited.insert(J);
|
|
|
|
|
|
|
|
for (User *KU : J->users()) {
|
2017-08-14 23:13:46 +08:00
|
|
|
// If all bits of a user are demanded, then we know that nothing below
|
|
|
|
// that in the def-use chain needs to be changed.
|
2017-08-13 00:41:08 +08:00
|
|
|
auto *K = dyn_cast<Instruction>(KU);
|
2017-08-17 00:09:22 +08:00
|
|
|
if (K && !Visited.count(K) && K->getType()->isSized() &&
|
|
|
|
!DB.getDemandedBits(K).isAllOnesValue())
|
2017-08-13 00:41:08 +08:00
|
|
|
WorkList.push_back(K);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-25 09:57:04 +08:00
|
|
|
static bool bitTrackingDCE(Function &F, DemandedBits &DB) {
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
SmallVector<Instruction*, 128> Worklist;
|
|
|
|
bool Changed = false;
|
2015-08-07 03:10:45 +08:00
|
|
|
for (Instruction &I : instructions(F)) {
|
[BDCE/DebugInfo] Preserve llvm.dbg.value's argument.
BDCE has two phases:
1. It asks SimplifyDemandedBits if all the bits of an instruction are dead, and if so,
replaces all its uses with the constant zero.
2. Then, it asks SimplifyDemandedBits again if the instruction is really dead
(no side effects etc..) and if so, eliminates it.
Now, in 1) if all the bits of an instruction are dead, we may end up replacing a dbg use:
%call = tail call i32 (...) @g() #4, !dbg !15
tail call void @llvm.dbg.value(metadata i32 %call, i64 0, metadata !8, metadata !16), !dbg !17
->
%call = tail call i32 (...) @g() #4, !dbg !15
tail call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !8, metadata !16), !dbg !17
but not eliminating the call because it may have arbitrary side effects.
In other words, we lose some debug informations.
This patch fixes the problem making sure that BDCE does nothing with the instruction if
it has side effects and no non-dbg uses.
Differential Revision: https://reviews.llvm.org/D27471
llvm-svn: 288851
2016-12-07 05:52:47 +08:00
|
|
|
// If the instruction has side effects and no non-dbg uses,
|
2016-12-08 05:47:32 +08:00
|
|
|
// skip it. This way we avoid computing known bits on an instruction
|
|
|
|
// that will not help us.
|
[BDCE/DebugInfo] Preserve llvm.dbg.value's argument.
BDCE has two phases:
1. It asks SimplifyDemandedBits if all the bits of an instruction are dead, and if so,
replaces all its uses with the constant zero.
2. Then, it asks SimplifyDemandedBits again if the instruction is really dead
(no side effects etc..) and if so, eliminates it.
Now, in 1) if all the bits of an instruction are dead, we may end up replacing a dbg use:
%call = tail call i32 (...) @g() #4, !dbg !15
tail call void @llvm.dbg.value(metadata i32 %call, i64 0, metadata !8, metadata !16), !dbg !17
->
%call = tail call i32 (...) @g() #4, !dbg !15
tail call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !8, metadata !16), !dbg !17
but not eliminating the call because it may have arbitrary side effects.
In other words, we lose some debug informations.
This patch fixes the problem making sure that BDCE does nothing with the instruction if
it has side effects and no non-dbg uses.
Differential Revision: https://reviews.llvm.org/D27471
llvm-svn: 288851
2016-12-07 05:52:47 +08:00
|
|
|
if (I.mayHaveSideEffects() && I.use_empty())
|
|
|
|
continue;
|
|
|
|
|
2015-08-14 19:09:09 +08:00
|
|
|
if (I.getType()->isIntegerTy() &&
|
|
|
|
!DB.getDemandedBits(&I).getBoolValue()) {
|
|
|
|
// For live instructions that have all dead bits, first make them dead by
|
|
|
|
// replacing all uses with something else. Then, if they don't need to
|
|
|
|
// remain live (because they have side effects, etc.) we can remove them.
|
|
|
|
DEBUG(dbgs() << "BDCE: Trivializing: " << I << " (all bits dead)\n");
|
2017-08-13 00:41:08 +08:00
|
|
|
|
|
|
|
clearAssumptionsOfUsers(&I, DB);
|
|
|
|
|
2015-08-14 19:09:09 +08:00
|
|
|
// FIXME: In theory we could substitute undef here instead of zero.
|
|
|
|
// This should be reconsidered once we settle on the semantics of
|
|
|
|
// undef, poison, etc.
|
|
|
|
Value *Zero = ConstantInt::get(I.getType(), 0);
|
|
|
|
++NumSimplified;
|
2016-12-08 05:47:32 +08:00
|
|
|
I.replaceNonMetadataUsesWith(Zero);
|
2015-08-14 19:09:09 +08:00
|
|
|
Changed = true;
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
}
|
2015-08-14 19:09:09 +08:00
|
|
|
if (!DB.isInstructionDead(&I))
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
Worklist.push_back(&I);
|
|
|
|
I.dropAllReferences();
|
|
|
|
Changed = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (Instruction *&I : Worklist) {
|
|
|
|
++NumRemoved;
|
|
|
|
I->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
2016-05-25 09:57:04 +08:00
|
|
|
PreservedAnalyses BDCEPass::run(Function &F, FunctionAnalysisManager &AM) {
|
|
|
|
auto &DB = AM.getResult<DemandedBitsAnalysis>(F);
|
2016-06-01 01:53:22 +08:00
|
|
|
if (!bitTrackingDCE(F, DB))
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
2017-01-15 14:32:49 +08:00
|
|
|
PreservedAnalyses PA;
|
|
|
|
PA.preserveSet<CFGAnalyses>();
|
2016-06-01 01:53:22 +08:00
|
|
|
PA.preserve<GlobalsAA>();
|
|
|
|
return PA;
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
}
|
|
|
|
|
2016-05-25 09:57:04 +08:00
|
|
|
namespace {
|
|
|
|
struct BDCELegacyPass : public FunctionPass {
|
|
|
|
static char ID; // Pass identification, replacement for typeid
|
|
|
|
BDCELegacyPass() : FunctionPass(ID) {
|
|
|
|
initializeBDCELegacyPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
|
|
|
bool runOnFunction(Function &F) override {
|
|
|
|
if (skipFunction(F))
|
|
|
|
return false;
|
|
|
|
auto &DB = getAnalysis<DemandedBitsWrapperPass>().getDemandedBits();
|
|
|
|
return bitTrackingDCE(F, DB);
|
|
|
|
}
|
|
|
|
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
|
|
|
AU.setPreservesCFG();
|
|
|
|
AU.addRequired<DemandedBitsWrapperPass>();
|
|
|
|
AU.addPreserved<GlobalsAAWrapperPass>();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
char BDCELegacyPass::ID = 0;
|
|
|
|
INITIALIZE_PASS_BEGIN(BDCELegacyPass, "bdce",
|
|
|
|
"Bit-Tracking Dead Code Elimination", false, false)
|
|
|
|
INITIALIZE_PASS_DEPENDENCY(DemandedBitsWrapperPass)
|
|
|
|
INITIALIZE_PASS_END(BDCELegacyPass, "bdce",
|
|
|
|
"Bit-Tracking Dead Code Elimination", false, false)
|
|
|
|
|
|
|
|
FunctionPass *llvm::createBitTrackingDCEPass() { return new BDCELegacyPass(); }
|