Re: [Qemu-devel] [PATCH v2] target/xtensa: rework zero overhead loops implementation

[Max Filippov]

On Fri, Jan 11, 2019 at 2:09 PM Richard Henderson
<address@hidden> wrote:
>
> On 1/12/19 9:01 AM, Max Filippov wrote:
> > Don't invalidate TB with the end of zero overhead loop when LBEG or LEND
> > change. Instead encode the distance from the start of the page where the
> > TB starts to the LEND in the TB cs_base and generate loopback code when
> > the next PC matches encoded LEND. Distance to a destination within the
> > same page and up to a maximum instruction length into the next page is
> > encoded literally, otherwise it's zero. The distance from LEND to LBEG
> > is also encoded in the cs_base: it's encoded literally when less than
> > 256 or as 0 otherwise. This allows for TB chaining for the loopback
> > branch at the end of a loop for the most common loop sizes.
> >
> > With this change the resulting emulation speed is about 10% higher in
> > softmmu mode on uClibc-ng and LTP tests. Emulation speed in linux
> > user mode is a few percent lower because there's no direct TB chaining
> > between different memory pages. Testing with lower limit on direct TB
> > chainig range shows gradual slowdown to ~15% for the block size of 64
> > bytes and ~50% for the block size of 32 bytes.
> >
> > Signed-off-by: Max Filippov <address@hidden>
>
> Reviewed-by: Richard Henderson <address@hidden>
>
>
> > +        /*
> > +         * 0 in the csbase_lend field means that there may not be a 
> > loopback
> > +         * for any instruction that starts inside this page. Any other 
> > value
> > +         * means that an instruction that ends at this offset from the page
> > +         * start may loop back.
>
> Nit: s/may/will/g
>
> Using "may" makes it seem like we may have missed a case that should have
> looped back.

Using "will" makes it seem like it always loops back, but it doesn't do it
when LCOUNT is 0.

-- 
Thanks.
-- Max