lightning
[Top][All Lists]
Advanced

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

Re: [Lightning] jit_movr broken on MIPS


From: Paul Cercueil
Subject: Re: [Lightning] jit_movr broken on MIPS
Date: Sun, 23 Nov 2014 20:56:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0

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.


   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.

Regards,

Paul



reply via email to

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