lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Cercueil
Subject: Re: Optimizing byte-swap-and-store on PPC
Date: Thu, 09 Feb 2023 16:05:25 +0000

Le jeudi 09 février 2023 à 12:46 -0300, Paulo César Pereira de Andrade
a écrit :
> 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.

Isn't this information already known at code generation time? My
assumption was that Lighning would do register liveliness analysis
before the code generation.

> > >   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

-Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]