If the merged instruction is call instruction, we need to set the scope to the closes common scope between 2 locations, otherwise it will cause trouble when the call is getting inlined.
Perhaps the API should change to be less error prone (so it's not the responsibility of the caller to know to pass the Instruction if it might be a call).
Could this be "applyMergedLocation" and have it take the Instruction as the first parameter & modify its debug location in place? (are there callers that don't have the destination Instruction on-hand at the point where they want to make this call?)
I'd expect to walk more than the inlined-at attributes, but the plain scopes too. Which should look something like "keep calling getScope until it returns null, then use getInlinedAt, then go back to walking scopes, etc, until getInlinedAt returns null".
Probably not as important/necessary, but could still help smooth out debug_ranges which cost a bunch of debug info size.
Might be worth checking the specific instructions that these lines apply to?
Updated the API:
MachineInstruction should use the original API
Discussed offline with David. It is an overkill to add another level of complexity to traverse Scope chain because
Looks good, thanks!
Adrian - dunno what you think about the API changes here. Open to iterating (probably just post-commit) if you reckon this doesn't add enough, or have other ideas.
This probably needs a similar assert/comment that I0 isn't a CallInst?
LGTM, I would add one extra line to the comment of applyMergedLocation (see inline).
I think if we spell this as \p applyMergedLocation it gets turned into a link by Doxygen, might be worth trying.
I was thinking of adding an extra line like to make the behavior clear to the casual reader: