Background: I have a non-o3, out of order CPU implemented on gem5. Since I don't have a checker implemented yet, I tend to diff committed instructions vs o3. Yesterday's patches caused a few of these diffs change because of load-linked/store-conditional behavior (better prediction on data ops that write the PC leads to denser load/store scheduling).
Issue: It seems O3's own loads/stores can cause its load-linked/store-conditional pair to fail. Previously running a single core under SE, every load-linked/store-conditional pair would succeed. Now I'm observing them failing 21% of the time (on single-threaded programs). Although the programs functionally work given how the LL/SC is coded currently, I think this points to the fact LL/SC should be handled slightly differently. Example: >From "Hello World" on ARM+O3+Single Core+SE+Classic Memory that shows this. This contains locks because I assume the C++ library is thread-safe. http://pastebin.com/sNjTPBWY The O3 CPU is effectively doing a "Test and TestAndSet". It looks like the load for the Test and the load-linked for the race for memory. Also, the CPU has a pending writeback to the same line. So effectively, the TestAndSet fails (haven't dug into it to determine if it was the racing load or the writeback that caused the failure). Given this, shouldn't load-linked (in this case ldrex) instructions be marked as non-speculative (or one of the other flags) so that they don't contend with earlier operations? Thanks.
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
