Bug 430485

After implementing Iop_MAdd/Sub for arm64 (bug #426014) we got a report that "the impossible happened":

> MSubF64(t15,t21,t22,t23)
> vex: the `impossible' happened:
>    expr_is_guardable: unhandled expr
> vex storage: T total 3295105024 bytes allocated
> vex storage: P total 0 bytes allocated
> 
> valgrind: the 'impossible' happened:
>    LibVEX called failure_exit().

And indeed expr_is_guardable doesn't handle Iex_Qop the tag IRExpr_Qop uses.
It seems something like the following should work (currently untested):

diff --git a/VEX/priv/guest_generic_bb_to_IR.c b/VEX/priv/guest_generic_bb_to_IR.c
index 0cee970e4..1e72ddacd 100644
--- a/VEX/priv/guest_generic_bb_to_IR.c
+++ b/VEX/priv/guest_generic_bb_to_IR.c
@@ -422,6 +422,8 @@ static Bool expr_is_guardable ( const IRExpr* e )
          return !primopMightTrap(e->Iex.Binop.op);
       case Iex_Triop:
          return !primopMightTrap(e->Iex.Triop.details->op);
+      case Iex_Qop:
+         return !primopMightTrap(e->Iex.Qop.details->op);
       case Iex_ITE:
       case Iex_CCall:
       case Iex_Get:

I am just surprised this hasn't come up before since other arches (ppc, s390) also implement scalar FMA operations.

Some more background in https://bugzilla.redhat.com/show_bug.cgi?id=1844910 (the fedora valgrind package has the arm64 fma patch backported).