Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 25/06/2019 07:56, Richard Henderson wrote:

>>> One more hint: if I try a build of d8dcbb57e9 along with my tcg_can_emit_vec_op()
>>> hack and pass --enable-debug-tcg to configure then I get an assert on startup:
>>>
>>> qemu-system-ppc: /home/mca/src/qemu/tcg/tcg.c:2207: process_op_defs: Assertion `tdefs
>>> != ((void *)0)' failed.
>>> Aborted
>>>
>>
>> Mark, Richard, Howard, David,
>>
>> I just sent v5 of the series, that is (in the sense of net-result of
>> code changes) equivalent to v4, but the patch 1/7 from v4 is now split
>> into ten smaller patches. This was done mainly to enable Mark to
>> perhaps try v5 and bisect, in order to at least somewhat narrow down
>> the culprit. Most likely it will be patch 5 from v5, that is still
>> sizeable, but even if this is the case, we can eliminate other smaller
>> things from consideration.
> 
> Thanks for the help on that.
> 
> I don't believe your split is actually bisectable -- there's a minimum amount
> that is required to enable vector opcodes at all.  Patch 5 is the first that
> enables tcg_out_{mov,ld,st}, so while patches beforehand may compile, they
> certainly will not run.
> 
> I can retain your split, but for real bisectability we need to move the enable
> of TCG_TARGET_HAS_v128 from patch 2 to patch 5.
> 
> Given that all this works for me on a Power9 host, I expect that there's a
> simple fix for Mark's G5 host.  Given the above assertion, a missing opcode
> definition, perhaps for -m32 vs -m64?

Right, I'm starting to dig into this a bit more now. First of all, I've figured out
what is triggering the above assertion:

"qemu-system-ppc: /home/mca/src/qemu/tcg/tcg.c:2207: process_op_defs: Assertion
`tdefs != ((void *)0)' failed."

The problem is that in tcg/tcg-op.h we define "DEF(dup2_vec, 1, 2, 0, IMPLVEC |
IMPL(TCG_TARGET_REG_BITS == 32))" and in the last patchset dup2_vec isn't introduced
until towards the end. Unfortunately it's not a simple as bringing the patch forward
within the series to maintain bisectability because the current implementation
depends on VMRG which only appears in the patch just before it...

Next to try and figure out what exactly is causing the fault. Just a quick question
out of curiosity: is your Power9 system BE or LE?


ATB,

Mark.