Re: [tclquadcode] Procedure inlining

[Donal K. F. <don...@ma...>]

On 30/12/2017 21:48, Kevin Kenny wrote:
> First, and most important by far, is that I can't inline a procedure 
> that might return failure. I've simply not found a way to do it with the 
> existing quadcode instruction repertoire. I can see the 
> 'returnException' instruction in the procedure to be inlined, but I 
> don't see a good way to construct the object that the procedure would 
> have returned. (Ideally, including the stack trace that would have 
> appeared, for which I have all necessary information, I think.) This is 
> blocking all but about a dozen of the potential opportunities for inlining.

Yes, that's important and will require a new opcode. The key things it
will need to do will be to release the stack frame (I presume we have a
plan to create new stack frames too?) and process the procedure exit
sequence. That opcode will need to know what procedure it is actually in
(currently, 'returnException' uses [namespace tail $cmd]).

We might wish to split our current 'returnException', which would
coincidentally allow the error exit sequence to use 'return'.

There will also need to be some review of 'param' usage. That opcode's
implementation accesses the bytecode definition dict in some cases (with
a warning about "default injection" if it does so; I think we don't spit
those out at the moment so we might be OK though I don't know how
thorough our testing is).

> A second limitation is that I don't seem to have any way in the
> @debug quadcodes to indicate that I've brought in code from a
> different source file. That will mess up stack traces, compile-time
> messages and so on, if a procedure in one file inlines a procedure
> defined in a different file.

There will need to be something for the shift in source file
(spitballing: @debug-file {} {literal /path/to/file}) and something for
the shift in procedure. (The order of these things is likely to be
important.)

> I'm hoping that Donal will be able to help me out.

Of course. But it might take quite a bit of tinkering to get the debug
info exactly correct.

> I suspect that in this specific case, LLVM is smart enough to inline
> the 'impure' procedure itself and generates approximately the same
> code.

Reading the (rather long) output of

   tclsh8.6 demos/perftest/tester.tcl -just impure -asm 1

indicates that this indeed the case. Indeed, it goes further in some
cases and inlines the result into the thunk function that provides the
actual Tcl command. (What's curious is that it doesn't when we use an
external optimiser. I guess the llvmtcl internal one has looser limits
on that sort of thing.)

Donal.