On Feb 05 15:03, Alex Bennée wrote: > Aaron Lindsay <aa...@os.amperecomputing.com> writes: > > Assuming you're right that TCG is detecting "a io_readx/io_writex when > > ->can_do_io is not true", could we detect this case when it occurs and > > omit the instruction callbacks for the re-translation of the single > > instruction (allow the initial callback to stand instead of trying to > > turn back time, in a way, to prevent it)? Maybe there would have be some > > bookkeeping in the plugin infrastructure side rather than entirely > > omitting the callbacks when re-translating, in case that translation got > > re-used in a case which didn't hit the same behavior and shouldn't be > > skipped? > > They are happening in two separate phases. The translation phase has no > idea what the runtime condition will be. Once we get to runtime it's too > late - and we trigger a new translation phase.
I believe I understand why we can't catch the initial translation. To make sure I'm communicating well, my current understanding is that the timeline for this case goes something like: 1) translate large block of instructions, including ldr 2) attempt to execute ldr, calling instruction callback 3) notice that access is to IO, trigger re-translation of single ldr instruction 4) execute block with single ldr instruction to completion, calling both instruction and memory callbacks I was wondering if it would be possible to inform the re-translation in step 3 that it's for a re-translated IO access so that it could ultimately cause the second of the duplicate instruction callbacks to be omitted during execution in 4. -Aaron
