Modeling CPU-specific behavior

[mrexodia]

Certain behaviors are CPU model-specific. One example is floating point rounding/approximation functions: https://www.felixcloutier.com/x86/rsqrtss

The semantics are vagueposted:

DEST[31:0] := APPROXIMATE(1/SQRT(SRC2[31:0]))
DEST[MAXVL-1:32] (Unmodified)

Currently it's implemented like this:

template <typename D, typename S1, typename S2>
DEF_SEM(RSQRTSS, D dst, S1 src1, S2 src2) {

  // Extract a "single-precision" (32-bit) float from [31:0] of src2 vector:
  auto src_float = FExtractV32(FReadV32(src2), 0);

  // Initialize dest vector, while also copying src1[127:32] -> dst[127:32].
  auto temp_vec = FReadV32(src1);

  // Store the square root result in dest[31:0]:
  auto square_root = SquareRoot32(memory, state, src_float);
  temp_vec = FInsertV32(temp_vec, 0, FDiv(1.0f, square_root));

  // Write out the result and return memory state:
  FWriteV32(dst, temp_vec);  // SSE: Writes to XMM, AVX: Zero-extends XMM.
  return memory;
}

But this isn't strictly correct and doesn't match on the bit-level. Ghidra implements this as a pcodeop:

define pcodeop rsqrtss;
:RSQRTSS         XmmReg, m32      is vexMode=0 &  $(PRE_F3) & byte=0x0F; byte=0x52; XmmReg ... & m32 { XmmReg = rsqrtss(XmmReg, m32); }
:RSQRTSS         XmmReg1, XmmReg2 is vexMode=0 &  $(PRE_F3) & byte=0x0F; byte=0x52; xmmmod = 3 & XmmReg1 & XmmReg2 { XmmReg1 = rsqrtss(XmmReg1, XmmReg2); }

Should we do the same and use an intrinsic for things like this? There is a similar issue with undefined flags, which you might want to implement in different ways depending on the CPU the software runs on which would require a 'similar' intrinsic. Just opening this for discussion.

[kyle-elliott-tob]

I'm personally leaning towards an intrinsic for these cases and other approximation classes (RCPSS, RSQRTSS, RSQRTPS, VRCP14SS, etc) with a nice fallback that performs the exact calculation. There's a wider discussion to be had about how modular we can make our representation (especially if we invoke CPU-specific undefined flag behavior), but this might be an okay middle ground for the meantime.

Hopefully this will provide a decent balance between shoving all these intrinsics that a consumer needs to implement by having a default implementation, while providing a nice fallback for those that don't really care to model CPU-specific behavior.

For undefined flags, I think the best solution was still what was discussed in #705 and #260, essentially the undefined intrinsic with a concrete hint that someone can override if they so choose to. Additionally #541 is worth taking a look at, as we're not even internally consistent with the current repository state.