lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mips delay slot optimization


From: Paul Cercueil
Subject: Re: Mips delay slot optimization
Date: Fri, 24 Feb 2023 13:00:36 +0000

Le vendredi 24 février 2023 à 08:17 -0300, Paulo César Pereira de
Andrade a écrit :
> Em sex., 24 de fev. de 2023 às 08:08, Paul Cercueil
> <paul@crapouillou.net> escreveu:
> > 
> > Hi Paulo,
> 
>   Hi Paul,
> 
> > Le jeudi 23 février 2023 à 13:34 -0300, Paulo César Pereira de
> > Andrade
> > a écrit :
> > >  Hi Paul,
> > > 
> > >   I wrote a new logic to optimize delay slot usage for the mips
> > > port.
> > > 
> > >  It was broken for mips6_p() anyway, so now there is  basically a
> > > full decoder to check if an instruction can be added to the delay
> > > slot,
> > > and a few new helpers to it.
> > > 
> > >   A basic documentation of how it works is in the commit
> > > changelog.
> > > 
> > >   I want to believe it is far more complete than your previous
> > > set of
> > > patches, and it also forces adding extra logic to the decoder if
> > > implementing new lightning functionality.
> > > 
> > >   To disable it in a hacky mode, just change instr() to never
> > > keep
> > > a pending() instruction.
> > > 
> > >   Please let me know if you see any regressions, or if somehow it
> > > is missing some delay slot usage optimization that was done in
> > > your patches.
> 
>   It was a really very large change, and it would be easy to get
> regressions.
> 
>   The new patch is far more aggressive, and relies in both, correct
> usage
> of jit_get_reg_for_delay_slot(), flush(), pending() and delay(), as
> well as
> jit_get_reg_for_delay_slot() correctly decoding the instruction and
> internally calling flush() if even if getting a valid register, still
> moving the
> 'pending()' instruction to the delay slot would cause a problem.
> 
> > There are definitely regressions, my emulator just hangs when
> > running
> > 8032a68, while 2.2.1 worked fine.
> 
>   Please try first with 8e5ba87. I did a new review of the patches,
> and
> found a major logic error in jmpi. It was passing "make check" in
> different
> test environments, but was by accident, surely soon or later the bug
> would arise.

It seems like 8e5ba87 fixed it, thanks.

Do you think this mechanism could be more backend-agnostic?

I'm thinking in particular about my SH4 port, where some branch opcodes
also have delay slots.

Cheers,
-Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]