The following changes since commit 2ccad61746ca7de5dd3e25146062264387e43bd4:

  Merge tag 'pull-tcg-20221109' of https://gitlab.com/rth7680/qemu into staging (2022-11-09 13:26:45 -0500)

are available in the Git repository at:

  https://github.com/quic/qemu tags/pull-hex-20221110

for you to fetch changes up to f2630d5994fb716a302289d97844d1c9622f3aff:

  Hexagon (target/hexagon) Use direct block chaining for tight loops (2022-11-10 09:49:35 -0800)

----------------------------------------------------------------

1)
Performance improvement
Add pkt and insn to DisasContext
Many functions need information from all 3 structures, so merge
them together.

2)
Bug fix
Fix predicated assignment to .tmp and .cur

3)
Performance improvement
Add overrides for S2_asr_r_r_sat/S2_asl_r_r_sat
These functions will not be handled by idef-parser

4-11)
The final 8 patches improve change-of-flow handling.

Currently, we set the PC to a new address before exiting a TB.  The
ultimate goal is to use direct block chaining.  However, several steps
are needed along the way.

4)
When a packet has more than one change-of-flow (COF) instruction, only
the first one taken is considered.  The runtime bookkeeping is only
needed when there is more than one COF instruction in a packet.

5, 6)
Remove PC and next_PC from the runtime state and always use a
translation-time constant.  Note that next_PC is used by call instructions
to set LR and by conditional COF instructions to set the fall-through
address.

7, 8, 9)
Add helper overrides for COF instructions.  In particular, we must
distinguish those that use a PC-relative address for the destination.
These are candidates for direct block chaining later.

10)
Use direct block chaining for packets that have a single PC-relative
COF instruction.  Instead of generating the code while processing the
instruction, we record the effect in DisasContext and generate the code
during gen_end_tb.

11)
Use direct block chaining for tight loops.  We look for TBs that end
with an endloop0 that will branch back to the TB start address.

----------------------------------------------------------------
Taylor Simpson (11):
      Hexagon (target/hexagon) Add pkt and insn to DisasContext
      Hexagon (target/hexagon) Fix predicated assignment to .tmp and .cur
      Hexagon (target/hexagon) Add overrides for S2_asr_r_r_sat/S2_asl_r_r_sat
      Hexagon (target/hexagon) Only use branch_taken when packet has multi cof
      Hexagon (target/hexagon) Remove PC from the runtime state
      Hexagon (target/hexagon) Remove next_PC from runtime state
      Hexagon (target/hexagon) Add overrides for direct call instructions
      Hexagon (target/hexagon) Add overrides for compound compare and jump
      Hexagon (target/hexagon) Add overrides for various forms of jump
      Hexagon (target/hexagon) Use direct block chaining for direct jump/branch
      Hexagon (target/hexagon) Use direct block chaining for tight loops

 target/hexagon/cpu.h                |  14 +-
 target/hexagon/gen_tcg.h            | 412 +++++++++++++++++++++++++++++++++++-
 target/hexagon/gen_tcg_hvx.h        |   6 +-
 target/hexagon/insn.h               |   9 +-
 target/hexagon/macros.h             |  16 +-
 target/hexagon/mmvec/macros.h       |   4 +-
 target/hexagon/translate.h          |  20 +-
 target/hexagon/decode.c             |  15 +-
 target/hexagon/genptr.c             | 392 +++++++++++++++++++++++++++++++++-
 target/hexagon/op_helper.c          |  28 ++-
 target/hexagon/translate.c          | 229 +++++++++++++-------
 tests/tcg/hexagon/hvx_misc.c        |  72 +++++++
 tests/tcg/hexagon/usr.c             |  34 ++-
 target/hexagon/gen_helper_funcs.py  |  13 +-
 target/hexagon/gen_helper_protos.py |  14 +-
 target/hexagon/gen_tcg_funcs.py     |  38 +++-
 target/hexagon/hex_common.py        |  29 ++-
 17 files changed, 1207 insertions(+), 138 deletions(-)

Hi Taylor,
QEMU is frozen for the 7.2 release cycle. Only bug fixes can be merged
as the tree is being stabilized. You can find the release schedule
here:
https://wiki.qemu.org/Planning/7.2

Please resend with only the bug fixes needed for the 7.2 release. Thanks!

Stefan

OK.  I wasn't sure if performance improvements would be considered new features or not.

Taylor


> -----Original Message-----
> From: Stefan Hajnoczi <stefanha@gmail.com>
> Sent: Thursday, November 10, 2022 7:07 PM
> To: Taylor Simpson <tsimpson@quicinc.com>
> Cc: qemu-devel@nongnu.org; richard.henderson@linaro.org;
> philmd@linaro.org; peter.maydell@linaro.org; Brian Cain
> <bcain@quicinc.com>; Matheus Bernardino (QUIC)
> <quic_mathbern@quicinc.com>; stefanha@redhat.com
> Subject: Re: [PULL 00/11] Hexagon bug fixes and performance improvement
> 
> Hi Taylor,
> QEMU is frozen for the 7.2 release cycle. Only bug fixes can be merged as the
> tree is being stabilized. You can find the release schedule
> here:
> https://wiki.qemu.org/Planning/7.2
> 
> Please resend with only the bug fixes needed for the 7.2 release. Thanks!
> 
> Stefan

On Tue, 15 Nov 2022 at 11:16, Taylor Simpson <tsimpson@quicinc.com> wrote:
>
> OK.  I wasn't sure if performance improvements would be considered new features or not.

No problem! If there is a performance regression in the upcoming
release, then fixes will be accepted. For example, if QEMU 7.1 was
fast but the upcoming QEMU 7.2 release is going to be slow then a
performance fix will be accepted to avoid a regression in 7.2.

On the other hand, if it's a fix for something that was already slow
in the last release (7.1), then it's less likely to be accepted during
freeze.

These are general guidelines and maintainers have a say in what gets
merged. In this case I looked at the pull request and I wasn't sure if
you had decided based on these guidelines or not. It helps when it's
clear from the commit message (or from the commit description in more
involved cases) that the commit fixes a bug or has some other
justification.

Thanks,
Stefan

> -----Original Message-----
> From: Stefan Hajnoczi <stefanha@gmail.com>
> Sent: Tuesday, November 15, 2022 10:52 AM
> To: Taylor Simpson <tsimpson@quicinc.com>
> Cc: qemu-devel@nongnu.org; richard.henderson@linaro.org;
> philmd@linaro.org; peter.maydell@linaro.org; Brian Cain
> <bcain@quicinc.com>; Matheus Bernardino (QUIC)
> <quic_mathbern@quicinc.com>; stefanha@redhat.com
> Subject: Re: [PULL 00/11] Hexagon bug fixes and performance improvement
> 
> On Tue, 15 Nov 2022 at 11:16, Taylor Simpson <tsimpson@quicinc.com>
> wrote:
> >
> > OK.  I wasn't sure if performance improvements would be considered new
> features or not.
> 
> No problem! If there is a performance regression in the upcoming release,
> then fixes will be accepted. For example, if QEMU 7.1 was fast but the
> upcoming QEMU 7.2 release is going to be slow then a performance fix will
> be accepted to avoid a regression in 7.2.
> 
> On the other hand, if it's a fix for something that was already slow in the last
> release (7.1), then it's less likely to be accepted during freeze.

The performance improvements fall into this bucket.

> 
> These are general guidelines and maintainers have a say in what gets
> merged. In this case I looked at the pull request and I wasn't sure if you had
> decided based on these guidelines or not. It helps when it's clear from the
> commit message (or from the commit description in more involved cases)
> that the commit fixes a bug or has some other justification.

I'm the maintainer for the directories touched by these patches (target/hexagon and tests/tcg/hexagon), but I'll defer you as a more senior maintainer to decide not to merge if it is too risky at this stage.

Taylor
 

On Tue, Nov 15, 2022, 12:44 Taylor Simpson <tsimpson@quicinc.com> wrote:

>
>
> > -----Original Message-----
> > From: Stefan Hajnoczi <stefanha@gmail.com>
> > Sent: Tuesday, November 15, 2022 10:52 AM
> > To: Taylor Simpson <tsimpson@quicinc.com>
> > Cc: qemu-devel@nongnu.org; richard.henderson@linaro.org;
> > philmd@linaro.org; peter.maydell@linaro.org; Brian Cain
> > <bcain@quicinc.com>; Matheus Bernardino (QUIC)
> > <quic_mathbern@quicinc.com>; stefanha@redhat.com
> > Subject: Re: [PULL 00/11] Hexagon bug fixes and performance improvement
> >
> > On Tue, 15 Nov 2022 at 11:16, Taylor Simpson <tsimpson@quicinc.com>
> > wrote:
> > >
> > > OK.  I wasn't sure if performance improvements would be considered new
> > features or not.
> >
> > No problem! If there is a performance regression in the upcoming release,
> > then fixes will be accepted. For example, if QEMU 7.1 was fast but the
> > upcoming QEMU 7.2 release is going to be slow then a performance fix will
> > be accepted to avoid a regression in 7.2.
> >
> > On the other hand, if it's a fix for something that was already slow in
> the last
> > release (7.1), then it's less likely to be accepted during freeze.
>
> The performance improvements fall into this bucket.
>
> >
> > These are general guidelines and maintainers have a say in what gets
> > merged. In this case I looked at the pull request and I wasn't sure if
> you had
> > decided based on these guidelines or not. It helps when it's clear from
> the
> > commit message (or from the commit description in more involved cases)
> > that the commit fixes a bug or has some other justification.
>
> I'm the maintainer for the directories touched by these patches
> (target/hexagon and tests/tcg/hexagon), but I'll defer you as a more senior
> maintainer to decide not to merge if it is too risky at this stage.
>

Thanks!

Stefan


> Taylor
>
>
>