[pypy-dev] [rpython] What might prevent a function call from beeing invlined by the JIT?

[Maciej Fijalkowski]

On Fri, Feb 22, 2013 at 1:56 PM, Костя Лопухин <kostia.lopuhin at gmail.com> wrote:
> Yes, it had a little loop that was setting arguments for a function
> call, now the call is inlined, thank you! But in the inlined code
> there is immidately "call_assembler", followed by a "keepalive" of the
> frame. Does it have an equally simple answer? Or it has to do with the
> function arguments?

call_assembler means that the function you call has a loop (such
functions are not inlined, only a part of it), so you end up with a
call. IF you call a simpler function with no loops, the call will
disappear

>
> 2013/2/22 Maciej Fijalkowski <fijall at gmail.com>:
>> On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin at gmail.com> wrote:
>>> In what cases does the jit decide not to inline a function call, but
>>> place "call_may_force" instead?
>>> The context is that I have a simple interpreter, like an expanded
>>> kermit, and I am testing how the jit helps - it perfectly unboxes
>>> wrapped objects in a loop, but does not inline function calls - I
>>> wonder what am I missing here. I found a place where PyPy interpreter
>>> makes a call and did not see anything special there.
>>
>> call_may_force means you call a function that has a loop that calls
>> back to the intepreter. Probably argument handling or so. You need to
>> annotate the function with @jit.unroll_safe (that means that each time
>> the number of iteration is different, you'll get slightly different
>> assembler, so beware)
>
>
> 2013/2/22 Maciej Fijalkowski <fijall at gmail.com>:
>> On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin at gmail.com> wrote:
>>> In what cases does the jit decide not to inline a function call, but
>>> place "call_may_force" instead?
>>> The context is that I have a simple interpreter, like an expanded
>>> kermit, and I am testing how the jit helps - it perfectly unboxes
>>> wrapped objects in a loop, but does not inline function calls - I
>>> wonder what am I missing here. I found a place where PyPy interpreter
>>> makes a call and did not see anything special there.
>>
>> call_may_force means you call a function that has a loop that calls
>> back to the intepreter. Probably argument handling or so. You need to
>> annotate the function with @jit.unroll_safe (that means that each time
>> the number of iteration is different, you'll get slightly different
>> assembler, so beware)
>
>
> 2013/2/22 Maciej Fijalkowski <fijall at gmail.com>:
>> On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin at gmail.com> wrote:
>>> In what cases does the jit decide not to inline a function call, but
>>> place "call_may_force" instead?
>>> The context is that I have a simple interpreter, like an expanded
>>> kermit, and I am testing how the jit helps - it perfectly unboxes
>>> wrapped objects in a loop, but does not inline function calls - I
>>> wonder what am I missing here. I found a place where PyPy interpreter
>>> makes a call and did not see anything special there.
>>
>> call_may_force means you call a function that has a loop that calls
>> back to the intepreter. Probably argument handling or so. You need to
>> annotate the function with @jit.unroll_safe (that means that each time
>> the number of iteration is different, you'll get slightly different
>> assembler, so beware)