Re: Optimizing byte-swap-and-store on PPC

[Paulo César Pereira de Andrade]

Em qui., 9 de fev. de 2023 às 08:18, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> Hi Paulo,

  Hi Paul,

> If you remember, I added an optimization (for my use case anyway) for
> the following code:
>
> jit_ldr(rY, rX);
> jit_bswapr(rY, rY);
>
> Lightning will only generate a single LWBRX instruction for this.
>
> Now I would like to do the same for stores. The problem is that the
> pattern typically use a temporary register T:
>
> jit_bswapr(T, rX);
> jit_str(rY, T);
>
> How can I know that the register T is dead after this pattern?

  Depends a bit on how T value is resolved.

  If from jit_get_reg() it is live until the jit_unget_reg() call. You
should avoid branches that cannot be followed in such cases.

  Bellow is explanation when an explicit value, not from jit_get_reg().

  It is considered live in the range it is set until the last use of the
register.
  It is considered dead in the range from last use (but not set)
until the next value change. Branches might cause it to be in
a state merged as live due to use in other paths.
  The liveness range is broken if it is not a callee save register
and when following the code it finds a function call or an indirect
branch to a register or non jit address.
  If it is a callee save register it is always considered live.

  There isn't an explicit jit_dead() call because most times it would
allow creating bugs that are difficult to debug. There is only a
jive_live() call to allow telling a non callee save register is live
at the point of an indirect branch or at a label entry, usually
a point where an indirect branch lands, or some function returns
a value in a non standard way.

  The easiest way to see what is happening is call jit_print() and
see the state it prints at label entry point.

  If this reply is not clear, please provide some sample example
code or jit_print() output.

> Cheers,
> -Paul

Thanks,
Paulo