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

[Richard Henderson <richard.henderson@linaro.org>]

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~