Allow specifying flag writes for float comparisons

[ek0]

Hey!

I've been doing some work on the x86 Architecture module, notably on the flag lifting. I need to be able to specify some flag writes for FP comparison instructions in order to modify this PR as suggested by @rssor.

Instead of directly lifting the flags for UCOMISD and al. as done originally in the PR, @rssor suggested to use the GetFlagWriteLowLevelIL and use IL_FLAGWRITE_ALL in an instruction without side effect. A good candidate would be to try with LLIL_FCMP_UO.

And in order to do so, I need to be able to specify the flags writes for these IL instructions :)

[rssor]

In this case I think it would be better to stick with using LLIL_FSUB, since flag roles will already do what you expect when using that op instead of assigning flag writes to FCMP operations.

[ek0]

The issue with LLIL_FSUB is that it is already used by FCOMI/FUCOMI/... (here). They have slightly different semantics, and I don't think I would be able to differentiate them in the callback. Also, I noticed FCOMI lifting seems to be incomplete.

[rssor]

The callback receives both the llil operation and the flag write type, so you can differentiate by a unique flag write for the new ops.

[fuzyll]

This is currently blocked on us adding a bunch of things to the core.

[ccarpenter04]

@fuzyll Is it still blocked by the core? If so has there been any progress on it in the last year? What type of blockers are there?

[rssor]

So I think I addressed this by refactoring the x86 code in https://github.com/Vector35/arch-x86/commit/5b134ac7da45c009094faf654f613a9ecd11cae8 to use our semantic flag system for a variety of floating point ops instead, instead of making use of the explicit writes to flags.

Generally speaking we convey the meaning of the flag write at the write location, and then in the observing condition it'll resolve most appropriately based on the instruction responsible for generating flags.

I think some of the confusion is because there are other blocked-by-core situations we need to be able to handle eventually, like saturating flags or flags that indirectly depend on other flags. But this particular issue is best addressed by using the existing semantic flags system.

The main limitation of the current system is that we look, once, at all flags that get observed, then at the places that should have generated those flags, and then generate the flag IL once. If, in the process of doing that, we realize we need to generate even more IL for flag operations we have bumped into the limits of the current system.