Multiple/unnecessary compilation case.
f gets compiled into rir before it is first executed. In the process, g's dispatch table is created and linked from f (so far so good). After the first invocation of f, a version specialized for int is compiled for function g.
Then next time f gets executed, compilation does not happen (since PIR_WARMUP=3 ). F runs bytecode, calls g, the specialized version for ints is used.
Now f is called once more. Compilation for f triggers. We can see in the compilation output that it takes many compilation passes and runs to infer the right context to g. And, since during each iteration the compiler tries to compile a suitable version of g, it ends up compiling 4 different versions with varying degrees of specialization. This is only to end up with the one that was compiled at the very beginning (the one for ints). The reason this version gets also recompiled is because we're in a new compilation session and, since PIR code is not kept around across sessions, a StaticCall instruction will trigger compilation of its callee to be hopefully available later for inlining (which I disabled in this case). The only step that is skipped is the translation for PIR to native for the int version, since it realizes that there is already a native version in the dispatch table for such context.
I believe the slow convergence to get the right context for the arguments to g is connected to the presence of the for loop. This needs to be looked into.
Also, even if inlining is disabled in the repro, this could happen in situations where there is a StaticCall but the inlinee cannot be inlined (there a many unsupported cases in Rsh).
The recompilation of the right version of g might be avoided if we decided to keep PIR code around (maybe the compile server could help here).
Running the following script:
f <- function() {
tot <- 0L
g <- function(x) x + 1
for (i in 1:100000) {
tot <- tot + g(i)
}
tot
}
rir.compile(f)
rir.disassemble(f)
f()
f()
f()
f()
And the command line: PIR_OSR=0 PIR_WARMUP=3 PIR_DEBUG=PrintPirAfterOpt,PrintToStdout bin/R -f compTest.R
while inlining is disabled (to achieve that simply return true at inline.cpp):
Multiple/unnecessary compilation case. f gets compiled into rir before it is first executed. In the process, g's dispatch table is created and linked from f (so far so good). After the first invocation of f, a version specialized for int is compiled for function g.
Then next time f gets executed, compilation does not happen (since PIR_WARMUP=3 ). F runs bytecode, calls g, the specialized version for ints is used. Now f is called once more. Compilation for f triggers. We can see in the compilation output that it takes many compilation passes and runs to infer the right context to g. And, since during each iteration the compiler tries to compile a suitable version of g, it ends up compiling 4 different versions with varying degrees of specialization. This is only to end up with the one that was compiled at the very beginning (the one for ints). The reason this version gets also recompiled is because we're in a new compilation session and, since PIR code is not kept around across sessions, a StaticCall instruction will trigger compilation of its callee to be hopefully available later for inlining (which I disabled in this case). The only step that is skipped is the translation for PIR to native for the int version, since it realizes that there is already a native version in the dispatch table for such context.
I believe the slow convergence to get the right context for the arguments to g is connected to the presence of the for loop. This needs to be looked into. Also, even if inlining is disabled in the repro, this could happen in situations where there is a StaticCall but the inlinee cannot be inlined (there a many unsupported cases in Rsh). The recompilation of the right version of g might be avoided if we decided to keep PIR code around (maybe the compile server could help here).
Running the following script:
And the command line:
PIR_OSR=0 PIR_WARMUP=3 PIR_DEBUG=PrintPirAfterOpt,PrintToStdout bin/R -f compTest.Rwhile inlining is disabled (to achieve that simply return true at inline.cpp):
Output: