Implement x87 invalid operation bit on F64 mode

[pmatos]

It attempts to use the IOC ARM64 bit to avoid lengthy checks on operation arguments.
This is the F64 counterpart to 726656d .

[bylaws]

Thank you copilot

[bylaws]

So there are a few things to note here:
The IOC bit is cumulative, so it will need to be zeroed at the entrypoint to a block and after any non-x87 float operation, which could set the bit on the arm side but would not on the x86 side.

As is you flush the IOC bit after every operation, it would make sense to only do this at block exit points, or whenever a non-x87 IOC setting instruction is used in a block. I think if you extend the IR json to track IOC setting operations, as the x87 pass already handles every x87 operation directly, you can just check op->SetsIOC in the non-x87 inst case to know when to flush.

[Sonicadvance1]

8-bit has a constraint issue on the load side but not the store side? That seems odd.

[pmatos]

load8/store8 doesn't work. Lets do load32/store32 which sounds more sensible. Thanks.

[pmatos]

So there are a few things to note here: The IOC bit is cumulative, so it will need to be zeroed at the entrypoint to a block and after any non-x87 float operation, which could set the bit on the arm side but would not on the x86 side.

As is you flush the IOC bit after every operation, it would make sense to only do this at block exit points, or whenever a non-x87 IOC setting instruction is used in a block. I think if you extend the IR json to track IOC setting operations, as the x87 pass already handles every x87 operation directly, you can just check op->SetsIOC in the non-x87 inst case to know when to flush.

Ah, yes, I do understand the issue: both bits are sticky, but the arm bit can be set by many other instructions that are not being emulated from x87 so the possibility of reading a wrong value exists. Need to think of a way to turn that into a unit test though. Need to have a think on how to best handle this case.

[pmatos]

I have rebase this on top of #4743 . Still working on addressing @bylaws earlier suggestion.

[pmatos]

hummm, VIXL doesn't support FPSR, so we might need to skip some tests on the simulator.

[pmatos]

So there are a few things to note here: The IOC bit is cumulative, so it will need to be zeroed at the entrypoint to a block and after any non-x87 float operation, which could set the bit on the arm side but would not on the x86 side.

As is you flush the IOC bit after every operation, it would make sense to only do this at block exit points, or whenever a non-x87 IOC setting instruction is used in a block. I think if you extend the IR json to track IOC setting operations, as the x87 pass already handles every x87 operation directly, you can just check op->SetsIOC in the non-x87 inst case to know when to flush.

Been trying to create a test where emulating a non-x87 invalid op causes, through an indirect setting of the FPSR flag on the arm side, the x87 IE flag to show up as set. I think this is what you were alluding to with "after any non-x87 float operation, which could set the bit on the arm side but would not on the x86 side." but I can't create a test that does this and nothing comes to mind. Any suggestions?

[pmatos]

So there are a few things to note here: The IOC bit is cumulative, so it will need to be zeroed at the entrypoint to a block and after any non-x87 float operation, which could set the bit on the arm side but would not on the x86 side.
As is you flush the IOC bit after every operation, it would make sense to only do this at block exit points, or whenever a non-x87 IOC setting instruction is used in a block. I think if you extend the IR json to track IOC setting operations, as the x87 pass already handles every x87 operation directly, you can just check op->SetsIOC in the non-x87 inst case to know when to flush.

Been trying to create a test where emulating a non-x87 invalid op causes, through an indirect setting of the FPSR flag on the arm side, the x87 IE flag to show up as set. I think this is what you were alluding to with "after any non-x87 float operation, which could set the bit on the arm side but would not on the x86 side." but I can't create a test that does this and nothing comes to mind. Any suggestions?

OK - found a test that shows the issue mentioned earlier where cumulative FPSR contaminates x87 status word IE flag. 62b625f#diff-2380a45bab6932717d4fe2ae0561fc1a1450f30d8430392c7b3ff4b29958fd5e

[pmatos]

Any comments on the current version of the patch? I am slightly worried I missed some instructions that SetsIOC or haven't set it in some other cases, but after reviewing it, I think I got most cases covered.

[Sonicadvance1]

The cost of doing this for every instruction that isn't an x87 instruction(and can set IOC) is too much and needs to be re-thought out to limit the performance impact.

[pmatos]

I have a few upcoming changes to x87 stack pass, so I will need to refactor this. moving it to draft.