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

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

On 10/4/18 3:14 PM, Max Filippov wrote:
> I thought about it some more and it looks like this is not going to work
> in general case in the presence of TB linking: a block with a big (and thus
> not precise) LEND distance may be linked to a block with a small (and
> thus precise) LEND distance. Then LEND may change so that next time
> it still goes to the first TB. In that case it shouldn't go from the first TB
> to the second, but with this scheme it will.

Indeed.  Perhaps think of ways in which LBEG and LEND can be represented
relative to each other and PC and store than in the 32-bits you have available
in the CS_BASE field.

Think first about how, if PC >= LEND or LEND - PC > PAGE_SIZE, that all of the
loop stuff is irrelevant because we won't hit LEND within this TB.

Think second about how to represent the common case -- how LOOP sets LBEG and
LEND together.  That is, LEND - LBEG <= 256.  So, usually, we can also have an
exact representation of LBEG and have a direct link rather than an indirect
link.  But I presume that one can play games with special registers to create
ranges that LOOP won't.  So we need some setting that will indicate that.

Consider CS_BASE fields:

  [12: 0]  EDIF = LEND - PC, if PC < LEND && LEND - PC < 2*PAGE_SIZE, or 0.
  [20:13]  BDIF = LEND - LBEG, if LEND - LBEG < 256, or 0.

So you can tell if advancing PC within a TB will exactly match LEND.  You can
tell what LBEG should be, except if BDIF == 0.  In that, presumably rare case,
you load LBEG at runtime as you did in this patch.

Note that if CS_BASE == 0, and thus EDIF == 0, looping is disabled for the TB.

I'll note that this also makes XTENSA_TBFLAG_EXCM redundant.  Simply skip
setting CS_BASE to a non-zero value instead.


r~