Re: [PULL 02/10] target/sparc: Use tcg_gen_lookup_and_goto_ptr in gen_goto_tb

[Richard Henderson]

On 6/28/23 15:00, BALATON Zoltan wrote:
> On Wed, 28 Jun 2023, Mark Cave-Ayland wrote:
> > From: Richard Henderson <richard.henderson@linaro.org>
> >
> > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> > Message-Id: <20230628071202.230991-2-richard.henderson@linaro.org>
> > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@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~