I'm involved in maintaining an out OOT-target, which uses VLIW, and
We never put the DBG-instructions inside the bundles. I don't remember
exactly how much of that is solved by downstream patch-ups of the in-tree
A lot of the backend code see the BUNDLE as one instruction, at least
after it has been finalized. So maybe I also should mention that we
finalize bundles a.s.a.p (already pre-RA if we introduce a bundle
before RA). And since you basically can't break in the debugger in
the middle of a bundle (at least not for our architecture) it doesn't
really make sense to have a DBG-instruction inside the bundle (unless
maybe if the bundle hasn't been finalized and you want to track what
is going on inside the bundle as long as possible).
We also got some extra heuristics/rules related to re-insertion of
DBG-instructions after scheduling. I don't have the exact details
right now, but sometimes we mark the DBG_VALUE as undef when inserting
it. And if for example having something like this
$r0 = load ...
DBG_VALUE $r0, ...
call @func($r0), implicit $r0
and the load and the call is bundled, and $r0 doesn't survive the calls
then I think we just drop the DBG_VALUE, because it would be wrong to
add it after the bundle.
Anyway, I agree that this is a really complicated problem.
I also think our current solution is a bit ad-hoc, just trying to
avoid some simple cases when the scheduling otherwise mess up things.
And at least in the past it has been quite sensitive to placement of
the DBG_VALUE instructions. I.e. if they are close to the definition
of the register that they refer the debug-experience hopefully isn't
that bad. So it isn't something that we have considered to upstream
(it is also probably a bit target dependent in the current state
and I don't know if it would be testable with any in-tree target).
This also reminds be that if we have a DBG_VALUE that refer to a
constant value and not a register, then one can't really look at
register liveness etc to understand if the DBG_VALUE is bogus after
scheduling. A more complete solution would need to consider how a
certain region in the IR maps to the original source, and what value
the variable should have. With WLIV, when we can be at X
different source lines at the same time, that is extra tricky.
I don't remember if there has been any discussions in the past
about allowing/disallowing DGB-instructions inside bundles.
If there would be a rule about not having DBG-instructions inside
bundles, then I think we could try to find any patches we have
downstream related to that and contribute to the upstream main branch.