https://bugs.kde.org/show_bug.cgi?id=432387
--- Comment #4 from Andreas Arnez <ar...@linux.ibm.com> ---
(In reply to Julian Seward from comment #3)
> Nice work!  The following look OK to land as-is:
> [...]
Great, thanks for reviewing!

> [...]
> Is `misc3` safe to always-build?  Or would it require gating on assembler
> features, in the style of "if BUILD_DFP_TESTS .." just below?
> 
> .. ah .. later .. I see misc3.c doesn't require any assembler support,
> since it just does `insn rrf,0x" #opcode "0000,%[out],%[a],%[b],0\n\t"`.
Right, I did consider using z15 mnemonics guarded by a configure switch,
but it just unnecessarily complicated things.  So I ended up with this
backwards-compatible approach.

> [...]
> +prog: misc3
> 
> Similarly, does this require gating on host hwcaps?  Looking at your
> _toIR.c implementation, maybe not, since that appears to be
> down-translating (I mean, translating from the z15 dialect into IR which
> will be re-emitted as instructions for some earlier zSeries CPU).  I
> suppose this means that on older platforms, it will be possible to
> compile this test, and run it on V, but not to run it natively.
That's correct.  I tested it on z14, and the test succeeded there, even
though the executable crashes without Valgrind.

> [...]
> +   s390_insn_assert("vcdlg", m3 == 2 || m3 == 3);
> (multiple times)
> This will fail only on internal logic errors, correct? .. it can't fail only
> because the insn can't be decoded, right?
Actually, the latter.  The s390_insn_assert macro passes a special kind of
decoding failure (a "specification exception") up through the call chain
if the asserted condition is not met.

> [...]
> Seeing use of Iop_Perm8x16 made me wonder if it had a definition that
> is independent of the guest/host endianness .. and, no it doesn't:
> libvex_ir.h says:
> 
>             for i in 0 .. 15 . result[i] = argL[ argR[i] ] 
> 
> so the meaning of "[n]" is itself ambiguous.  Anyways, no need to
> change anything in your code.
OK.  I interpreted vec[n] to represent the vector's nth lane (starting
with zero) when split up in 8-bit integer elements.  And (at least on
z/Architecture) this happens to be the same as the nth byte of the vector
when stored in memory.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to