Uh oh!
There was an error while loading. Please reload this page.
Extending variable live ranges in more cases - #77439
Conversation
When the emitter moved to the next group but has not emitted any instruction, and the variable died and becomes alive again, we would like to extend its range.
ghost
commented
Oct 25, 2022
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsWhile debugging Issue 47202, I found that variables can die and born again without an instruction being emitted nor the emitter moving. Here is an example from #77289 (comment): I found a case where a variable (V06) dies (in [000054]) at the beginning of a basic block (BB05), and becomes alive (in [000016]) before an instruction is emitter. We would want to extend the live ranges in this case:
|
Just to be consistent with new method objective and description.
BrianBohe
commented
Oct 25, 2022
After this PR |
AndyAyersMS
commented
Oct 26, 2022
I wonder if we should consider moving to a "lazy kill" mode like we do for gc tracking. That is, even if a local is no longer live, so long as the register it was in does not get modified, we can still report the local in the debug info. |
BrianBohe
commented
Oct 26, 2022
I didn't know that such a thing exists, sounds like the appropriate case. Let me read about it a little bit. |
ghost
commented
Dec 17, 2022
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
While debugging Issue 47202, I found that variables can die and born again without an instruction being emitted nor the emitter moving.
Here is an example from #77289 (comment):
I found a case where a variable (V06) dies (in [000054]) at the beginning of a basic block (BB05), and becomes alive (in [000016]) before an instruction is emitter. We would want to extend the live ranges in this case: