If you want real (and costly) optimizations, GNU lightning is perhaps
not the best JIT library. In that case, consider instead libgccjit (see
https://gcc.gnu.org/onlinedocs/jit/ for more) or LLVM (see
http://llvm.org/ ...).
I didn't mean costly optimizations. I just meant to expose some information GNU lightning is already collecting anyway so that the user code emitting GNU lightning instructions does not have to do the same work.
For my use case, I don't need register spilling for an arbitrary number of variables (which libgccjit and llvm would do), I only need a fixed set of registers.
I could either take the minimum amount of registers available (R0, R1, R2, V0, V1, V2) provided by any lightning backend (which would waste registers on backends with more registers), or I could take an amount of registers provided on common CPUs (e.g. R0-R3, V0-V3 on AMD64 with System V ABI). In the latter case, I would have to emulate these registers on lightning backends with less registers, e.g. by stack locations. To handle these, scratch registers are needed.
Of course, the generated code would run faster,
but the generation time (actually some compilation) would be slower.
Alternatively, emit C code into a temporary file, compile it into some
plugin, then use plugin loading facilities like dlopen (on POSIX).
I need proper tail calls, so I cannot compile to C (without contortions). I expect code generation to happen very often and only in small pieces, so GNU lightning seems to be much more appropriate than LLVM or libgccjit (which, by the way, I would prefer to LLVM for political reasons).
Marc
Cheers
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France