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
dev:crosscompiler:backend:register_allocator [2018/02/28 14:42] – [Resolving of Phi-Functions] ursgrafdev:crosscompiler:backend:register_allocator [2019/08/29 16:53] (current) – [Determine Used Parameters] ursgraf
Line 11: Line 11:
 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.\\
Line 40: Line 39:
  
 ===== Determine Used Parameters ===== ===== Determine Used Parameters =====
-Parameters are passed in volatile registers. Some of them have to be copied to nonvolatile registers. Some parameters might not be used at all in a method. This can be determined in the exit set of the last node. If a value is null in that set the parameter with this index was never loaded and hence no register must be reserved. The following example demonstrates parameter usage.+Parameters are passed in volatile registers. Some of them have to be copied to nonvolatile registers. Some parameters might not be used at all in a method. This can be determined in the exit set of the last node. If a value is null in that set the parameter with this index was never loaded and hence no register must be reserved. The following example demonstrates parameter usage on a PPC platform.
 <code java> <code java>
   float m2(long a, float b, double c, byte[] d, short e, int f, int g) {   float m2(long a, float b, double c, byte[] d, short e, int f, int g) {
Line 72: Line 71:
 Some instruction need 1 or 2 additional (auxiliary) registers. These will be reserved and stored in //regAux1// and //regAux2//. At the end of the instruction they can be released again. It's possible that the result of the SSA instruction occupies the same register as one of the auxiliary registers. Some instruction need 1 or 2 additional (auxiliary) registers. These will be reserved and stored in //regAux1// and //regAux2//. At the end of the instruction they can be released again. It's possible that the result of the SSA instruction occupies the same register as one of the auxiliary registers.
 ==== Releasing of Operand Registers ====  ==== Releasing of Operand Registers ==== 
-Registers of operands, whose live range expires, must be released. If they are of type //Long//, this step must happen at the very end.+Registers of operands, whose live range expires, must be released. If they are of type //long//, this step must happen at the very end.
 ==== Reservation of a Result Register ====  ==== Reservation of a Result Register ==== 
 The register pool will be searched for a free register for the result. The result type determines if 1 or 2 GPR's or a FPR must be reserved. The following two cases must be considered. The register pool will be searched for a free register for the result. The result type determines if 1 or 2 GPR's or a FPR must be reserved. The following two cases must be considered.
Line 93: Line 92:
 ==== Releasing of Result Registers ==== ==== Releasing of Result Registers ====
 The result register can be released immediately if the live range already expires.  The result register can be released immediately if the live range already expires. 
 +
 +===== Locals on the Stack =====
 +Local variables which cannot be assigned a register get assigned a stack slot. Stack slots are numbered from 0x100. The code generator will handle the transfer to and from these stack slots. Whenever the code generator tries to translate an SSA instruction and one of the operands is on the stack, the following has to be dones:
 +
 +  * load stack slot into free register
 +  * execute instruction
 +
 +If the result of the SSA instruction is assigned a stack slot, the code generator will have to save to the stack:
 +
 +  * execute instruction, destination register is free register
 +  * store destination register onto stack
 +
 +During register allocation of a method a variable //fullRegSet// signals, if at least one stack slot was used. If that was the case the register allocation is done again, but this time with a reduced register set, because some of the registers must be free in order to be used for fetching stack slots and using them in the following instructions.
 +
dev/crosscompiler/backend/register_allocator.1519825321.txt.gz · Last modified: 2018/02/28 14:42 by ursgraf