Re: GNU Lightning needs a new maintainer

[Paulo César Pereira de Andrade]

]Em qua., 13 de abr. de 2022 às 15:43, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> Hi,

  Hi,

> We are a few people trying to contribute to GNU Lightning, but the
> maintainer (Paulo) seems to be MIA. His last email on the mailing list
> was on May of last year. Since then we couldn't get a patch in.

  Sorry. I understand the situation. I missed most emails, and only
look at this email address every few weeks or months. I will attempt
to reply next to at least a few from archives.

  My job and my real life are absorbing most of my time, and very few
time is left for volunteer efforts.

> I think it would make sense to find a new maintainer to unlock the
> situation.
>
> The second point I would like to talk about: I do wish this project was
> on github/gitlab, one part for the convenience (managing PRs and
> integrated bugzilla), and the other part is the need of CI. GNU
> Lightning supports 10+ architectures in various configurations, it is
> just impossible to test properly every patch that we make. Automated
> builds would be a big help.
>
> Cheers,
> -Paul

Thanks!
Paulo


>From more recent to older:

[PATCH] Add conditional move opcodes:
I absolutely do not dislike it. But this might be an optimization in the
wrong place. Either lightning should understand and create it, but need
a back end specific optimizer, or this is just the start of making it far
more complex, and would need a fallback for arches that do not have
it, and it might be complex, would be like jit_b{o,x}{add,sub}* but instead
of a conditional jump, a conditional move.
There are a few optimizations, and this likely could be done in the
generic optimizer, if it knows the target extra features, or, it could be
done by a backend specific optimization pass. But really, it would be
better to think on how make lightning simpler, not more complicated.

[Patches for configure Script and Doc]
Sorry about these. I do not use Ubuntu but will add the patches and
possibly patch it to not break at least in the environments I use.

[[PATCH 0/6] Misc patches to pass the testsuite and remove warnings]
Can work on some of these, but really, -fno-strict-aliasing should be
default if doing any optimized build, or, you might end with a hidden bug
very difficult to find. Better to just stick with -fno-strict-aliasing.

[Issue when using jit_label() before a jump or branch]
It appears it was already discussed in the thread. Unless I misunderstood
the issue, the generated code is correct. It is a non conditional jump to
a non conditional jump, so, it is ok to take a short circuit.

[[PATCH 1/6] riscv: Fix movi/relatives loading incorrect value]
The patch is incorrect. The sign extension is expected. The "magic" is
the use of addiw. Note that constants are 64 bit, so, you might be
doing something wrong.

[[PATCH 2/6] arm: Force RES0 bits in TST/A1 to be 0]
Need to check it on actual hardware. For the past 10+ years I did only
test arm variants on qemu images.

[[PATCH 3/6] mips: Use DEXT when in 64-bit mode instead of EXT]
I did never test on mips 64. Note that apparently will just amend a
patch you already did send. But I can add it.

[[PATCH 6/6] Include math.h in check/lightning.c]
This is straight and should not have any side effects.

[[PATCH 5/6] misc: Add bfd_arch to arm/aarch64/mips]
This appears to dependent on the binutils version. As long as it works
with older binutils (from my test vms) it can be added, otherwise, will
need a binutils version check.

[[PATCH 4/6] ppc: Add endianness check to _truncr_d_i]
Thanks, this appears to be correct, and somehow missed when doing
the ppc64le port. Need to review again, probably I missed a make check
in some of the last steps.

[Atomic operations]
If patches are provided, sure it would be welcome. My main usage of
lightning was fine with calls to pthread_* as it was only jit for a custom
language. The main problem comes with fallbacks for arches that do
not support it, so, only some minimal set likely could be added.

>From here I see my comments... but will review further the archives.