[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] Register liveness analysis and spilling

From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Register liveness analysis and spilling
Date: Mon, 4 Sep 2017 16:18:29 -0400

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 (I agree that
jit_callee_save_p is hackish, but on some ports JIT_R? are indeed callee

>> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]