[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optimizing byte-swap-and-store on PPC
From: |
Paulo César Pereira de Andrade |
Subject: |
Re: Optimizing byte-swap-and-store on PPC |
Date: |
Thu, 9 Feb 2023 12:46:58 -0300 |
Em qui., 9 de fev. de 2023 às 11:20, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> Le jeudi 09 février 2023 à 09:49 -0300, Paulo César Pereira de Andrade
> a écrit :
> > 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().
>
> In my case it is with an explicit value, yes.
>
> > 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.
>
> I myself do know when the registers are dead, if I look at the code -
> that was not my question. What I'm wondering, is whether it is possible
> to know if a given public register (as in JIT_V/JIT_R) is dead, at a
> specific point in the code generation step within Lightning itself.
>
> Something like a (private)
> "bool reg_is_dead(jit_node_t node, jit_int32_t reg)" function.
>
> The code generator for "jit_str" (and related) would then convert the
> jit_bswapr(T, rX) + jit_str(rY, T) to a single "STBRX rY, rX"
> instruction, if we know that T is dead after this point.
This should be done at code generation time. It probably would
require some extra steps, but the core logic should be to call the
macro in include/lightning/jit_private.h:
#define jit_reg_free_p(regno) \
(!jit_regset_tstbit(&_jitc->reglive, regno) && \
!jit_regset_tstbit(&_jitc->regarg, regno) && \
!jit_regset_tstbit(&_jitc->regsav, regno))
Extra steps should be required because the jit_str(rY, T) is the start
of a live range for T, so, need to better understand the conditions.
Basically, it is live until next time T is used as source operand, or
dead if not used as source operand until an instruction that uses T
as output/result.
> > 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
>
> Cheers,
> -Paul