When creating high MachineMemOperand for MSTORE/MLOAD we supply
it with the original PointerInfo, while the pointer itself had been incremented.
The patch adds the proper offset to the PointerInfo.
The problem originated from a miscompare in a benchmark. That appeared to be a machine-scheduler that moved writes after reads of a pointer. It turned out that the scheduler was within its rights to do so, as it checked the offset of the following pointer:
VMASKMOVPSYmr %stack.1.stack_output_vec, 1, $noreg, 32, $noreg, [[AVX_SET0_]], killed [[VMASKMOVPSYrm1]] :: (store 32 into %ir.stack_output_vec, align 4)
.. and it returned '0', instead of '32' I don't have a testcase-ready assembly at this point, but since the problem is local, I believe having MIR test to check that would be a better choice
Why the Ptr should have only 2 operands? Can TLI increment memory address using GEP? Can it be done using ADD?
The offset should always be the size of the Lo, right? Why 0? Why 32?