Re: [PATCH 0/4] Misc patches

[Paulo César Pereira de Andrade]

Em seg., 17 de mai. de 2021 às 15:59, Paul Cercueil
<paul@crapouillou.net> escreveu:

  Hi Paul,

> Hi Paulo,
>
> Le lun., mai 17 2021 at 14:38:27 -0300, Paulo César Pereira de Andrade
> <paulo.cesar.pereira.de.andrade@gmail.com> a écrit :

[...]
> >>  A Re-re-resend of various patches that I have locally and that
> >> should
> >>  benefit the project.
> >
> >   Thanks! Just pushed most of the patches.
> >   Will review better the new bswapr patches and reconsider adding
> > the _ui interfaces to 32 bit. The _ui were not added as at first it
> > appeared to be better to have the programmer understanding what
> > was going on, but requiring the check for word size, what might be
> > done in some extra macro.

  The hppa version should be easy, just copy&paste some non
optimized version from other arch port. But first check the manual, and
on qemu-hppa should be able to debug in case there are already
byte reversal instructions.

 For the moment, it would be better to add the codes replacing
jit_code_last, to ensure binary compatibility, and reorder when
some major release is done. It could use another name as well,
like 'rev' instead of 'bswap' but that is cosmetic :)

> Great, thanks!
>
> I have some more patches queued to enhance the code generation for
> MIPS, I'll send them soon.
>
> One thing I'd like to see is an automatic (or assisted) way for
> Lightning to fill delay slots. Right now I have a lot of delay slots
> filled with NOPs. I am not sure what would be the best way to do it
> though.

  There is no standard way to do it in lightning. It would be required to hook
some code during instruction generation. It might be possible to do in the
pattern used in lib/jit_arm.c:_load_const that creates a buffer of
constants after unconditional branches, or generate one if run out
of offset space. But most likely, it would be required an intermediate
buffer, to use somewhat like the logic in lib/jit_ia64-cpu.c:_flush,
that keeps a few instructions in a buffer, then, if it notices the need to
sync registers, that is, a register would be modified more than once
in a sequence and cannot be executed in the same cycle.
  Thinking very carefully about the issue, it is possible to come with
some simple solution, like the logic used to keep track of jit_carry.


> Another thing nice to have, would be conditional move instructions
> (move if zero/non-zero). I know for sure these are implemented in MIPS,
> ARM and Aarch64. I can send a patchset for these.

  In the mips port it uses only movz in the b{o,x}add* interfaces. I
believe some were added to -{fpu,sse,x87}.c interfaces in complicated
logic to detect comparison on ordered/unordered values.

> Finally, I am trying to write a backend for SH-2/4 processors. I am
> hitting a rock as the SH's FPU can be toggled between 32-bit mode and
> 64-bit mode, in which the registers are paired, so I have no idea how
> to properly handle that. My idea was to use one of these modes
> unconditionally, but then it fails to pass any test that involves the
> FPU. Any ideas?

  Likely you need to either switch the mode in the main code, or
implement jit for the default mode. Also, unless not available, you
need both, 32 and 64 bit values. I believe the sparc code is the
most close to it, where it uses only even numbered float registers.

> Cheers,
> -Paul

Thanks!
Paulo