Inconsistencies between lifting IRs and physical CPU about remill

[pgoodman]

This is probably the cause:

remill/lib/Arch/X86/Semantics/BINARY.cpp

Lines 246 to 256 in 269e61a

	template <typename T, typename U, typename V>
	ALWAYS_INLINE static void WriteFlagsMul(State &state, T lhs, T rhs, U res,
	V res_trunc) {
	const auto new_of = Overflow<tag_mul>::Flag(lhs, rhs, res);
	FLAG_CF = new_of;
	FLAG_PF = BUndefined(); // Technically undefined.
	FLAG_AF = BUndefined();
	FLAG_ZF = BUndefined();
	FLAG_SF = BUndefined();
	FLAG_OF = new_of;
	}

[artemdinaburg]

Adding some context to Peter's comments: According to the Intel Processor Manual (https://cdrdv2.intel.com/v1/dl/getContent/671110), for IMUL:
The SF, ZF, AF, and PF flags are undefined. (Page 3-503)

Where this becomes confusing is that operations that happen on real, physical CPUs for undefined flags sometimes feel very much defined in practice. The problem is that since these flags are officially undefined and documented as being undefined, the observed behavior is inconsistent across generations of CPU and CPUs from different manufacturers (e.g., AMD).

[pgoodman]

We should really have a one-argument form of __remill_undefined_8 that takes in a concrete value.

[pgoodman]

It looks like with the P4 core, IMUL started preserving some of the flags: https://www.sandpile.org/x86/flags.htm