qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v7 00/22] tcg/ppc: Add vector opcodes


From: Mark Cave-Ayland
Subject: Re: [PATCH v7 00/22] tcg/ppc: Add vector opcodes
Date: Tue, 1 Oct 2019 21:33:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 30/09/2019 21:21, Richard Henderson wrote:

> Changes since v6:
>   * The have_foo tests have been split so that VSX is not
>     combined with ISA revision.
>   * The power{7,8,9} patches have been split by isa extension.
>   * Force the [TABC]X bits on within the VSX instruction defines,
>     making the usage of the VSX insns clearer, since we have no
>     additional or'ing of seemingly random bits.
> 
> Changes since v5:
>   * Disable runtime altivec detection until all of the required
>     opcodes are implemented.
>     Because dup2 was last, that really means all of the pure altivec
>     bits, so the initial patches are not bisectable in any meaningful
>     sense.  I thought about reshuffling dup2 earlier, but that created
>     too many conflicts and I was too lazy.
>   * Rearranged the patches a little bit to make sure that each
>     one actually builds, which was not the case before.
>   * Folded in the fix to tcg_out_mem_long, as discussed in the
>     followup within the v4 thread.
> 
> Changes since v4:
>   * Patch 1, "tcg/ppc: Introduce Altivec registers", is divided into
>     ten smaller patches.
>   * The net result (code-wise) is not changed between former patch 1
>     and ten new patches.
>   * Remaining (2-7) patches from v4 are applied verbatim.
>   * This means that code-wise v5 and v4 do not differ.
>   * v5 is devised to help debugging, and to better organize the code.
> 
> Changes since v3:
>   * Add support for bitsel, with the vsx xxsel insn.
>   * Rely on the new relocation overflow handling, so
>     we don't require 3 insns for a vector load.
> 
> Changes since v2:
>   * Several generic tcg patches to improve dup vs dupi vs dupm.
>     In particular, if a global temp (like guest r10) is not in
>     a host register, we should duplicate from memory instead of
>     loading to an integer register, spilling to stack, loading
>     to a vector register, and then duplicating.
>   * I have more confidence that 32-bit ppc host should work
>     this time around.  No testing on that front yet, but I've
>     unified some code sequences with 64-bit ppc host.
>   * Base altivec now supports V128 only.  Moved V64 support to
>     Power7 (v2.06), which has 64-bit load/store.
>   * Dropped support for 64-bit vector multiply using Power8.
>     The expansion was too large compared to using integer regs.
> 
> Richard Henderson (22):
>   tcg/ppc: Introduce Altivec registers
>   tcg/ppc: Introduce macro VX4()
>   tcg/ppc: Introduce macros VRT(), VRA(), VRB(), VRC()
>   tcg/ppc: Create TCGPowerISA and have_isa
>   tcg/ppc: Replace HAVE_ISA_2_06
>   tcg/ppc: Replace HAVE_ISEL macro with a variable
>   tcg/ppc: Enable tcg backend vector compilation
>   tcg/ppc: Add support for load/store/logic/comparison
>   tcg/ppc: Add support for vector maximum/minimum
>   tcg/ppc: Add support for vector add/subtract
>   tcg/ppc: Add support for vector saturated add/subtract
>   tcg/ppc: Support vector shift by immediate
>   tcg/ppc: Support vector multiply
>   tcg/ppc: Support vector dup2
>   tcg/ppc: Enable Altivec detection
>   tcg/ppc: Update vector support for VSX
>   tcg/ppc: Update vector support for v2.07 Altivec
>   tcg/ppc: Update vector support for v2.07 VSX
>   tcg/ppc: Update vector support for v2.07 FP
>   tcg/ppc: Update vector support for v3.00 Altivec
>   tcg/ppc: Update vector support for v3.00 load/store
>   tcg/ppc: Update vector support for v3.00 dup/dupi
> 
>  tcg/ppc/tcg-target.h     |   51 +-
>  tcg/ppc/tcg-target.opc.h |   13 +
>  tcg/ppc/tcg-target.inc.c | 1118 +++++++++++++++++++++++++++++++++++---
>  3 files changed, 1101 insertions(+), 81 deletions(-)
>  create mode 100644 tcg/ppc/tcg-target.opc.h

I've just tried this version with my OS X/MacOS 9 CDROM boot tests and it looks 
good
here: no crashes or visible artefacts AFAICT:

Tested-by: Mark Cave-Ayland <address@hidden> (PPC32)


ATB,

Mark.



reply via email to

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