How is load->store reordering possible with in-order commit -- follow up

I would like to ask for some clarification about what discussed in this thread How is load->store reordering possible with in-order commit ? -- sorry I've not enough reputation to add comments directly there.

A load can't fault after you've checked the TLB and/or whatever memory-region stuff for it. That part has to be complete before it retires, or before it reaches the end of an in-order pipeline. Just like a retired store sitting in the store buffer waiting to commit, a retired load sitting in a load buffer is definitely happening at some point.

So the sequence on an in-order pipeline is:

lw r0, [r1] TLB hit, but misses in L1d cache. Load execution unit writes the address (r1) into a load buffer. Any later instruction that tries to read r0 will stall, but we know for sure that the load didn't fault.

With r0 tied to waiting for that load buffer to be ready, the lw instruction itself can leave the pipeline (retire), and so can later instructions.

So you're basically saying that lw instruction (or its micro-op) can retire even though, after it retires, the load itself can stay 'in flight' inside the load buffer (load queue) waiting for the data arrive from somewhere.

sw r2, [r3] store execution unit writes address + data to the store buffer / queue. Then this instruction can retire.

Probing the load buffers finds that this store doesn't overlap with the pending load, so it can commit to L1d. (If it had overlapped, you couldn't commit it until a MESI RFO completed anyway, and fast restart would forward the incoming data to the load buffer).

Here you are saying that when the store executes (or actually after it retires ?) it will search inside the load buffer to check if there is any older in-flight load waiting for data that happen to overlap with that store's target address.

Does it make sense ? Thank you.

Recommended topics

Hot tags