Re: [PATCH] ppc: Add optimization to generate endian-swapping load opcodes

[Paulo César Pereira de Andrade]

Em sex., 12 de ago. de 2022 às 09:43, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
>
>
> Le ven., août 12 2022 at 09:40:30 -0300, Paulo César Pereira de
> Andrade <paulo.cesar.pereira.de.andrade@gmail.com> a écrit :
> > Em sex., 12 de ago. de 2022 às 09:26, Paul Cercueil
> > <paul@crapouillou.net> escreveu:
> >>
> >>
> >>  [...]
> >>
> >>  >>  Actually that case would be fine. It's for the case where the
> >> LABEL
> >>  >> is
> >>  >>  between the ldr_ui and the bswapr_ui. I do check the previous
> >>  >> opcode,
> >>  >>  because that's where the jit_flag_patch seems to be.
> >>  >
> >>  >   I see. The logic is just checking if the previous node is a
> >> label
> >>  > or an
> >>  > epilog implicit patch.
> >>
> >>  Actually it looks like the detection code is broken. With the
> >> example
> >>  code of my previous email, if I add a jit_label() between the
> >>  jit_ldr_ui() and the jit_bswapr_ui(), it still converts to the LWBRX
> >>  opcode and Lightning eventually fails an assert() in jit_address().
> >
> >   It should not fail if you use jit_indirect() instead of
> > jit_label(). Using
> > jit_label() is subject to optimization, if there is no jump to it. The
> > assertion is because the label is not used.
>
> I used jit_address() though, is that not considered as using the label?

  If you did use jit_print() or jit_disassembly(), it would not show the label,
as it should been removed from the linked list, due to no jump targeting it.
  It is done in lightning.c:sequential_labels()

> >   I will apply the patch, and possibly add a small further patch with
> > a comment about moving it to another place if a backend specific
> > optimization pass is implemented.
>
> Great, thanks!
>
> Cheers,
> -Paul
>
>