https://bugs.kde.org/show_bug.cgi?id=360035
--- Comment #5 from Julian Seward <jsew...@acm.org> ---
I looked at the V-bit code generation stuff in expr2vbits_Triop for
these cases. It is:
/* BCDIops */
case Iop_BCDAdd:
case Iop_BCDSub:
complainIfUndefined(mce, atom3, NULL);
return assignNew('V', mce, Ity_V128, triop(op, vatom1, vatom2, atom3));
I think that might be the problem. What this does is to apply the BCD
add/sub operation to the definedness (V) bits of the first two operands:
triop(op, vatom1, vatom2, atom3)
Applying the original operation to the definedness bits is appropriate
in cases where the original operation rearranges/copies bits in the
arguments, so we want to rearrange/copy the V bits in the same way,
for example in the cases just above -- Slice64 and SetElem*. But
that's not the case here: BCD{add,sub} actually do computations with
their operands, at least the first two.
I'm not clear what the "lane" behaviour of these instructions is. Are
the two operands treated as single 128-bit entities? If so, I think
the following is possibly appropriate:
/* BCDIops */
case Iop_BCDAdd:
case Iop_BCDSub:
return mkLazy3(mce, Ity_V128, vatom1, vatom2, vatom3);
What this will do is to mark the entire 128 bit result as undefined if
any of the bits in the three operands (V128, V128, I8) is undefined.
As far as I can see, the third operand is an 8 bit control field
copied out of the original instruction, and will always be defined, so
passing its V bits to mkLazy3 is pointless, but it doesn't matter, and
in any case the post-instrumentation optimisation pass should fold out
any unnecessary code.
--
You are receiving this mail because:
You are watching all bug changes.
