Aaron Lindsay <aa...@os.amperecomputing.com> writes:
> 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. This is what I've done - re-executed blocks are compiled with CF_NOINSTR which skips any instrumentation. If you could test the series I posted and confirm the problem is solved that would be great: Subject: [PATCH v2 00/21] plugins/next pre-PR (hwprofile, regression fixes, icount count fix) Date: Wed, 10 Feb 2021 22:10:32 +0000 Message-Id: <20210210221053.18050-1-alex.ben...@linaro.org> -- Alex Bennée
