This adds the missing handling for defs for target index operands, as is
already done for registers.
There are two kinds of target indices: local indices and stack operands.
- Locals are something similar to registers in Wasm-land. For local indices, we can check for local-defining instructions (local.set or local.tee).
- Wasm is a stack machine, so we have values in certain Wasm value stack location, which change when Wasm instructions produce or consume values. So basically any value-producing instrucion, i.e., instruction with defs, can change values in the Wasm stack. But I think we don't need to worry about this here, because WebAssemblyDebugFixup, which runs right before this analysis, makes sure to insert terminating DBG_VALUE $noreg instructions whenever a stack value gets popped. After WebAssemblyDebugFixup, there shouldn't be any DBG_VALUEs for stack operands that don't have a terminating DBG_VALUE $noreg within the same BB.
So this CL only works on DBG_VALUEs for locals. When we encounter a
local.set or local.tee instructions, we delete DBG_VALUEs for
those target index locations from the open range set, so they will not
be availble in OutLocs. For example,
bb.0: successors: %bb.1 DBG_VALUE target-index(wasm-local) + 2, $noreg, "var", ... ... local.set 2 ... bb.1: ; predecessors: %bb.0 ; We shouldn't add `DBG_VALUE target (wasm-local) + 2 here because ; it was killed by 'local.set' in bb.0
After disabling register coalescing at -O1, the average PC ranges
covered
for Emscripten core benchmarks is currently 20.6% in the LLVM
tot. After applying D138943 and this CL, the coverage goes up to 57%.
This also enables LiveDebugValues analysis in the Wasm pipeline by
default.
Nit: could I suggest writing "target index" as "TargetIndex" to make it clear it's a noun, and an operand kind. That makes it very clear to readers that it's a specific data structure rather than some higher level concept applicable to all targets.