On Mon, 31 Oct 2011, Nilay Vaish wrote:
On Mon, 31 Oct 2011, Nilay Vaish wrote:
On Mon, 31 Oct 2011, Nilay Vaish wrote:
The instruction in this context is the load part of a locked CMPXCHG. Its
sequence number is 8916. I kind of know what the control flow is.
Apparently Ruby already has some request that is aliased with this request
and the request is not serviced. The O3 CPU then starts squashing
everything and this instruction raises the assert. Given that this
instruction is a memory barrier, I am not sure why the load request was
issued in first place.
Apparently it is possible to speculatively issue memory operations that
appear after the memory barrier before the memory barrier is done with. In
the file src/cpu/o3/iew_impl.hh, instructions are checked first for being
loads, and then they are checked whether or not they are a barrier
instruction. Since the load portion of a CMPXCHG is a load and as well as a
barrier, it is never marked as barrier.
if (load) {
} else if (store) {
} else if (barrier) {
}
Has this behavior has been agreed upon before?
It seems to me that originally it was assumed that memory barrier will only
act as a barrier i.e. it will not do anything other than acting as a barrier.
But with x86 locked instructions, a load or a store also acts a barrier and
it is this behavior which the current implementation of the O3 cpu cannot
handle. Similarly, I think nonspeculative and memory barrier flags were
assumed to be exclusive of each other.
The more code that I read, the more murkier the situation looks. I think
unless we redo a major portion of instruction queue, iew and memory
dependence unit, it may not possible to impart an instruction semantics of
memory access as well as a barrier. What we can do instead is that where
ever ldstl and stul are used, we can have an mfence before and after the
microop. Since mfence it self does not perform any memory access, it
should work correctly with the current implementation of the O3 CPU. Also,
we can mark the microops ldstl and stul as nonSpec, so that once ldstl is
executed, it will never be squashed. But we do need to make sure that the
flags isLoad/Store and isNonSpec mix with each other correctly.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
