lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Lightning needs a new maintainer


From: Paulo César Pereira de Andrade
Subject: Re: GNU Lightning needs a new maintainer
Date: Tue, 10 May 2022 18:11:05 -0300

Em seg., 9 de mai. de 2022 às 20:22, Paul Cercueil
<paul@crapouillou.net> escreveu:

  Just added most patches from archives. Need to still check
other ones.

  For the moment checking what could be done about the conditional
mov suggestion.

[snip]

> Some time ago I did update the patch, the latest can be found here:
> https://github.com/pcercuei/gnu_lightning/commit/6f101bf8eccef737d60bf7e6ba85558db49e7908

  This is good but there is a possible incorrect code generation path.

  It should handle jit_code_movzr and jit_code_movnr in lib/lightning.c,
then, add an implicit block split when finding these instructions, but
most likely would just work if assuming the register is always modified.
E.g. needs at least an entry in _jit_classify like this (or just extending
matching ones):

    case jit_code_movnr:    case jit_code_movzr:
        mask = jit_cc_a0_reg|jit_cc_a0_chg|jit_cc_a1_reg;
        break;

The code that keeps track of register live states does not do full SSA
optimization, so, assuming the register is always changed should work,
without the need of splitting the code block, i.e. treating it as conditional
branch, but need to check carefully.

> I added conditional opcodes for ARM and Aarch64, and a fallback
> implementation for PowerPC. Adding fallback implementations for the
> rest of the architectures shouldn't be too hard, the hard part is
> creating a qemu image and testing for every arch...
>
> If I understand you correctly, the optimizer would detect this pattern:
>
> branch = jit_beqi(r2, 0);
> jit_movr(r0, r1);
> jit_patch(branch);
>
> And replace it with a conditional opcode for the current arch?
>
> I guess that works for me, it keeps the API simple, but I'm not sure I
> can implement that. The inner Lightning (outside *-cpu.c) is scary and
> I wouldn't know where to start.

[snip]

> Cheers,
> -Paul

Thanks,
Paulo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]