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.