[Valgrind-developers] ARM64 and MSUB

[LATHUILIERE B. <bru...@ed...>]

Hello everyone,
I recently discovered a bug in verrou regarding fma on arm64 architecture. More specifically it comes from Iop_MSubF64 and Iop_MSubF32. In the file VEX/pub/libvex_ir.h the definition of MAddF32 and MSubF32 is arg2 * arg3 - arg4, but in the file VEX/priv/guest_arm64_toIR.c a different definition is used - arg2*arg3+ arg4.
Valgrind does not see the problem because the same definition is used in host part.
I have fixed this problem with the patch:  https://raw.githubusercontent.com/edf-hpc/verrou/refs/heads/master/valgrind.fma_arm64.diff

Some notes about the patch :
     - Not ready for valgrind integration yet, but I share it now since it is needed to write floating-point tools.
     - In guest_arm64_toIR.c I only use Iop_Madd32/64 and Iop_NegF32/64 to avoid the MSub problem.
     - I also solve another problem with vectorized FMA (I only make one patch as the two bugs affect the same lines). In the current implementation, vectorized fma generates an ADD and a MUL Iop, which leads to rounding problems. As for amd64 arch I unroll the vectorization to use scalar MAdd Iop. Since the results are modified, I updated the unit test to be consistent with native execution.

The patch fixes the problem, but is not clean enough for integration :
- Do we need to keep MSub Iops?
- Do we want to introduce NegMSub and NegMAdd Iop like for F128?
- Do we want to introduce the vectorized version of FMA to avoid unrolling and performance loss?
What's your opinion about FMA Iops?


Since it was painful to discover the bug so late, I wanted to improve my test coverage. To do this, I want to run all the test-cases from other tools (the ones that do not modify the standard output, especially none) with the verrou tool and default options (to avoid modifying the results).  To do this, I have patched the tests/vg_regtest.in file to add new options :
  --force-tool= to specify a tool (not the one detected from the test cas path).
  --stderr-ignore to ignore stderr comparison (verrou and none stderr output are not the same)
  --toolopt-ignore to ignore the tool option defined in the test case (callgrind uses options that are not recognized by verrou)
  --post-ignore , --clean-ignore to ignore the post and clean step (verrou and callgrind l do not generate the same files )

The simplest use case is :
perl ./tests/vg_regtest none/tests --force-tool=verrou --stderr-ignore

For none tool, this approach is really convenient, but for tools that define multiple test-cases with the same binary and the same input it means multiple runs of equivalent test-cases.

The patch is available there:
https://raw.githubusercontent.com/edf-hpc/verrou/refs/heads/master/valgrind.vgregtest.diff
I can maintain the patch in verrou repo, but if it is useful to anyone, we can consider integration.

Do you think it can be useful for other tools?

++
Bruno



Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.