An ARM Backend for PyPyls Tracing JIT - STUPS Group

34 6 A BACKEND FOR PYPY’S JITin frames. When forcing happens we can not continue with the execution of the optimizedloop and have to fall back to interpretation. Because of this, around calls that cantrigger such a frame forcing we need to check if forcing happened, in order to leave theoptimized loop in that case.To perform the steps described above we make use of the force_index, mentionedbefore when describing the frame layout. We use the slot of the force_index on thestack to store a value that is changed when we force the frame. Using this value wecan check if the frame was forced and exit the loop if necessary. Additionally we makeuse of the address of the force_index, that is stored in the FP register, to restore thevariables used in the loop so the frontend can create the frame objects. We can restorethe variables using the address of the force_index, because the variables are stored ina known offset from this address.6.5 Guards and Leaving the LoopAs described in Section 3.2 traces correspond to only one possible path through the tracedloop. Operations called guards are inserted in the trace at all points where the executioncould take a different path than the one recorded during tracing. These operations checkthat the conditions valid during tracing are still valid during execution. Examples forsuch guards are guard_value, guard_class, guard_true, etc. which check the conditionindicated by their name to be true.Because a trace contains a large amount of guards and guards fail rarely we want toimplement guards in a way that the case where the guard does not fail is efficient. Theefficiency of the failure case is not as important.Guards are implemented by generating a comparison instruction on the input argumentof the guard and the provided condition. If the condition passes we jump over the blockof instructions generated for the guard and continue with the execution of the loop.In the case the check fails we enter the guard block. Within the guard block we first savethe locations of all variables, i.e. the registers they are associated with, and jump to aprocedure that takes care of all the steps needed to exit the loop. Each guard is associatedwith a list of variables that should be passed to the frontend to restore the state of theexecution in case the guard fails. When we generate the instructions for a guard, weadditionally allocate a small piece of memory which is associated with the guard. In thispiece of memory we store in an encoded way the information about where each of thearguments associated with the guard is currently stored. Because of the large numberof guards generated we want to keep this encoding as compact as possible to reduce thememory footprint of the compiled loops. For each variable the encoding consists of upto 6 bytes: one byte for the type (int, pointer or float), one for the location (stack, registeror immediate) and four for the value itself, in the case of register locations we only storethe type and the register number, which on ARM fits into one byte.After a guard failure we jump to a pre-generated procedure that serves as a common exitpath for all compiled loops. This procedure takes care of saving all values that should bepassed to the frontend and then finally leaves the compiled loop by returning from thefunction that executes the trace. The saving of the values is done by reading the encoding