deep

a Cross Development Platform for Java

User Tools

Site Tools


dev:crosscompiler:backend:register_allocator

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
dev:crosscompiler:backend:register_allocator [2018/01/04 15:39] – [Register Usage] ursgrafdev:crosscompiler:backend:register_allocator [2018/02/28 14:42] – [Resolving of Phi-Functions] ursgraf
Line 5: Line 5:
 Registers can be classified as //dedicated//, //volatile// or //nonvolatile//. //Dedicated// are register with a special purpose, such as the stackpointer. //Volatile// means, that this register might be used any time. It does not have to be stored when another method is called. //Nonvolatile// registers must be saved in the prologue of a method before they can be used and after use they must be restored. The number of volatile and nonvolatile registers must be equal for all methods.  Registers can be classified as //dedicated//, //volatile// or //nonvolatile//. //Dedicated// are register with a special purpose, such as the stackpointer. //Volatile// means, that this register might be used any time. It does not have to be stored when another method is called. //Nonvolatile// registers must be saved in the prologue of a method before they can be used and after use they must be restored. The number of volatile and nonvolatile registers must be equal for all methods. 
  
-[[dev:crosscompiler:backend_ppc:register_allocation|Register Allocation for PPC]] +  * [[dev:crosscompiler:backend_ppc:register_allocation|Register Allocation for PPC]]  
-[[dev:crosscompiler:backend_arm:register_allocation|Register Allocation for ARM]]+  [[dev:crosscompiler:backend_arm:register_allocation|Register Allocation for ARM]]
 ===== Resolving of Phi-Functions ===== ===== Resolving of Phi-Functions =====
 The operands of a phi-function must all get the same register as the result of the phi-function. For this purpose all these operands have a field //join//. \\ The operands of a phi-function must all get the same register as the result of the phi-function. For this purpose all these operands have a field //join//. \\
 Before the phi-functions can be resolved, loops need special treatment. Let's consider the folowing case: Before the phi-functions can be resolved, loops need special treatment. Let's consider the folowing case:
 [{{ .:phifunctionloop1.png?110 |//Phi-Function in a loop//}}] [{{ .:phifunctionloop1.png?110 |//Phi-Function in a loop//}}]
 +{{:dev:crosscompiler:backend:phifunctionloop1.png?400|}}
  
 The SSAValue of //a// is used in the loop. The live range of //a// extends to the instruction for //b = 2 * a//. However, this would be wrong, because the register for //a// would be released at this point and might be used otherwise. It must stay reserved until the end of the loop. At the beginning of node 2 a phi-function is created for //a//. This function will be deleted because //a// is set in node 1 and only read in node 2. For all phi-functions in loops (whether deleted or not) the field //last// is set to the last instruction of this loop.\\ The SSAValue of //a// is used in the loop. The live range of //a// extends to the instruction for //b = 2 * a//. However, this would be wrong, because the register for //a// would be released at this point and might be used otherwise. It must stay reserved until the end of the loop. At the beginning of node 2 a phi-function is created for //a//. This function will be deleted because //a// is set in node 1 and only read in node 2. For all phi-functions in loops (whether deleted or not) the field //last// is set to the last instruction of this loop.\\
dev/crosscompiler/backend/register_allocator.txt · Last modified: 2019/08/29 16:53 by ursgraf