Hi, I am experiencing a problem from the "extra conservativeness" (a quote from the source code comment) of the memory order violation check.
Currently, it raises an ordering violation when a load is being executed and the following conditions are met 1. there is a newer load (e.g. lsq index is larger) whose effAddrValid == true 2. and (that newer load's effAddr) >> 8 == (load being executed effAddr >> 8) LSQUnit<Impl>::executeLoad @ src/cpu/o3/lsq_unit_impl.hh My problematic scenario is when a sequence of uncacheable loads to adjacent addresses are executed. (They are uops generated from a micro op but it doesn't seem to be related). Since they are uncacheable, the actual execution is postponed until they reach the head of the ROB. However, during their attempt to execute in IEW stage, the effAddrValid flag is set to true. When the first load reaches the head of the ROB, it tries to execute and detects there is a newer load, whose effAddrValid is true with the effAddr close enough to its own. Immediate solution I can think of is instead of using effAddrValid flag to determine a load is executed, use a separate flag (or is there already one?) to check if a load has been executed. This would solve this particular problem. Any other suggestion would be appreciated. My another concern (or question) is, why does it check (effAddr >> 8)? I assume it's a byte addressable and then it checks at least 256B: that's not a quad word (the comment says so), but a quad 64B cache lines amount of data - that would make any load reordering within 256B block cause a violation/squashing of the pipe. Shouldn't it check if the data two loads actually fetches overlap? Thanks, Min
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
