[x86 / Refactor] Corrected some incorrect uses of RemoveCurrentP in OptPass1_V_MOVAP

Summary

This merge request corrects some incorrect uses of the RemoveCurrentP routine in the OptPass1_V_MOVAP peephole optimization.

• In the first case, p gets set to an instruction that might not immediately follow it, thus skipping out on optimisations and potentially causing bad register tracking.
• In the second case, p gets set to hp1 when it might not be the immediate next instruction, similar to the first case, and once again may cause incorrect register tracking.
• In the third case, which is the most severe, the two-parameter version of RemoveCurrentP gets called with the second actual parameter set to nil. This causes p to get set to nil and, as a result, immediately terminates the current pass (p = nil is synonymous with reaching the end of the procedure), meaning all the following instructions in the current procedure are not analysed for potential optimisations.

System

• Processor architecture: i386, x86_64

What is the current bug behavior?

When OptPass1_V_MOVAP makes an improvement, subsequent optimisations in the current iteration of Pass 1 may not be performed correctly, if at all.

What is the behavior after applying this patch?

Behaviour is made safer and more consistent after OptPass1_V_MOVAP makes an improvement.

Relevant logs and/or screenshots

Under x86_64-win64, under -O3 and above, no changes in generated code should logically occur (assuming the register tracking doesn't become bad) since iteratiosn of Pass 1 are always run until no more optimisations are made. However, no changes were observed under -O2 and below either, making this a pure refactor. Nevertheless, it is not logically impossible for generated code to be different in contrived examples.