Something strange with many XmmVar objects

[Nekotekina]

Hi! Sorry if I'm idiot myself, and I can't explain the bug properly. It seems to occur occasionally, only on relatively "heavy" things.

I tried to write this code:
https://github.com/Nekotekina/rpcs3/blob/180f8aac5d2d64c79703503fb7c3e504640d9f9a/rpcs3/Emu/Cell/SPURecompiler.h#L2854

If I uncomment this code and remove "wrapper", some "heavy" thing stops working. But relatively easy things are not affected.

I tried to catch all input and output values using "wrapper", but bug disappeared. All values were similar to "correct" ones. It also passes some easy autotest. So I couldn't find any situation my algorithm fails on. Well, I'm not sure, but I can say that adding specific call() with setArg() changed its behaviour but shouldn't.

Now I decided to add 16 XmmVar variables once when Compiler object is created, instead of local ones in every function, and things got even worse.

EDIT: Found that I was using "void" instead of "FnVoid", going to check it...

[kobalicek]

Hi Ivan,

I checked out your code and it seems that you are using asmjit the right way, before we move on I would like to ask you to check if asmjit is running in debug mode (simply try ASMJIT_ASSERT(0) ), because a possible misuse would be highly probably catched by asmjit itself. If you are not running asmjit in debug mode try defining ASMJIT_DEBUG and see what happens.

Btw what do you mean if you remove "wrapper"? Maybe trying removing wrappers one-by-one and checking if things still work is a good idea, or do you have any integration code to test if the generated code is correct?

[Nekotekina]

Seems debug mode is enabled with debug mode of whole solution enabled.
There is valid high-level code that I try to call from inside of interpreter. My wrapper takes this code and generates call from inside of JIT. I often switch between wrapped code and asm. Unfortunately, I don't use anything more advanced.

[kobalicek]

Well, there are two possibilities if I consider bug on asmjit side:

1. Incorrect machine code generated by assembler
2. Incorrect code generated by compiler

Checking assembler output is easy, just use a disassembler on the generated output and compare with the asmjit logger - perfect place is the place where it crashes, I fixed incorrect lea instruction generation recently by using this technique.

Checking compiler output is a bit tricky, I would recommend to use logger and log everything it emits, with liveness analysis it will be probably a huge output, but I think it's worth it.

Pasting output from logger for working version and non-working version can help as well

[Nekotekina]

Finally I found an error...

http://pastebin.com/zxWsk9JZ the whole function generated.

Second PSHUFB is wrong:

movdqa xmm2, oword ptr [rbp+576] ; 660F6F9540020000 | movdqa reg_3, [cpu+576]
pshufb xmm6, xmm0 ; 660F3800F0 | pshufb reg_3, reg_2

It's reg_3 that should be xmm2 but it's xmm6

[kobalicek]

Hi Ivan,

I just checked it out and I think that I know where is the problem, it seems that pshufb instruction is incorrectly flagged in x86defs, give me around 1 hour and I will try to fix it if this is the issue.

Thanks for the report

[kobalicek]

Hi Ivan,

please check out master and let me know the commit above fixed the issue.

[Nekotekina]

Thanks, seems pshufb works right now, but I was experiencing weird behaviour even without using pshufb at all. Maybe other similar issues could exist?

[kobalicek]

Well, to be honest I think that you are hitting a bug in Compiler, but to track it down I would need more information and some output. Comparing asmjit output with disasm may also help to track invalid opcode generated, hard to say, I think important is if it's a register allocation issue or machine code generation issue.

[Nekotekina]

Hmm, I don't see explicit problems anymore...

[kobalicek]

Let me know if you face any problem again.