On 6/28/23 15:00, BALATON Zoltan wrote:
On Wed, 28 Jun 2023, Mark Cave-Ayland wrote:
From: Richard Henderson <richard.hender...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
Message-Id: <20230628071202.230991-2-richard.hender...@linaro.org>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
---
target/sparc/translate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index bad2ec90a0..28d4cdb8b4 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -318,10 +318,10 @@ static void gen_goto_tb(DisasContext *s, int tb_num,
tcg_gen_movi_tl(cpu_npc, npc);
tcg_gen_exit_tb(s->base.tb, tb_num);
} else {
- /* jump to another page: currently not optimized */
+ /* jump to another page: we can use an indirect jump */
tcg_gen_movi_tl(cpu_pc, pc);
tcg_gen_movi_tl(cpu_npc, npc);
- tcg_gen_exit_tb(NULL, 0);
+ tcg_gen_lookup_and_goto_ptr();
Out of curiosity, did you test this is actually faster? The reason I ask is because I've
tried to optimise similar case in target/ppc by using lookup_and_goto_ptr but found it was
slower than without that. I think this may depend on the usage but I wonder if that could
be a generic issue with lookup_and_goto_ptr or only specific for the case I've tried.
It is faster.
It should be *always* faster, because returning to the main cpu loop will always do more
work than merely checking to see if we already have built the required TB.
If you see slowdowns, then *probably* you are using lookup_and_goto_ptr incorrectly in
some instance, such that an interrupt has gotten overly delayed. (One must always return
to the main loop after anything that might re-enable interrupts. Otherwise the interrupt
handler may be delayed indefinitely. This was in fact the problem with v1 of this patch set.)
r~
