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.
Details
- Reviewers
craig.topper delena RKSimon
Diff Detail
Event Timeline
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
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
1215–1218 | Why the Ptr should have only 2 operands? Can TLI increment memory address using GEP? Can it be done using ADD? | |
1219 | The offset should always be the size of the Lo, right? Why 0? Why 32? |
That makes sense, thanks for the comments. In the new version there is a change in compress_expand.ll, which in my view is ok
@aivchenk Didn't you land this with rL325135? If you include 'Differential Revision: https://reviews.llvm.org/D43087' in your commit message it will close the phab for you.
Why the Ptr should have only 2 operands? Can TLI increment memory address using GEP? Can it be done using ADD?
I don't think that you can assume anything about the TLI operation.