Re: [Lightning] jit_movr broken on MIPS

[Paulo César Pereira de Andrade]

2014-11-23 17:56 GMT-02:00 Paul Cercueil <address@hidden>:
> Hi Paulo,
>
>>    Please post the disassembly log (you may post it off list to me to
>> avoid a 6M+ mail, and I would reply with only what should matter).
>> Please also have in the log a call to jit_print, and edit the log to tell
>> where it was optimized out. If the jit_print call already removed the
>> jit_movr please annotate in the log where it was done.
>>    This should make it easier to understand what condition led
>> to the instruction being optimized out.
>
>
> I uploaded three snippets of log:
>
> The reference, generated by a different JIT, that shows hashes of the 2 MiB
> of RAM, of the (emulated) 32 MIPS GPR and 32 CP0 registers before and after
> the execution of the code:
> http://crapouillou.net/~paul/reference.txt
>
> The machine code generated by my lightning-based dynarec, with latest GIT of
> Lightning. The issue I'm talking about can be seen line 47, where a call to
> jit_retval_i() doesn't generate any code.
> http://crapouillou.net/~paul/broken.txt
>
> Finally, the machine code generated by the *exact* same binary, not
> recompiled in between, with the GIT version of Lightning patched to use
> jit_orr(dst, 0, src) instead of jit_movr(dst, src) within the function
> jit_retval_i():
> http://crapouillou.net/~paul/fixed.txt
>
> There, the bug doesn't appear anymore. The return value of the function call
> is correctly fetched into s0. The hashes corresponding to the final state
> match perfectly the ones of the reference JIT.

  I just pushed
http://git.savannah.gnu.org/cgit/lightning.git/commit/?id=c95a356c1ad9e1d1dda43545f8b030f33a1155ae
that should correct it. The optimization had a flaw in the way
it handles a calle save register set to a non callee save register,
and instead of correcting the check condition, I changed it to the
common denominator of not optimizing it, because it is a complex
condition, and I could oversight some other special condition.

>>    Note that, unless you found a bug, it may optimize out a store
>> to a non callee save register under certain conditions, like before
>> a jit_ret* (non callee save register liveness reach epilog) or a
>> jit_jmpr, or a jit_jmpi patched to an absolute address; it treats
>> jit_jmpr and jit_jmpi to absolute address as a function call, as
>> otherwise it would need to consider all non callee save registers
>> live on a jump to an undefined target, and that would defeat the
>> register allocator.
>
>
> I would have understood that; But in my case the optimized-out register is
> s0, which is a callee-saved register.

  Yes. I think you just found a bug that happens on not so special
conditions, but is a code pattern that was not "exercised" before.

  I will try to write a special test case that would trigger this
condition later.

  Please test with the latest commit in lightning git.

> Regards,
>
> Paul

Thanks,
Paulo