lightning
[Top][All Lists]
Advanced

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

Re: [PATCH] ppc: Fix 'calli' when floating-point arguments are passed


From: Paulo César Pereira de Andrade
Subject: Re: [PATCH] ppc: Fix 'calli' when floating-point arguments are passed
Date: Mon, 5 Sep 2022 14:00:41 -0300

Em sáb., 3 de set. de 2022 às 12:33, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> Hi Paulo,
> [...]

  Hi Paul,

> >>  About the "call" check, I didn't debug it yet, but it may be
> >> related to
> >>  calling "near" code as well. I had to use the following temporary
> >>  workaround in my code to avoid crashes:
> >>  https://github.com/pcercuei/lightrec/blob/master/emitter.c#L35-L47
> >
> >   This is strange. check/*.tst is full of forward and backward jumps.
> > Not just call.tst has them. But call.tst has a few forward/backward
> > tests of calls and jumps. Unless the can_sign_extend_jump_p() macro
> > has some bug in the displacement test, and  was never experienced
> > in the tests.
>
> What happens is I have a pointer that I keep in the last JIT_V()
> register, and the jit_jmpi() call uses the same register as a temporary.

  Please double check if it is JIT_V13 or jit_(13), it could be some
mistake with jit_v_num() telling there are 14 callee save registers.
It also happens to be "r14".

> Adding a jit_live() right before the jit_jmpi() fixes it, but it makes
> me wonder why Lightning considered it okay to use this register in the
> first place.

  I would need at least a jit_print() of all the assembly to understand the
reason it is apparently considering the register as dead.

  Please also make sure to test with assertions enabled. But this should
not make much of a difference if jit_live() is a workaround, so, it should
be some condition leading it to think the register is dead.

> Cheers,
> -Paul

Thanks,
Paulo



reply via email to

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