Update lsra-detail.md #45235
Update lsra-detail.md #45235
Conversation
Dotnet-GitSync-Bot
added
the
area-CodeGen-coreclr
|
@dotnet/jit-contrib PTAL |
| @@ -308,6 +309,7 @@ After LSRA, the graph has the following properties: | |||
| must issue the appropriate move. | |||
|
|
|||
| - However, if such a node is constrained to a set of registers, | |||
| as in the case of x86 instructions which require a byte-addressible register, | |||
| @@ -321,7 +323,12 @@ After LSRA, the graph has the following properties: | |||
|
|
|||
| - Note that a write-thru variable def is always written to the stack, and the `GTF_SPILLED` | |||
There was a problem hiding this comment.
while you are here: "and it is marked as GTF_SPILLED"
| @@ -321,7 +323,12 @@ After LSRA, the graph has the following properties: | |||
|
|
|||
| - Note that a write-thru variable def is always written to the stack, and the `GTF_SPILLED` | |||
| flag (not otherwise used for pure defs) to indicate that it also remains live | |||
| in the assigned register. | |||
| in the assigned register. This is somewhat counter-intuitive, but | |||
There was a problem hiding this comment.
May be we should move this after we describe what a node with GTF_SPILLED means and further re-phrase as :
"If a node has both GTF_SPILL and GTF_SPILLED, the tree node is spilled after it is evaluated (GTF_SPILL) and reloaded prior to the use (GTF_SPILLED). After the node is spilled and before the reload, its value is not live in the register. However, for EH-write-thru variables, there is an exception. The variable def is always written to the stack (GTF_SPILL), should always be reloaded (GTF_SPILLED) and always remain live in the register as well."
There was a problem hiding this comment.
Sounds good, though the description should be reordered to make it clear that the reloading comes first in the general case.
| would require us to spill the lclVar and reload it for the next use. | ||
| Instead, we retain the assignment of the register to the lclVar, and mark that `RegRecord` as | ||
| `isBusyUntilNextKill` so that it isn't reused if the lclVar goes dead before the call. | ||
| (Otherwise, if the either the lclVar is in a different register, or if its next use is after |
There was a problem hiding this comment.
nit: Otherwise, if the lclVar is...
| the register assignments across edges. | ||
|
|
||
| - The critical edges are handled first. These are the most problematic, as there | ||
| is no single location at which the moves can be added. We handle the critical |
There was a problem hiding this comment.
This sentence doesn't sound right. Did you mean "We handle all the critical edges that originates from the source block"?
There was a problem hiding this comment.
No, all the critical edges are handled first. I'll work on a rephrasing of this.
|
Changes looks good. Thanks! |
ghost
locked as resolved and limited conversation to collaborators
No description provided.