[Mpi3-rma] MPI-3 UNIFIED model clarification

[Underwood, Keith D]

> On 07/29/2013 10:48 PM, Underwood, Keith D wrote:
> >> On 07/29/2013 10:18 PM, Underwood, Keith D wrote:
> >>> And, um, technically, if loads can be hoisted  across the MPI_Recv,
> >>> then the MPI_Recv semantics are incorrect and  you have to have a
> >>> memory barrier in MPI_Recv.
> >>
> >> Why is reordering not permitted for two unrelated memory loads?
> >> AFAIK, ARM allows that.
> >
> > I'm talking about a load of the data written for the MPI_Recv getting
> > hoisted across MPI_Recv.  There is no guarantee of anything in that
> > MPI_Recv actually touching the data being received.  There is no
> > guarantee of anything telling the microarchitecture that you are doing
> > an illegal hoist across that receive.
> 
> No, we are obviously not talking about data reordering for dependent data.
> In the example I gave, the recv of some other data is essentially a flag for me
> to tell that the origin has flushed some data to the target.  Here's the
> example again:
> 
> P0:
> Win_lock_all
> Put(a, P1)
> Flush
> MPI_Send(P1, flag)
> 
> P1:
> Win_lock_all
> MPI_Recv(P0, flag)
> read a
> 

Can you point to the line in there that tells the architecture that the read of A is not touched by MPI_Recv?  Let's say the data movement for MPI_Recv is done by a NIC or done by another core.  How can the microarchitecture tell the difference?