Adding a Lightning backend in MIR project ? about mir HOT 9 OPEN

Would it make sense ? Any comments ?

Gnulighting is an interesting project. I considered its usage about 2 years ago. IMHO using it would hurt generated code performance significantly. Two compiler optimizations giving the biggest performance gain are register allocation and code selection.

Lighting abstract machine model assumes only 6 general regs (for comparison optimizing compilers assumes infinite number of regs). The small number of general reg is a big constraint for effective using regs for most RISC architectures (usually they have 32 general regs) and even for x86-64 (16 regs).

Lighting insn model is RISC machine model which will hurt performance for x86-64 CISC which, for example, permits using memory for arithmetic insn even with an immediate in the insn.

In general my understanding is that gnu lighting mostly solves machine insn encoding problem and does it in a very fast way. Implementation of this is tedious and time consuming task. Still I managed to port MIR to aarch64 for 2 full weeks. So I don't think that encoding task will be a big obstacle for MIR.

Also another cons for me to use gnulighting were a license and big source code size mostly because of many targets it supports. I don't think some of these targets are important now.

I believe MIR could be used for dynamic recompilation too. For this only RA could be used. By the way I will add optimization levels to vary generation speed vs generated code performance. There is still probably a market niche for gnulighting because I see analogous approach in BPF very hyped these days.

from mir.

Also another cons for me to use gnulighting were a license and big source code size mostly because of many targets it supports. I don't think some of these targets are important now.

One of the greatest assets of MIR is that it is has MIT license, is small and self contained with zero external dependencies, and yet achieves great performance. This combination of features is so unique that I think nothing should be allowed to change it.

from mir.

OK, thanks for the detailed answer.

from mir.

Lighting abstract machine model assumes only 6 general regs (for comparison optimizing compilers assumes infinite number of regs). The small number of general reg is a big constraint for effective using regs for most RISC architectures (usually they have 32 general regs) and even for x86-64 (16 regs).

Lightning gives you at least 6 general regs. Most archs have more.

Lighting insn model is RISC machine model which will hurt performance for x86-64 CISC which, for example, permits using memory for arithmetic insn even with an immediate in the insn.

Yes, that's why you should have optimized code generators for the "important" archs like x86_64 and Aarch64. But for all the archs you're not going to bother writing a backend for, Lightning would be a good idea.

I believe MIR could be used for dynamic recompilation too.

I use Lightning in a dynarec I wrote for Playstation emulators: https://github.com/pcercuei/lightrec. Unless MIR can compile thousands of functions per second on a weak 1 GHz ARM SoC, then no, it cannot be used for dynamic recompilation.

from mir.

Lightning gives you at least 6 general regs. Most archs have more.

Sorry, I probably misread this. So if you use more regs than a target machine permits what will happen? As I understand gnulighting somehow dealing with this situation. Will it reject the program? Or this means that lighting has a RA? It could be primitive one (e.g. putting higher regs on a stack), but still RA.

I use Lightning in a dynarec I wrote for Playstation emulators: https://github.com/pcercuei/lightrec. Unless MIR can compile thousands of functions per second on a weak 1 GHz ARM SoC, then no, it cannot be used for dynamic recompilation.

Thank you for reference for your github project. I probably will work in this direction too although it would be less priority for me. MIR-generator would simplify the code, does RA (I can speed up it considerably decreasing RA quality, no big deal for me as I worked mostly in RA area for last 15 years) and encode the insns. In this pipeline I don't see a big difference with gnulighting so the speed can be close to gnulighting.

from mir.

Paul, sorry for bothering you. Looking at your litrec project, I see a lot of things (e.g. optimizations) you are doing by yourself besides using gnulighting. I am just curious, what % of CPU time gnulighting actually use in all you program work?

from mir.

Sorry, I probably misread this. So if you use more regs than a target machine permits what will happen? As I understand gnulighting somehow dealing with this situation. Will it reject the program? Or this means that lighting has a RA? It could be primitive one (e.g. putting higher regs on a stack), but still RA.

Basically you have between 3 and JIT_R_NUM caller-saved registers, and between 3 and JIT_V_NUM callee-saved registers. Treat them like regular hardware registers of a CPU: you still need a RA.

Paul, sorry for bothering you. Looking at your litrec project, I see a lot of things (e.g. optimizations) you are doing by yourself besides using gnulighting. I am just curious, what % of CPU time gnulighting actually use in all you program work?

I don't have any actual number at hand, but it's neglectible. The API functions listed in the manual are generally tiny wrappers. Lightning doesn't do any optimization whatsoever, which is perfect in my case since I recompile code that has been optimized by GCC in the first place (GCC2, but still).

from mir.

Basically you have between 3 and JIT_R_NUM caller-saved registers, and between 3 and JIT_V_NUM callee-saved registers. Treat them like regular hardware registers of a CPU: you still need a RA.

Thank you. I forgot all this about lighting. I only remember a general impression.

So basically it means lighting can not be used as machine-independent language and its user should treat this as real CPU and does some RA by himself. Or it can be used as machine-independent language but in this case only 6 regs can be used.

from mir.

Yes, exactly.

from mir.