Re: [Lightning] On the benefits of inlining

[Ludovic Courtès]

Hi,

Paolo Bonzini <address@hidden> writes:

> the overhead is high and patching is not lightweight, either.  i have 
> not understood exactly when you do it.

Patching the jump instruction only needs to be done once.  However,
patching the `movi' instruction (in order to pass the input/output
parameter) is done every time before the dynamically compiled code is
used.

I was assuming that patching was pretty lightweight, at least on RISC
machines.

> but be careful, you do need to call jit_prolog to set up lightning 
> before generating the first instruction.  GNU Smalltalk has some 
> examples of compiling prolog-less subroutines that are used by the 
> jit-ed code.

I'm actually using `leaf' instead of `prolog'.

> Instead of the goto you can put an asm ("jmp *%0" : : "r" (&&abc) : 
> "eax", "ecx", "edx"); so you can avoid the push/pop and GCC does not 
> think that no instruction will execute after the jump (which it does, if 
> you have a goto).  It is unportable, however. :-(

Right, hence the need for a mapping of register names.  And a mapping
for some instructions (like `jmp') would come in handy as well.  ;-)

> This would *not* make sense for very small pieces of code like this one, 
> or did I miss something?

Well, so long as the inlined code has to save registers and so on, this
doesn't make much sense anyway.  But my belief is that it would make
sense for small pieces of code is a register mapping was available.
Then, for larger pieces of code, the function-call overhead can often be
considered little compared to the number of cycles spent executing the
function itself; consequently, inlining large functions would not make
much sense.

But then there are cache misses.  Perhaps inlining one-instruction code
would not be as efficient as it seems if that code is located far away
from the caller...

Thank you,
Ludovic.