On 19 September 2012 18:00, Richard Henderson <r...@twiddle.net> wrote: > On 09/19/2012 05:57 AM, Peter Maydell wrote: >>> > - s->code_ptr += 16; >>> > + tcg_out32 (s, NOP); >>> > + tcg_out32 (s, NOP); >>> > + tcg_out32 (s, NOP); >>> > + tcg_out32 (s, NOP); >> Not too familiar with the PPC backend, but doesn't this mean that >> in the retranslation case we will overwrite a correct jump destination >> with these NOP words and then rewrite it again with the correct >> destination? That can cause problems with cache incoherency; >> compare the fix applied in commit c69806ab8276 for ARM. > > Well, i386 certainly doesn't care about re-translation here:
i386 is weird (as usual) in that it maintains i/d side cache coherency entirely automatically. I don't know about PPC, but explicit cache maintenance is more common for RISC... > And as far as the referenced change, that has to do with "real" > branches, i.e. INDEX_op_brcond et at. Which *do* need to be > protected against retranslation. But INDEX_op_goto_tb is a > different case. Can you elaborate? If we're emitting a native branch insn and we're potentially changing the value in memory several times during retranslate I would have thought it still applied. -- PMM
