On Fri, Feb 22, 2013 at 1:56 PM, Костя Лопухин <kostia.lopuhin@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@gmail.com>:

...

On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin@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@gmail.com>:

...

On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin@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@gmail.com>:

...

On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin@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)

On Fri, Feb 22, 2013 at 1:56 PM, Костя Лопухин <kostia.lopuhin@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@gmail.com>:

...

On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin@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@gmail.com>:

...

On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin@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@gmail.com>:

...

On Fri, Feb 22, 2013 at 8:49 AM, Костя Лопухин <kostia.lopuhin@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)