lightning
[Top][All Lists]
Advanced

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

Re: [PATCH] lightning: Only optimize movr for regular registers


From: Paulo César Pereira de Andrade
Subject: Re: [PATCH] lightning: Only optimize movr for regular registers
Date: Thu, 22 Jun 2023 14:27:09 -0300

Em qui., 22 de jun. de 2023 às 14:18, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> Hi Paulo,

  Hi Paul,

> Le jeudi 22 juin 2023 à 14:08 -0300, Paulo César Pereira de Andrade a
> écrit :
> > Em qui., 22 de jun. de 2023 às 13:58, Paul Cercueil
> > <paul@crapouillou.net> escreveu:
> >
> >   Hi Paul,
> >
> > > When a jit_movr() or jit_movi() targets a register that is not used
> > > by
> > > Lightning, the opcode should be emitted or undefined behaviour may
> > > occur.
> > >
> > > This makes it possible to read/write system registers using
> > > jit_movr(),
> > > for instance the GBR register on SuperH processors, which is
> > > generally
> > > used as the base address of the thread-local storage data.
> > >
> > > Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> > > ---
> > >  lib/lightning.c | 18 +++++++++++++++++-
> > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/lib/lightning.c b/lib/lightning.c
> > > index 95502e5..5f49643 100644
> > > --- a/lib/lightning.c
> > > +++ b/lib/lightning.c
> > > @@ -3585,11 +3585,21 @@ _simplify_movr(jit_state_t *_jit,
> > > jit_node_t *prev, jit_node_t *node,
> > >  {
> > >      jit_int32_t                 regno;
> > >      jit_int32_t                 right;
> > > +    jit_int32_t                 spec;
> > >      jit_value_t                *value;
> > >
> > >      regno = jit_regno(node->u.w);
> > >      right = jit_regno(node->v.w);
> > >      value = _jitc->values + regno;
> > > +
> > > +    spec = jit_class(_rvs[regno].spec);
> > > +    if (!(spec & (jit_class_gpr | jit_class_xpr | jit_class_fpr)))
> > > {
> > > +       /* reserved register */
> > > +       value->kind = 0;
> > > +       ++_jitc->gen[regno];
> > > +       return (0);
> > > +    }
> > > +
> > >      if ((value->kind == jit_kind_register &&
> > >          jit_regno(value->base.q.l) == right &&
> > >          value->base.q.h == _jitc->gen[right]) ||
> > > @@ -3627,12 +3637,18 @@ _simplify_movi(jit_state_t *_jit,
> > > jit_node_t *prev, jit_node_t *node,
> > >         ++_jitc->gen[regno];
> > >         return (0);
> > >      }
> > > +    spec = jit_class(_rvs[regno].spec);
> > > +    if (!(spec & (jit_class_gpr | jit_class_xpr | jit_class_fpr)))
> > > {
> > > +       /* reserved register */
> > > +       value->kind = 0;
> > > +       ++_jitc->gen[regno];
> > > +       return (0);
> > > +    }
> > >      if (value->kind == kind) {
> > >         if (memcmp(&node->v.w, &value->base.w, size) == 0) {
> > >             del_node(prev, node);
> > >             return (1);
> > >         }
> > > -       spec = jit_class(_rvs[regno].spec);
> > >         if (kind == jit_kind_word)
> > >             spec &= jit_class_gpr;
> > >         else
> > > --
> > > 2.40.1
> >
> >   Before adding the patch, are you using jit_class_xpr in some
> > context
> > it is not or'ed with jit_class_fpr?
> >
> >   Usage of jit_class_xpr is just an extra flag to jit_class_fpr in
> > current
> > usage to know if it is a sse register in x86. There are other special
> > maks, like jit_class_sng for sparc and jit_class_sfw for arm.
>
> No I don't, so I guess it doesn't need to be or'd in there.

  Just pushed the commit.

  Nice to know you are working in the SuperH port you commented
some time ago.

  Did not do much in Lightning after 2.2.2 release. I am considering
at some point in the near future work in some vector abstraction,
that should match riscv and/or loognarch as closely as possible, and
adapt for other architectures, possibly with full fallback...

> Cheers,
> -Paul

Thanks,
Paulo



reply via email to

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