We added speculation barrier semantics to LFENCE, but haven't taught instruction scheduling (or other reordering passes) about that semantic.
The compiler may reorder LFENCEs in a basic block in a way that may not be correct, whether reordering branch instructions and LFENCEs or loads/stores and LFENCEs.
Possible directions to go in for a test case:
A MIR basic block with LFENCEs interleaved with multiple jCC instructions -- it is not valid to sink or hoist the LFENCEs.
Another posible testing strategy would be to interleave stores with an LFENCE.
For example, store -> LFENCE -> load: historically changing this to LFENCE -> store -> load is okay, but from the perspective of speculative execution there is a difference between the two orderings.
Extended Description
Problem
We added speculation barrier semantics to LFENCE, but haven't taught instruction scheduling (or other reordering passes) about that semantic.
The compiler may reorder LFENCEs in a basic block in a way that may not be correct, whether reordering branch instructions and LFENCEs or loads/stores and LFENCEs.
Possible directions to go in for a test case: A MIR basic block with LFENCEs interleaved with multiple
jCC
instructions -- it is not valid to sink or hoist the LFENCEs.Another posible testing strategy would be to interleave stores with an LFENCE. For example, store -> LFENCE -> load: historically changing this to LFENCE -> store -> load is okay, but from the perspective of speculative execution there is a difference between the two orderings.