This patch restricts SelectionDAGs movement of DBG_VALUEs for function Arguments, to try and only apply to function parameter variables. Note that this similar but *unrelated* to PR40188. Crucial information, here "Argument" refers to LLVM IR Values that represent inputs to the function.
Right now, if one refers to a function Argument IR Value with a dbg.value, the DBG_VALUE will be hoisted to the top of the function by EmitFuncArgumentDbgValue -- because SelectionDAG wants to put Arguments at the start of the function as often as possible. This is problematic if you have a local variable that takes on the Argument value at a later stage in the function, because that DBG_VALUE will be hoisted, possibly re-ordering it. I've also found examples of locations going missing because they've been hoisted past complicated control flow and (LiveDebugValues I think?) can't track it -- the code for this is copied in the added test case. xyzzy gets inlined into bar, its arguments DBG_VALUE hoisted to the top of bar, after which the location gets lost passed the switch statement.
This patch improves matters by increasing the set of dbg.values that can associate with a vreg, which allows normal variables and inlined arguments to point at vregs for Argument values without having the EmitFuncArgumentDbgValue specialness applied to them. This limits the set of dbg.values that *must* dangle and be resolved by EmitFuncArgumentDbgValue to:
- dbg.values referring to function Arguments,
- that are also parameter variables, and
- where those parameters are parameters to the current function, not inlined ones.
This patch doesn't completely save all normal variables: EmitFuncArgumentDbgValue should reject non-param Variables. However adding code to do this seems to increase the number of locations dropped, and triggers a variety of test failures I haven't looked into yet. Thus this change is an incremental improvement.
I don't see much variable-location-coverage gain in a build of clang-3.4 (0.3% increase), however bytes-in-scope coverage increases by 2%.
DebugInfo/Sparc/subreg.ll needs a fix as a result of this change: the Argument to that function gets optimised out, because nothing uses it. With this patch, the normal-variable DBG_VALUE referring to it gets optimised out too. IMO this is desired behaviour: it's true to say that the normal variable it gets optimised out, and we only intend to preserve parameters. To keep the test passing I mark the variable to be a parameter to the function: it then gets special handling and is preserved in the output.