On 01/10/2011 10:37 AM, Aurelien Jarno wrote: >> mov y,x >> deposit y,y,x,8,8 >> >> So I could simply put a tcg_abort there. It would be up to whoever >> improves the register allocator to provide some mechanism for a >> backend to allocate a scratch. What do you think? >> > > Do you have a way to trigger this problem? or a dump of the ops and asm > output?
IN: 0x408120c4: rlwimi r4,r4,8,16,23 OP: ---- 0x408120c4 deposit_i32 r4,r4,r4,8,8 goto_tb $0x0 movi_i32 nip,$0x408120c8 exit_tb $0x7fbb00ca5758 OUT: [size=52] 0x60294380: mov 0x10(%r14),%ebp 0x60294384: mov %ebp,%ebx 0x60294386: ror $0x8,%ebp 0x60294389: shrd $0x8,%ebx,%ebp 0x6029438d: rol $0x10,%ebp 0x60294390: mov %ebp,0x10(%r14) 0x60294394: jmpq 0x60294399 0x60294399: mov $0x408120c8,%ebp 0x6029439e: mov %ebp,0x25c(%r14) 0x602943a5: mov $0x7fbb00ca5758,%rax 0x602943af: jmpq 0x622b772e That should do it. This is present in linux-user-test ppc/ls. This output still contains that allocate-a-scratch path. r~