Re: [Lightning] Register liveness analysis and spilling

[Paulo César Pereira de Andrade]

2017-09-04 5:38 GMT-04:00 Marc Nieper-Wißkirchen <address@hidden>:
> Would it make sense, for example, to expose the functions jit_get_reg and
> jit_unget_reg to user code?

  This could introduce too many bugs :( jit_get_reg and jit_unget_reg are only
used when implementing one lightning instruction. It also works in two ways,
in the parse/ir stage, were temporaries can be renamed, and spurious spills
are removed, and when actually generating code.

> Marc Nieper-Wißkirchen <address@hidden> schrieb am So., 3. Sep.
> 2017 um 17:18 Uhr:
>>
>> When generating lightning instructions from higher level code, scratch
>> registers are sometimes needed (for example, to code a move from memory to
>> memory).
>>
>> The generating code could analyze which registers do not contain live data
>> and use those as scratch registers (if there are none, it has to spill some
>> registers).

  In the way lightning works, you should consider registers as resources.
Just statically allocate JIT_R0, JIT_R1, JIT_R2, and possibly more
depending on if JIT_R3 is defined, JIT_R4 is defined, etc,  and then
keep track of temporaries or long lived registers. See as an example
https://github.com/pcpa/owl/blob/master/lib/oemit.c#L352 (I agree that
jit_callee_save_p is hackish, but on some ports JIT_R? are indeed callee
save).

>> Browsing through the lighting source code it seems that lightning already
>> contains some liveness analysis and some spilling algorithm. It would be
>> great if some interface to this could be offered to user code, for example
>> by offering two "virtual registers" that are emulated by overlaying them to
>> real registers (that are either dead or spilled during the live time of the
>> virtual registers).
>>
>> On some ports, e.g. the AMD64 port, these virtual registers could, in
>> fact, be real registers like RSI or RDI most of the time, which are usually
>> only used for arguments to C procedure calls, and are wasted otherwise.

  I agree on this point. But then, the point would be only if you generate
jit for a single architecture. If your code specializes too much, it likely
will be very difficult to get correct jit generated on a different architecture.

>> Marc

Thanks,
Paulo