bugc: preserve the call-site source range through inlining#267
Merged
Conversation
When a call is inlined, the real call instruction — which mapped to the call expression (e.g. `square(a)`) — is replaced by the spliced callee body, and jump-optimization later folds the entry jump that carried the call-site range. So at O2/O3 the call site mapped to no instruction, even though the callee body still mapped (to the callee's source). Preserve it: gather the call-site `code` range onto the entry inlined instruction, alongside the callee-body range it collides with. Two source ranges apply to that instruction (the call site and the callee body), so they gather. The callee-body context keeps its invoke/transform siblings as a single gather child, so consumers still find those discriminators on a leaf rather than as siblings of `gather`.
Contributor
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #263 (call-site source range on invoke/return), covering
the inlined case.
When a call is inlined at O2/O3, the real call instruction — which
mapped to the call expression (
square(a)) — is replaced by thespliced callee body, and jump-optimization folds the entry jump that
carried the call-site range. So the inlined code mapped only to the
callee's definition (
x * x); the call site itself mapped to noinstruction, and stepping-by-source couldn't reach it.
This gathers the call-site
coderange onto the entry inlinedinstruction, alongside the callee-body range it collides with. Two
source ranges genuinely apply to that instruction — the call site and
the callee body — so they
gather(per the context-compositionguidance: colliding keys gather). The callee-body context keeps its
invoke/transformsiblings as a single gather child, so consumersthat walk gather still find those discriminators on a leaf rather than
as siblings of
gather.Verified: at O2 and O3 the inlined instruction carries two distinct
code ranges, one of which is the call expression; O0 is unaffected
(no inlining); runtime behavior unchanged at every level.
Deferred (unchanged from #263): the TCO back-edge JUMP still needs the
call-site loc threaded into the tail-call IR object — separate.