1 files changed, 102 insertions, 0 deletions
diff --git a/results/classifier/118/peripherals/1851095 b/results/classifier/118/peripherals/1851095
new file mode 100644
index 000000000..175216b50
--- /dev/null
+++ b/results/classifier/118/peripherals/1851095
@@ -0,0 +1,102 @@
+peripherals: 0.945
+debug: 0.926
+semantic: 0.924
+graphic: 0.904
+performance: 0.900
+device: 0.892
+architecture: 0.889
+arm: 0.871
+assembly: 0.863
+PID: 0.837
+permissions: 0.832
+register: 0.829
+risc-v: 0.811
+hypervisor: 0.802
+socket: 0.799
+vnc: 0.799
+files: 0.785
+network: 0.764
+boot: 0.751
+user-level: 0.746
+ppc: 0.733
+mistranslation: 0.690
+VMM: 0.657
+kernel: 0.649
+TCG: 0.629
+virtual: 0.579
+x86: 0.525
+KVM: 0.493
+i386: 0.361
+
+[feature request] awareness of instructions that are well emulated
+
+While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64). Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed.
+
+Here is a pull request for the zig language that runs into this problems in qemu https://github.com/ziglang/zig/pull/2945/
+
+I have more code for validation if someone is working on this.
+
+On Sun, 3 Nov 2019 at 04:41, Shawn Landden <email address hidden> wrote:
+> While qemu's scalar emulation tends to be excellent, qemu's SIMD
+> emulation tends to be incorrect (except for arm64 from x86_64)--i have
+> found this both for mipsel and arm32. Until these code paths are
+> audited, which is probably a large job, it would be nice if qemu knew
+> its emulation of this class of instructions was not very good, and thus
+> it would give up on finding these instructions if a "careful" operation
+> is passed.
+
+I'm not sure how this could work. If QEMU reports (via ID regs
+etc) to the guest that it supports instruction class X when it
+does not, that's a bug and we should fix it. If QEMU implements
+an instruction but gets it wrong, that's also a bug and we should
+fix it. In both cases, we'd need to have specific bug reports,
+ideally with reproduce-cases. But we don't really have "known
+areas where the emulation is incorrect" that we could somehow
+differentiate and disable (except at a very vague level, eg
+"probably better not to rely on the x86 emulation").
+
+You might be able by careful selection of the cpu type to avoid
+CPUs which implement vector operations. Some architectures
+also allow individual CPU features to be disabled with extra
+'-foo' qualifiers on the -cpu argument.
+
+For Arm in particular (32 or 64 bit) I believe our implementation
+should be correct and am happy to look at bug reports for that.
+
+thanks
+-- PMM
+
+
+ok, here is a double precision exponent implementation that works on arm32 hardware, but fails in qemu with the wrong checksum. https://github.com/shawnl/zig-libmvec/blob/master/exp.zig
+
+You need to build zig with the above patch-set.
+
+I guess I am starting from a pessimistic perspective, where I have only ever seen SIMD work with arm64 emulation (which is quite new), and am sorry for that.
+
+Can you please provide a binary (preferably statically built or with required shared libraries attached)?
+
+Thanks,
+
+Laurent
+
+example binary doing double-precision exponent on 16 megs
+
+expected output:
+
+checksum: f181b401cd42aa7b
+
+actual output:
+
+checksum: 4004022b0ba624fb
+
+
+Here is the same thing compiled with optimizations on
+
+appears the random number generator produces different results on 32-bit arches, while my code seems to work fine in qemu
+
+I can confirm bench_simple gives the same result on both qemu-arm and my aarch32 hardware.
+
+Can you provide a clearer repro example of what doesn't wirk on mipsel platform?
+
+In last two QEMU releases mips (Wave) developers went to great lenghts making sure both mips SIMD and mips FP instructions (in both scalar and vector variants) are emulated properly. Some of the unit tests were published, but also many were left internal, and there are many integration tests devised and run as well. We in mips (Wave) consider these two areas well tested. Still, we'll consider seriuosly fixing your example, if you prove experimentally that this is a mips-related bug, but just provides us with a reasonably convenient repro procedure.
+