4283d2116d
Cranelift crates have historically been much more verbose with debug-level
logging than most other crates in the Rust ecosystem. We log things like how
many parameters a basic block has, the color of virtual registers during
regalloc, etc. Even for Cranelift hackers, these things are largely only useful
when hacking specifically on Cranelift and looking at a particular test case,
not even when using some Cranelift embedding (such as Wasmtime).
Most of the time, when people want logging for their Rust programs, they do
something like:
RUST_LOG=debug cargo run
This means that they get all that mostly not useful debug logging out of
Cranelift. So they might want to disable logging for Cranelift, or change it to
a higher log level:
RUST_LOG=debug,cranelift=info cargo run
The problem is that this is already more annoying to type that `RUST_LOG=debug`,
and that Cranelift isn't one single crate, so you actually have to play
whack-a-mole with naming all the Cranelift crates off the top of your head,
something more like this:
RUST_LOG=debug,cranelift=info,cranelift_codegen=info,cranelift_wasm=info,...
Therefore, we're changing most of the `debug!` logs into `trace!` logs: anything
that is very Cranelift-internal, unlikely to be useful/meaningful to the
"average" Cranelift embedder, or prints a message for each instruction visited
during a pass. On the other hand, things that just report a one line statistic
for a whole pass, for example, are left as `debug!`. The more verbose the log
messages are, the higher the bar they must clear to be `debug!` rather than
`trace!`.
59 lines
2.1 KiB
Rust
59 lines
2.1 KiB
Rust
//! Unreachable code elimination.
|
|
|
|
use crate::cursor::{Cursor, FuncCursor};
|
|
use crate::dominator_tree::DominatorTree;
|
|
use crate::flowgraph::ControlFlowGraph;
|
|
use crate::ir;
|
|
use crate::timing;
|
|
|
|
/// Eliminate unreachable code.
|
|
///
|
|
/// This pass deletes whole blocks that can't be reached from the entry block. It does not delete
|
|
/// individual instructions whose results are unused.
|
|
///
|
|
/// The reachability analysis is performed by the dominator tree analysis.
|
|
pub fn eliminate_unreachable_code(
|
|
func: &mut ir::Function,
|
|
cfg: &mut ControlFlowGraph,
|
|
domtree: &DominatorTree,
|
|
) {
|
|
let _tt = timing::unreachable_code();
|
|
let mut pos = FuncCursor::new(func);
|
|
while let Some(block) = pos.next_block() {
|
|
if domtree.is_reachable(block) {
|
|
continue;
|
|
}
|
|
|
|
log::trace!("Eliminating unreachable {}", block);
|
|
// Move the cursor out of the way and make sure the next lop iteration goes to the right
|
|
// block.
|
|
pos.prev_block();
|
|
|
|
// Remove all instructions from `block`.
|
|
while let Some(inst) = pos.func.layout.first_inst(block) {
|
|
log::trace!(" - {}", pos.func.dfg.display_inst(inst, None));
|
|
pos.func.layout.remove_inst(inst);
|
|
}
|
|
|
|
// Once the block is completely empty, we can update the CFG which removes it from any
|
|
// predecessor lists.
|
|
cfg.recompute_block(pos.func, block);
|
|
|
|
// Finally, remove the block from the layout.
|
|
pos.func.layout.remove_block(block);
|
|
}
|
|
|
|
// Remove all jumptable block-list contents that refer to unreachable
|
|
// blocks; the jumptable itself must have been unused (or used only in an
|
|
// unreachable block) if so. Note that we are not necessarily removing *all*
|
|
// unused jumptables, because that would require computing their
|
|
// reachability as well; we are just removing enough to clean up references
|
|
// to deleted blocks.
|
|
for jt_data in func.jump_tables.values_mut() {
|
|
let invalid_ref = jt_data.iter().any(|block| !domtree.is_reachable(*block));
|
|
if invalid_ref {
|
|
jt_data.clear();
|
|
}
|
|
}
|
|
}
|